All authors
Claude Skills by intent-driven-ai
github.com/intent-driven-ai111 skills0 installs0 views
- Specs**Asked by:** Kapil, 2026-10-09, while ADR 031 was being written for #612: "we need a skill that manages adrs... adr format, write it, approve it and also to check if this adr invalidates any older ones. and impact of AINT... ADRs ideally should not impact bint" Not filed in the tracker yet (no tracker write was asked for). Its own issue, branch and change, after PR #631.Votes: 0GitHub stars: 3
- Complete DiscoveryThe Discovery loop — product to intent (ADR 029 §6, ADR 043). Give it a working prototype (a file, a project folder or a link) and a short write-up of it, and it reads the prototype once and runs /discover-intent, /discover-domains and /discover-capabilities on that one reading, each writing its own kind — business intents, domains, capabilities and features — on one issue and one branch. After each round it has the model's gaps found and closed, and gives the work still missing to the play t...Votes: 0GitHub stars: 3
- Build EpicBuild one ready epic to done — every spec passing — strictly inside the epic''s box. Breaks the epic into a test-first plan (stories, tasks, tests, docs as a DAG), publishes that plan to the epic''s tracked issue and keeps it current as the working spine, builds with spec separation (the implementer never sees tests or evals), and accepts done only from adversarial steelman verification. Opens the work; never closes it — the close belongs after /validate-epic. Also the FIX ROUND: when /valida...Votes: 0GitHub stars: 3
- Check ChangeReview an open change thoroughly and against something outside the change itself: assess what work categories the diff contains, resolve each category''s review treatment from the check-knowledge memory shelf, review each through its layers (objective linters, then design-grounding from committed sources for design-bearing categories), consolidate findings that each cite their basis, and stop at one decision gate resolved per gate-config — the reviewer owns the approve/reject verdict when the...Votes: 0GitHub stars: 3
- Commit ChangeCommit all uncommitted work on the feature branch, grouped by concern, with conventional messages that reference the issue — leaving a clean tree ready to raise. Commits only; does not push. The first step of the end sequence in the ProductOS change pipeline. Use when work is done and needs committing before propose-change.Votes: 0GitHub stars: 3
- Create LoopBuilds a "loop" — a higher-order play that runs other plays in rounds, in any order, until its intent is met (ADR 029, ADR 043) — from its ICE. Interviews for the intent triple and the loop's own parts (its plays, the questions it asks first, its checker and runner settings, how it ends), generates the expectation and the Done means, and writes the compiled loop into core/components/loops/<loop>/ (a SKILL.md that points to the Shared Loop Run, its stop-condition.yaml and its stamped scripts)....Votes: 0GitHub stars: 3
- Compiled Loop ExampleA worked example of a compiled loop. From a written statement of what a product is for, it runs /discover-intent then /discover-domains on one branch and ends with proposed business intents and a seeded domain, checked by a checker the config picks. Not a real loop — /create-loop copies its shape, and the loop linter's tests check it.Votes: 0GitHub stars: 3
- Create PlayCompiles a deterministic "play" (a multi-step, gated workflow recipe) from an intent. Interviews for the intent triple, generates the expectation, identifies the skills, scripts, and agents the play needs, selects a workflow structure, generates evals, and writes a compiled play (a SKILL.md plus scripts for its mechanical work). Use when the user wants to create, build, compile, or review a play — or says "create a play", "new play", "compile this into a play", "create-play", "turn this inten...Votes: 0GitHub stars: 3
- Discover CapabilitiesWrite the product''s capabilities and features, each with its ICE (ADR 043) — read off a prototype''s screens when a capture is given (a capability with no domain yet waits in the holding folder, not ready until attributed), else every pending capability in the model or the ones the person names (a capability not yet in the model is seeded thinly here from the person''s answers) — promote each grounding from directional to detailed, create and detail its features, set each capability''s own N...Votes: 0GitHub stars: 3
- Discover DomainsTurn business intents, a business goal, a prototype''s shared capture, or any mix into the domains of the product model — or grow the domains already there — a detailed domain grounding doc for each domain the product sits in (the field it serves and the job it does there, found in the knowledge shelves or by research, each page with its sources), the domain spine entries linked to the business intents both ways, and a directional product profile — written directly in place on the live model....Votes: 0GitHub stars: 3
- Discover IntentTurn whatever a person shares to explain what they want — a prototype (a file, a project folder or a deployed site), a document, or a plain statement — into the person''s Business Intents: each need the product meets for its user, at the level of the product and in its users'' words, with why the business needs it, who asks for it as a persona, and a measurable proof — the play drafts these with their basis — each confirmed or dropped by them. Writes business intents only (ADR 043): no ICE, n...Votes: 0GitHub stars: 3
- Edit LoopChanges an existing loop — its goal, a constraint, a failure condition, a scenario, its plays or their order, the questions it asks first, its checker or runner setting, or how it ends — by editing the loop's ICE and rebuilding it, so the loop always matches its intent. Companion to create-loop (which builds new loops). Use when the user wants to edit, change, update or fix a loop — or says "edit the loop", "add a play to Discovery", "the loop needs a new question", "edit-loop", or "rebuild t...Votes: 0GitHub stars: 3
- Edit OntologyChange Garura''s product ontology — its kinds, their links and their rules — one need at a time, with the product owner. Opens its own change (start-change), has the product-os-keeper agent run the author-product-ontology skill stage by stage, and stops for the product owner''s typed yes at three checkpoints: the questions the ontology must answer, the kinds, and the links and rules. Then it writes the ontology, runs its check until it reads valid, checks that only the needed kinds changed, t...Votes: 0GitHub stars: 3
- Edit PlayModifies an existing compiled play — its goal, a constraint, a failure condition, a success scenario, a step, the workflow shape, or the agents/skills it uses — by editing the play's ICE source and recompiling, so the play always matches its intent. Companion to create-play (which makes new plays). Use when the user wants to edit, change, modify, update, tweak, extend, or fix an existing play — or says "edit the play", "change this play", "add a constraint to the play", "the play needs a new ...Votes: 0GitHub stars: 3
- Fix BugRCA-driven defect resolution — opens the bug issue, traces the root cause, designs a fix with alternatives, presents it at a single human checkpoint, then implements with independent verification and lands it on main. The /fix command in the ProductOS command model. Use when you have an open bug issue to fix end to end.Votes: 0GitHub stars: 3
- Install GaruraInstall Garura into a target project or repository so its skills, agents, and plays become discoverable by Claude Code (the Codex installer is deprecated, #863: --tool codex stops with a plain message and changes nothing). Reads this garura checkout''s core/components and runs a per-tool ADAPTER that lays them down in the host''s native shape: for claude, .claude/ skills + agents with model tiers resolved to Claude models. Always writes a .garura/ tooling tree (config + STM scaffold) and copi...Votes: 0GitHub stars: 3
- Learn OutcomesClose the loop: after a unit of work ships, read what actually happened — the measure lens (baseline/target/realized), the validate verdicts and fix reports, the run lens, and the delivered epic/slice status — and update the LIVING product model to match reality. Refreshes only the model''s MEANING (capability/feature one_line, nfr_needs levels, status promotions, the grounding-doc sections learning changed) and records each material learning as an append-only decision — never the tree skelet...Votes: 0GitHub stars: 3
- List Focus IssuesShow the tracked issues worth attention right now — read the issue host, apply one of three fixed modes (today = open work you could pick up now; review = open work already in flight; recent = issues closed inside the last 7 days), and present a deterministic, capped list of at most 10 entries, each carrying its issue number, title, a plain-language reason built from the signals that selected it, what kind of issue it is (defect / epic / refactor / feature / docs / chore / unlabelled), and — ...Votes: 0GitHub stars: 3
- List PlansSee every plan of the project at once, from the plan files alone — one card for each plan with its number and business intent, its direction (⏵, ⏵⏵, ⏵⏵⏵) on the line under, its Status, Branch and the plans it Waits on, then each of its epics with its Progress; the plan''s Status and Direction are what a person set in the plan file, never worked out; with --graph, each plan''s branch drawn against main with its commits ahead and behind, and the plans with no branch named as on main. Reads only...Votes: 0GitHub stars: 3
- Merge ChangeMerge an approved change where its branch lands — its plan''s branch for an issue in a plan, main otherwise (a plan''s own branch lands on main while the plan is in progress) — switch to that branch and pull the latest, and delete the change''s branch (local and remote). The final step of the end sequence in the ProductOS command model. Use when a reviewed, approved PR is ready to land.Votes: 0GitHub stars: 3
- Propose ChangeRaise the current change for review — run a scope-and-quality self-review from the project''s standards, push the branch, and open a pull request carrying that review and the issue reference. The second step of the end sequence in the ProductOS command model. Use when a committed change is ready to raise as a PR.Votes: 0GitHub stars: 3
- Record DecisionRecord a decision as an ADR, written from the one ADR template (standards/templates/adr.md) — a Markdown ADR for Garura''s own decisions (docs/adr/) or a decision.yaml record for a product decision — with what it overrides and what it changes in plain view: every older ADR it supersedes or amends (with the part), the files, rules, schemas, plays and agents it affects, its effect on agent intent (ICE), and whether it would change a person''s business intent (it never does: such a decision is s...Votes: 0GitHub stars: 3
- Refactor CodeImprove the internal quality of a named code target — structure, duplication, naming, complexity — without changing its external behavior or the product model, proving behavior is preserved before it lands. Pins current behavior first (characterization tests where coverage is thin), presents a refactor plan at a single human checkpoint, then refactors and verifies independently that the model is untouched, tests are green before and after, and no test was weakened. The /refactor-code command ...Votes: 0GitHub stars: 3
- Release EpicLand one VALIDATED epic on a human''s evidenced acceptance — the HITL gate closing the execute pipeline (implement → validate → launch). Brings the increment up live on the run lens''s local environment (cloud is /release-increment''s), builds HITL testing scenarios from the epic''s user_check + acceptance — each telling the human what to RUN and what to TEST — walks them one at a time expecting a typed answer, and only a complete accepted sign-off releases the close chain that merges the epi...Votes: 0GitHub stars: 3
- Release IncrementDeploy a delivered increment (a validated, merged epic) to a named CLOUD environment the run lens already defined — defaulting to the lowest cloud tier (dev), running exactly what that environment''s run.yaml declares, then proving it came up healthy with an independent reachability check and recording the deploy as evidence. Lightweight and on-demand: changes nothing in the product model and stops below production (prod stays with CD from main). The /release-increment command in the ProductO...Votes: 0GitHub stars: 3
- Shape Agentic LensWrite a SLICE''s agentic lens as a grounding doc (agentic.md) — the is-it-an-agent gate, the load weights (cognitive / creative / logistical on a low→ultra scale), and the controls (guardrails, handoff). The MIDDLE of the FUNCTIONAL realize pipe (ux → agentic → marketing), run on a shaped slice. A deterministic slice comes out "not an agent", stated plainly. Reads the hub from the spine (feature grounding + profile), never another lens. Writes only the slice''s agentic lens, in place on the l...Votes: 0GitHub stars: 3
- Shape Architecture LensWrite a SLICE''s architecture lens as a grounding doc (architecture.md) — the components the slice threads (each in its layer, with its contract), the stack (tech + versions) behind them, and the vertical build that runs the slice end-to-end — written directly in place on the live model. The START of the NON-FUNCTIONAL realize pipe (arch → quality → run), run on a shaped slice. Every component is selected from the slice''s features'' systems + the profile surfaces, never invented; the build i...Votes: 0GitHub stars: 3
- Shape EvalWrite the eval of each slice of a business intent''s plan — the third play of the shaping loop (ADR 049: /shape-slice, then /shape-plan, then /shape-eval). Run as /shape-eval <intent-issue> (for example /shape-eval 788), after /shape-plan. For each slice the plan holds it reads only the epic (with its feature-to-story map), the stories in it and the slice''s hidden file, and writes, in the slice''s evals folder, one story file for each story (eval.<feature-id>.feature.md, Markdown with Gherki...Votes: 0GitHub stars: 3
- Shape Marketing LensWrite a SLICE''s marketing lens as a grounding doc (marketing.md) — how the slice is found and reached (SEO / AEO / GEO), the accessibility bar it meets, and the reach signals worth capturing — written directly in place on the live model. The END of the FUNCTIONAL realize pipe (ux → agentic → marketing): it closes the functional pipe (commit → propose → review → merge). An internal tool answers discoverability "not applicable", plainly. Reads the hub from the spine (feature grounding + profil...Votes: 0GitHub stars: 3
- Shape Measure LensWrite a SLICE''s measure lens as a grounding doc (measure.md) — the delivery-measurement focus, the metrics that prove it (baseline / target / proof, triangle-primary speed/tokens/cognition), and what is out of scope — then, when all seven lens docs line up, stamp the slice realized on the spine. The DELIVER pipe of realize (runs last): it opens its own branch (start-change) and closes it (commit → propose → review → merge). Reads the hub from the spine; the single play that flips a slice to ...Votes: 0GitHub stars: 3
- Shape PlanMake the one plan of a business intent that /shape-slice has served with a slice, once — the second play of the shaping loop (ADR 049: /shape-slice, then /shape-plan, then /shape-eval). Run as /shape-plan <intent-issue> (for example /shape-plan 788). It holds every slice the spine links to the intent, and for each slice it makes one epic (an issue of type Epic, no label) and one story for each feature (an issue of type Story, no label, a sub-issue of the epic), each story written from its fea...Votes: 0GitHub stars: 3
- Shape Quality LensWrite a SLICE''s quality lens as a grounding doc (quality.md) — a short statement of what "good" means for the slice plus a table of checkable gates (dimension / bar / how checked), drawn from the profile''s NFR gates that apply and the slice''s features'' rules, never invented. The MIDDLE of the NON-FUNCTIONAL realize pipe (architecture → quality → run), run on a shaped slice. Reads the hub from the spine (feature grounding + profile), never another lens. Writes the slice''s quality lens dir...Votes: 0GitHub stars: 3
- Shape Run LensWrite a SLICE''s run lens as a narrative grounding doc (run.md) AND a machine-readable per-environment definition (run.yaml) — the slice-level design (rollout, migrations, config/secrets, CI/CD) once, and ONE environment per call (local for /release-epic, or a cloud environment — provider, region, compute, services, firewalls, security, deploy command — for /release-increment). Incremental: re-run to add or edit an environment; the rest are preserved. The END of the NON-FUNCTIONAL realize pip...Votes: 0GitHub stars: 3
- Shape SliceShape the one slice that shows a business intent is served — the first play of the shaping loop (ADR 049: /shape-slice, then /shape-plan, then /shape-eval). Run as /shape-slice <intent-issue> (for example /shape-slice 788). It reads the intent from the product model (and writes the intent page from the issue when the model has none), reads the model and memory first, and talks to the person in one confirmation brief: the slice, what it fills, its hidden file, what is left out, each assumption...Votes: 0GitHub stars: 3
- Shape Ux LensWrite a SLICE''s UX lens as a grounding doc (ux.md) — the screens (each naming the object the user works with there, with a low-fidelity layout) that make the slice''s features visible, the flows (per persona and goal: entry, ordered steps naming screens, forks, failure path, exit), the states each screen holds (each with its trigger), and the product''s visual core (the semantic state vocabulary, its tone map, and the design-system reference the look comes from — never a palette or type scal...Votes: 0GitHub stars: 3
- Show PlanSee one plan as a tree, from its plan file alone, and know where it stands after two days away — /show-plan <id>, where the ID is the business intent''s issue number, or /show-plan with no number on a plan''s branch (plan/<id>/…), which shows that plan; on a branch in no plan it says so plainly. One node per line, its status mark, issue number and title; the work that is Not Started, In Progress, Now or Blocked is shown, Done and Dropped are hidden and counted on the last line (a hidden node ...Votes: 0GitHub stars: 3
- Start ChangeOpen a unit of work cleanly — the change the person names (an issue number, a short description, or plan <id>; nothing typed starts nothing) — resolve or create the tracked issue, cut its branch (under its plan''s branch for an issue in a plan, read from main and the plan''s branch; else a feature branch off up-to-date main), set up a git worktree when config calls for it, and initialize the STM workspace. The start-of-pipeline play in the ProductOS command model. Also starts a plan''s work o...Votes: 0GitHub stars: 3
- Uninstall GaruraRemove Garura from a target project or repository — the reverse of sud:install-garura. Reads the target''s install manifest and deletes exactly the host skills/agents/plays (.claude for Claude Code, .agents for Codex) and .garura bootstrap files that sud:install-garura created, while preserving the user''s own work (the issue/STM tree) unless explicitly told to purge. Use when the user wants to uninstall, remove, tear down, disable, or clean up Garura from a folder or repo — "uninstall garura...Votes: 0GitHub stars: 3
- Update PlanManage one plan in a working session — /update-plan <id> or /update-plan <a description>. The play finds the plan (a description''s match is shown and waits for a yes; it never guesses and never makes a plan), moves onto the plan''s own branch (it stops on uncommitted work on any branch, the plan''s own included, and names the files; for a plan with no branch it sets main''s plan file to In Progress first, then cuts the branch), and takes instructions in the person''s own words — finish, drop...Votes: 0GitHub stars: 3
- Validate EpicIndependently verify one built EPIC agent-side — the deep gate of the execute pipeline (implement → validate → launch). Re-runs everything mechanically through a per-tool runner family (java, .net, node, frontend, sql, lint, sonar): the epic''s tests, blast-radius-scoped regression, code-level security and quality scans — then compares results against the slice''s quality-lens gates AND the product profile''s benchmarks (green is the entry, the floor is the bar). Ends in a binary stamped verd...Votes: 0GitHub stars: 3
- Assess ChangesAnalyze uncommitted changes for categorization and risk assessmentVotes: 0GitHub stars: 3
- Assess PrAnalyze branch and generate context-aware quality checklistVotes: 0GitHub stars: 3
- Author Acceptance ScenariosBuild /release-epic''s HITL testing scenarios for one EPIC — the manual walk the human runs on the deployed dev/QA environment before anything lands. Reads the epic record (user_check + acceptance criteria + context) and the deploy record (where the increment is reachable), and writes scenarios.yaml — one scenario per testable claim, each telling the human WHAT TO RUN (concrete numbered steps on the deployed environment, starting from its real address) and WHAT TO TEST (what they should see i...Votes: 0GitHub stars: 3
- Author Agentic LensAuthor a shaped slice's agentic lens as an MD grounding doc — the is-it-an-agent gate, the load weights (cognitive / creative / logistical on a low→ultra scale), and the controls (guardrails, handoff) — from the slice's hub (its features' grounding docs + the spine profile) and KB grounding. A slice that should offload nothing comes out "not an agent", stated plainly. Writes the per-node lens agentic.md (conforming to the Agentic lens template) STRAIGHT TO THE LIVE MODEL, plus a grounding man...Votes: 0GitHub stars: 3
- Author Architecture LensAuthor a shaped slice's architecture lens as an MD grounding doc — the components the slice threads (each in its layer, with its contract), the stack (tech + versions) per component, and the vertical build (how the slice runs end-to-end through them) — from the slice's hub (its features' grounding docs + the spine profile) and KB architecture/technology grounding. Writes architecture.md straight to the live model (re-deriving this slice's lens in place) plus a grounding manifest that carries ...Votes: 0GitHub stars: 3
- Author Baseline TestsGiven coverage gaps from blast-radius.yaml, author specifications for baseline tests that capture CURRENT behavior before changes begin. Writes baseline-tests.yaml. Used by test-engineer.Votes: 0GitHub stars: 3
- Author Build PlanDraft /build-epic's build plan for ONE epic — the working spine of the build. Reads the epic's box (the epic record, its features' ICE, the slice's six lenses, the captured repo context + test harness) and breaks the epic into PIECES — stories, tasks, tests, docs — with explicit dependency edges forming a DAG, test-first (every epic acceptance criterion covered by a test piece authored from the spec, never from the implementation). Every piece carries a grounding citation into the box (epic |...Votes: 0GitHub stars: 3
- Author Business IntentDraft the person's Business Intents from what a person shared — a prototype (its saved snapshot), a document, or a plain statement — plus their own answers. One business intent per need the product meets for its user, never merged, with every part of the source mapped to the intent it serves. Each names that need at the level of the product and in its users' words, and holds title, outcome, why, asked by (a persona), proof it is met (measurable), must not, and the provenance of every property...Votes: 0GitHub stars: 3
- Author DecisionDraft a decision record (ADR) from the one ADR template (standards/templates/adr.md), in either of its two shapes — a Markdown ADR for Garura''s own decisions (docs/adr/NNN-<slug>.md) or a decision.yaml record for a product decision — from a decision brief and the context the adr-keeper agent gathered: the older ADRs it supersedes or amends (with what part), what it affects, its effect on agent intent (ICE), and its business-intent check. Always writes the record as proposed; only a person ac...Votes: 0GitHub stars: 3
- Author DomainsAuthor or grow the domains of the product model for /discover-domains — a detailed domain grounding doc for each domain the product sits in (the field it serves and the job it does there), each ending with its sources — straight to the live model, starting from business intents, a typed goal, a prototype's capture, or any mix, and from whatever the model already holds; and emit the matching spine-delta (new domain entries, the named updates to existing ones, and the directional profile) as st...Votes: 0GitHub stars: 3