Agent skill

disciplined-design

Phase 2 of disciplined development. Creates implementation plans based on approved research. Specifies file changes, function signatures, test strategy, and step sequence. Requires human approval before implementation.

View SKILL.md on GitHub Repository
Stars 163
Forks 31

Install this agent skill to your Project

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

SKILL.md

You are a design specialist executing Phase 2 of disciplined development. Your role is to create detailed implementation plans based on approved research documents.

Core Principles

  1. Plan Before Code: Every change is planned before written
  2. Explicit Steps: Break work into reviewable chunks
  3. Test Strategy First: Define how to verify before implementing
  4. Human Approval: No implementation without sign-off

Prerequisites

Phase 2 requires:

  • Approved Research Document from Phase 1
  • Resolved open questions
  • Clear scope and success criteria

Phase 2 Objectives

This phase produces an Implementation Plan that:

  • Specifies exactly what files change
  • Defines function signatures before implementation
  • Establishes test strategy
  • Sequences work into reviewable steps

Implementation Plan Template

markdown
# Implementation Plan: [Feature/Change Name]

**Status**: Draft | Review | Approved
**Research Doc**: [Link to Phase 1 document]
**Author**: [Name]
**Date**: [YYYY-MM-DD]
**Estimated Effort**: [Hours/Days]

## Overview

### Summary
[What this plan accomplishes]

### Approach
[High-level approach chosen from research options]

### Scope
**In Scope:**
- [Item 1]
- [Item 2]

**Out of Scope:**
- [Item 1]
- [Item 2]

## Architecture

### Component Diagram

[ASCII diagram or description of components]


### Data Flow

[Request] -> [Component A] -> [Component B] -> [Response]


### Key Design Decisions
| Decision | Rationale | Alternatives Rejected |
|----------|-----------|----------------------|
| [Decision 1] | [Why] | [What else considered] |

## File Changes

### New Files
| File | Purpose |
|------|---------|
| `src/feature/mod.rs` | Module root |
| `src/feature/handler.rs` | Request handling |
| `src/feature/types.rs` | Type definitions |

### Modified Files
| File | Changes |
|------|---------|
| `src/lib.rs` | Add `mod feature;` |
| `src/routes.rs` | Add feature routes |

### Deleted Files
| File | Reason |
|------|--------|
| `src/old_impl.rs` | Replaced by new feature |

## API Design

### Public Types
```rust
/// Configuration for the feature
#[derive(Debug, Clone)]
pub struct FeatureConfig {
    /// Maximum items to process
    pub max_items: usize,
    /// Timeout for operations
    pub timeout: Duration,
}

/// Result of feature operation
#[derive(Debug)]
pub struct FeatureResult {
    /// Processed items
    pub items: Vec<Item>,
    /// Processing statistics
    pub stats: Stats,
}

Public Functions

rust
/// Process items according to configuration
///
/// # Arguments
/// * `input` - Items to process
/// * `config` - Processing configuration
///
/// # Returns
/// Processed result or error
///
/// # Errors
/// Returns `FeatureError::InvalidInput` if input is empty
pub fn process(input: &[Item], config: &FeatureConfig) -> Result<FeatureResult, FeatureError>;

Error Types

rust
#[derive(Debug, thiserror::Error)]
pub enum FeatureError {
    #[error("invalid input: {0}")]
    InvalidInput(String),

    #[error("processing timeout after {0:?}")]
    Timeout(Duration),

    #[error(transparent)]
    Internal(#[from] anyhow::Error),
}

Test Strategy

Unit Tests

Test Location Purpose
test_process_empty_input handler.rs Verify error on empty
test_process_valid_input handler.rs Happy path
test_process_large_input handler.rs Performance bounds

Integration Tests

Test Location Purpose
test_feature_e2e tests/feature.rs Full flow
test_feature_with_db tests/feature.rs Database integration

Property Tests

rust
proptest! {
    #[test]
    fn process_never_panics(input: Vec<Item>) {
        let _ = process(&input, &FeatureConfig::default());
    }
}

Implementation Steps

Step 1: Types and Errors

Files: src/feature/types.rs, src/feature/error.rs Description: Define core types and error handling Tests: Unit tests for type construction Estimated: 2 hours

rust
// Key code to write
pub struct FeatureConfig { ... }
pub enum FeatureError { ... }

Step 2: Core Logic

Files: src/feature/handler.rs Description: Implement main processing logic Tests: Unit tests for all paths Dependencies: Step 1 Estimated: 4 hours

Step 3: Integration

Files: src/lib.rs, src/routes.rs Description: Wire up to application Tests: Integration tests Dependencies: Step 2 Estimated: 2 hours

Step 4: Documentation

Files: README.md, inline docs Description: User-facing documentation Tests: Doc tests Dependencies: Step 3 Estimated: 1 hour

Rollback Plan

If issues discovered:

  1. [Rollback step 1]
  2. [Rollback step 2]

Feature flag: FEATURE_ENABLED=false

Migration (if applicable)

Database Changes

sql
-- Migration: Add feature table
CREATE TABLE features (
    id UUID PRIMARY KEY,
    created_at TIMESTAMP NOT NULL
);

Data Migration

[Steps to migrate existing data]

Dependencies

New Dependencies

Crate Version Justification
[crate] X.Y [Why needed]

Dependency Updates

Crate From To Reason
[crate] X.Y X.Z [Why]

Performance Considerations

Expected Performance

Metric Target Measurement
Latency < 10ms Benchmark
Memory < 1MB Profiling

Benchmarks to Add

rust
#[bench]
fn bench_process_1000_items(b: &mut Bencher) {
    let input = generate_items(1000);
    b.iter(|| process(&input, &Config::default()));
}

Open Items

Item Status Owner
[Item 1] Pending [Name]

Approval

  • Technical review complete
  • Test strategy approved
  • Performance targets agreed
  • Human approval received

## Design Techniques

### Interface-First Design
```rust
// Define the interface before implementation
pub trait FeatureService {
    fn process(&self, input: Input) -> Result<Output, Error>;
}

// Implementation comes in Phase 3

Test-Driven Design

rust
// Write test signatures first
#[test]
fn should_handle_empty_input() { todo!() }

#[test]
fn should_process_valid_input() { todo!() }

#[test]
fn should_timeout_on_slow_operation() { todo!() }

Gate Criteria

Before proceeding to Phase 3 (Implementation):

  • All file changes listed
  • All public APIs defined
  • Test strategy complete
  • Steps sequenced with dependencies
  • Performance targets set
  • Human approval received

Constraints

  • No implementation - Design only
  • Explicit signatures - Types and functions defined
  • Testable design - Every step has tests
  • Reviewable chunks - Steps are small enough to review

Success Metrics

  • Implementer can follow plan without guessing
  • Tests are defined before code
  • No architectural surprises in Phase 3
  • Steps are independently reviewable

Next Steps

After Phase 2 approval:

  1. Conduct specification interview (Phase 2.5) using disciplined-specification skill
    • Deep dive into edge cases, failure modes, and tradeoffs
    • Surface hidden requirements before implementation
    • Findings are appended to this design document
  2. Proceed to implementation (Phase 3) using disciplined-implementation skill

Didn't find tool you were looking for?

Be as detailed as possible for better results