Skip to main content
Invoke: /feature-context AB#1234 (tracker) or /feature-context <your requirement> (direct) · Side effects: read-only · Writes: .shipflow/{id}/context.md
Turns a requirement — from a tracker work item or handed over directly — into a normalized, testable context document, establishing exactly what has to be true when the work is done and flagging anything ambiguous before a single line of code is written.

​
What it does

  1. Reads shipflow.config.md and the standing context (product.md, if present) to interpret the requirement in the product’s own terms — and also reads any existing CLAUDE.md, AGENTS.md, .cursorrules, or .github/copilot-instructions.md at the repo root, which document conventions and hard rules with zero setup, distinct from shipflow’s own ratified product.md.
  2. Resolves the source. A work-item reference (AB#1234 / PLAT-567) → tracker: read through the connected MCP server for your provider (never raw REST; if the MCP isn’t connected it says so plainly rather than fabricating content). No reference but a requirement given inline or as a local .md file → direct: the message body is the requirement, no MCP call, {id} is a kebab slug prefixed by requirements.direct.id_prefix.
  3. For tracker, pulls title, description, acceptance criteria, current state, and links (parent, related, existing PRs) — keeping the original wording; it normalizes a copy.
  4. Rewrites the acceptance criteria as atomic, testable statements, numbered AC1, AC2, … — splitting compound criteria, preserving measurable thresholds verbatim. It records provenance: from source (tracker item, or ACs you supplied inline) versus proposed (direct source with no ACs given — shipflow proposes them and will not act until you confirm). It never invents coverage the source stated, and never acts on proposed ACs unconfirmed.
  5. Grounds it locally: current branch, the likely area of the codebase, test framework signals. In polyrepo, notes which configured repos are likely touched (a first read — feature-plan commits to the actual set).

​
Clarifications, not assumptions

Ambiguous or contradictory requirements, or an AC that isn’t testable, become a clarifications needed list carried back to you — never resolved by guessing.

​
Gate

This phase is gated by governance.gates.after_context — the orchestrator pauses here for you to confirm the requirement was read correctly before planning begins. In direct mode where the ACs were proposed (you gave a requirement but no criteria), this gate is mandatory regardless of config: the flow will not continue until you confirm or edit the proposed ACs.