klum-ast

Build a domain-first KlumAST Schema. Use when a Domain API Developer and Schema Developer want to model a domain independently of downstream targets, decide between Layer 3 and direct-schema, define DSL Object boundaries, and prove the resulting completed model with an API-only client and executable test.

Build a KlumAST authoring Schema for an authoritative external contract. Use when an adopter is replacing or simplifying Helm values, another configuration document, or a target-specific API contract while keeping that contract authoritative.

Advise on applicable KlumAST features in an existing Schema or configured model. Use when an adopter wants a ranked, evidence-based KlumAST improvement review, an explanation of supported 4.x features that fit their model, or selected, validated model improvements.

Author a configured KlumAST model. Use when a Model Writer wants to turn a representative configuration into a KlumAST model, add validation, construct it through the generated DSL, or create an executable model test.

Start or adapt a Gradle project for KlumAST. Use when an adopter wants to scaffold a KlumAST project, add KlumAST to an existing Gradle build, choose domain-first or target-contract modeling, choose Layer 3 or direct-schema structure, or verify a first schema build.

Maintain a compact, evidence-backed horizon of user-selectable repository work; create and reconcile user-visible tasks without confusing completed execution with delivered repository state.

Ask which skill or flow fits your situation. A router over the skills in this repo.

Hand the current conversation off to a fresh background agent that picks up the work immediately.

A relentless interview to sharpen a plan or design.

A relentless interview to sharpen a plan or design, which also creates docs (ADR's and glossary) as we go.

Compact the current conversation into a handoff document for another agent to pick up.

Implement a piece of work based on a PRD or set of issues.

Scan a codebase for deepening opportunities, present them as a visual HTML report, then grill through whichever one you pick.

Grill me about specs for the workflows I want to build, within this workspace.

Configure this repo for the engineering skills — set up its issue tracker, triage label vocabulary, domain doc layout, and issue-commit policy. Run once before first use of the other engineering skills.

Teach the user a new skill or concept, within this workspace.

Break a plan, spec, or PRD into independently-grabbable issues on the project issue tracker using tracer-bullet vertical slices.

Turn the current conversation into a PRD and publish it to the project issue tracker — no interview, just synthesis of what you've already discussed.

Move issues and external PRs through a state machine of triage roles — categorise, verify, grill if needed, and write agent-ready briefs.

Reference for writing and editing skills well — the vocabulary and principles that make a skill predictable.

Inventory, investigate, cluster, and provisionally classify KlumAST GitHub issues for release planning. Use for global issue sweeps, duplicate discovery, 4.0 scope analysis, or refreshing the persistent curation indexes without mutating GitHub issues.

Conduct an evidence-led maintainer interview for a KlumAST issue or issue cluster. Use when curation leaves product, compatibility, architecture, canonical-issue, or release-placement decisions unresolved.

Turn confirmed KlumAST curation decisions into structured GitHub issue updates, duplicate closures, and obsolete-issue explanations. Use only after the maintainer has confirmed intent, disposition, and release placement.

Reconcile KlumAST 4.0 issue curation against the repository, merged work, CI, ADRs, migration guidance, and release notes. Use for periodic release-scope reviews, API-freeze readiness, blocker analysis, and safe deferral recommendations.

Implement one approved KlumAST issue or tracer-bullet slice with module-appropriate Spock coverage, Groovy 3/4/5 compatibility checks, and synchronized release-facing documentation. Use after issue intent and architectural decisions are settled.

Review the changes since a fixed point (commit, branch, tag, or merge-base) along two axes — Standards (does the code follow this repo's documented coding standards?) and Spec (does the code match what the originating issue/PRD asked for?). Runs both reviews in parallel sub-agents and reports them side by side. Use when the user wants to review a branch, a PR, work-in-progress changes, or asks to "review since X".

Convert a confirmed cross-cutting KlumAST issue cluster into an ADR decision and an implementation plan with tracer-bullet slices. Use when work spans modules, changes generated or public contracts, extends Builder-first architecture, or needs executable acceptance coverage before implementation.

Create a detailed refactor plan with tiny commits via user interview, then file it as a GitHub issue. Use when user wants to plan a refactor, create a refactoring RFC, or break a refactor into safe incremental steps.

Test-driven development. Use when the user wants to build features or fix bugs test-first, mentions "red-green-refactor", or wants integration tests.

Map the KlumAST repository architecture into the persistent issue-curation architecture map. Use for the initial architecture study, after a major architectural change, or when later issue work exposes stale or missing architecture knowledge.