add CI images to repo
This commit is contained in:
parent
abce966b76
commit
817aa75f84
16 changed files with 386 additions and 54 deletions
|
|
@ -0,0 +1,129 @@
|
|||
---
|
||||
name: implement
|
||||
description: Mechanically execute approved design. Creates tasks, writes tests first, implements feature.
|
||||
---
|
||||
|
||||
# Implement Skill
|
||||
|
||||
Mechanical execution of DESIGN.md. No architectural decisions, only code that maps directly to specs.
|
||||
|
||||
## Core Principle
|
||||
|
||||
**Implementation is execution, not planning**. If you need to make a design decision, the design is incomplete. STOP and surface it.
|
||||
|
||||
## Startup
|
||||
|
||||
**MUST run on startup**:
|
||||
1. Read `DESIGN.md` from current directory
|
||||
2. If missing: STOP, instruct user to run `/design` first
|
||||
|
||||
## Process
|
||||
|
||||
### 1. Task Decomposition
|
||||
|
||||
Create `IMPLEMENTATION.md` with ordered task list.
|
||||
|
||||
**Task list structure**:
|
||||
|
||||
```markdown
|
||||
# Task List
|
||||
|
||||
## Status: [In Progress / Complete]
|
||||
|
||||
- [ ] Task 1: Write tests for [feature area]
|
||||
- Files: `tests/feature.test.c`
|
||||
- Creates test cases from DESIGN.md § Test Cases
|
||||
- [ ] Task 2: Implement [interfaces]
|
||||
- Files: `src/interfaces.c`
|
||||
- Functions: `funcName()`
|
||||
- Implements DESIGN.md § Interfaces & APIs
|
||||
- [ ] Task 3: Integrate [parts]
|
||||
- Files: `src/main.c`, `src/util.c`
|
||||
- Connects components per DESIGN.md § Architecture
|
||||
- [ ] Task 4: End-to-end validation
|
||||
- Run all tests, verify feature works
|
||||
|
||||
# Decisions Log
|
||||
|
||||
Description of any deviation from DESIGN.md, with rationale. Remember that any deviation should be surfaced to the user.
|
||||
|
||||
# Notes
|
||||
Any implementation context, gotchas encountered, etc.
|
||||
```
|
||||
|
||||
**Task requirements**:
|
||||
- **First tasks write tests** from DESIGN.md test cases, provides feedback loops
|
||||
- Each task = one logical unit of diff
|
||||
- Specify: what changes, which files, which functions
|
||||
- Order to minimize conflicts/dependencies
|
||||
- Include end-to-end validation
|
||||
|
||||
**Purpose**: State tracking across sessions. Prevents losing track when resuming. NOT for planning, all planning in DESIGN.md.
|
||||
|
||||
### 2. Implementation
|
||||
|
||||
Execute tasks in order. Update checkboxes as completed.
|
||||
|
||||
**Rules**:
|
||||
- Map DESIGN.md specs directly to code
|
||||
- **Tests first**: run tests, fix failures, proceed
|
||||
- Do not introduce scope beyond DESIGN.md
|
||||
- **Minimal comments**: Only when drastically improving clarity. Prefer self-documenting code (clear names, small functions, obvious structure)
|
||||
- Mark tasks complete: `- [x] Task 1: ...`
|
||||
|
||||
**Failure mode handling**:
|
||||
|
||||
If task requires decision not in DESIGN.md:
|
||||
1. **STOP immediately**
|
||||
2. Surface ambiguity to user: "DESIGN.md doesn't specify [X]. Options: [A], [B]. Which should I use?"
|
||||
3. Recommend updating DESIGN.md
|
||||
4. User updates DESIGN.md → restart `/implement` from fresh session
|
||||
|
||||
**Never make architectural decisions silently.**
|
||||
|
||||
### 3. Test Feedback Loops
|
||||
|
||||
- Run tests after implementing all functionality
|
||||
|
||||
### 4. Decisions Log
|
||||
|
||||
If any deviations from DESIGN.md occur (even minor), log in IMPLEMENTATION.md
|
||||
|
||||
Examples:
|
||||
- Changed file structure slightly for [reason]
|
||||
- Added helper function not in DESIGN.md for [reason]
|
||||
- Adjusted error handling approach because [reason]
|
||||
|
||||
## Code Style
|
||||
|
||||
- **Self-documenting code**: Clear variable/function names, small focused functions
|
||||
- **Comments**: Rare. Only for non-obvious "why" (never "what")
|
||||
- Follow existing codebase patterns discovered during `/design`
|
||||
|
||||
## Context Management
|
||||
|
||||
For very large implementations: break into sub-sessions or delegate to subagents. Maintain coherence via shared DESIGN.md and IMPLEMENTATION.md.
|
||||
|
||||
## Commit Scope
|
||||
|
||||
**One feature = one commit**. Complete all tasks before invoking `/commit`.
|
||||
|
||||
## Completion
|
||||
|
||||
When all tasks complete:
|
||||
```
|
||||
Implementation complete. Ready for /commit to generate commit message and PR description.
|
||||
```
|
||||
|
||||
## Artifact Lifecycle
|
||||
|
||||
**IMPLEMENTATION.md is ephemeral** and deleted before commit. Only DESIGN.md is committed.
|
||||
|
||||
## Philosophy
|
||||
|
||||
You are a compiler: DESIGN.md → working code. The better the design, the more mechanical your work. If you're making judgment calls, something's wrong upstream - STOP.
|
||||
|
||||
**Why mechanical execution?**
|
||||
- Prevents scope creep and ensures design intent preserved
|
||||
- Human made hard decisions with full context
|
||||
- Agent executes reliably without interpretation
|
||||
Loading…
Add table
Add a link
Reference in a new issue