enforcement-audit-and-upgrade
Audit existing enforcement infrastructure, identify gaps between advisory and strict modes, create hard-gate scripts, and incrementally roll out enforcement. Pattern from
Best use case
enforcement-audit-and-upgrade is best used when you need a repeatable AI agent workflow instead of a one-off prompt.
Audit existing enforcement infrastructure, identify gaps between advisory and strict modes, create hard-gate scripts, and incrementally roll out enforcement. Pattern from
Teams using enforcement-audit-and-upgrade should expect a more consistent output, faster repeated execution, less prompt rewriting.
When to use this skill
- You want a reusable workflow that can be run more than once with consistent structure.
When not to use this skill
- You only need a quick one-off answer and do not need a reusable workflow.
- You cannot install or maintain the underlying files, dependencies, or repository context.
Installation
Claude Code / Cursor / Codex
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/enforcement-audit-and-upgrade/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How enforcement-audit-and-upgrade Compares
| Feature / Agent | enforcement-audit-and-upgrade | Standard Approach |
|---|---|---|
| Platform Support | Not specified | Limited / Varies |
| Context Awareness | High | Baseline |
| Installation Complexity | Unknown | N/A |
Frequently Asked Questions
What does this skill do?
Audit existing enforcement infrastructure, identify gaps between advisory and strict modes, create hard-gate scripts, and incrementally roll out enforcement. Pattern from
Where can I find the source code?
You can find the source code on GitHub using the link provided at the top of the page.
SKILL.md Source
# Enforcement Audit and Upgrade Pattern ## Overview Audit enforcement infrastructure, find the gap between what exists and what actually blocks, then incrementally upgrade from advisory to strict mode. ## Key Finding: Advisory Mode Is No Enforcement Scripts that print warnings but exit 0 are NOT enforcement. Real enforcement must exit 1 to block the operation. Every existing enforcement mechanism defaults to advisory mode. ## Audit Checklist 1. **Find all enforcement scripts**: `ls scripts/enforcement/` 2. **Find all git hooks**: `ls .git/hooks/ | grep -v sample` 3. **Find all Codex hooks**: `ls .Codex/hooks/` + check `.Codex/settings.json` 4. **Read each script**: Does it exit 0 (advisory) or exit 1 (blocking)? 5. **Check default mode**: What happens when no env vars are set? 6. **Check hook chain**: Is the enforcement script actually called by the hooks? 7. **Check compliance logs**: `cat logs/hooks/*.jsonl | tail -20` 8. **Run compliance dashboard**: `bash scripts/enforcement/compliance-dashboard.sh` ## Implementation Pattern ### Step 1: Audit existing infrastructure ```bash # Map what exists ls scripts/enforcement/ ls .git/hooks/ | grep -v sample ls .Codex/hooks/ cat .Codex/settings.json | grep -A5 hooks ``` ### Step 2: Identify the gap Look for: - Scripts that warn but allow (exit 0 instead of exit 1) - Hooks that don't call enforcement scripts - Missing enforcement scripts (e.g., no pre-commit plan gate) - Compliance metrics far below threshold ### Step 3: Create hard-gate scripts Three types needed: 1. **require-plan-approval.sh** — pre-commit gate 2. **compliance-dashboard.sh** — metrics and reporting 3. **upgrade-enforcement.sh** — safe transition script ### Step 4: Gradual rollout Week 1: Plan gate strict, review gate advisory Week 2: Review gate strict for engineering-critical only Week 3: Full strict mode Week 4: CI integration (GitHub Actions) ### Step 5: Document and link Create methodology docs in `docs/methodology/`: - compound-engineering.md (the full methodology) - enforcement-over-instruction.md (why gates beat text) - Links to all related issues ## Pitfalls ### Compliance metrics are worse than expected The audit often reveals compliance is much lower than assumed. Document the real numbers (e.g., 4%) — this is the baseline, use it to justify strict mode. ### Bypass mechanisms already exist Existing scripts support env var bypass (`SKIP_REVIEW_GATE=1`, `GIT_PRE_PUSH_SKIP=1`). Don't remove them — they're safety valves. Log every bypass attempt instead. ### Codex hooks and git hooks are different enforcement levels Codex PreToolUse hooks only intercept specific tool calls (Write, Edit, Bash). They don't intercept direct git commit/push. Git hooks (.git/hooks/) catch everything. Both are needed. ### Don't go strict on everything at once Sudden strict mode breaks workflows. Use the upgrade shell script for gradual rollout. Start with the easiest gate to satisfy (plan approval), then escalate. ## Verification After deployment: ```bash # Test plan gate blocks without approval FORCE_PLAN_GATE_STRICT=1 bash scripts/enforcement/require-plan-approval.sh --check # Test compliance dashboard generates report bash scripts/enforcement/compliance-dashboard.sh # Check logging works cat logs/hooks/plan-gate-events.jsonl 2>/dev/null || echo "No events yet" ```
Related Skills
llm-wiki-audit-feedback-loop
Durable feedback loop for correcting llm-wiki pages without losing the correction to chat history. Use when (1) a human notices a wiki page is wrong, outdated, or contradicts a source, (2) processing the `audit/` inbox of a domain wiki, (3) reviewing what feedback has been resolved vs deferred, (4) needing to leave a comment on a specific text range that survives line- number drift. Implements the anchored-text audit file pattern from lewislulu/llm-wiki-skill, adapted for workspace-hub's domain-wiki layout under /mnt/local-analysis/llm-wiki/wikis/<domain>/. Extends the 5-op model (compile/ingest/query/lint) from research/llm-wiki with the missing `audit` op. Never silently delete feedback — rejected audits stay archived with rejection rationale.
pre-completion-cleanup-audit
Audit and dispose of session residue (orphan files, scratch dirs, sibling-repo state, locks, trash-stages) BEFORE claiming a task complete. Required gate before any agent says "all done", "task complete", or hands work back to user/orchestrator.
repo-mission-portfolio-audit
Audit the workspace-hub repo portfolio to extract each repo's mission, identify documentation gaps, and prioritize a plan/approval sequence with explicit LLM-wiki weighting for future issue triage.
provider-session-ecosystem-audit-and-exporters
Build and maintain cross-provider session-log audits for Codex, Codex, Hermes, and Gemini, including exporter design, normalization, and behavioral verification.
orcawave-orcaflex-readiness-audit
Audit the real readiness of digitalmodel OrcaWave/OrcaFlex spec-driven workflows by reconciling workspace-hub issues, source/tests, semantic-equivalence boundaries, and wiki synthesis gaps.
read-only-pre-implementation-audit
Systematic cross-check workflow to validate assumptions before TDD coding begins
provider-audit-bootstrap-and-path-classification
Fix provider-session ecosystem audit failures caused by source-checkout imports and over-aggressive symbolic-path classification.
gtm-site-readiness-audit-local-vs-production
Audit GTM feature work by separating local artifact readiness from production deployment state, then fix common blockers in aceengineer-website and GTM collateral.
gsd-operational-audit
Audit a repo's live GSD/get-shit-done workflow state against docs, issues, and runtime outputs to find stale issues, automation reliability gaps, parser drift, migration residue, and policy contradictions.
github-issue-label-existence-audit
Prevent GitHub issue creation failures by auditing exact label existence, duplicate titles, and partial-create risk before calling gh issue create.
github-issue-label-audit-and-command-bundles
Safely turn drafted issue bodies into reusable gh issue create commands by auditing repo labels, exact duplicates, and auth first.
orcaflex-spec-audit
Audit, classify, and score OrcaFlex spec.yml files across the model library for quality, schema validity, and structure type categorization.