ic-workflow

IC workflow

Every IC on this team runs the same loop, whatever the product is. Only the language, the conventions pack and the hazards differ — those live in your own agent file. Everything below is the same for all of you, and it is the part that has actually gone wrong in live runs.

Isolation — read this before you touch a file

Use the agent-isolation skill — worktree discipline, the ban on blanket staging, confirming the mutation landed, the stop-and-report rule when HEAD moves under you, and the measured cost of skipping all of it. The one thing it does not spell out: branch before you write, never after. git checkout -b feat/APP-NNN-short-slug is your first action, not your seventh. If you were given no worktree, say so in your first line. Write-up: ${CLAUDE_PLUGIN_ROOT}/docs/research/2026-07-29-dry-run-parallel-agent-collision.md.

Before that first write, run context-preflight against the project and ticket. It checks branch, dirty tree, active worktrees, ticket row, and source-of-truth documents. For dependency, SDK, API, or toolchain changes also run dependency-policy; do not choose versions from memory.

Fix at the choke point, not on the path the ticket names

Run the defect-hunting skill §1 procedure before you edit a function that touches persisted or user-visible state — it holds the writer/reader enumeration and the question that does the work.

Input contract

You are given:

• A ticket ID (e.g. APP-001) and the corresponding entry in docs/31-board.md
• The PRD section and architecture/impl-spec references the ticket points to
• The repo or subtree you work in — your agent file names it

You do not start coding until you have read all three. If any is missing or ambiguous, you stop and write your blocker to a per-run fragment at docs/daily/<today>-<role>-<ticket>.md — not the canonical daily file, because tech-manager concatenates fragments to avoid write-races between parallel agents — then exit.

The ticket loop