القائمة
Phases 4–5 of the feature flow, standalone: the triage + ship gates. Use when the user says /feature-ship, "ship it", "close the slice", or brings manual-test findings on a finished branch.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Resolve residual Biome lint findings on a feature branch's changed files — the rules `biome check --write` can't safely auto-fix. Invoked by /feature-qc as its final pass; also runnable standalone on a branch (/feature-lint). NOT for a one-off lint of a single file — run `pnpm lint:fix` directly for that.
Phase 1 of the feature flow, standalone: the plan gate (the plan is the spec). Use when the user says /feature-plan, "plan this feature", "spec this out", or wants a plan gate without committing to the full flow. Not for building — that is /feature-build.
Phase 3 of the feature flow, standalone: the full QC battery over the current feature branch. Use when the user says /feature-qc, "run QC", "quality pass", or wants the branch proven buildable+bootable mid-flight. For just one pass, use /simplify, /code-review, or /feature-lint directly instead.
The end-to-end feature flow: plan → build → QC → triage+ship, run as one guided sequence. Use when the user wants a full slice built from idea to shipped commit. For a single phase, use the granular skills directly: /feature-plan, /feature-build, /feature-qc, /feature-ship (or /simplify, /code-review, /feature-lint for individual QC passes).
Phase 2 of the feature flow, standalone: implement the approved plan from the ft/N issue (or a directly-stated small build) with parallel implementers, a fast per-task typecheck gate, and deep review reserved for the foundational task. Use when the user says /feature-build, "build the plan", "implement the tasks", or "just build X" mid-flight on a feature branch.
| name | feature-ship |
| description | Phases 4–5 of the feature flow, standalone: the triage + ship gates. Use when the user says /feature-ship, "ship it", "close the slice", or brings manual-test findings on a finished branch. |
| argument-hint | [issue#] |
| allowed-tools | Bash(git *) Bash(gh *) Bash(pnpm *) |
| model | inherit |
For each finding the user reports, exactly one label:
feature-lint + the boot smoke.
Not DoD-breaking → not fix-now, however tempting..claude/skills/feature/scripts/backlog-add.sh "<item> — <context>; origin #<issue#>; <next slice | someday>[; · agent]". Lead the line's context with
whether it's a likely next slice or someday, and add · agent when the agent's
own analysis surfaced it (plain when scribing the USER's own deferral).Loop test → triage → fix-now until no fix-nows remain. See AGENTS.md → "Issue labels" for the full taxonomy and the single-living-backlog rule.
GATE ✋: ask in plain words — "Ready to ship, or more to fix first?" A green build is never permission. Only their explicit "ship it" advances.
First, preserve the plan's Deferred. ship.sh closes the feature issue, so its
## Deferred section dies with it — migrate those items into the single living backlog
first. For each still-relevant Deferred item (skip any this slice ended up addressing),
append one line: .claude/skills/feature/scripts/backlog-add.sh "<item> — <why deferred>; origin #<issue#>". This is the one point where plan-Deferred graduates from the closing
feature issue into the durable backlog.
From the repo root, on ft/<issue#>:
.claude/skills/feature/scripts/ship.sh <issue#> "<feature summary>"
It refuses on wrong branch / stray flow worktree; folds any uncommitted tree
changes on the branch into the squash (your approved manual edits — deletions,
tweaks — belong to this same-branch slice); squash-merges to main as ONE commit;
pushes; deletes the branch; closes the issue (the permanent record); sweeps scratch
(.feature/, legacy .superpowers/) and the empty worktree mount; leaves the repo
on main.
Hard rules: ship target is main, via ship.sh's squash-merge only; no PRs, no CI.