# Work

> 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.

- Skill: `alexanderop/work` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add alexanderop/work`
- Raw SKILL.md: https://api.skillmd.com/api/skills/alexanderop/work/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: alexanderop (https://skillmd.com/u/alexanderop)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/alexanderop/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