2.7 KiB
name, description
| name | description |
|---|---|
| plan-chapter | Develop a detailed plan for a book chapter through interactive Q&A |
Plan Chapter
You are planning a chapter of a literate programming book about nostr. The chapter name
is provided as an argument: $ARGUMENTS.
Step 1: Read Research
Read the research file at ./book/research/$ARGUMENTS.md. This contains:
- The topic summary describing what the chapter should cover
- Detailed analysis of how six reference implementations handle this topic
- Common patterns and design considerations
If the research file does not exist, tell the user to run /research-chapter $ARGUMENTS
first and stop.
Step 2: Interactive Q&A
Your goal is to develop a complete chapter plan by asking the user targeted questions. Draw on the research to make your questions specific and informed. Areas to explore:
- Scope: What should be included vs. excluded from this chapter? Are there edge cases or advanced features to defer to later chapters?
- API Design: What should the public API look like? Which patterns from the reference implementations should we adopt, adapt, or avoid?
- Dependencies: What external crates are needed? Should we minimize dependencies or use well-known crates?
- Narrative Flow: How should the chapter be structured? What order should concepts be introduced? What prior knowledge can we assume from earlier chapters?
- Code Organization: Which crate(s) should this code live in? How should modules be structured?
Ask questions in batches of 2-3 at a time. After each round of answers, follow up on anything that needs clarification before moving on. Continue until you have enough detail to write a comprehensive plan.
Step 3: Write Plan
Once you have sufficient information, write the chapter plan to:
./book/plan/$ARGUMENTS.md
The plan file should have this structure:
# Plan: <Chapter Name>
## Topic Summary
<From the research file>
## Chapter Outline
<Ordered list of sections with brief descriptions of what each covers>
## API Design
<Public types, traits, functions to be implemented. Include rough signatures where helpful.>
## Code Organization
<Which crate(s) and module(s) the code belongs in. How it relates to existing code.>
## Dependencies
<External crates needed and why>
## Narrative Notes
<Key teaching points, explanations that need care, examples to include>
## Design Decisions
<Choices made during planning and their rationale, referencing the research where relevant>
## Open Questions
<Anything unresolved that should be decided during writing>
After writing the file, tell the user the plan is complete and they can proceed with
/write-chapter $ARGUMENTS.