Claude Skills by GentBajko

Use when designing a new/greenfield project's architecture - exhaustive persisted one-question-at-a-time interview, then the full prescriptive reference.

Use when turning a finished capstone design into working code - researches how the chosen stack connects, writes an implementation plan (backend first, then frontend), gates on user approval, then writes the code in subagents or inline, whichever you pick.

Internal to the capstone suite - carries the shared rules (references/) and scripts every capstone subcommand reads; it exists so npx-skills installs ship them alongside the command skills. Not meant to be invoked directly; when invoked anyway, run references/../scripts/help.sh and output its stdout verbatim.

Use when the capstone docs area needs a consistency check or repair - torn writes, done markers without ledger entries, voided plan approvals, index rows pointing at missing files, absorption gaps - reports findings with their owning rules, then applies only the repairs the user approves.

Use when the user wants one feature taken from idea to working code - "add a feature", "build X end to end", "take X from idea to shipped" - runs the feature chain groom -> plan -> implement consecutively, detecting the feature's stage and resuming at the first incomplete one. For the whole-product greenfield pipeline use start; to execute an already-approved plan use implement.

Use when starting work on a feature or change for a project that already has capstone docs - "new feature", "add a feature", "implement X", "build X", "design a feature", "spec it out", "flesh out", "refine this idea", "let's work on X" - a doc-grounded one-question-at-a-time interview producing a traceable feature spec in docs/capstone/features/, the first stage of the feature chain before plan and implement. Not whole-product discovery (mockup), not the greenfield pipeline (start); to carry...

Use when asked what the capstone plugin can do - prints the usage block.

Use when an approved feature plan is ready to become code - executes plan.md task by task with verification, in subagents or inline as you pick, reviews the diff recursively until no new findings survive, then refreshes the affected reference chapters.

Use when pinning down an app's business logic scenario by scenario - triggers, exact rules, branches, unhappy paths, state transitions, invariants - via a depth-first interview, one file per scenario in docs/capstone/logic/.

Use when asked to build, refresh, update, or check a codebase's architecture reference docs - "map the codebase", "document this repo", "are the docs current", "bring the docs in line with the code" - writes a docs/capstone/ index plus topic chapters, the logic/ business-logic map and the uiux/ surface map, then on later runs rewrites only the files whose covered paths drifted. One verb for both - no reference yet means build it, an existing one means refresh it. "map check" is the read-only ...

Use when defining a new product idea - adaptive purpose/business-plan/scenarios interview persisted to a file, then a traceable markdown mockup.

Use when a groomed feature spec needs an implementation plan - studies the chapters the spec cites, writes a task-by-task TDD plan an engineer with zero context could execute, gated on user approval.

Use when asked for an opinionated review of the codebase - architecture/backend findings, UI findings against the project's own design docs, or both - severity-ranked with evidence, written to docs/capstone/review.md. Bare "review" does both sides; "review backend" or "review frontend" does one. Opt-in judgment; never edits code.

Use when picking the concrete libraries, packages, and paid services for a designed project - researches current options per capability, presents pros/cons/license/pricing, and records the user's picks into the dependencies chapter.

Use when capturing how code must be written in this project - typing strictness, library-vs-build posture, paradigm, error handling, testing style, git and commit discipline, and what an AI assistant must never do here - via an interview, producing a normative standards doc that outranks generic best practice. Binding rules you decided, not a description of what the code currently does; the observed conventions live in the reference's own conventions chapter.

Use when the user says just "capstone" with nothing else, or asks to start or continue the capstone pipeline - runs the greenfield chain one stage at a time (mockup -> logic -> uiux -> architecture -> standards -> stack -> build), detecting completed stages and resuming at the first incomplete one.

Use when deciding how the product's UI should look and how its UX should behave, from the mockup and logic docs - visual direction, design system, and per-screen design chapters via an interview, using capstone's own vendored design method.