garura

Review 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 review-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 gate is on; when off the computed recommendation is recorded and posted as a clearly marked harness verdict. The gate (third step) of the end sequence in the ProductOS command model. Use when a PR is ready to be reviewed and a verdict is needed.

Diff-bounded single-pass quality evaluation for PR review. Classifies every changed path by ARTIFACT TYPE first (runtime code / deployable config / tests / docs-planning / garura prose / ProductOS model / STM evidence / wireframes — pure globs, first match wins), then evaluates standard-ID checks against the diff using mechanical match rules from the PR severity taxonomy — grep-based rules fire only on runtime-code/deployable-config/tests (a keyword in prose is not a security defect,

Merge an approved change — merge the PR, switch to main and pull the latest, and delete the feature 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.

Compile 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 emits a compiled play (a SKILL.md plus bundled scripts for its mechanical work). Use this whenever the user wants to create, build, compile, or review a play — or says "create a play", "new play", "compile this into a play", "play-creator", "turn this intent into a play", or "review my play for gaps" — even if they don't say the word "play" explicitly but are describing a repeatable, multi-step, checkpoint-gated workflow they want captured as a runnable recipe.

Commit 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.

Raise 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.

Open a unit of work cleanly — resolve or create the tracked issue, cut 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. Use when beginning work on a change, starting an issue, or kicking off a feature.

Modify an existing compiled play — change 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, never by hand-patching the output into disagreement with its intent. This is the companion to play-creator (which makes new plays). Use this whenever 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 failure condition / step / scenario", "play-editor", or "recompile the play after I changed its intent" — even if they don't say "play" outright but are clearly reshaping a workflow recipe that already exists.

Detail one capability that /vision seeded — promote its grounding from directional to detailed, create and detail its functionalities, set the capability's own NFR + compliance needs, and roll those needs up into the product profile, firming the box and recording a decision for any out-of-box move. The product-manager step of the ProductOS strategy pipeline, after /vision and before /shape — the last detailing step. Opens no delivery issue.

Independently 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 verdict: `validated` (the precondition /launch requires) or `fix_required` (blocks /launch; the fix report names each failure by check and location so /implement fixes exactly that, nothing more). Implement ↔ validate is expected to loop — scope narrows per round, 3 rejections halt to a human. Finds, never fixes; every finding mechanically cited. The /validate command in the ProductOS command model. Use when an implemented epic awaits validation.

Turn a business goal into the seed of the product model — a detailed domain grounding doc, directional capability grounding docs, the spine entries that wire them, and a directional product profile. The entry play of the strategic (shaping) pipeline in the ProductOS command model — the CXO conversation. Use when starting a new product area from a business goal, before /understand and /shape. Opens no delivery issue.

Deploy 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 /deploy command in the ProductOS command model. Use when a delivered increment needs to run on a cloud environment /run already defined.

RCA-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.

Build 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. Also the FIX ROUND: when /validate stamps an epic fix_required, implement re-enters lightweight — the fix report is the exact work list, revision pieces on the existing plan, no fresh breakdown — and the epic flips back to in_delivery. The /implement command in the ProductOS command model. Use when a grilled epic is ready to build, or a validated-rejected epic needs its fix.

Improve 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 command in the ProductOS command model. Use when code needs to get better on the inside without changing what it does.

Write 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 (functionality grounding + profile), never another lens. Writes only the slice's agentic lens.

Write 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. The START of the NON-FUNCTIONAL realize pipe (arch → quality → run), run on a shaped slice. Every component is selected from the slice's functionalities' systems + the profile surfaces, never invented; the build is one vertical end-to-end. Reads the hub from the spine (functionality grounding + profile) and MAY read the functional lenses, never the measure or run lens. Writes only the slice's architecture lens.

Write 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. 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 (functionality grounding + profile), never another lens. Writes only the slice's marketing lens.

Write 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 realized — the marker /grill checks.

Write 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 functionalities' 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 (functionality grounding + profile), never another lens. Writes only the slice's quality lens.

Plan the product's vertical slices into a build sequence — order the slices /shape produced across all domains, resolve their dependencies, and estimate each one's effort, writing only the plan onto each slice. The planning play in the ProductOS command model, after /shape. Reads the slices to judge order and effort but writes only the plan (order, effort, dependencies). Opens no delivery issue.

Write 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 /launch, or a cloud environment — provider, region, compute, services, firewalls, security, deploy command — for /deploy). Incremental: re-run to add or edit an environment; the rest are preserved. The END of the NON-FUNCTIONAL realize pipe (architecture → quality → run): it closes the pipe (commit → propose → review → merge). Reads the hub from the spine (functionality grounding + profile) and the slice's architecture lens, never another lens. It never stamps the slice realized — that is /measure's job.

Select what to build in one domain and compose it into deliverable verticals — confirm or prune its capabilities against the firmed profile + KB, select which of the functionalities /understand created to build now, create the personas and user journeys, and bundle the functionalities into vertical slices, each behind a user-facing surface scaffolded slice by slice. The product-owner step of the ProductOS strategy pipeline, after /vision and /understand. Selects against the profile but never writes it; composes slices but never cuts epics or plans order. Opens no delivery issue.

Write a SLICE's UX lens as a grounding doc (ux.md) — the screens (each with a low-fidelity layout) that make the slice's functionalities visible, the states each holds, and the product's visual core (color + typography). The START of the FUNCTIONAL realize pipe (ux → agentic → marketing), run on a shaped slice. Accessibility is not here (it lives in the marketing lens); flows are the build's to derive. Reads the hub from the spine (functionality grounding + profile), never another lens. Writes only the slice's ux lens.

Install Garura into a target project or repository so its skills, agents, and plays become discoverable by a host coding tool — Claude Code or the OpenAI Codex CLI. 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; for codex, .agents/skills Agent Skills plus AGENTS.md and ~/.codex model/sandbox/approval profiles. Always writes a .garura/ tooling tree (config + STM scaffold) and copies shared memory to the machine-global ~/.garura, and records an install manifest so uninstall-garura can reverse exactly what was placed. Use when the user wants to install, set up, bootstrap, add, or enable Garura in another folder or repo for claude or codex — "install garura into X", "set up garura in this repo for codex", "bootstrap garura", "make codex see the garura skills". Takes the target path, an optional --tool, and an optional --scope (full = everything, the default; ha

Cut one REALIZED slice into user-testable delivery epics — the handoff from the product model to the delivery pipeline. /roadmap says which slice to build; the seven realize lenses have solved its design and /measure has stamped it realized — the marker /grill requires before it cuts. Each epic is a meaningful increment a user can open, exercise, and verify when delivered (the user-testability grain — never internal-only work), self-contained, referencing the slice's intent and lenses, never copying them. The cut is GRILLED before it is written — grilling draws the box from realized slice to delivery epics so nothing drifts outside the declared intents: every challenge cites a specific declared item (never taste), questions are asked plainly ONE AT A TIME with no recommendations attached, a tension closes only on the typed human answer (the record carries the push-back shown, the human's words, and the human-derived directive or reason — the agent never self-resolves), and an unresolved delivery-method choice

Recommend what to do next on the product — read the product model's current state (slices, lenses, epics, profile, roadmap order + dependencies), derive every runnable or blocked action through a deterministic decision tree, and present ONE next-best-action plus a ranked list (≤11 entries total), fitted to the person running. The model is the single source: no backlog, sprint plan, or work queue exists or is consulted. Operator fit is computed lexically from the person's git identity + commit history against the KB's work-intelligence shelf (glob path match + BM25 — never inference), and skipped with a notice when history is thin. A model inconsistency that blocks downstream work (e.g. a slice stamped realized with a lens missing) is a repair action and takes the next-best-action slot. Recommend ONLY: the play never modifies the model, never creates work items, never launches a play — multiple people and parallel agents can each pick a different lane from its output. Read-only and position none: runnable anyt

Remove 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 from X", "remove garura", "tear down garura in this repo", "undo the garura install". Takes the target path as its argument. For the forward direction, see sud:install-garura.

Close 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/functionality 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 skeleton. Replaces the old capture/codify/distill/enrich/reap loop. One delivered unit per run; one human checkpoint before anything persists. Reads the model from the spine; writes the spine + grounding docs + decisions through the change pipeline.

Land 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 /deploy'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 epic (then stamped delivered + kept as the as-delivered record, never deleted; prod follows from main via CD). A rejected scenario becomes a defect report on the epic's tracked issue and stamps the epic fix_required — /implement's lightweight fix loop, the same seam /validate uses. An agent never signs for the human (#436). The /launch command in the ProductOS command model. Use when a validated epic is ready for human acceptance.

Author a shaped slice's quality lens as an MD grounding doc — a short statement of what "good" means for the slice plus a table of checkable gates (dimension / bar / how checked) — from the slice's hub (its functionalities' grounding docs + the spine profile's NFR gates). Every gate is grounded (a profile gate that applies or a functionality's rule made checkable) and concrete, never a vague adjective. Writes a draft quality.md (conforming to the Quality lens template) plus a grounding manifest and any material decision; reads the functionality.md docs + the profile for the hub, never another lens. Generative artifact production for the /quality play; writes a draft only, never the live model.

Execute a quality lens's binding cards — the machine sibling quality-gates.yaml — against a project and emit one verdict per gate. Runs every machine-owned card's command through the project's own tools (linters, tests, type checks, coverage, custom check scripts), reads declared measures against thresholds, and normalizes outcomes to pass | fail | error | missing-tool | human. A card whose demanded tooling is absent is a missing-tool FINDING the build loop consumes as provisioning work — never a silent pass. Human-owned cards are visibly skipped, never judged. Verdicts feed the run's evidence file (Gate Outcomes) and, downstream, the loop's stop condition. Use whenever a play or loop needs the quality gates actually executed — "run the gates", "check the quality gates", "execute the lens". Purely mechanical: the script does the work; no inference.

Write a content string to a target path inside the `.garura/` folder whitelist. Enforces whitelist compliance at the write boundary. Used by the scriber agent.

Walk the inference-output directory under STM, read every proposal artifact each infer-*-from-code skill produced, and compose the master proposals.yaml index classified by the two-level learning taxonomy (learning_category + sub_category). This is the artifact that /garura:enrich consumes. Used exclusively by the /codify play.

Analyze uncommitted changes for categorization and risk assessment

Author 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 functionalities' grounding docs + the spine profile) and KB grounding. A slice that should offload nothing comes out "not an agent", stated plainly. Writes a draft agentic.md (conforming to the Agentic lens template) plus a grounding manifest and any autonomy decision; reads the functionality.md docs for the hub, never another lens. Generative artifact production for the /agentic play; writes a draft only, never the live model.

Author 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 functionalities' grounding docs + the spine profile) and KB architecture/technology grounding. Writes a draft architecture.md (conforming to the Architecture lens template) plus a grounding manifest and any material-choice decisions; reads the functionality.md docs for the hub, MAY read the functional lens docs (ux/agentic/marketing) optionally, never the measure or run lens. Generative artifact production for the /arch play; writes a draft only, never the live model.

Draft /implement's build plan for ONE epic — the working spine of the build. Reads the epic's box (the epic record, its functionalities' 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 | ice | lens | repo) — an ungroundable piece becomes an open_question, never invented work. Writes the plan draft to STM only, never the product model. Also applies revision directives (re-plan after retry exhaustion, steelman refutations as new pieces) to an existing draft. The generative planning work for the /implement play.

Draft /grill's epic cut for one REALIZED slice — the user-testable delivery increments the delivery pipeline picks up. Reads the slice's hub from the spine (its functionalities' grounding docs `functionality.md` + the spine profile) AND all SEVEN lens grounding docs (quality, ux, agentic, marketing, architecture, run, measure — the solved design), then cuts epics by the user-testability grain — when an epic is delivered, a user can open the product, do something, and see it work. For EACH epic it drafts a spine `epics` index entry PLUS a rich `epic.md` grounding doc, referencing the slice's functionalities by spine id, never copying functionality or lens content. Orders the cut (explicit acyclic dependencies; the first epic stands alone) and records explicit deferrals for any slice functionality not cut this run. Also applies revision directives from /grill's grilling rounds to an existing draft. Writes a draft only (in STM), never the live model. The generative work for the /grill play.

Build /launch'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 if it works), with a `covers` list tracing every scenario to an acceptance index or the user_check. Both directions must close: every acceptance criterion gets a scenario, every scenario traces to the box — nothing invented, nothing untested. Draft only — the play presents the scenarios one at a time and records the human's typed answers; this skill never presents, never answers, never signs. The scenario-authoring work for the /launch play.