feature-implement (Phase 3)

Executes the approved plan on a branch, task by task, with conventional commits. Never pushes.

Invoke: /feature-implement AB#1234 · Side effects: branch + commits, never pushes · Reads: plan.md, tasks.md

What it does

1. Branches using git_conventions.branch.pattern (feature/{id}-{slug}) off git_conventions.branch.base. Polyrepo: branches in each touched repo, off that repo’s own base, same branch name and work-item reference across all of them.
2. Works through tasks.md task by task — matching the surrounding code’s conventions and the house rules in product.md, keeping each change scoped to its task (new necessary work becomes a new tagged task, not scope creep on an existing commit).
3. Commits with the conventional subject pattern ({type}: {summary} ({provider_ref})) — at least one commit carries the work-item reference so the tracker auto-links.
4. Ticks off tasks and updates .shipflow/{id}/state.json as it goes (per-repo in polyrepo), so a resume knows exactly where it left off.

Hard git rules — never violated

No co-author trailer, no “generated-by”/“Co-Authored-By” trailer on any commit — the author is the human. No plain --force. Never rewrite history on a base branch.

Boundaries

Does not push (push_to_remote is never_autonomous) and does not open a PR or touch the work item’s tracker state — those belong to feature-pr, and only with explicit approval.