P1a.5: the four skills

[kurowski]

Checkpoint P1a, sub-scope 1a.5, the four skills. Stacked on #8, whose toolkit additions these skills call; merge #8 first, then this.

• start, next, lesson, done under plugins/rolling/skills/, holding the loop of docs/plan.md § 5 and the spike's coaching rules with its fourth-wall slips corrected.
• Grants are the rolling-* commands each needs and read-only git; no map command, no package manager, no tree-changing git. lesson is the one model-invocable skill; next hands off to it through the Skill tool under its own narrow grant.
• Every file of the tutor's goes through the pen; the skills forbid what the first runs caught the tutor doing (reading toolkit source, --help, listing the state directory, code in heredocs, parking files in the repo).
• The mechanism rows for 1a.5 are recorded: Skill-from-skill works under the caller's own grant; a slash command in print mode runs the skill; grants hold only for the invoking turn; the data directory is a protected path.
• One write lesson ran end to end on the Rallly clone twice; the 1a.5 paragraph has the transcript read and the warts left for 1a.6, 1a.7, and P1b. Prose is reviewed by running it, per CLAUDE.md; that run is the review.

Gate: claude plugin validate --strict on the plugin and the marketplace; the toolkit suite unchanged from #8.

🤖 Generated with Claude Code

https://claude.ai/code/session_01X6P54zABxhBhazCERoY1ki

[kurowski]

@claude review this

[claude]

Claude finished @kurowski's task in 7m 4s —— View job

---

Review of PR #9 — the four skills

• Read CLAUDE.md and repo conventions
• Read the diff (this PR's own commits: df5d7ef..HEAD, matching the stated 609/−12 across the 6 listed files)
• Read the four new SKILL.md files in full
• Check against CLAUDE.md rules and the toolkit they call (plugins/rolling/lib/rolling/cli.py, writes.py, tasks.py)
• Post review

Overall this holds the rules well: no skill names a script/task/profile file to the learner, next's grants are read-only git plus the rolling-* pen, lesson is the one model-invocable skill, and the pen (rolling-write/rolling-note) is used everywhere instead of Write/Edit for the tutor's own state. One correctness bug, and one open question.

1. next's inline map check aborts the skill exactly when it's supposed to report a fault

plugins/rolling/skills/next/SKILL.md:212-214:

## Map check

!`rolling-check-map`

and the "Choosing" section says: "If the map check below reports faults, tell the learner the map has a problem the author needs to fix, quote the faults, and stop." (lines 78-79)

But rolling-check-map is registered under ACTIONS, not INLINE, in plugins/rolling/lib/rolling/cli.py:461-469, and cmd_check_map (cli.py:414-429) return 1s when the map has faults — the same exit-1 behavior plugins/rolling/tests/test_cli.py's test_check_exit_codes and test_an_unreadable_lessons_directory assert on directly. cli.py's own module docstring is explicit about why the split exists: "an inline command... always exits 0, because a non-zero inline exit aborts the skill." CLAUDE.md states the same rule for skills generally: "A non-zero exit from a !`command` aborts the skill."

So on an actually broken map, the inline rolling-check-map call aborts next before the model's turn even begins — the graceful "tell the learner, quote the faults, stop" branch the skill describes can never execute. It'd likely surface as a raw tool failure instead of the tutor's voice, which is also in tension with "no fourth wall." The two demo runs recorded in docs/plans/p1a-write-mode.md didn't exercise this because the map validated cleanly both times (the healthy path returns 0 and is invisible).

Fix: give next an inline-safe way to see map faults — e.g. add a variant to cli.py's INLINE dispatch (alongside show/claim-session/session-start/diff/verify/report) that always exits 0 and reports faults in words, while keeping rolling-check-map's existing exit-1 contract for its other callers (the eventual CI gate / rolling-author verify, and the existing tests).

Fix this →

2. Open question: how does "try your own solution until the test passes" run, before a task exists?

next/SKILL.md's seam-task path (## Building the task, option 3) has the tutor write a test and "try your own solution in the tree beside it until the test passes," then call rolling-begin-task <lesson> --here <the test's path>. But at that point no task.md exists yet, and rolling-verify (cli.py's _verify) refuses with "no open task" until one does; next's allowed-tools also grants no map-declared test/build command directly (by design — no package manager grant). So it's not obvious what actually runs the test during that "try until it passes" step. The two recorded demo runs did build a seam task successfully (docs/plans/p1a-write-mode.md's 1a.5 write-up), so either this resolves in a way I'm not seeing from the skill text alone, or the demo runs used elevated permissions not representative of the shipped grants. Worth a sentence in the skill (or the plan doc) clarifying the mechanism, since it's the one step in the loop that looks like it needs a capability the skill isn't granted.

Minor

• plugins/rolling/README.md and the PR body describe next's grants as "the rolling-* commands each needs and read-only git," but next also carries full Edit/Write (needed for option 3's test-in-tree authoring). Intentional per the design (the tree is the tutor's to prepare before a task exists), just broader than that one-line summary suggests — worth a reader's note, not a change.
  · Branch: p1a.5/skills