shipflow.config.md is created from shipflow.config.example.md the first time you run init.
It’s meant to be committed — the whole team shares one config, and every skill treats it as
authoritative: if a rule here conflicts with a skill’s default behavior, the config wins.
requirements
Where a requirement comes from. shipflow accepts two sources, resolved automatically from your message: a tracker work item (read via the connected MCP server, never raw REST) or a direct free-text requirement given inline or as a local.md file.
Direct mode keeps shipflow’s spine. If you supply acceptance criteria inline they’re used as-is;
if you don’t,
feature-context proposes atomic ACs and forces the after_context gate so a
human confirms them — shipflow never silently invents ACs. A direct-mode PR carries no tracker
link-back, which is expected rather than a defect.context
The path to your standing “constitution” doc — see Product Context.code_host
Where PRs get opened, and which CLI does it.repos
Empty by default (single-repo mode). Populate this for polyrepo — see the dedicated Polyrepo guide before touching this section.git_conventions
Branch pattern, commit style, and the hard rules every skill that writes git history must follow.Hard rules, not defaults: no co-author trailer, no “generated-by” trailer, no plain
--force (only --force-with-lease after explicit approval), and the base branch is never
rewritten. These aren’t configurable away — they’re enforced by every phase skill.linking
How code links back to the work item so the tracker graph stays honest.tests
repos[].tests.{framework,run_command} if it uses a different stack.
governance
The human-in-the-loop gates — the part of the config most worth reading carefully before your first run.never_autonomous is not just a default — pushing, opening the PR, updating tracker state, and
merging always need a human, regardless of how the gates above are set.
workspace
Where shipflow keeps its per-work-item scratch files. Add this directory to.gitignore.
state.json is what makes a run resumable — in polyrepo, it tracks branch, commit progress, test
result, and PR URL per touched repo.