work

name	work
description	Execute an implementation plan step by step with testing and commits. Use when the user says 'implement this', 'build this', 'start working', 'execute the plan', or wants to turn a plan into working code.
argument-hint	Path to plan file or describe what to implement

Work

Execute implementation plans efficiently while maintaining quality and shipping complete features.

Subagents

This skill uses the cexplore subagent for codebase pattern research during implementation.

Support Files

Read these on-demand at the step that needs them — do not bulk-load at start:

• work.references/execution-strategies.md — inline vs sequential vs parallel execution (read at Phase 1, Step 3)
• work.references/quality-checklist.md — pre-ship checklist and code review tiers (read at Phase 3)

Workflow

Phase 1: Quick Start

1. Read Plan and Clarify

• If no plan path was provided, read the path from docs/plans/.latest
• Read the plan document completely
• Review any referenced files or links
• If anything is unclear, use #askQuestions to get clarification on specific ambiguities (scope, approach, trade-offs) before starting
• Get user approval to proceed
• Do not skip this — better to ask now than build the wrong thing

1b. Check for TDD Tests

• Check if docs/tests/.latest exists
• If it does, read it to get the list of pre-written failing test files
• Read each test file to understand the expected behavior
• These tests define "done" — your goal is to make them all pass
• Announce: "Found [N] pre-written test files from TDD red phase. Implementation goal: make all tests green."
• If no docs/tests/.latest exists, proceed normally — you'll write tests as part of implementation

2. Setup Environment

Check the current branch:

• If already on a feature branch: use #askQuestions to ask whether to continue on this branch or create a new one
• If on the default branch: create a feature branch with a meaningful name (e.g., feat/user-authentication, fix/email-validation)
• Never commit directly to the default branch without explicit user permission

3. Break Down Tasks and Choose Strategy

Read work.references/execution-strategies.md to select the right approach.

• Break the plan into actionable tasks
• Prioritize based on dependencies
• Include testing tasks
• Keep tasks specific and completable
• Choose execution strategy:
  • 1-2 tasks -> inline (execute directly)
  • 3+ independent tasks -> parallel subagents
  • 3+ dependent tasks -> sequential subagents

Phase 2: Execute

Task Execution Loop

For each task in priority order:

1. Read any referenced files from the plan
2. Look for similar patterns in the codebase using the cexplore subagent
3. Implement following existing conventions
4. If TDD tests exist: run them to check which pass now — focus on making the next failing test green
5. If no TDD tests: write tests for new functionality
6. Run tests after changes
7. Check off the corresponding item in the plan file (- [ ] -> - [x])
8. Evaluate for incremental commit

Incremental Commits

After completing each logical unit, evaluate whether to commit:

Commit when...	Don't commit when...
Logical unit complete (model, service, component)	Small part of a larger unit
Tests pass + meaningful progress	Tests failing
About to switch contexts (backend -> frontend)	Purely scaffolding with no behavior
About to attempt risky/uncertain changes	Would need a "WIP" commit message

Heuristic: "Can I write a commit message that describes a complete, valuable change? If yes, commit."

Commit workflow:

1. Run tests (use project's test command)
2. Stage only files related to this logical unit
3. Commit with conventional message: feat(scope): description

Follow Existing Patterns

• Read referenced files from the plan first
• Match naming conventions exactly
• Reuse existing components where possible
• When in doubt, search for similar implementations

Test Continuously

• Run relevant tests after each significant change
• Fix failures immediately
• Add new tests for new functionality

Phase 3: Quality Check

Read work.references/quality-checklist.md and run through the pre-ship checklist.

1. Run the full test suite
2. Run linting (per project conventions)
3. Verify all plan tasks are checked off
4. Ensure code follows existing patterns
5. Determine review tier:
   • Tier 1 (self-review): purely additive, single concern, pattern-following, plan-faithful -> ship
   • Tier 2 (full review, default): everything else -> recommend review

Phase 4: Handover

After implementation is complete:

1. Create a final commit if uncommitted work remains
2. Push to remote

Use #askQuestions to ask what the user wants to do next:

Option	When to show
Simplify Code (Recommended) — load the /simplify skill	Always (default)
Write Tests — load the /test skill for post-implementation verification	When no TDD tests were pre-written
Review Changes — hand off to creview agent for code review	Always
Ship It — load the /git-commit-push-pr skill to create a PR	When Tier 1 self-review is sufficient
Done — end the workflow	Always

After the user picks a next skill, announce the handover and load the chosen skill.

Key Principles

• Start fast, execute faster — clarify once, then build
• The plan is your guide — follow referenced patterns, don't reinvent
• Test as you go — continuous testing prevents big surprises
• Ship complete features — finish the feature, don't leave it 80% done
• Update the plan — check off items as you complete them

Response Rules

• Never echo full file contents into chat — reference by path
• Keep status updates to 1-2 lines per task completed
• Don't repeat the plan back — just execute it
• Only show code snippets when asking for user input on a decision