constitution-enforcer
Skill74 starsChanged 10 months agoMITView on GitHub
Validates compliance with 9 Constitutional Articles and Phase -1 Gates before implementation.
We split this skill into the rules it gives an agent
15 rules. About 0 are common, 14 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈14
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 35
Article Enforcement: Check compliance with each constitutional article
- Distinctive: line 37
Complexity Tracking: Document justified exceptions
- Distinctive: line 44
Rule: Every feature MUST begin as a standalone library.
- Distinctive: line 65
Rule: All libraries MUST expose CLI interfaces.
- Distinctive: line 108
Rule: All requirements MUST use EARS patterns.
- Distinctive: line 154
Rule: All skills MUST check steering before work.
- Distinctive: line 199
Rule: Use framework features directly, single model representation.
- Distinctive: line 221
Rule: Prefer real databases over mocks, contract tests mandatory before implementation.
- Distinctive: line 361
Check relevant artifacts (requirements, design, code, tests)
- Distinctive: line 367
Run all Phase -1 Gates:
- Distinctive: line 517
If PASS → Implementation proceeds
- Distinctive: line 518
If FAIL → orchestrator triggers remediation skills
- Distinctive: line 526
Enforce Early: Run Phase -1 Gates before any code is written
- Very specific: line 528
Document Exceptions: All justified violations must be in complexity-tracking.md
- Distinctive: line 576
Use these commands to enforce constitutional compliance programmatically:
≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
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 abstractionArticle 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 pointArticle 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 firstArticle 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 stackArticle 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 justificationArticle 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 PrismaArticle 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 databasePhase -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 implementationGuardrails 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/**/*.jsProject 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/specs/[feature]-constitutional-compliance.md
In this repository28 other files it gives its agents.
- AGENTS.mdAGENTS.md
- .claude/AGENTS.mdAGENTS.md
- .github/AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- ai-ml-engineerSkill
- api-designerSkill
- bug-hunterSkill
- change-impact-analyzerSkill
- cloud-architectSkill
- code-reviewerSkill
- database-administratorSkill
- database-schema-designerSkill
- devops-engineerSkill
- orchestratorSkill
- performance-optimizerSkill
- project-managerSkill
- quality-assuranceSkill
- release-coordinatorSkill
- requirements-analystSkill
- security-auditorSkill
- site-reliability-engineerSkill
- software-developerSkill
- steeringSkill
- system-architectSkill
- technical-writerSkill
- test-engineerSkill
- traceability-auditorSkill
- ui-ux-designerSkill
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
Reviews can't be read right now.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

