菜单
Formally amend the constitution, with mandatory impact analysis before any change lands. The constitution is supreme law; amendments are versioned and their downstream effects scanned first.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
The drift check. Compare what was built against the design doc and master spec. Sets the Double Gate — A3 cannot start until A1 is at zero findings.
Mechanical FR/AC compliance. Walk every functional requirement and acceptance criterion and render a binary Pass/Fail with evidence. No judgment about quality, direction, or architecture.
Code/content quality. Dead code, hardcoded values, leftover TODOs, weak error handling, security holes, performance traps, standards violations. Enforces the Double Gate — blocks until A1 is at zero findings.
Vision-gap analysis. Compared to the perfect-world North Star, what is missing, drifting, or underbuilt — and what to add or change now to close the gap. Not a passive alignment scorecard.
Research the world. Real web research to find what the best teams do for every technology and pattern in the build, then implement superior approaches now (not later). The only lens that brings outside knowledge.
The boundary ritual — review what just landed, record an approval, journal it, and advance the phase. The ONLY step that writes approvals, and it does NO git.
| name | Amend |
| description | Formally amend the constitution, with mandatory impact analysis before any change lands. The constitution is supreme law; amendments are versioned and their downstream effects scanned first. |
| argument-hint | [section] [--impact] [--force] |
The formal process for changing the constitution, with mandatory impact analysis before any change lands. The constitution is supreme law; amendments are versioned and their downstream effects are scanned first.
Identify the amendment. Take the section number as an argument, or show the constitution's table of contents and ask. Amendment types: tech stack, quality gates, conventions, architecture decisions.
Impact analysis (always first). Before applying anything, scan for downstream impact:
approvals/master.json and group-N.json for records referencing the affected section or the constraints being changed.Present a summary with a risk level:
Impact Analysis for Amendment:
AFFECTED FEATURES: {list with approval status}
APPROVAL RECORDS: {count} reference affected constraints
IMPLEMENTATIONS AT RISK: {count} completed implementations
RISK LEVEL: {Low | Medium | High | Critical}
--impact stops here (analysis only). If risk is High/Critical and --force is not set, refuse: "This amendment affects {N} active features. Use --force to proceed, or resolve in-progress work first."
Apply the amendment. On approval:
Draft the amendment text with its rationale.
Write the change to the constitution.
Append to the constitution's changelog (the versioning record):
| #{NNN} | {date} | S{section} | {summary} | {rationale} |
The sequential #NNN is the amendment's version identifier; the changelog is the durable history.
Update the project-state.md session log.
Downstream cleanup checklist — after applying, verify every reference still holds:
Fix any failing check before committing. Amendments that don't propagate leave stale references that the final audits catch.
Commit. A single scoped commit, e.g. amend: constitution section {N} — {summary}.
- "amend the constitution"
- "change a project rule"
- "what would this amendment affect"