// Use after specifying is complete — writes detailed implementation plan from a spec
[HINT] Download the complete skill directory including SKILL.md and all related files
| name | plan |
| description | Use after specifying is complete — writes detailed implementation plan from a spec |
| type | workflow |
Write a detailed implementation plan from a spec. Real code, exact file paths, no placeholders.
If $ARGUMENTS is a file path, read that spec and start. Otherwise ask the user for the spec path.
After loading the spec and reading the issue: value from its frontmatter, before writing any plan content:
hexis status read <issue>STATE: NEEDS_PLAN: proceed.After loading the spec, check whether the work can be split:
If both conditions hold for N ≥ 2 units: propose decomposition to the user. Do not proceed until confirmed.
On confirmed decomposition:
docs/specs/YYYY-MM-DD-<unit-name>-design.md> **Superseded.** Decomposed into: [unit-a](path), [unit-b](path)linked_spec pointing to its new SpecIf no decomposition: single plan (continue below), with linked_spec pointing to the parent Spec.
Every plan must start with this header:
---
issue: N
status: READY_TO_IMPLEMENT
linked_spec: docs/specs/YYYY-MM-DD-<topic>-design.md
---
# [Feature Name] Implementation Plan
> **For agentic workers:** REQUIRED SUB-SKILL: Use `hexis:implement` to execute task by task. For TDD tasks, follow `hexis:testing-principles`. Steps use checkbox (`- [ ]`) syntax for tracking.
**Goal:** [One sentence]
**Architecture:** [2–3 sentences on approach]
**Tech Stack:** [Key technologies]
---
Before defining tasks, list files to be created or modified. One responsibility per file.
ultrathink before decomposing tasks — never skip this.
For each task, determine whether TDD applies before writing steps.
TDD applies when the task involves:
TDD does not apply when the task involves only:
Label each task [TDD] or [No TDD — <reason>] in the task name.
Each task: one action, 2–5 minutes. Use the TDD or non-TDD step structure below based on the task label.
### Task N: [Name]
**Files:**
- Create: `exact/path/to/file.ts`
- Modify: `exact/path/to/existing.ts:123-145`
- [ ] **Step 1: Write failing test**
```typescript
test('specific behavior', () => {
const result = fn(input)
expect(result).toBe(expected)
})
```
- [ ] **Step 2: Confirm failure**
Run: `<exact test command>`
Expected: FAIL — "function not defined"
- [ ] **Step 3: Minimal implementation**
```typescript
function fn(input) {
return expected
}
```
- [ ] **Step 4: Confirm pass**
Run: `<exact test command>`
Expected: PASS
- [ ] **Step 5: Commit**
```bash
git add <files>
git commit -m "feat: add specific feature"
```
For tasks labeled [No TDD — <reason>]:
### Task N: [Name] [No TDD — <reason>]
**Files:**
- Create/Modify/Delete: `exact/path/to/file`
- [ ] **Step 1: Implement**
[exact changes — no placeholders]
- [ ] **Step 2: Verify**
Run: `<exact command>`
Expected: `<exact expected output>`
- [ ] **Step 3: Commit**
```bash
git add <files>
git commit -m "type: description (#issue)"
```
Never write: TBD, TODO, "add appropriate error handling", "write tests for the above", "similar to Task N".
Every code step must contain actual code.
After writing: spec coverage, placeholder scan, type/method name consistency.
docs/plans/YYYY-MM-DD-<feature>.md. Commit: docs: add <feature> plan.
After saving, tell the user that the plan was saved at docs/plans/<filename> and that hexis:implement is the next step.