菜单
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.
用 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-review-release |
| description | 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. |
Produce the smallest coherent 4.0 scope consistent with accepted decisions and current implementation.
Read AGENTS.md, CONTEXT.md, docs/agents/issue-tracker.md, docs/agents/feature-triage.md, docs/agents/pull-requests.md, all curation files, open issues and milestones, recent merged PRs, current CI status, CHANGES.md, README.md, wiki/Builder-First-Migration.md, and relevant ADRs and implementation notes.
Cross-check every curation claim against current GitHub and repository state. Identify:
Treat green CI as evidence of tested state, not proof that unresolved product or compatibility decisions are complete. Treat feature use-case classification as priority evidence rather than an automatic ranking. Do not require a retroactive classification pass over already-triaged issues; use the record when present or when an issue is revisited for another reason.
During analysis, update only:
docs/implementation/issue-curation/release-4.0.mddocs/implementation/issue-curation/Record evidence, recommendation, owner/decision needed, and next action for each blocker. Keep accepted facts separate from proposed scope changes.
Present proposed changes to wiki/Roadmap.md, CHANGES.md, milestones, labels, and GitHub issues separately. Apply them only after explicit maintainer confirmation and through the appropriate repo-specific skill.
Finish only when the issue index, release plan, repository state, and GitHub state reconcile; every 4.0 item has a disposition and evidence; and the recommended scope states its blockers, deferrals, and residual risks.