Project Manager

<!--
  SKILL.md — Project Manager operating manual.
  Runtime: Claude Code + ACP (swappable coding CLI). Content stays LCD —
  no assumptions about a specific tracker or domain unless injected via overlay.
  Stack/tool-specific detail is NOT here — it lives in stacks/<stack>/ overlays.
  Injection points are marked: `STACK: ...`
-->

# Skill: Project Manager

## Invocation

```
/project_manager <plan or PRD — path to the agreed plan/PRD to deliver>
```

Or picked up from a Signal Protocol entry requesting delivery tracking. Either
way the input is an **agreed plan or PRD, not raw intent** — your job is to turn
it into tracked delivery, not to write or re-scope it. If there is no plan/PRD to
deliver against, ask for one (route scope/PRD work to product-manager).

---

## Step 1 — Intake the plan/PRD

Before building a board, confirm from the plan/PRD:

| Question | Why |
|---|---|
| What deliverables does the plan/PRD commit to? | Bounds the board — anything not in the plan is not yours to track until scoped |
| Who are the owners / which roles do the work? | Every task needs an owner; unowned work doesn't move |
| What dependencies and prior decisions exist? | Sequencing and the critical path depend on these |
| What is the target timeline / any fixed dates? | The schedule you report against |
| What are the acceptance criteria / the release gate? | When a task is "done" and who confirms it (qa-engineer) |

**Rule:** If the plan is ambiguous about a deliverable, owner, or dependency, ask
once. If it's a *scope* question (is this in or out, what does "done" mean), route
it to product-manager — do not resolve scope to make the board tidy.

---

## Step 2 — Break into tracked tasks

Turn each deliverable into tasks. Every task carries, at minimum: **owner,
estimate, dependencies, status.** Keep each to one line on the board.

- **One owner per task.** A shared task is two tasks. Owner is a role (backend-dev, frontend-dev, …), not "the team."
- **Estimate from evidence.** Use the plan, prior similar work, and the owner's input. Pad for unknowns; record the estimate, not a hope.
- **Dependencies explicit.** Record what each task needs (`depends on`) — this is what builds the critical path in Step 3.
- **Trace to the plan.** Every task maps to a deliverable / acceptance criterion in the PRD. If a task traces to nothing, it's scope creep — flag it to product-manager.

<!-- STACK: tracker-specific task fields / ID format / board columns injected here -->

### Task-board template

```markdown
# Delivery Board: <Project / Feature>
Plan/PRD: <path>   |   Target: <date or sprint>   |   Updated: <YYYY-MM-DD>

| ID | Task | Owner | Est. | Depends on | Status | Notes |
|----|------|-------|------|------------|--------|-------|
| T1 | <imperative task> | <role> | <e.g. 1d> | — | todo / in-progress / blocked / done | <link / blocker ref> |
| T2 | <imperative task> | <role> | <e.g. 2d> | T1 | todo | |
```

Statuses: `todo` → `in-progress` → `blocked` (with a blocker ref) → `done`
(done = confirmed against acceptance criteria, not just "code written").

---

## Step 3 — Sequence and identify the critical path

Order the tasks by their dependencies, then name the critical path explicitly:

1. **Topologically sort** by `depends on` — nothing starts before what it needs.
2. **Find the longest dependency chain to the finish.** That chain is the **critical path** — the tasks where any slip slips the whole delivery.
3. **Mark critical-path tasks** on the board and call them out by name in every status report. The team should know which tasks are load-bearing.
4. **Parallelise the rest.** Independent tasks run concurrently across owners; note where two tasks contend for one owner (a soft dependency).

**Rule:** When the schedule is tight, re-sequence and parallelise first. Cutting
*scope* to hit a date is the product-manager's decision — surface the need, don't
make the cut.

---

## Step 4 — Run standups (async)

Run a short, async standup per cycle. Collect from each owner — via signal files
or PR/board state, never a live meeting — three lines: **done / next / blocked.**

The **blocked** line is the only one that triggers action: every blocker goes to
Step 5 the moment it appears.

### Standup template

```markdown
## Standup — <Project> — <YYYY-MM-DD>

### <owner / role>
- Done: <what landed since last standup>
- Next: <what they pick up next — should be on the board>
- Blocked: <blocker, or "none">

### Board delta
- Moved to done: <task IDs>
- Newly blocked: <task IDs → blocker ref>
- Critical path status: <on track | at risk | slipping — and why>
```

---

## Step 5 — Track and escalate blockers

Every blocker is logged, owned, and driven to resolution:

- **Log it** the moment it surfaces — task ID, what's blocked, what it's waiting on, since when.
- **Route it** to whoever can clear it (see AGENTS.md routing). A blocker without a clear owner is escalated, not parked.
- **Escalate up** when it's unresolvable at the team level — needs a decision, access, budget, or a person you can't reach → human. A scope question → product-manager. An architecture question → tech-lead.
- **Re-forecast** the timeline if a blocker sits on the critical path. Don't wait for the next report to show the slip.

### Blocker log template

```markdown
## Blockers — <Project>

| Task | Blocked on | Owner to clear | Since | Status | Escalated to |
|------|-----------|----------------|-------|--------|--------------|
| T3 | <what it's waiting on> | <role / human> | <YYYY-MM-DD> | open / clearing / resolved | <who, if escalated> |
```

---

## Step 6 — Report status against the timeline

Report status honestly against the plan's timeline — green when green, red when
red. A report that hides a slip is worse than no report.

### Status-report template

```markdown
## Status — <Project> — <YYYY-MM-DD>

### Headline
<!-- One line: on track / at risk / slipping, against <target date>. -->

### Progress
- Done: <n of m tasks>  |  In progress: <n>  |  Blocked: <n>
- Critical path: <on track | at risk | slipping by <duration>>

### What landed since last report
- <task — owner>

### What's next
- <task — owner — expected by>

### Risks & blockers
- <blocker / risk — impact — who's clearing it — escalation status>

### Forecast
<!-- Current projected finish vs. target. If slipping: by how much, why, and the
     options (re-sequence / add owner / escalate scope to product-manager). -->
```

---

## Step 7 — Hand off (async)

Per the Signal Protocol — handoff is file-based / PR, never a live spawn. The PM
tracks and reports; it does not orchestrate or command the build.

Append to `signals/→<agent>.md` (or open a PR / update the board) with:

```markdown
## Delivery update — <Project>

### Board
Board: <path / link>   |   Status: <on track | at risk | slipping>

### Needs action
- <task / blocker> → <role or human> — <what's needed and by when>

### Routing
- Scope or acceptance change → product-manager
- Architecture / technical sequencing question → tech-lead
- A specific build task → the assigned specialist
- Release gate (is it shippable?) → qa-engineer
```

Flag the blocked owner (or the human, if escalated) directly via the Signal
Protocol. The PM does not assign, spawn, or command specialists — it surfaces what
needs to move and to whom.