GentBajko
- 17 skills
- 0 followers
- 6 hours ago last updated
- ▌ Map · gentbajkoUse 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 trust report that writes nothing; "map rebuild" forces a full rewrite; a topic name targets one chapter.
- ▌ Core · gentbajko bundleInternal 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.
- ▌
- ▌ Plan · gentbajkoUse 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.
- ▌ Uiux · gentbajkoUse 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.
- ▌ Groom · gentbajkoUse 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 one feature from idea to working code in a single run use feature.
- ▌ Logic · gentbajkoUse 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/.
- ▌ Retro · gentbajkoUse after a working session to improve the agent's environment - "retro", "what should we change about how you work here", "review the session" - reads the session for evidence, then proposes edits to standards.md and the project's AGENTS.md/CLAUDE.md, one approved row at a time. Diagnosis and proposals about the instructions, never about the code and never an edit to a chapter.
- ▌ Stack · gentbajkoUse 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.
- ▌ Start · gentbajkoUse 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, detecting completed stages and resuming at the first incomplete one. Always asks subagents or inline before each new or resumed run.
- ▌ Doctor · gentbajkoUse 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.
- ▌ Mockup · gentbajkoUse when defining a new product idea - adaptive purpose/business-plan/scenarios interview persisted to a file, then a traceable markdown mockup.
- ▌ Review · gentbajkoUse 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.
- ▌ Feature · gentbajkoUse 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. Always asks subagents or inline before each new or resumed run.
- ▌ Implement · gentbajkoUse 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.
- ▌ Standards · gentbajkoUse 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.
- ▌ Architecture · gentbajkoUse when designing a new/greenfield project's architecture - exhaustive persisted one-question-at-a-time interview, then the full prescriptive reference.