| name | study |
| description | Interactive active-recall learning and note distillation session. The agent explains complex technical concepts with official documentation/RFC references and optional CLI experiments, drills the user with adaptive active-recall questions (scaled to topic complexity, max 5), rigorously validates answers (prompting re-attempts on mistakes), rewords validated responses into structured Markdown cheat sheets, and commits them to ~/Documents/notes/<category>/.
|
Study
Active-recall learning session that turns technical concepts, codebase patterns, and official RFCs into deeply understood personal knowledge base notes.
Quick start
/study # Ask what concept or file to study
/study <topic> # Study a specific concept (e.g. /study cgnat, /study select-case)
/study <file_path> # Study logic/patterns from a specific codebase file
Setup & Prerequisites (Dynamic & Configurable)
-
Detect / Ask Notes Target Directory:
- Do not hardcode a single path. Check for common notes locations:
~/Documents/notes
./docs/notes or ./notes/ within the current workspace
- If ambiguous or on first run without an obvious notes folder, ask the user:
"Where would you like to save your study notes? (e.g. ~/Documents/notes, ./docs/notes, or custom path)"
- Remember the selected path for the remainder of the session.
-
Category Routing:
- Organize notes into logical subdirectories under the target notes path (e.g.,
<target_notes_dir>/<category>/<NN-slug>.md).
- Automatically create missing category directories as needed.
-
Safe Git Persistence (Conditional):
- Check if the chosen notes directory is inside a Git repository (
git rev-parse --is-inside-work-tree).
- If Git is initialized: Automatically stage and commit the note (
git add + git commit).
- If Git is not initialized: Save the Markdown note file safely without attempting Git commands.
Workflow
Step 1 — Identification & Grounding (Theory & Experiments)
- Understand the Target Topic:
- If a file/code snippet is passed, read it with
view_file or code search tools.
- If a general technical topic is passed, search official documentation or IETF RFCs with
search_web.
- Explain with Clarity & Precision:
- Break down the theory using simple analogies, ASCII diagrams, comparison tables, and code snippets.
- Grounding Rule: Always ground claims in official documentation (e.g., IETF RFCs, Docker Specs, Go Standard Library docs).
- Optional Hands-on CLI Experiment:
- If the concept involves CLI commands, networking interfaces, or system tools, provide step-by-step commands for the user to try in their terminal.
Step 2 — Active Recall Question Drill & Interactive Evaluation
-
Adaptive Question Generation:
- Generate focused active-recall questions scaled to topic complexity (2–3 questions for simple or narrow concepts, up to a maximum of 5 for broad architectural or system topics) covering core principles, syntax, security implications, edge cases, and practical code implementations.
- Do not force 5 questions if the concept is thoroughly covered in 2–3.
-
Evaluate & Give Precise Feedback on Each Answer:
- If Correct: Confirm and briefly reinforce key takeaways.
- If Partially Correct / Incomplete: Explicitly clarify what parts are accurate and explain the missing or ambiguous aspects so the user gains a complete understanding.
- If Incorrect / Misconception:
- DO NOT create notes prematurely!
- Provide a guided explanation and point the user in the right conceptual direction.
- Require the user to re-attempt answering the missed question before advancing to note creation.
-
Deep-Dive Pause:
- If the user asks a clarification question or struggles with a concept during the drill, pause the Q&A, explain the missing concept clearly (or offer a mini-experiment), and resume when ready.
Step 3 — Note Distillation & Structuring
- Take the user's validated answers and reword them into a professional, highly structured Markdown cheat sheet.
- Include the following sections in the note:
# Cheat Sheet: <Topic Title>
## 1. <Core Definition & Background>
## 2. <Architecture / Syntax / Comparison Table>
## 3. <Practical Code / Command Usage>
## 4. <Security & Edge Cases>
## 5. <Codebase References> (if codebase files were studied)
## Related References (Verified external links + relative links to existing notes).
- Formatting Quality Rule:
- Keep lines clean and readable.
- Use standard code blocks (
text, go, bash) for code/equations instead of nested math markers inside bold text.
Step 4 — File Writing & Git Auto-Commit
- Determine the sequential prefix number based on existing files in
<target_notes_dir>/<category>/ (e.g., 01-, 02-, 03-, 04-).
- Save the note to
<target_notes_dir>/<category>/<NN-slug>.md.
- If
<target_notes_dir> is a Git repository, execute Git commands:
git add <category>/<NN-slug>.md
git commit -m "docs: add <NN-slug>.md note"
- Present a summary of the created note path and git status to the user.
Rules
- Strict Drill Completion & No Premature Notes: Never write a final note without running the active recall drill and validating that every question is answered correctly. If any answer is incorrect, provide guidance and prompt a re-attempt first.
- Explicit Feedback on Partial Answers: Provide clear, explicit feedback distinguishing correct parts from misconceptions so the user knows exactly where they stand.
- Adaptive Questions (Max 5): Scale question count to topic complexity (2–3 for focused topics, max 5 for broad topics).
- Configurable Destination: Always check or ask for the user's preferred notes directory (
<target_notes_dir>). Do not force a single hardcoded path.
- Reference Grounding: Always verify external facts (RFC numbers, CLI syntax, standard library behaviors) before asserting them.
- No Silo Notes: Always include a
Related References section with relative Markdown links to related notes in <target_notes_dir>.
- Safe Persistence: Stage and commit notes only if the target notes folder is a Git repository; otherwise, save the file cleanly.