> ## Documentation Index
> Fetch the complete documentation index at: https://kowshik-93.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# feature-context (Phase 1)

> Establishes a normalized, testable requirement — from a tracker work item or a direct requirement — and grounds it in your repo. Read-only.

<Info>
  **Invoke:** `/feature-context AB#1234` (tracker) or `/feature-context <your requirement>` (direct)
  · **Side effects:** read-only · **Writes:** `.shipflow/{id}/context.md`
</Info>

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](/shipflow/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.