Add agents.md and skills
This commit is contained in:
@@ -0,0 +1,87 @@
|
||||
---
|
||||
name: plan-chapter
|
||||
description: 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?
|
||||
- **Teaching Approach**: Are there concepts that need careful explanation? Diagrams?
|
||||
Worked examples?
|
||||
|
||||
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:
|
||||
|
||||
```markdown
|
||||
# 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`.
|
||||
Reference in New Issue
Block a user