con un clic
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.
Menú
Phase 3 of disciplined development. Executes approved implementation plans step by step. Each step includes tests, follows the design exactly, and produces reviewable commits.
Secure secret management using 1Password CLI. Detect plaintext secrets in files and codebases, convert environment files to 1Password templates, inject secrets securely using op inject, and audit codebases for security compliance.
Comprehensive Caddy web server management across multiple environments. Handles multi-server operations, zero-downtime deployments, secret management with 1Password, custom builds with plugins, and systemd service management.
Generates Rust code for GPUI desktop UI components following Zed editor patterns. Use when building desktop applications with gpui crate, creating themed UI components, implementing autocomplete/completions, building command palettes, or working with the gpui-component library. Covers RenderOnce components, Entity state management, theming with ActiveTheme, and Zed-style UI patterns.
MD-Book documentation generator skill. Use when working with MD-Book, a modern mdbook replacement for generating HTML documentation from Markdown files. Supports syntax highlighting, live reload, Pagefind search, and Tera templates.
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.
Phase 1.5/2.5 of disciplined development. Evaluates document quality using the KLS (Krogstie-Lindland-Sindre) 6-dimension framework. Produces structured ratings, identifies gaps, suggests specific revisions, and blocks phase transitions when quality is below threshold. Applies to Phase 1 research docs and Phase 2 design docs.
| name | disciplined-implementation |
| description | Phase 3 of disciplined development. Executes approved implementation plans step by step. Each step includes tests, follows the design exactly, and produces reviewable commits. |
| license | Apache-2.0 |
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.
This phase embodies McKeown's EXECUTE principle. Make execution effortless through preparation.
Before each step, ask: "How can I make this step effortless?"
If implementation feels heroic:
Slow is smooth, smooth is fast.
Phase 3 requires:
Execute the implementation plan:
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 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);
}
// Code written to pass tests
pub fn function_under_test(input: Input) -> Output {
// Implementation
}
feat(feature): implement [step name]
[Description of what this step accomplishes]
Part of: [Issue/Plan reference]
| What Was Hard | How Resolved | Prevention for Future |
|---|---|---|
| [Friction point] | [Resolution] | [How to avoid] |
[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)
// 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<()> { ... }
# 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"
type(scope): short description
[Optional body with details]
[Optional footer with references]
Types: feat, fix, docs, test, refactor, chore
**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
**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
# All tests pass
cargo test
# No warnings
cargo clippy -- -D warnings
# Formatted
cargo fmt -- --check
# Documentation builds
cargo doc --no-deps
# Full test suite
cargo test --all-features
# Security audit
cargo audit
# Coverage check (if configured)
cargo tarpaulin
## 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: [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]
Before marking Phase 3 complete:
## 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
After Phase 3 completion:
disciplined-verification skill
disciplined-validation skill