work

# 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