Critical path analyzer · free AI skill

Analyzes a task and dependency list to compute the critical path, identify float on every task, flag near-critical chains, and surface schedule risks with a prioritized set of actions to protect or compress the…

Purpose

Compute the critical path and float for every task in a program schedule, then surface which tasks actually gate the delivery date and where slack exists to absorb slips or reallocate resources. Turns a raw dependency list into a defensible answer to "what is driving our date, and what can we safely delay?"

When to Use

Invoke this skill when the user asks to:

Find the critical path in a project or program schedule
Determine which tasks have float/slack and how much
Diagnose why a hardware milestone (EVT/DVT/PVT, tapeout, tooling, mass production) is slipping
Decide where to add resources or run tasks in parallel to compress the timeline
Identify near-critical chains that could become the new bottleneck
Convert a task/dependency dump into a schedule risk assessment

Inputs Required

Before starting, collect:

Task list: Each task with an ID or name and a duration (days, weeks, or sprints)
Dependencies: Predecessor/successor relationships (Task B depends on Task A). Note dependency type if known — Finish-to-Start, Start-to-Start, Finish-to-Finish
Target/committed date: The milestone date the program is driving toward
Project start date or "day 0" reference: When work begins (or "today" for a mid-flight analysis)
Methodology context: Waterfall (fixed durations) or Agile (sprint-based / rolling estimates)
Fixed constraints: Any external dates — supplier lead times, tooling readiness, certification windows, factory booking slots
Current progress (optional): % complete or actual finish dates for tasks already started

If durations are given without units, assume the most common unit used across the list and state the assumption. If dependency types are omitted, default to Finish-to-Start.

Instructions

Step 1: Normalize the Schedule Data

Build a clean task table before any calculation:

Assign each task a stable ID
Confirm every task has a duration in one consistent unit
List each task's direct predecessors
Flag any task with no predecessor (a start node) and any with no successor (an end node)
Flag orphan tasks (no links in or out) and circular dependencies — these must be resolved before analysis and should be surfaced to the user immediately

Step 2: Forward Pass — Early Start / Early Finish

Walk the network from start to end:

Early Start (ES) of a start node = day 0 (or project start date)
Early Finish (EF) = ES + duration
For any task with predecessors, ES = the latest EF of all its predecessors
Adjust for dependency type (Start-to-Start uses predecessor ES; Finish-to-Finish aligns EFs)
The project's earliest possible finish = the maximum EF across all end nodes

Step 3: Backward Pass — Late Start / Late Finish

Walk the network from end to start:

Late Finish (LF) of each end node = the project's earliest finish (or the target date if the target is later and being tested for feasibility)
Late Start (LS) = LF − duration
For any task with successors, LF = the earliest LS of all its successors

Step 4: Compute Float and Identify the Critical Path

For every task:

Total Float = LS − ES (equivalently LF − EF)
Tasks with zero total float form the critical path — the longest dependency chain determining the finish date
Also compute Free Float = (earliest ES of successors) − EF, i.e., how long a task can slip without delaying any successor
If multiple chains have zero float, report all of them (parallel critical paths)

Step 5: Feasibility Check Against Target Date

Compare the computed earliest finish to the committed target date
If earliest finish ≤ target: report the buffer (project-level float) in days
If earliest finish > target: report the overrun and mark the program as at-risk, quantifying the gap

Step 6: Near-Critical and Risk Flagging

Flag every task whose total float is at or below a threshold (default: ≤ 10% of the critical path length, or ≤ 5 days for short programs) — these are near-critical and likely to become the bottleneck if a critical task recovers
Flag tasks tied to external fixed constraints (supplier lead time, tooling, certification) even if they show float — real-world hardware constraints override paper float
Flag any single task whose slip would move the finish date most (highest sensitivity)

Step 7: Compression and Mitigation Options

For the critical path specifically, propose concrete levers ranked by leverage:

Fast-tracking: Which sequential critical tasks could run in parallel, and the added risk of doing so
Crashing: Which critical tasks would benefit most from added resources (best duration reduction per unit of cost/headcount)
Scope/sequence changes: Tasks that could be deferred, split, or de-risked with early prototypes
Absorb from float: Where free float on non-critical tasks can free up people for critical work State for each option: which task it affects, expected days saved, and the primary risk introduced.

Output Format

Structure: Task table first, then critical path, then risk flags, then mitigation actions
Length: 700–1,100 words plus the task table
Format: A table for the task-level results (Task ID, Name, Duration, ES, EF, LS, LF, Total Float, Free Float, On Critical Path Y/N); prose and ranked lists for analysis and mitigation
Sections: Schedule Summary → Task/Float Table → Critical Path → Feasibility vs. Target → Near-Critical & Constraint Flags → Ranked Mitigation Actions
Tone: Program manager reviewing a schedule with leadership — precise, quantitative, decision-oriented; leads with what drives the date and what to do about it

Quality Checklist

Before delivering output, verify:

[ ] Every task in the input appears in the table with ES, EF, LS, LF, and both float values
[ ] The critical path consists only of tasks with zero total float, and forms an unbroken chain from a start node to an end node
[ ] The computed earliest finish is explicitly compared to the target date with a numeric buffer or overrun
[ ] Any circular dependencies, orphan tasks, or missing durations are called out rather than silently guessed
[ ] Near-critical tasks are flagged against a stated float threshold, not by intuition
[ ] Each mitigation action names the affected task, expected days saved, and the risk introduced

Notes

On hardware programs the paper critical path is often not the real one — supplier lead times, tooling, and certification windows frequently gate the date regardless of internal float. Always cross-check computed float against fixed external constraints.
In Agile contexts, treat sprint capacity as the duration unit and re-run the analysis when velocity estimates change; the critical path can shift sprint-to-sprint.
Zero float is fragile: a program with many parallel critical paths has no margin anywhere. When multiple chains tie, prioritize buying back float on the chain with the most external dependencies.
The highest-value output is usually not the critical path itself but the near-critical chain — that is where the next slip comes from.

How to use this skill

This file is a Claude Code skill in Anthropic's standard format — markdown with YAML frontmatter at the top.

Installing in Claude Code:

~/.claude/skills/<folder-name>/SKILL.md — auto-loads in every session anywhere on your machine (recommended for skills you'll use across multiple projects)
<your-project>/.claude/skills/<folder-name>/SKILL.md — auto-loads only when working in that project (recommended for project-specific skills)

Restart Claude Code or open a new session to register.

Using in Claude.ai, ChatGPT, Gemini, or other AI tools:

Drag this file into a new chat, or copy and paste its contents
Send your task or request as your next message — the AI will apply the skill where it fits

For Claude Code skill details: https://docs.anthropic.com/en/docs/claude-code/skills