
Claude Skills by tomthebearded
github.com/tomthebeardedThe requirements changed while someone is halfway through a learn-as-you-go guide — fold the change in WITHOUT rewriting the work they've already executed. Reads foundation/progress.md to find the frontier (and stops to have it confirmed if it's missing or stale), verifies any new fact online, then delivers an impact report and WAITS for approval. On approval it rewrites only what's ahead of the frontier, leaves executed steps untouched except for a superseded banner, and puts the repair for ...
Lint/QA a drafted learn-as-you-go guide against the GuideForge contract and report violations, ranked by severity — structural (missing Done-when, no nav line, partial code, dead links, no overview) and pedagogy (undefined terms, missing WHERE/WHY, arrow-chains, vague values, a solved capability hand-rolled without naming the library it replaces, a repetition hidden behind one sentence with no count and no bulk path). Read-only: it flags, it does not fix. Use when the user wants to check/QA/r...
Reconcile the REAL project against the learn-as-you-go guide you have been following — does what you built actually contain what the steps you executed told you to write? Reads the milestone checkpoints (the complete-file sections of each NN_verify.md), diffs them against your files while ignoring cosmetic differences, cross-checks foundation/progress.md against version-control history to catch steps ticked but never performed, re-runs only the gate checks that need no human, and classifies e...
Run the pedagogy pass over ONE existing step of a learn-as-you-go guide to remove confusion — without changing what the step does. Use when a step reads unclearly, a reader got stuck, or a term went undefined. Invoke with the step to clarify, e.g. "/clarify-step 03_first-route.md".
Draft an approved learn-as-you-go build guide into folders of atomic, teaching step files — the WHOLE guide by default (every milestone, in one pass), or a single named milestone if one is given (for re-drafts/fixes). Use after a plan from the plan-guide skill has been approved. Invoke with no argument to draft the whole guide, or a milestone to draft just that one, e.g. "/draft-milestone M2". Honors the approved ladder, audience model, conventions, and pedagogy rules.
A reader hit friction while following a learn-as-you-go guide — capture it to the guide's feedback log WITHOUT changing the guide. Appends one dated, structured entry (where · reader · what happened · suspected class · severity · tags · quote) to guide/feedback-log.md, so friction becomes durable data for improving the guide and the GuideForge method later. Log-only: it does not diagnose or fix (that's /report-issue). Use when you want to record a reader's snag, confusion, or error without ed...
Record what you have actually EXECUTED while following a learn-as-you-go guide — step by step — into the guide's foundation/progress.md ledger, and reconcile foundation/status.md (frontier, milestone table, session log) with it. Marks only: it never edits step files, never fixes anything, and never marks a milestone ✅ unless its verify gate was observed. This ledger is what /amend-guide reads to know which work must not be rewritten. Use when you finish a step, a sitting, or a milestone. Invo...
Restructure an EXISTING flat tutorial / README / runbook / legacy guide into a learn-as-you-go GuideForge plan: reverse-engineer its implicit ladder, diagnose it against the pedagogy principles, verify its (likely stale) stack online, and re-cast it as a plan with a source-map. Use when the user has an existing guide/tutorial to modernize or convert — not a from-scratch idea (that's plan-guide). Invoke with the doc, e.g. "/modernize-guide README.md", attaching the source file(s) and any real ...
Plan a learn-as-you-go, step-by-step developer build guide from a one-line idea. Use when the user wants to create a tutorial, course, onboarding doc, or build guide that TEACHES while it builds — for any domain (games, libraries, web, CLIs, APIs). Runs an audience interview, then produces a milestone-laddered plan — including a build-vs-borrow table that offers you the verified library behind every capability the guide would otherwise write from scratch, so you choose per capability instead ...
Pre-flight a contribution to the GuideForge repo before opening a PR — verify every CONTRIBUTING ground rule and PR-checklist item is respected, and that the repo is internally consistent (skill frontmatter valid, README/EXPLAINER skill list in sync, CHANGELOG updated, version stamps aligned, no dead links). Read-only: it reports PASS/FAIL with a checklist, it does not fix. Use right before you `git push` / open a PR against GuideForge. Invoke with no argument to check the current branch's di...
A reader hit a real issue while following a learn-as-you-go guide — report it and fix the guide so the issue can't recur. Diagnoses the root cause, fixes the step where they got stuck, then sweeps the WHOLE guide for every other place the same class of defect appears and fixes those too, adds a failure-note guard, logs it in status.md + decision-log.md, proposes a pedagogy rule if it's a general confusion, marks affected milestones for re-verification (never ✅), and hands off to audit-guide. ...
Reconcile a learn-as-you-go guide (or one step) against reality BEFORE you execute it — catch stale APIs, moved files, renamed UI, missing prerequisites. Use right before acting on a guide written a while ago, or against a codebase/tool that may have moved. Invoke with the step to review, e.g. "/review-before-follow M2/03_persist.md", optionally attaching the real project files to check against.
Stamp the folder skeleton + six foundation docs (stack, status, progress, glossary, conventions, decision-log) of a GuideForge guide from an approved plan, pre-filled from the plan and with a placeholder overview per milestone — so drafting can start immediately. Use after a plan is approved and before drafting the first milestone. Invoke with the plan, e.g. "/scaffold-guide", attaching PLAN.md.
Re-verify a guide's framework/library versions online and bring the guide up to date. Re-checks each tool's latest stable version, rewrites stack.md, then scans the guide and rewrites ONLY the steps whose code/commands/APIs/doc-links the bump affects (using the new version's features), logs the drift in status.md + decision-log.md, refreshes the README Updates log, and hands off to audit-guide to QA the changes. Reads foundation/progress.md first and STOPS for your decision before rewriting a...