원클릭으로
select-feature
Score and select the next backlog feature by value, effort, and dependencies
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
메뉴
Score and select the next backlog feature by value, effort, and dependencies
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | select-feature |
| description | Score and select the next backlog feature by value, effort, and dependencies |
| version | 1.0 |
| author | product-owner |
| audience | product-owner |
| workflow | feature-lifecycle |
Select the next most valuable, unblocked feature from the backlog using a lightweight scoring model grounded in flow economics and dependency analysis.
Research basis: Weighted Shortest Job First (WSJF) — Reinertsen Principles of Product Development Flow (2009); INVEST criteria — Wake (2003); Kano model — Kano (1984); Dependency analysis — PMBOK Critical Path Method. See docs/research/requirements-elicitation.md.
Core principle: Cost of Delay ÷ Duration. Features with high user value and low implementation effort should start first. Features blocked by unfinished work should wait regardless of value.
Load this skill when WORK.md @state is [IDLE] (or no active item) — before moving any feature to in-progress/.
ls docs/features/in-progress/
1 files → WIP violation; stop and resolve before proceeding
Read each .feature file in docs/features/backlog/. Check its discovery section for Status: BASELINED.
@product-owner with skill define-scope to baseline the most promising backlog item firstIMPORTANT
NEVER move a feature to in-progress/ unless its discovery section has Status: BASELINED. Only the PO may move .feature files — no other agent ever creates, edits, or moves them.
For each BASELINED feature, fill this table:
| Feature | Value (1–5) | Effort (1–5) | Dependency (0/1) | WSJF |
|---|---|---|---|---|
<name> | Value ÷ Effort |
Value (1–5) — estimate user/business impact:
Use the number of Must Examples in the feature's Rule: blocks as a tiebreaker: more Musts → higher value.
Effort (1–5) — estimate implementation complexity:
@id Examples, no new domain concepts@id Examples, one new domain entity@id Examples or cross-cutting concernDependency (0/1) — does this feature assume another backlog feature is already built?
A Dependency=1 feature is ineligible for selection regardless of WSJF score. Apply WSJF only to Dependency=0 features.
Pick the BASELINED, Dependency=0 feature with the highest WSJF score.
Ties: prefer higher Value (user impact matters more than effort optimization).
If all BASELINED features have Dependency=1: stop and resolve the blocking dependency first — select and complete the depended-upon feature.
mv docs/features/backlog/<name>.feature docs/features/in-progress/<name>.feature
Update WORK.md — add (or replace) the active item block:
## Active Items
@id: <name>
@state: [STEP-1-DISCOVERY] or [STEP-2-READY] — whichever is next
@branch: [NONE]
Rule: blocks yet → @state: STEP-1-DISCOVERY; Run @product-owner — load skill define-scope and write storiesRule: blocks but no @id Examples → @state: STEP-1-CRITERIA; Run @product-owner — load skill define-scope and write acceptance criteria@id Examples → @state: STEP-2-READY; Run @software-engineer — load skill version-control and create feat/<name> branchgit add docs/features/in-progress/<name>.feature WORK.md
git commit -m "chore: select <name> as next feature"
in-progress/ confirmed empty before selectionin-progress/WORK.md updated with correct @stateStep 2 — Architecture and domain design, one feature at a time
Step 1 — discover requirements through stakeholder interviews and write Gherkin acceptance criteria
Generate and update architecture diagrams, living glossary, and system overview from existing project docs
Enforce code quality using ruff, pytest coverage, and static type checking
Create pull requests with conventional commits, proper formatting, and branch workflow
Flow protocol — design and operate state machine workflows with FLOW.md + WORK.md