writing-plans
Use when you have a spec or requirements for a multi-step task, before touching code. Write comprehensive implementation plans assuming the engineer has zero context for our codebase and questionable taste.
- License 许可
- MIT
- 所属仓库
- mrtolkien/GHOST
- 最近更新
- 2026-04-24
- Stars
- ★ 5
- Forks
- 0
01 前言 Front Matter
- name
- writing-plans
- available
- coding
- description
- Use when you have a spec or requirements for a multi-step task, before touching code. Write comprehensive implementation plans assuming the engineer has zero context for our codebase and questionable taste.
02 资源文件 13
- 参考文档_meta.json139 B
- 脚本breakout-strategy.py7.0 KB
- 脚本donchian-adx-strategy.py4.7 KB
- 脚本ema-strategy.py4.5 KB
- 脚本mean-reversion-strategy.py7.0 KB
- 参考文档README.md2.9 KB
- 脚本rsi-bollinger-strategy.py5.0 KB
- 参考文档skill-card.md2.5 KB
- 参考文档SOURCE.md266 B
- 脚本strategy_common.py25.2 KB
- 脚本taker-strategy.py8.0 KB
- 参考文档TRUST.auto.yaml2.2 KB
- 脚本vwap-strategy.py6.6 KB
03 SKILL.md 正文
Writing Plans
Overview
Write comprehensive implementation plans assuming the engineer has zero context for our codebase and questionable taste. Document everything they need to know: which files to touch for each task, code, testing, docs they might need to check, how to test it. Give them the whole plan as bite-sized tasks. DRY. YAGNI. TDD. Frequent commits.
Assume they are a skilled developer, but know almost nothing about our toolset or problem domain. Assume they don't know good test design very well.
Announce at start: "I'm using the writing-plans skill to create the implementation plan."
Save plans to: docs/plans/YYYY-MM-DD-<feature-name>.md
Bite-Sized Task Granularity
Each step is one action (2-5 minutes):
- "Write the failing test" - step
- "Run it to make sure it fails" - step
- "Implement the minimal code to make the test pass" - step
- "Run the tests and make sure they pass" - step
- "Commit" - step
Plan Document Header
Every plan MUST start with this header:
# [Feature Name] Implementation Plan
> **For Claude:** REQUIRED SUB-SKILL: Use superpowers:executing-plans to implement this
> plan task-by-task.
**Goal:** [One sentence describing what this builds]
**Architecture:** [2-3 sentences about approach]
**Tech Stack:** [Key technologies/libraries]
---
Task Structure
### Task N: [Component Name]
**Files:**
- Create: `exact/path/to/file.rs`
- Modify: `exact/path/to/existing.rs:123-145`
- Test: `tests/exact/path/to/test.rs`
**Step 1: Write the failing test**
```rust
#[test]
fn test_specific_behavior() {
let result = function(input);
assert_eq!(result, expected);
}
```
**Step 2: Run test to verify it fails**
Run: `cargo test test_name -- --nocapture` Expected: FAIL with "cannot find function"
**Step 3: Write minimal implementation**
```rust
fn function(input: &str) -> Expected {
Expected
}
```
**Step 4: Run test to verify it passes**
Run: `cargo test test_name -- --nocapture` Expected: PASS
**Step 5: Commit**
```bash
git add tests/path/test.rs src/path/file.rs
git commit -m "feat: add specific feature"
```
Remember
- Exact file paths always
- Complete code in plan (not "add validation")
- Exact commands with expected output
- Reference relevant skills by name (e.g., "Read the
tddskill") - DRY, YAGNI, TDD, frequent commits
Execution Handoff
After saving the plan, offer execution to the OPERATOR:
"Plan complete and saved to docs/plans/<filename>.md. Ready to execute?"
If yes, use agent(action: "start", ...) to dispatch a coding agent per task, reviewing
between tasks for fast iteration.
04 同仓库更多 Skills
system-management
Use when reading or changing GHOST configuration (providers, models, timing, compaction, services, any config.toml key), adding or switching LLM providers, answering questions about GHOST's own features or capabilities, a CLI tool is missing or "not found", services need starting/stopping/debugging, updating GHOST to a newer version, managing the Nix shell environment, or troubleshooting GHOST setup.
writing-skills
Use when creating new skills, editing existing skills, or verifying skills work before deployment
verification
Use when about to claim work is complete, fixed, or passing, before committing or creating PRs. Requires running verification commands and confirming output before making any success claims. Evidence before assertions, always.
tdd
Use when implementing any feature or bugfix, before writing implementation code. Write the test first. Watch it fail. Write minimal code to pass.
systematic-debugging
Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes
subagent-development
Use when executing implementation plans with independent tasks in the current session. Dispatch a fresh subagent per task, with two-stage review after each — spec compliance review first, then code quality review. Keeps context clean and quality high.