Skill-Details
study
General guided learning, tutoring, quizzing, and study-queue workflow.
Vor Nutzung prüfen
Die automatische Prüfung bewertet Relevanz, nicht Sicherheit oder Empfehlung. Lies vor der Nutzung die Quellanweisungen.
SKILL.md
Dieser Auszug wurde bei der Prüfung gespeichert. Die externe Quelle enthält die vollständige und aktuelle Version.
--- name: study description: "A personal, cross-project learning queue and tutor. Capture topics you want to understand deeply into a dumb home-dir backlog (~/.study/topics.md) from anywhere, then on demand run a guided, canvas-driven, recall-checked deep dive on any one of them. Topics can be grounded in your real code, in a sandbox the agent scaffolds, or be purely conceptual (\"investing\", \"solving a rubik's cube\"). Use whenever the user wants to learn or understand something deeply, park a rabbit hole for later, or be taught/quizzed — \"add X to my study list\", \"I want to understand Y\", \"teach me Z\", \"quiz me on…\", \"let's do a deep dive\", \"what's on my study queue\", \"explain how our <thing> actually works\" — and as the place other skills (e.g. better-planning-sync, better-planning-comprehend) send knowledge gaps. Works standalone; uses the canvas skill for interactive lessons when installed." --- # Study Relying on agents to write code (and to answer everything) quietly erodes understanding: the rabbit holes you'd once have chased — "wait, how *does* RRULE expansion work?" — get skipped to stay on task, and the gap compounds until you're a spectator to your own systems. `study` is the counter-habit. It splits learning into two cheap halves: **capture now** (a frictionless backlog of things worth understanding) and **learn later** (a guided, tested deep dive when you actually have the time). It's general — code is its strength, not its limit; "investing" and "the Krebs cycle" belong on the same queue. ## The home: a dumb queue, the filesystem as state Everything lives under `~/.study/` (full protocol in `references/study-layout.md` — read it before touching the files): - **`~/.study/topics.md` is pure backlog** — one topic per line, nothing else. A bare topic, or a topic plus free-form context if the author felt like typing it. **No status tags, no dates, no machine fields, no parsing.** It stays short and human; anything (including you, by hand) can append a line. - **A topic's state *is* its directory.** No `~/.study/<slug>/` ⇒ not started (just a queue line). Directory exists ⇒ picked up. Done ⇒ recorded *inside* the dir (the learning record marks it). Read state by looking at the filesystem, never by parsing the queue. - **Picking a topic up graduates its line out** of `topics.md` into a fresh `~/.study/<slug>/` workspace that seeds the dive. The queue shrinks as you act; a topic is never in two places. ## The four verbs The user's intent maps to one of these — do the one they asked for; don't force a dive when they only wanted to capture. ### capture — append a line "Add X to my study list", or a topic surfaced mid-conversation worth parking. Append one line to `~/.study/topics.md` (create the file on first use). Keep the human's words; attach free-form context only if it's cheap and useful (e.g. the repo + path the question came from), never machine tags. Confirm in a sentence; do **not** start teaching. This is the GTD capture — get it out of the head and move on. ### browse — show the queue, help pick "What's on my study queue?" Show `topics.md` (and, if asked, the started/finished dirs from `ls ~/.study/*/`). Help choose what to learn now — by what's quick, what's blocking real work, or what the user's in the mood for. Recommend one, but it's their call. ### learn — scaffold and run the dive The user picks a topic (from the queue or fresh). Derive a slug, scaffold `~/.study/<slug>/`, move the topic line + its context out of `topics.md` into the workspace seed, then run the dive (next section). If a workspace already exists for the slug, resume from its learning record instead of starting over. ### record — capture what stuck, mark done On the way out of a dive (or when the user says they're done), write/append the learning record: what clicked, what's still fuzzy, the next thing to chase. Marking it done lives **in the dir**, not the queue. The record is both the retention aidVollständige Quelle auf GitHub lesen (öffnet externe Seite)