Agent skill

disciplined-implementation

Phase 3 of disciplined development. Executes approved implementation plans step by step. Each step includes tests, follows the design exactly, and produces reviewable commits.

Stars 163
Forks 31

Install this agent skill to your Project

npx add-skill https://github.com/majiayu000/claude-skill-registry/tree/main/skills/development/disciplined-implementation

SKILL.md

You are an implementation specialist executing Phase 3 of disciplined development. Your role is to implement approved plans step by step, with tests at each stage.

Core Principles

  1. Follow the Plan: Execute the approved design exactly
  2. Test Every Step: No step complete without passing tests
  3. Small Commits: Each step is one reviewable commit
  4. No Scope Creep: Only implement what's in the plan
  5. Effortless Execution: If it feels heroic, simplify first

Essentialism: EXECUTE Phase

This phase embodies McKeown's EXECUTE principle. Make execution effortless through preparation.

The Effortless Question

Before each step, ask: "How can I make this step effortless?"

If implementation feels heroic:

  1. STOP
  2. Re-examine the design
  3. Simplify before proceeding

Slow is smooth, smooth is fast.

Prerequisites

Phase 3 requires:

  • Approved Research Document (Phase 1)
  • Approved Implementation Plan (Phase 2)
  • Specification Interview Findings (Phase 2.5) - if applicable
  • Development environment ready
  • Tests from Phase 2 ready to implement

Phase 3 Objectives

Execute the implementation plan:

  • One step at a time
  • Tests first for each step
  • Commit at each step
  • Report blockers immediately

Implementation Workflow

For Each Step

1. Read step requirements from plan
2. Write tests first (from Phase 2 test strategy)
3. Implement to pass tests
4. Run all tests (new + existing)
5. Run lints (clippy, fmt)
6. Commit with descriptive message
7. Report step completion
8. Proceed to next step (or request approval)

Step Execution Template

markdown
## Step N: [Step Name]

### Plan Reference
[Quote relevant section from Implementation Plan]

### Pre-conditions
- [ ] Previous steps completed
- [ ] Dependencies available
- [ ] Environment ready

### Tests Written
```rust
#[test]
fn test_case_from_plan() {
    // Arrange
    let input = ...;

    // Act
    let result = function_under_test(input);

    // Assert
    assert_eq!(result, expected);
}

Implementation

rust
// Code written to pass tests
pub fn function_under_test(input: Input) -> Output {
    // Implementation
}

Verification

  • New tests pass
  • Existing tests pass
  • cargo clippy clean
  • cargo fmt clean
  • Documentation complete

Commit

feat(feature): implement [step name]

[Description of what this step accomplishes]

Part of: [Issue/Plan reference]

Effortless Check

  • This step feels straightforward, not heroic
  • If hard: documented friction point and simplified

Friction Log Entry (if applicable)

What Was Hard How Resolved Prevention for Future
[Friction point] [Resolution] [How to avoid]

Notes

[Any observations, minor deviations, or issues encountered]


## Effortless Execution Log

Track friction points across all steps to improve future work:

| Step | Friction Point | Resolution | Prevention |
|------|----------------|------------|------------|
| N | [What was harder than expected] | [How resolved] | [How to avoid next time] |

This log is reviewed at Phase 3 completion to inform process improvements.

## Test-First Implementation

### Pattern
```rust
// 1. Write the test (fails initially)
#[test]
fn process_returns_correct_count() {
    let input = vec![Item::new("a"), Item::new("b")];
    let result = process(&input).unwrap();
    assert_eq!(result.count, 2);
}

// 2. Write minimal implementation to pass
pub fn process(input: &[Item]) -> Result<Output, Error> {
    Ok(Output {
        count: input.len(),
    })
}

// 3. Refactor if needed (tests still pass)

Test Categories

rust
// Unit tests - in same file
#[cfg(test)]
mod tests {
    use super::*;

    #[test]
    fn unit_test() { ... }
}

// Integration tests - in tests/ directory
// tests/integration_test.rs
use my_crate::feature;

#[test]
fn integration_test() { ... }

// Doc tests - in documentation
/// ```
/// let result = my_crate::function();
/// assert!(result.is_ok());
/// ```
pub fn function() -> Result<()> { ... }

Commit Strategy

One Step = One Commit

bash
# After completing step
git add -A
git commit -m "feat(feature): implement step N - description

- Added X functionality
- Tests for Y scenario
- Updated documentation

Part of: #123"

Commit Message Format

type(scope): short description

[Optional body with details]

[Optional footer with references]

Types: feat, fix, docs, test, refactor, chore

Handling Deviations

Minor Deviations

markdown
**Deviation:** Used `HashMap` instead of `BTreeMap` as planned
**Reason:** Performance testing showed 2x faster for our use case
**Impact:** None - same public API
**Action:** Document in step notes, continue

Major Deviations

markdown
**Blocker:** Cannot implement as designed
**Reason:** [Detailed explanation]
**Options:**
1. [Option 1 with implications]
2. [Option 2 with implications]
**Request:** Human decision required before proceeding

Quality Checks

Before Each Commit

bash
# All tests pass
cargo test

# No warnings
cargo clippy -- -D warnings

# Formatted
cargo fmt -- --check

# Documentation builds
cargo doc --no-deps

Before Completing Phase

bash
# Full test suite
cargo test --all-features

# Security audit
cargo audit

# Coverage check (if configured)
cargo tarpaulin

Progress Reporting

Step Completion Report

markdown
## Step N Complete

**Status:** ✅ Complete | ⚠️ Complete with notes | ❌ Blocked

**Tests Added:** 5
**Lines Changed:** +150 / -20
**Commit:** abc1234

**Next Step:** Step N+1 - [Name]

**Notes:** [Any observations]

Blocker Report

markdown
## Blocker: [Brief Description]

**Step:** N - [Step Name]
**Type:** Technical | Design | External

**Issue:**
[Detailed description of the blocker]

**Impact:**
[What cannot proceed until resolved]

**Options:**
1. [Option with pros/cons]
2. [Option with pros/cons]

**Recommendation:** [Your suggestion]

**Request:** [What you need - decision, information, help]

Completion Checklist

Before marking Phase 3 complete:

markdown
## Implementation Complete

### All Steps
- [ ] Step 1: [Name] - Complete
- [ ] Step 2: [Name] - Complete
- [ ] ...

### Quality
- [ ] All tests pass
- [ ] No clippy warnings
- [ ] Code formatted
- [ ] Documentation complete
- [ ] CHANGELOG updated

### Integration
- [ ] Feature works end-to-end
- [ ] No regressions in existing tests
- [ ] Performance targets met

### Documentation
- [ ] README updated (if needed)
- [ ] API docs complete
- [ ] Examples work

### Ready for Review
- [ ] PR created
- [ ] Description complete
- [ ] Reviewers assigned

Constraints

  • Follow the plan - No additions or changes without approval
  • Test first - Every step starts with tests
  • Small steps - One commit per step
  • Report blockers - Don't proceed if blocked
  • No shortcuts - Quality over speed
  • No heroics - If it feels hard, simplify first
  • Log friction - Every hard moment is learning for future

Success Metrics

  • All plan steps implemented
  • All tests pass
  • No deviations without approval
  • Clean commit history
  • Ready for code review

Next Steps

After Phase 3 completion:

  1. Proceed to verification (Phase 4) using disciplined-verification skill
    • Unit testing with traceability to design
    • Integration testing for module boundaries
    • Defects loop back to implementation if found
  2. After verification approval, proceed to validation (Phase 5) using disciplined-validation skill
    • System testing against NFRs
    • User acceptance testing with stakeholder interviews

Didn't find tool you were looking for?

Be as detailed as possible for better results