work-on-feature

name	work-on-feature
description	Automatically execute all Tasks in a Feature. Creates an Agent Team with Worker/Verifier teammates, enables bidirectional communication via SendMessage, and handles Review & Refactor. Triggers: 'work on feature', 'feature 진행', 'feature 실행', '피처 진행', 'run feature'

Work on Feature

Automatically execute all Tasks in a Feature — creating an Agent Team with Worker and Verifier teammates, coordinating via bidirectional messaging, running reviews, verifying quality, and recording lessons.

When to Use

• When a Feature has Tasks ready to execute (backlog status)
• User wants automated end-to-end Feature execution
• Tasks have been planned (/sprint:plan-backlog) or are self-explanatory

Prerequisites

Sprint folder with:

• BACKLOG.md - Feature with Tasks defined
• HANDOFF.md - Current status
• INSTRUCTION.md - Agent guidelines
• personas/ - Persona files
• active/ - Feature context
• refs/ - Reference documents

---

Architecture: Agent Teams

This skill uses Agent Teams (TeamCreate) instead of standalone Sub-Agents.

Lead (you)
├── TeamCreate("feature-F-{slug}")  ← creates team + shared task list
├── Agent(team_name, name)          ← spawns teammates into the team
├── SendMessage(to: name)           ← bidirectional communication
└── TaskCreate/TaskUpdate           ← shared task board coordination

Why Agent Teams:

• Bidirectional messaging — Lead ↔ Worker ↔ Verifier can communicate freely via SendMessage
• Shared task board — All teammates see the same TaskList, claim work, update status
• Persistent teammates — Workers stay alive across review cycles (no respawn overhead)
• Peer collaboration — Teammates can message each other directly when needed

---

Workflow

Step 1: Context Loading

Read these files:

File	Purpose
BACKLOG.md	Feature's Task list, statuses, dependencies
refs/designs/F-{slug}.md	Feature design (goals, type, scope)
refs/plans/F-{feature-slug}-T-*.md	Task plans (if exist)
refs/lessons/*.md	Existing lessons for Worker prompts
personas/*.md	All persona files (for matching)
active/F-{slug}.md	Feature context (if exists)

Parse Feature Tasks:

• Extract all Tasks under the target Feature
• Identify the Review & Refactor Task (always last non-merge Task)
• Separate: regular Tasks vs. R&R Task vs. merge Task (worktree mode)

Resume detection: Check Task statuses for resume scenario:

Status	Action
done	Skip
backlog	Normal execution
in_progress	Reset to backlog, rework from start
review	Skip to Verifier Agent (work already done)
blocked	Stop immediately. Report: "T-{task-slug} is blocked. Resolve and re-run."

---

Step 2: Briefing (Optional)

Ask the user:

This Feature has N Tasks:
- T-{task-slug}: ...
- T-{another-slug}: ...
- T-review-{feature-slug}: Review & Refactor {Feature Name}

Would you like a detailed explanation before proceeding?
1. Yes → /explain briefing
2. No → proceed to execution plan

If Yes: invoke /explain:explain with Feature design doc and Task list as context.

---

Step 3: Execution Plan

3a: Persona Matching

For each Task (excluding R&R):

1. Read Task description, type (from Feature Design), and plan (if exists)
2. Read all personas/*.md files — check traits.domain, traits.decision_style
3. Match Task to best persona:

Signal	Persona Match
Task type coding + backend keywords (API, database, server)	Check personas with domain: backend
Task type coding + frontend keywords (UI, component, CSS)	Check personas with domain: frontend
Task type coding + fullstack/prototype keywords	Check personas with domain: fullstack
Task type coding + infra/deploy/migration keywords	Check personas with domain: infra
Task type ideation or discussion	Check personas with domain: discussion
Task type docs or general	Analyze content, pick closest domain match

R&R Task always uses thorn.

3b: Dependency Analysis

For Tasks with plans (refs/plans/F-{feature-slug}-T-*.md):

1. Read "Files to Modify" section
2. Check file overlap between Tasks
3. Group into batches:

Parallel eligibility:
├── Both Tasks have plans with file lists → check overlap
│   ├── No overlap → same batch (parallel)
│   └── Overlap → sequential batches
├── One or both lack plans → sequential (safe default)
└── Explicit dependency noted → sequential

For Tasks without plans: always sequential.

3c: Present Execution Plan

## Execution Plan for F-{feature-slug}: {Feature Name}

**Team**: feature-F-{feature-slug}
**Model**: opus (all teammates)

**Batch 1** (parallel)
| Task | Teammate | Persona | Type | Plan |
|------|----------|---------|------|------|
| T-{task-slug}: {name} | worker-T-{task-slug} | {persona} | {type} | {plan path or "none"} |
| T-{another-slug}: {name} | worker-T-{another-slug} | {persona} | {type} | {plan path or "none"} |

**Batch 2** (after Batch 1)
| Task | Teammate | Persona | Type | Plan |
|------|----------|---------|------|------|
| T-{third-slug}: {name} | worker-T-{third-slug} | {persona} | {type} | {plan path or "none"} |

**Verifier**: verifier-T-{task-slug} (thorn, spawned per verification cycle)
**Review & Refactor**: reviewer-F-{feature-slug} (thorn)

---
Proceed? You can modify persona assignments or batch grouping.

Wait for user approval. User may:

• Change persona assignments
• Force sequential execution
• Exclude specific Tasks

---

Step 4: Team Creation & Batch Loop

4a: Create Agent Team

TeamCreate({
  team_name: "feature-F-{feature-slug}",
  description: "Feature F-{feature-slug}: {feature name} execution team"
})

4b: Create Team Tasks

Create tasks in the shared task list for all planned work:

TaskCreate({
  title: "T-{task-slug}: {task name}",
  description: "Persona: {persona}, Type: {type}, Plan: {plan path or 'none'}",
  status: "not_started"
})

Create tasks for:

• Each regular Task (not_started)
• Each verification task (blocked — unblocked after worker completes)
• R&R task (blocked — unblocked after all regular Tasks done)

4c: Update Sprint Files (Pre-Work)

For each Task in the current batch:

• Update BACKLOG.md: Task status → in_progress
• Update HANDOFF.md: Add to In Progress table
• Create/update active/F-{slug}.md if needed

4d: Spawn Worker Teammates

For each Task in the current batch, spawn a teammate into the team:

Agent({
  name: "worker-T-{task-slug}",
  team_name: "feature-F-{feature-slug}",
  description: "Sprint Task T-{task-slug}",
  model: "opus",
  prompt: <see Worker Teammate Prompt below>,
  mode: "auto"
})

Spawn all Workers in a batch in parallel (single message with multiple Agent calls).

Worker Teammate Prompt Construction:

You are {persona_name}, a teammate in the "feature-F-{feature-slug}" Agent Team working on a sprint Task.

## Your Persona
{content of personas/{name}.md}

## Team Info
- Team: feature-F-{feature-slug}
- Your name: worker-T-{task-slug}
- Lead: The agent who spawned you (send messages via SendMessage)
- You can message any teammate by name via SendMessage

## Task Assignment
- Task: T-{task-slug}: {task name}
- Feature: F-{feature-slug}: {feature name}
- Type: {coding/docs/ideation/general}

## Context
{content of active/F-{slug}.md}

## Feature Design
{content of refs/designs/F-{slug}.md}

## Task Plan
{content of refs/plans/F-{feature-slug}-T-*.md OR "No plan. Use Feature Design and Task description."}

## Lessons from Previous Tasks
{content of refs/lessons/F-{slug}-lessons.md if exists, OR "No prior lessons."}

## Instructions
1. Check TaskList to find your assigned task and claim it via TaskUpdate (owner: "worker-T-{task-slug}", status: "in_progress")
2. Execute the Task following your persona's style
3. When implementation is complete, send a completion report to the lead via SendMessage:
   - The complete list of files you created or modified
   - Brief summary of what you implemented
4. Wait for the lead's instructions — the lead will tell you to run review-work
5. When instructed, run /sprint:review-work and send the findings to the lead
6. Wait for the lead's selection — the lead will tell you which items to fix
7. Fix the selected items, then send the updated file list to the lead
8. Wait for the lead's verification result — the lead will spawn a Verifier to check your work
9. If the Verifier contacts you with questions about design intent, respond via SendMessage

## Communication
- **Always use SendMessage** to communicate with the lead or other teammates
- Plain text output is NOT visible to others — you MUST use SendMessage
- When you need help or have questions, message the lead

## Sprint File Rules
- Do NOT modify BACKLOG.md, HANDOFF.md, or active/ files
- Only work on implementation code and tests

4e: Lead Directs Review-Work Cycle

Step 1 — Worker reports implementation complete. Lead receives file list + summary.

Step 2 — Lead instructs review-work:

SendMessage({
  to: "worker-T-{task-slug}",
  summary: "Run review-work on T-{task-slug}",
  message: "Implementation looks good. Now run /sprint:review-work on your work and send me the findings."
})

Step 3 — Worker sends review findings. Lead receives categorized results.

Step 4 — Lead selects "all" (fix everything including Suggestions):

SendMessage({
  to: "worker-T-{task-slug}",
  summary: "Fix all review items for T-{task-slug}",
  message: "Fix all items: select 'all'. This includes 🔴 Critical, 🟡 Improvement, 🟢 Minor, and 💡 Suggestion.
  After fixing, send me the updated file list."
})

Step 5 — Worker sends fix completion + updated file list. Proceed to verification (Step 4f).

4f: Spawn Verifier Teammate

Spawn a Verifier into the same team:

Agent({
  name: "verifier-T-{task-slug}",
  team_name: "feature-F-{feature-slug}",
  description: "Verify Task T-{task-slug}",
  model: "opus",
  prompt: <see Verifier Teammate Prompt below>,
  mode: "auto"
})

Verifier Teammate Prompt Construction:

You are Thorn, an uncompromising code reviewer and a teammate in the "feature-F-{feature-slug}" Agent Team.

## Your Persona
{content of personas/thorn.md}

## Team Info
- Team: feature-F-{feature-slug}
- Your name: verifier-T-{task-slug}
- Lead: The agent who spawned you (send messages via SendMessage)
- Worker who wrote this code: worker-T-{task-slug}

## Verification Target
- Task: T-{task-slug}: {task name}
- Feature: F-{feature-slug}: {feature name}
- Type: {coding/docs/ideation/general}

## Files to Verify
{list of files from Worker report}

## Acceptance Criteria
{from Task plan or Feature Design}

## Instructions

### 1. Code Review (Third-Party Perspective)
Review all modified files with fresh eyes. You did NOT write this code.
Apply your review standards: correctness, maintainability, naming, security, test coverage.

### 2. Mechanical Verification
Run these checks and report results:
- Tests: run the project's test suite (or relevant subset)
- Build: verify the project builds without errors
- Type check: run type checker if applicable
- Lint: run linter if applicable

### 3. Fix Issues
If you find issues:
- Fix them directly
- Report what you fixed and why

### 4. Communicate
- If you need clarification about intent, message the Worker directly:
  SendMessage({ to: "worker-T-{task-slug}", message: "..." })
- The Worker can explain their design decisions — use this before making assumptions

### 5. Report
Send your report to the lead via SendMessage:
- Verification status: PASS or FAIL
- Issues found and fixed (if any)
- Issues found but NOT fixable (if any — explain why)
- Final file list after your fixes

If you cannot fix an issue, clearly state why and mark as FAIL.

## Communication
- **Always use SendMessage** to communicate with the lead or other teammates
- You CAN message the Worker directly for clarification — this is encouraged
- Plain text output is NOT visible to others — you MUST use SendMessage

4g: Process Verifier Result

If PASS:

• Update BACKLOG.md: Task [x] done
• Update HANDOFF.md: Move to Recently Done
• Update active/F-{slug}.md with completion notes
• TaskUpdate: mark verification task as completed
• Continue to 4h

If FAIL (unfixable issues):

• Stop immediately. Do not proceed to next Task.
• Report to user:

  ❌ T-{task-slug} verification failed — unfixable issues:
  - {issue description}
  
  Task remains in `in_progress`. Please resolve and re-run /sprint:work-on-feature F-{feature-slug}.
  

4h: Learning Loop

After successful Task completion:

1. Check Verifier's report for patterns (repeated issues across Tasks)
2. If patterns found, append to refs/lessons/F-{slug}-lessons.md:

## Lesson from T-{task-slug} ({date})

**Pattern**: {description of repeated issue}
**Fix applied**: {what was done}
**Prevention**: {how to avoid in future Tasks}

3. These lessons are included in subsequent Worker prompts (Step 4d)

4i: Shutdown Completed Workers

After a Worker's Task is fully done (verified + lessons recorded):

SendMessage({
  to: "worker-T-{task-slug}",
  message: { type: "shutdown_request" }
})

Also shutdown the Verifier:

SendMessage({
  to: "verifier-T-{task-slug}",
  message: { type: "shutdown_request" }
})

4j: Report to User

One-line summary:

✓ T-{task-slug} done ({persona}) — {N} self-review fixes, {M} verification fixes

4k: Parallel Batch Completion

When all Tasks in a batch complete:

1. Conflict detection (parallel batches only):
   • Check if any Workers/Verifiers modified the same files
   • If conflict detected: Stop. Report conflicting files and which Tasks touched them.
2. Proceed to next batch

---

Step 5: Review & Refactor Task

After all regular Tasks are done:

5a: Update Sprint Files

Update BACKLOG.md: R&R Task → in_progress Update HANDOFF.md: Add to In Progress TaskUpdate: unblock R&R task

5b: Spawn R&R Teammate

Agent({
  name: "reviewer-F-{feature-slug}",
  team_name: "feature-F-{feature-slug}",
  description: "Review & Refactor F-{feature-slug}",
  model: "opus",
  prompt: <see R&R Teammate Prompt below>,
  mode: "auto"
})

R&R Teammate Prompt Construction:

You are Thorn, performing a comprehensive Feature audit as a teammate in the "feature-F-{feature-slug}" Agent Team.

## Your Persona
{content of personas/thorn.md}

## Team Info
- Team: feature-F-{feature-slug}
- Your name: reviewer-F-{feature-slug}
- Lead: The agent who spawned you (send messages via SendMessage)

## Feature Under Review
- Feature: F-{feature-slug}: {feature name}
- Type: {coding/docs/ideation/general}
- Design: {content of refs/designs/F-{slug}.md}

## Completed Tasks
{list of all Tasks and what they accomplished}

## Instructions

### Run /sprint:review-backlog in immediate-fix mode

1. Invoke /sprint:review-backlog targeting Feature F-{feature-slug}
2. When the skill asks about mode, choose **immediate-fix mode**
3. Apply the comprehensive checklist against the entire Feature
4. For each issue found: fix it directly
5. After all fixes, send report to the lead via SendMessage:
   - Total issues found per category
   - All fixes applied
   - Any issues you could NOT fix (with explanation)

### Learning
Record Feature-level lessons:
- Architectural patterns that worked well
- Recurring issues across Tasks
- Suggestions for future Features

Send these lessons to the lead via SendMessage.

## Communication
- **Always use SendMessage** to communicate with the lead
- Plain text output is NOT visible to others — you MUST use SendMessage

### Sprint File Rules
- Do NOT modify BACKLOG.md, HANDOFF.md, or active/ files
- Only modify implementation code, tests, and documentation

5c: Process R&R Result

1. Record lessons → refs/lessons/F-{slug}-lessons.md (Feature-level section)
2. Update BACKLOG.md: R&R Task → review (NOT done)
3. Update HANDOFF.md: Move to In Review
4. Update active/F-{slug}.md with R&R notes

5d: Shutdown R&R Teammate

SendMessage({
  to: "reviewer-F-{feature-slug}",
  message: { type: "shutdown_request" }
})

---

Step 6: Team Shutdown & Completion Report

6a: Shutdown All Remaining Teammates

Send shutdown to any teammates still alive:

SendMessage({
  to: "*",
  message: { type: "shutdown_request" }
})

6b: Completion Report

## Feature F-{feature-slug}: {name} — Execution Complete

**Team**: feature-F-{feature-slug} (shutdown)

| Task | Teammate | Persona | Review Fixes | Verification Fixes | Status |
|------|----------|---------|-------------|-------------------|--------|
| T-{task-slug} | worker-T-{task-slug} | {persona} | {N} self-review | {M} | ✓ done |
| T-{another-slug} | worker-T-{another-slug} | {persona} | {N} self-review | {M} | ✓ done |
| T-review-{feature-slug} R&R | reviewer-F-{feature-slug} | thorn | {N} | — | ⏳ review |

**Lessons recorded**: refs/lessons/F-{slug}-lessons.md

R&R Task is in `review` status. Please verify and mark done when ready.

---

Error Handling

Failure Point	Behavior
Worker teammate fails to complete Task	Stop. Report failure reason. Task stays in_progress.
Worker cannot resolve self-review items	Stop. Report unresolved items. Task stays in_progress.
Verifier finds unfixable issues	Stop. Report issues. Task stays in_progress.
Build/test failures persist	Stop. Report error logs. Task stays in_progress.
Parallel batch file conflict	Stop. Report conflicting files.
Blocked Task encountered (resume)	Stop. Report blocked Task and reason.
Teammate becomes unresponsive	Send message asking for status. If no response, report to user.

On any failure:

❌ {Task ID} failed at {stage} — {reason summary}
Task remains in current state. Resolve the issue and re-run:
/sprint:work-on-feature F-{feature-slug}

On failure cleanup: Shutdown all teammates before stopping:

SendMessage({ to: "*", message: { type: "shutdown_request" } })

---

Key Principles

• Agent Teams, not Sub-Agents — All agents are teammates in a shared team with bidirectional messaging
• Lead delegates, decides, and verifies — Lead assigns work, directs review-work, selects fix scope ("all"), and spawns Verifiers
• Workers execute — Workers implement, run review-work when told, fix selected items, and report back
• Lead manages sprint files — Worker and Verifier teammates never touch BACKLOG.md, HANDOFF.md, or active/
• Bidirectional communication — Workers and Verifiers can message each other and the Lead freely via SendMessage
• Shared task board — TaskCreate/TaskUpdate for coordination, visible to all teammates
• Opus by default — All teammates use model: "opus" for maximum capability
• Fresh Verifier per Task — No accumulated bias, clean context
• Verifier ↔ Worker dialogue — Verifier can ask Worker for design intent before assuming bugs
• Lessons feed forward — Earlier Task lessons improve later Worker prompts
• Fail fast — Any unresolvable issue stops the entire flow
• Clean shutdown — Always shutdown teammates via SendMessage before stopping
• R&R ends at review — User makes the final call on Feature quality
• Parallel when safe — Only when file overlap is confirmed absent

---

Related Skills

• /sprint:review-work — Same-session review (used by Worker teammates)
• /sprint:review-backlog — Comprehensive audit (used by R&R teammate in immediate-fix mode)
• /sprint:add-backlog — Add work items
• /sprint:plan-backlog — Design Task details
• /explain:explain — Feature briefing
• @INSTRUCTION.md — Manual session start