task-next

name	task-next
description	Start the next implementation task for the active project. Reads the project's task doc, picks the next unblocked card, loads only the referenced spec anchors, states non-negotiables, presents a plan, and executes after user confirmation.

task-next — Start the next task

You are starting a new implementation task. This skill works for ANY project — it detects the active project from the branch name or program-plan.csv, then reads that project's task doc.

When invoked within /execute autonomous loop: Skip plan presentation (Step 4). Go straight from context loading to implementation. Do NOT ask "proceed?".

Project detection

Determine the active project from (in priority order):

1. User argument — if the user passed a project name or task ID (e.g. /task-next sf-private-apps or /task-next SF-1.3), use that.
2. Branch name — match branch against program-plan.csv branch column. If branch is feat/sf-private-apps → project is sf-private-apps. If feat/segmenter → Segmenter. If feat/bb3-* → BB-3. If feat/si-billing → SI Billing.
3. program-plan.csv — find the project with status: executing.
4. Ask — if ambiguous, ask which project.

Project sources

ADF projects (under docs/projects/<name>/):

Source	Path
Task doc	docs/projects/<name>/tasks.md
Architecture	docs/projects/<name>/architecture.md
Tracker	docs/projects/<name>/tracker.csv
Non-negotiables	architecture.md §12 or task doc Ground Rules

Legacy pipeline modules (predating ADF directory structure):

Module	Task doc	Design spec	Non-negotiables source
Segmenter	docs/MIGRATION-SEGMENTER-TASKS.md	docs/MIGRATION-SEGMENTER-DESIGN.md	Task doc "Non-negotiables" section
BB-3 Normalizer	docs/MIGRATION-PLANNER-BB3-TASKS.md	docs/MIGRATION-PLANNER-BB3-DESIGN.md	CLAUDE.md "BB-3 non-negotiables" section
SI Billing	docs/SI-BILLING-TASKS.md	docs/SI-BILLING-SPEC.md	Task doc "Non-negotiables" + "Key design decisions" in Ground Rules

Step 1 — Pick the task

If the user passed a task ID, use that.

Otherwise, find the next unblocked task:

1. Read the module's task doc — look for the phase/inventory section.
2. Check git log --oneline --all | grep -oE 'Task: [A-Z0-9.-]+' to see which task IDs are already committed.
3. Identify the lowest-numbered task whose dependencies are all merged AND which is not yet implemented.
4. If multiple candidates exist, prefer the one in the current phase.
5. Show the user the candidate and wait for confirmation before proceeding.

Step 2 — Load task context (NARROWLY)

Once the task is chosen:

1. Read ONLY that task card from the task doc — use grep -n "### <TASK-ID>" to locate it, then Read with offset/limit.
2. Read ONLY the spec sections the card cites (e.g. §5.2, §8.1) — NOT the whole design spec.
3. Read ONLY the files the card lists under "Files".
4. If the task touches existing code, read the existing files.

Do NOT speculatively read unrelated sections. Context is precious.

Step 3 — Quote the non-negotiables

Print to the user:

• Module + Task ID + title
• Non-negotiables (from the module's task doc or CLAUDE.md, verbatim)
• Files to touch (list)
• Test coverage required (from the card)
• Effort estimate

Step 4 — Present the plan

Before writing any code:

1. For effort L or XL tasks: enter plan mode or use the Plan subagent.
2. Lay out the implementation as ordered steps.
3. Identify edge cases — cross-reference the design spec's edge-cases section.
4. State which tests you will write FIRST.
5. Ask the user "proceed?" and WAIT for confirmation.

Step 5 — Execute

After confirmation:

1. Write tests first where the taxonomy allows.
2. Implement the code.
3. Run file-level tests as you go.
4. Do NOT invoke /ship-it yourself unless the user has explicitly pre-authorized it.

Module-specific invariants

Segmenter invariants (from MIGRATION-SEGMENTER-TASKS.md)

• Determinism: same graph + options → byte-identical assignment + manifest. All sorting uses strict </>, never localeCompare. runtimeStats excluded.
• No silent fall-through: unknown edge types throw. Missing structural-edge targets throw.
• Thin dependencies: @revbrain/migration-segmenter depends on @revbrain/migration-ir-contract + zod only. No cross-package imports from bb3-normalizer.
• All thresholds injectable via SegmenterOptions, validated by Zod.
• Content-addressable IDs: length-prefixed streaming hash. base64url. Never truncate.

BB-3 invariants (from CLAUDE.md)

• RCA neutrality: no CPQ-target concept names in normalizer sources.
• Determinism: no Date.now(), Math.random(), etc. in graph-affecting code.
• canonicalJson only in identity/hash paths.
• NodeRef, not string[] for node references.
• No wall-clock timeouts on parsers.
• Contract package stays thin.

SI Billing invariants (from SI-BILLING-TASKS.md Ground Rules)

• State machine is pure (no I/O): agreement + milestone state machines validate and return updates. Route handlers do persistence, Stripe, and email.
• Acceptance + Stripe is atomic: if Stripe invoice creation fails during acceptance, the entire operation rolls back. No "accepted but no invoice" state.
• ≤$500K compute-only: proceed-migration for ≤$500K returns computed terms without persisting. Value, SOW, and milestones persist only on accept-migration.
• Assessment fee IS the floor: no separate floor_amount. All monetary math in integer cents + integer bps. No floating point.
• paid_via guards: milestones with paid_via = carried_credit MUST NOT create Stripe invoices. Reconciliation excludes them from cash sums.
• Immutable accepted terms: once accepted, an agreement's assessment_terms_snapshot and migration_terms_snapshot are never modified. Amendments create a new version.
• Overdue reminder dedupe: per-milestone timestamps prevent duplicate sends.
• i18n: every UI string in both en/*.json and he/*.json. Use start-*/end-* CSS, never left-*/right-*.

Step 6 — Task is done when...

1. Every acceptance checkbox on the card is satisfied.
2. Every required test type is written and passing.
3. /ship-it has run green.

What NOT to do

• Do NOT load entire design specs into context. Load only cited sections.
• Do NOT write code before presenting the plan and getting confirmation.
• Do NOT skip tests.
• Do NOT mark a task done without /ship-it green.
• Do NOT deviate from the spec silently.