claude-code-plugin-ref…
Explain plugin, skill, command, agent, and hook mechanics used here. Use when authoring or debugging plugins. Do not use for ops; use night-market-operations.
Classifies and enforces constraints via soft vows, hard vows, and Nen Court layers. Use when designing or auditing enforcement mechanisms for project rules.
$ npx -y skills add athola/claude-night-market --skill vow-enforcement --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
/vow-enforcementContext preview
The summary Claude sees to decide when to auto-load this skill.
Classifies and enforces constraints via soft vows, hard vows, and Nen Court layers. Use when designing or auditing enforcement mechanisms for project rules.
name: vow-enforcement description: Classifies and enforces constraints via soft vows, hard vows, and Nen Court layers. Use when designing or auditing enforcement mechanisms for project rules. alwaysApply: false category: workflow-methodology tags: - enforcement - constraints - hooks - compliance - governance dependencies: - imbue:proof-of-work - imbue:scope-guard - imbue:justify tools: [] usage_patterns: - constraint-classification - vow-graduation - compliance-auditing - enforcement-design complexity: intermediate model_hint: standard estimated_tokens: 2800 role: hook-target
> Rules that depend on willpower fail under pressure. > Enforcement earns trust by making the right path the > only path.
ODCV-Bench found that agents break self-imposed constraints 30-50% of the time when goals conflict. Practitioner consensus confirms: past 150 soft rules, compliance drops for ALL rules, not just the new ones.
The core insight: "settings.json is a firewall; CLAUDE.md is an employee handbook." Handbooks work for guidance. Firewalls work for enforcement. Mixing them up creates a false sense of security.
| Layer | Mechanism | Compliance | Examples | |-------|-----------|------------|---------| | **Soft Vow** | Skill instructions, CLAUDE.md rules | ~80% | "Write tests first", "Keep commits small" | | **Hard Vow** | Hooks (PreToolUse/PostToolUse), settings.json permissions | ~100% | Block `--no-verify`, enforce file size limits | | **Nen Court** | External validator agents checking output | Deterministic | Lint checks, test runs, constraint audits |
**Soft Vows** rely on model compliance. Cheap to add and easy to iterate, but unreliable under goal conflict. Use when the constraint requires judgment, violation is annoying but not dangerous, or you are still learning what the right rule is.
**Hard Vows** block forbidden actions before they execute via hooks and settings.json permissions. Use when the constraint is binary, violation causes real damage, or the soft vow version was violated repeatedly.
**Nen Court** spawns external validator agents that audit output after a phase completes. Use when the constraint requires analysis (not pattern matching), a hook cannot express the rule, or the check needs codebase context.
When adding a new constraint, follow this sequence:
Add the rule to the relevant skill or CLAUDE.md. This is the cheapest path: zero cost, minutes to deploy, ~80% compliance.
Track violations via execution logs, post-hoc audits (`imbue:justify` reports), user complaints, and Nen Court findings from related audits.
If violation rate exceeds 20% over a 30-day window:
positives exceed 10%, move to Nen Court.
Current classification of existing constraints:
| Constraint | Current Layer | Target Layer | Notes | |------------|--------------|--------------|-------| | Iron Law (no impl without failing test) | Nen Court | Nen Court | `validators/iron_law.py` audits commit order (#406) | | No `--no-verify` | Hard | Hard | Already hook-enforceable | | Scope-guard worthiness scoring | Soft | Soft | Requires judgment, not binary | | Proof-of-work evidence | Nen Court | Nen Court | `validators/proof_of_work.py` checks `[Ex]` refs and status (#406) | | Bounded discovery reads | Hard | Hard | `vow_bounded_reads.py` with `fcntl.flock` for parallel safety (#418) | | No AI attribution in commits | Hard | Hard | Hook pattern-matches git commit command | | Markdown line wrapping at 80 chars | Nen Court | Nen Court | `validators/markdown_wrap.py` flags >80-char prose lines (#406) | | No emojis in commits | Hard | Hard | Hook pattern-matches git commit command |
The three Nen Court validators are standalone scripts under `plugins/imbue/validators/`. Each reads JSON on stdin and writes a verdict JSON on stdout, using exit codes 0 (pass), 1 (violation), and 2 (inconclusive). Examples:
# Markdown wrap audit on a list of files
echo '{"files": ["README.md", "docs/guide.md"]}' \
| python plugins/imbue/validators/markdown_wrap.py
# Iron Law audit on an explicit commit log
echo '{"commits": [
{"sha": "abc", "ts": 100, "files": ["tests/test_x.py"]},
{"sha": "def", "ts": 200, "files": ["src/x.py"]}
]}' | python plugins/imbue/validators/iron_law.py
# Proof-of-work audit on agent output
echo '{"text": "Tested foo [E1] [E2] [E3]. Status: PASS.", "min_evidence": 3}' \
| python plugins/imbue/validators/proof_of_work.pyMission orchestrator integration: dispatch the appropriate validator at each phase boundary (see Nen Court Protocol below) and treat exit code 1 as a blocking gate, exit code 2 as advisory.
A vow graduates when any of these conditions hold:
1. **Frequency**: 3+ violations detected in 30 days 2. **Severity**: Single violation caused rollback, data loss, or broken CI 3. **User escalation**: User explicitly requests enforcement ("make it impossible to X")
1. Document the violation pattern with evidence 2. Design the hook or validator agent 3. Test the enforcement mechanism in isolation 4. Deploy alongside the soft vow (shadow mode) 5. After 1 week with no false positives, retire
A plugin marketplace for Claude Code. Install only the plugins you need to run git workflows, code review, spec-driven development, and autonomous agents from inside your Claude Code session.
Explain plugin, skill, command, agent, and hook mechanics used here. Use when authoring or debugging plugins. Do not use for ops; use night-market-operations.
States load-bearing decisions, invariants, and weak points. Use when judging a design change. Do not use for gating; use night-market-change-control.
Rebuild the dev environment: uv, Python tiers, pins, traps. Use when onboarding or toolchain breaks. Do not use for daily commands; use night-market-operations.
Classify, gate, and review changes. Use when landing a PR, releasing, or amending rules. Do not use for failure triage; use night-market-debugging-playbook.
Search and record project memory (Discussions, journal, ADRs). Use before re-investigating anything. Do not use for settled battles; see failure-archaeology.
Bind loop 'done' to unfakeable gates. Use to harden egregore/herald loops or promote completion_integrity. Not for QA gates; use night-market-validation-and-qa.