implement

分类: 工具与效率 | 上传者: heiko-braun | 下载: 0 | 版本: v1.0（最新）

Implement features with phase checkpoints. Use after a spec exists in .claude/specs/ or when implementing a confirmed specification.

更新日志: Source: GitHub https://github.com/heiko-braun/draft

目录结构

当前层级: .cursor/skills/implement/

📄 SKILL.md 3.6 KB

SKILL.md

---
name: implement
description: Implement features with phase checkpoints. Use after a spec exists in .claude/specs/ or when implementing a confirmed specification.
---

# Implementation

You implement features as small, complete vertical slices with continuous testing.

## When to Activate

- After the spec skill has created and confirmed a specification
- When user says "implement" and a spec file exists
- When user explicitly references a spec file

## Workflow

### 1. Load Spec & Assess Blast Radius

Read the relevant `/specs/{feature}.md` file. If multiple specs exist and it's unclear which one, ask the user.

Before writing any code, assess the change:

- **Which modules/files will this touch?** List them. If the spec has an "Affected Modules" section, verify it's still accurate.
- **Are we modifying shared code?** Changing a shared utility, interface, or base class affects every consumer. Flag this to the user.
- **Can we contain the change?** Prefer adding new files/functions over modifying widely-imported ones. Prefer narrow interfaces that isolate the new behaviour from the rest of the codebase.
- **Are we adding new dependencies?** Each dependency is a coupling point. Avoid unless clearly justified.

If the blast radius is wider than expected, flag it: *"This will touch N modules beyond what the spec anticipated. Want to proceed or restructure?"*

### 2. Implement

Implement the spec as **one integrated piece** — types, logic, wiring, and tests together. A small vertical slice doesn't need artificial separation into "foundation" and "core logic" and "integration" phases.

Use TodoWrite to track progress against the spec's acceptance criteria.

**Design for modularity as you go:**
- Place new behaviour behind clear interfaces — functions, types, modules — so callers don't depend on implementation details.
- Avoid reaching into the internals of other modules. If you need something, use or extend its public interface.
- Keep new files/functions narrowly focused. One responsibility per unit.
- If a change to shared code is unavoidable, make the interface change first, verify existing tests still pass, then build the new behaviour on top.

**Test continuously:**
- After each meaningful change, run existing tests to catch regressions early.
- Write tests for new behaviour as you implement it, not after.
- If the project has a linter or build step, run it periodically — don't wait until the end.

### 3. Verify & Complete

Before marking the feature complete:

1. Run the **full test suite** — not just new tests.
2. Run the **build/linter** if the project has one.
3. Re-read the spec's acceptance criteria and check each one explicitly.
4. Report: "Criterion met" or "Needs attention: {issue}" for each.

Only mark complete when all criteria pass and the build is green.

After successful implementation:
- **Update spec status** from `proposed` to `implemented`
- Check off completed acceptance criteria in the spec file
- Add any notes about implementation decisions

## Checkpoint Behaviour

Since each spec is a small vertical slice, heavy checkpointing is unnecessary.

**Do checkpoint** (pause and ask the user) when:
- The blast radius turns out wider than expected
- You face a design decision with trade-offs the user should weigh
- A test failure reveals a deeper issue that changes the approach

**Skip checkpoint** for:
- Normal forward progress within the spec
- Minor follow-up fixes
- Formatting/cleanup
- When user explicitly says "continue without asking"

## Recovery

If implementation is interrupted:
- TodoWrite preserves progress
- Spec file shows which criteria are done
- User can say "continue implementing {feature}" to resume

登录后下载/点赞/收藏 ❤ 4 | ★ 0

implement

目录结构

SKILL.md

举报内容

提示