executing-plans
Use when you have a written implementation plan to execute in a separate session with review checkpoints. Load plan, review critically, execute tasks in batches, and report for review between batches.
- License 许可
- MIT
- 所属仓库
- mrtolkien/GHOST
- 最近更新
- 2026-04-24
- Stars
- ★ 5
- Forks
- 0
01 前言 Front Matter
- name
- executing-plans
- available
- coding
- description
- Use when you have a written implementation plan to execute in a separate session with review checkpoints. Load plan, review critically, execute tasks in batches, and report for review between batches.
02 资源文件 2
- 参考文档SOURCE.md183 B
- 参考文档TRUST.auto.yaml2.2 KB
03 SKILL.md 正文
Executing Plans
Overview
Load plan, review critically, execute tasks in batches, report for review between batches.
Core principle: Batch execution with checkpoints for architect review.
Announce at start: "I'm using the executing-plans skill to implement this plan."
The Process
Step 1: Load and Review Plan
- Read plan file
- Review critically - identify any questions or concerns about the plan
- If concerns: Raise them with the OPERATOR before starting
- If no concerns: Create
todo(action: "plan", ...)and proceed
Step 2: Execute Batch
Default: First 3 tasks
For each task:
- Mark as in_progress
- Follow each step exactly (plan has bite-sized steps)
- Run verifications as specified
- Mark as completed
Step 3: Report
When batch complete:
- Show what was implemented
- Show verification output
- Say: "Ready for feedback."
Step 4: Continue
Based on feedback:
- Apply changes if needed
- Execute next batch
- Repeat until complete
Step 5: Complete Development
After all tasks complete and verified:
- Announce: "I'm using the finishing-a-development-branch skill to complete this work."
- REQUIRED SUB-SKILL: Read the
finishing-branchskill - Follow that skill to verify tests, present options, execute choice
When to Stop and Ask for Help
STOP executing immediately when:
- Hit a blocker mid-batch (missing dependency, test fails, instruction unclear)
- Plan has critical gaps preventing starting
- You don't understand an instruction
- Verification fails repeatedly
Ask for clarification rather than guessing.
When to Revisit Earlier Steps
Return to Review (Step 1) when:
- The OPERATOR updates the plan based on your feedback
- Fundamental approach needs rethinking
Don't force through blockers - stop and ask.
Remember
- Review plan critically first
- Follow plan steps exactly
- Don't skip verifications
- Reference skills when plan says to
- Between batches: just report and wait
- Stop when blocked, don't guess
- Never start implementation on main/master branch without explicit OPERATOR consent
Integration
Required workflow skills:
writing-plans- Creates the plan this skill executesfinishing-branch- Complete development after all tasks
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
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.
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