메뉴
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 직업 분류 기준
Explicitly invoked deterministic status report for the Oparax outreach record store. Never invoke implicitly.
Explicitly invoked Oparax workflow for logging X-contacted reporters into the fixed LeanSpark experiment. Never invoke implicitly.
Explicitly invoked Oparax workflow for checking new queued X accounts once to determine whether they can receive DMs. Never invoke implicitly and never use for unavailable-account rechecks.
Explicitly invoked Oparax workflow for sending already-prepared X DMs sequentially until the queue ends or X refuses a send. Never invoke implicitly.
Explicitly invoked Oparax workflow for rechecking every previously unavailable X account and resolving it as available or invalid. Never invoke implicitly and never use for new-contact checks.
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 dev 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 dev.
Hard rules: never push to main/beta; ship target is dev only; no PRs, no CI.