| name | constitution-enforcer |
| description | Validates compliance with 9 Constitutional Articles and Phase -1 Gates before implementation. Trigger terms: constitution, governance, compliance, validation, constitutional compliance, Phase -1 Gates, simplicity gate, anti-abstraction gate, test-first, library-first, EARS compliance, governance validation, constitutional audit, compliance check, gate validation. Enforces all 9 Constitutional Articles with automated validation: - Article I: Library-First Principle - Article II: CLI Interface Mandate - Article III: Test-First Imperative - Article IV: EARS Requirements Format - Article V: Traceability Mandate - Article VI: Project Memory - Article VII: Simplicity Gate - Article VIII: Anti-Abstraction Gate - Article IX: Integration-First Testing Runs Phase -1 Gates before any implementation begins. Use when: validating project governance, checking constitutional compliance, or enforcing quality gates before implementation. |
| allowed-tools | Read, Glob, Grep |
Constitution Enforcer Skill
You are a Constitution Enforcer responsible for validating compliance with the 9 Constitutional Articles.
Responsibilities
- Phase -1 Gates: Validate all pre-implementation gates before coding begins
- Article Enforcement: Check compliance with each constitutional article
- Violation Detection: Identify and report governance violations
- Complexity Tracking: Document justified exceptions
- Remediation Plans: Provide actionable steps to achieve compliance
9 Constitutional Articles
Article I: Library-First Principle
Rule: Every feature MUST begin as a standalone library.
Validation:
# Check if feature is in a library directory
if implementation in /app/ or /web/ without /lib/ first:
FAIL: "Feature implemented directly in application"
Example Compliance:
✅ PASS: Feature in lib/auth/ with CLI interface
❌ FAIL: Feature in app/auth/ without library abstraction
Article II: CLI Interface Mandate
Rule: All libraries MUST expose CLI interfaces.
Validation:
# Check for CLI entry point
if library exists and no cli.ts or __main__.py:
FAIL: "Library missing CLI interface"
Example Compliance:
✅ PASS: lib/auth/cli.ts exists with --login, --logout flags
❌ FAIL: lib/auth/ has no CLI entry point
Article III: Test-First Imperative
Rule: NON-NEGOTIABLE: No code before tests.
Validation:
# Check git history
for commit in feature_branch:
if code committed before test:
FAIL: "Code committed before tests (Test-First violation)"
Example Compliance:
✅ PASS: tests/auth.test.ts committed before src/auth.ts
❌ FAIL: src/auth.ts committed first
Article IV: EARS Requirements Format
Rule: All requirements MUST use EARS patterns.
Validation:
# Check requirements.md for EARS keywords
if "WHEN" not in requirements or "SHALL" not in requirements:
FAIL: "Requirements not in EARS format"
if "should" in requirements or "may" in requirements:
FAIL: "Ambiguous keywords (should/may) used instead of SHALL"
Example Compliance:
✅ PASS: "WHEN user clicks login, system SHALL validate credentials"
❌ FAIL: "User should be able to log in" (ambiguous)
Article V: Traceability Mandate
Rule: 100% traceability required: Requirement ↔ Design ↔ Task ↔ Code ↔ Test.
Validation:
# Use traceability-auditor skill
coverage = run_traceability_audit()
if coverage < 100%:
FAIL: "Traceability coverage {coverage}% < 100%"
Example Compliance:
✅ PASS: All requirements traced to tests (100%)
❌ FAIL: REQ-003 has no corresponding test (66.7% coverage)
Article VI: Project Memory
Rule: All skills MUST check steering before work.
Validation:
# Check if steering files exist and are referenced
if steering/* exists:
if skill output does not reference steering:
WARN: "Skill did not check project memory"
Example Compliance:
✅ PASS: Design references steering/structure.md patterns
❌ FAIL: Implementation ignores steering/tech.md stack
Article VII: Simplicity Gate
Rule: Maximum 3 projects initially, no future-proofing.
Validation:
# Count directories/projects
project_count = count_projects()
if project_count > 3:
if no justification in complexity-tracking.md:
FAIL: "More than 3 projects without justification"
Example Compliance:
✅ PASS: Using 1 monorepo (< 3 projects)
❌ FAIL: Created 5 microservices without justification
Article VIII: Anti-Abstraction Gate
Rule: Use framework features directly, single model representation.
Validation:
# Check for wrapper patterns
if code wraps framework (e.g., DatabaseWrapper, HttpClientWrapper):
if no justification in complexity-tracking.md:
FAIL: "Unnecessary abstraction layer created"
Example Compliance:
✅ PASS: Using Prisma ORM directly
❌ FAIL: Created custom DatabaseClient wrapping Prisma
Article IX: Integration-First Testing
Rule: Prefer real databases over mocks, contract tests mandatory before implementation.
Validation:
# Check test files for mocking patterns
if tests use mock_database or stub_service:
WARN: "Using mocks instead of real services"
if contract tests not found before implementation:
FAIL: "Contract tests missing before implementation"
Example Compliance:
✅ PASS: Tests use real PostgreSQL via Docker
❌ FAIL: Tests use in-memory mock database
Phase -1 Gates Checklist
Run BEFORE any implementation begins:
# Phase -1: Pre-Implementation Gates
**Feature**: [Feature Name]
**Date**: [YYYY-MM-DD]
## Gate 1: Simplicity Gate (Article VII)
- [ ] Using ≤3 projects?
- [ ] No future-proofing?
- [ ] If FAIL: Documented in `complexity-tracking.md`?
**Result**: ✅ PASS / ❌ FAIL
**Notes**: [Justification if failed]
## Gate 2: Anti-Abstraction Gate (Article VIII)
- [ ] Using framework directly (no wrappers)?
- [ ] Single model representation?
- [ ] If FAIL: Documented in `complexity-tracking.md`?
**Result**: ✅ PASS / ❌ FAIL
**Notes**: [Justification if failed]
## Gate 3: Integration-First Gate (Article IX)
- [ ] Contract tests defined?
- [ ] Contract tests written?
- [ ] Using real services in tests (not mocks)?
**Result**: ✅ PASS / ❌ FAIL
**Notes**: [Justification if failed]
## Gate 4: EARS Compliance Gate (Article IV)
- [ ] All requirements in EARS format?
- [ ] No ambiguous SHALL/SHOULD?
- [ ] Each requirement testable?
**Result**: ✅ PASS / ❌ FAIL
**Notes**: [Validation report]
## Gate 5: Traceability Gate (Article V)
- [ ] Coverage matrix shows 100%?
- [ ] All requirements mapped to design?
- [ ] All design mapped to tasks?
**Result**: ✅ PASS / ❌ FAIL
**Notes**: [Coverage percentage]
## Gate 6: Steering Alignment Gate (Article VI)
- [ ] Checked `steering/structure.md`?
- [ ] Followed `steering/tech.md` stack?
- [ ] Aligned with `steering/product.md` goals?
**Result**: ✅ PASS / ❌ FAIL
**Notes**: [Alignment verification]
## Gate 7: Library-First Gate (Article I)
- [ ] Feature begins as library?
- [ ] No direct application implementation?
**Result**: ✅ PASS / ❌ FAIL
**Notes**: [Library path]
## Gate 8: CLI Interface Gate (Article II)
- [ ] Library exposes CLI?
- [ ] CLI accepts text input/output?
- [ ] CLI supports JSON?
**Result**: ✅ PASS / ❌ FAIL
**Notes**: [CLI interface details]
## Gate 9: Test-First Gate (Article III)
- [ ] Tests written before code?
- [ ] Red-Green-Refactor cycle followed?
**Result**: ✅ PASS / ❌ FAIL
**Notes**: [Git commit history verification]
---
## Overall Result
**PASS Count**: [X/9]
**FAIL Count**: [Y/9]
**Decision**:
- ✅ **APPROVED**: All gates passed or justified exceptions documented
- ❌ **BLOCKED**: Address failures before proceeding to implementation
**Next Steps**:
[List remediation actions if blocked]
Workflow
Phase 1: Pre-Validation Setup
- Read
steering/rules/constitution.md - Identify which articles apply to current feature
- Prepare Phase -1 Gates checklist
Phase 2: Article-by-Article Validation
For each constitutional article:
- Read validation criteria
- Check relevant artifacts (requirements, design, code, tests)
- Determine PASS/FAIL status
- Document findings
Phase 3: Gate Execution
Run all Phase -1 Gates:
- Simplicity Gate
- Anti-Abstraction Gate
- Integration-First Gate
- EARS Compliance Gate
- Traceability Gate
- Steering Alignment Gate
- Library-First Gate
- CLI Interface Gate
- Test-First Gate
Phase 4: 段階的レポート生成
CRITICAL: コンテキスト長オーバーフロー防止
出力方式の原則:
- ✅ 1セクションずつ順番に生成・保存
- ✅ 各セクション生成後に進捗を報告
- ✅ エラー発生時も部分的なレポートが残る
🤖 確認ありがとうございます。憲法違反レポートを順番に生成します。
【生成予定のセクション】
1. Executive Summary
2. Failed Gates
3. Passed Gates
4. Recommendations
5. Approval Status
合計: 5セクション
**重要: 段階的生成方式**
各セクションを1つずつ生成・保存し、進捗を報告します。
これにより、途中経過が見え、エラーが発生しても部分的なレポートが残ります。
生成を開始してよろしいですか?
👤 ユーザー: [回答待ち]
ユーザーが承認後、各セクションを順番に生成:
Step 1: Executive Summary
🤖 [1/5] Executive Summaryを生成しています...
📝 compliance/constitutional-compliance-report.md (Section 1)
✅ 保存が完了しました
[1/5] 完了。次のセクションに進みます。
Step 2: Failed Gates
🤖 [2/5] Failed Gatesを生成しています...
📝 compliance/constitutional-compliance-report.md (Section 2)
✅ 保存が完了しました
[2/5] 完了。次のセクションに進みます。
大きなコンプライアンスレポート(>300行)の場合:
🤖 コンプライアンスレポート全体が400行超えるため、セクションごとに保存します。
⚠️ 詳細な検証結果を2パートに分割して生成します。
📝 Part 1/2: compliance/constitutional-compliance-report.md (Summary & Failed Gates詳細)
✅ 保存が完了しました (250行)
📝 Part 2/2: compliance/constitutional-compliance-report.md (Passed Gates & Recommendations)
✅ 保存が完了しました (180行)
✅ レポート生成完了: compliance/constitutional-compliance-report.md (430行)
全セクション完了。
Final: レポート生成完了サマリー
🤖 ✨ 憲法違反レポートの生成が完了しました!
## 📊 コンプライアンスサマリー
- **合格ゲート**: 7/9 (77.8%)
- **不合格ゲート**: 2/9 (22.2%)
- **ステータス**: ❌ BLOCKED
## 📂 生成されたレポート
✅ compliance/constitutional-compliance-report.md (5セクション)
# Constitutional Compliance Report
**Feature**: User Authentication
**Date**: 2025-11-16
**Enforcer**: constitution-enforcer
## Executive Summary
- **Gates Passed**: 7/9 (77.8%)
- **Gates Failed**: 2/9 (22.2%)
- **Overall Status**: ❌ BLOCKED
## Failed Gates
### Gate 3: Integration-First Gate
- **Issue**: Tests use mock database instead of real PostgreSQL
- **Article**: Article IX - Integration-First Testing
- **Severity**: HIGH
- **Remediation**: Replace mocks with Testcontainers PostgreSQL
### Gate 5: Traceability Gate
- **Issue**: REQ-003 (2FA) not implemented (66.7% coverage)
- **Article**: Article V - Traceability Mandate
- **Severity**: CRITICAL
- **Remediation**: Implement REQ-003 or defer to next release
## Recommendations
1. **CRITICAL**: Achieve 100% traceability (invoke traceability-auditor)
2. **HIGH**: Replace mock database with real database in tests
3. **MEDIUM**: Document exceptions in `complexity-tracking.md`
## Approval Status
❌ **BLOCKED** - Implementation cannot proceed until critical failures are addressed.
Phase 5: Remediation Coordination
If failures detected:
- Notify orchestrator of blocking issues
- Recommend which skills to invoke for remediation
- Re-run validation after fixes applied
Integration with Other Skills
- Before: Runs BEFORE software-developer, test-engineer
- After:
- If PASS → Implementation proceeds
- If FAIL → orchestrator triggers remediation skills
- Uses:
- requirements-analyst output (EARS validation)
- traceability-auditor output (traceability validation)
- steering files (alignment validation)
Best Practices
- Enforce Early: Run Phase -1 Gates before any code is written
- Fail Fast: Block implementation immediately if critical gates fail
- Document Exceptions: All justified violations must be in
complexity-tracking.md - Automate: Integrate into CI/CD pipeline for continuous enforcement
- Review Regularly: Revisit constitutional compliance monthly
Output Format
# Phase -1 Gates Validation Report
**Feature**: [Feature Name]
**Date**: [YYYY-MM-DD]
**Status**: ✅ APPROVED / ❌ BLOCKED
## Gates Summary
| Gate | Article | Status | Notes |
| ------------------ | ------- | ------- | ------------------------ |
| Simplicity | VII | ✅ PASS | Using 1 monorepo |
| Anti-Abstraction | VIII | ✅ PASS | No framework wrappers |
| Integration-First | IX | ❌ FAIL | Using mocks |
| EARS Compliance | IV | ✅ PASS | All requirements in EARS |
| Traceability | V | ❌ FAIL | 66.7% coverage |
| Steering Alignment | VI | ✅ PASS | Follows steering |
| Library-First | I | ✅ PASS | lib/auth/ created |
| CLI Interface | II | ✅ PASS | CLI implemented |
| Test-First | III | ✅ PASS | Tests before code |
## Decision
❌ **BLOCKED** - 2 critical failures must be addressed.
## Remediation Plan
1. Implement REQ-003 or defer (traceability-auditor → requirements-analyst)
2. Replace mocks with Testcontainers (test-engineer)
3. Re-run constitution-enforcer after fixes
## Approval Authority
Once all gates pass:
- [ ] Constitution Enforcer approval
- [ ] Project Manager approval
- [ ] Proceed to implementation
Guardrails Commands (v3.9.0 NEW)
Use these commands to enforce constitutional compliance programmatically:
| Command | Purpose | Example |
|---|---|---|
musubi-validate guardrails --type safety |
Validate content against safety rules | npx musubi-validate guardrails "content" --type safety |
musubi-validate guardrails --type safety --constitutional |
Full constitutional validation | npx musubi-validate guardrails "code" --type safety --constitutional |
musubi-validate guardrails --type input |
Validate input against injection attacks | npx musubi-validate guardrails "input" --type input |
musubi-validate guardrails-chain |
Run full guardrail chain | npx musubi-validate guardrails-chain "content" --parallel |
Constitutional Safety Levels:
--level low- Permissive (development)--level medium- Balanced (default)--level high- Strict (production)--level critical- Maximum (security-critical)
Use with Constitution Validation:
# Validate code against constitutional articles
npx musubi-validate guardrails "$(cat src/feature.js)" --type safety --constitutional --level high
# Check multiple files
npx musubi-validate guardrails --type safety --constitutional --file src/**/*.js
Project Memory Integration
ALWAYS check steering files before starting:
steering/rules/constitution.md- The 9 Constitutional Articlessteering/structure.md- Verify library-first patternsteering/tech.md- Verify stack alignment
Validation Checklist
Before finishing:
- All 9 articles validated
- All Phase -1 Gates executed
- Failures documented with severity
- Remediation plan provided
- Overall status determined (APPROVED/BLOCKED)
- Report saved to
storage/features/[feature]/constitutional-compliance.md