メニュー
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.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
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.
| name | klum-map-architecture |
| description | 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. |
Build the compact architecture cache used by later issue-curation work.
AGENTS.md, CONTEXT.md, and the agent policies they route to.settings.gradle, the root and module build files, buildSrc/src/main/groovy/, .junie/guidelines.md, README.md, CHANGES.md, wiki/_Sidebar.md, and wiki/Builder-First-Migration.md.docs/adr/ and docs/implementation/. Treat accepted ADRs as authoritative and surface contradictions.Map dependency and public-API boundaries for:
klum-ast-annotationsklum-astklum-ast-runtimeklum-ast-jacksonklum-ast-bean-validationklum-ast-gradle-pluginklum-ast-bomTreat code-coverage-report as build infrastructure, not an architectural module.
Inspect enough source to locate:
Use tests as executable specifications: module src/test/groovy/, both relevant src/testFixtures/groovy/ trees, and klum-ast/src/test/scenarios/. Record representative paths rather than cataloguing every test.
Create or refresh only docs/implementation/issue-curation/architecture-map.md. Preserve useful confirmed content already present.
Include:
Keep confirmed facts separate from hypotheses. Cite repository paths for claims that later curators may need to verify. Finish only when every listed module and architectural concern is represented and no file outside the authorized map changed.