Wolf Governance Skill

This skill provides access to Wolf's governance framework, including compliance requirements, quality gates, approval hierarchies, and process standards refined over 50+ phases of development.

When to Use This Skill

• •REQUIRED before making architectural or process changes
• •When checking compliance requirements for work
• •For understanding approval and review requirements
• •When determining quality gates that must pass
• •For escalation and authority questions

Core Governance Framework

The Four Pillars (Canon Charter)

All governance decisions are evaluated against these foundational principles:

1. •

   Portability 🔄

   • •Cross-environment compatibility
   • •System adaptability
   • •Platform independence
   • •Provider agnosticism
2. •

   Reproducibility 🔁

   • •Consistent outcomes
   • •Predictable behavior
   • •Deterministic processes
   • •Verifiable results
3. •

   Safety 🛡️

   • •Risk mitigation
   • •Secure operations
   • •Fail-safe mechanisms
   • •Progressive validation
4. •

   Research Value 🔬

   • •Scientific methodology
   • •Knowledge advancement
   • •Evidence-based decisions
   • •Learning capture

Authority Structure

Decision Authority Hierarchy

Code Reviewers:
  - Final merge authority
  - Architectural decisions
  - Technical standards
  - Pattern enforcement

PM Agents:
  - Requirements authority
  - Prioritization decisions
  - Workflow coordination
  - Release sign-off

Specialist Roles:
  - Domain expertise
  - Comment-only reviews
  - Advisory input
  - Escalation triggers

Implementers:
  - Cannot merge own PRs
  - Cannot bypass gates
  - Cannot grant exceptions
  - Must follow process

Separation of Concerns

MANDATORY: No agent can approve their own work

• •Implementers → Reviewers
• •Reviewers → Different reviewer for meta-reviews
• •PM defines requirements → Cannot implement
• •Security can block any change

Quality Gates

Definition of Done (DoD)

MUST have (blocking):

• •✅ All tests passing
• •✅ Code review approved
• •✅ Documentation updated
• •✅ Journal entry created
• •✅ CI/CD checks green
• •✅ Proper Git/GitHub workflow followed
  • •Feature branch used (never main/master/develop)
  • •Draft PR created at task start (not task end)
  • •No direct commits to default branches
  • •Project conventions respected (templates, naming)
  • •Prefer gh CLI over git commands where available
• •✅ PR is appropriately sized (incremental PR strategy)
  • •<500 lines of actual code (excluding tests/docs)
  • •<30 files changed
  • •Provides stand-alone value (can merge without breaking main)
  • •Can be explained in 2 sentences (clear, focused scope)
  • •Can be reviewed in <1 hour
  • •If multi-PR feature: Sequence documented in first PR
  • •Reference: wolf-workflows/incremental-pr-strategy.md

SHOULD have (strong recommendation):

• •📊 Performance benchmarks met
• •🔒 Security scan clean
• •♿ Accessibility validated
• •📈 Metrics improved

MAY have (optional):

• •🎨 UI/UX review
• •🌍 Internationalization
• •📱 Mobile testing

Two-Tier Test Pipeline

Fast-Lane (5-10 minutes)

Purpose: Rapid iteration and basic validation

Requirements:

• •Linting: Max 5 errors allowed
• •Unit tests: 60% coverage minimum
• •Critical integration tests pass
• •Security: 0 critical, ≤5 high vulnerabilities
• •Smoke tests: Core services start

Full-Suite (30-60 minutes)

Purpose: Production readiness validation

Requirements:

• •E2E tests: 90% success rate
• •Performance: Score ≥70/100
• •Security: Score ≥80/100
• •Cross-platform: Node 18/20/21 compatible
• •Migration: Rollback procedures tested

Good/Bad Examples: Definition of Done

Example 1: Feature Pull Request

✅ All MUST-have items complete:

• •Tests: 47 tests passing (unit + integration + E2E)
  • •Fast-Lane: ✅ 8min, 0 linting errors, 85% coverage
  • •Full-Suite: ✅ 45min, 95% E2E success, perf 75/100, security 85/100
• •Review: Approved by @code-reviewer-agent (not self-approved)
• •Documentation:
  • •README.md updated with auth setup instructions
  • •API.md documents new endpoints
  • •CHANGELOG.md entry added
• •Journal: 2025-11-14-user-authentication.md created
  • •Problems: OAuth token refresh edge case
  • •Decisions: Chose JWT over sessions for scalability
  • •Learnings: Auth middleware testing patterns
• •CI: All checks green ✅

✅ SHOULD-have items addressed:

• •Performance: Login latency <200ms (target: <300ms) ✅
• •Security: OAuth2 threat model documented, scan clean ✅
• •Metrics: Login success rate tracking added ✅

Assessment: Meets Definition of Done. ✅ Ready to merge. </Good>

❌ Missing MUST-have items:

• •Tests: "Tests pass on my machine" (no CI evidence)
  • •Fast-Lane: Not run
  • •Full-Suite: Skipped "to save time"
• •Review: Self-approved "since it's urgent"
• •Documentation: "Will update later"
• •Journal: No entry created
• •CI: Checks failing (linting errors, 2 test failures)

❌ Governance violations:

• •Merged own PR (violates separation of concerns)
• •Skipped quality gates "because it's a hotfix"
• •No root cause analysis (reliability-fixer archetype requirement)
• •No regression test added

Assessment: Does NOT meet Definition of Done. ❌ Should be reverted and reworked.

Why this is wrong:

• •Hotfixes still require governance (use expedited review, not no review)
• •Self-approval violates authority structure
• •Skipping tests means bug might not actually be fixed
• •No journal = no learning capture = problem will recur </Bad>

Example 2: Security Change

✅ Security-hardener archetype requirements:

• •Threat Model: docs/security/rate-limiting-threats.md
  • •Attack vectors documented
  • •Mitigation strategies defined
  • •Residual risks assessed
• •Security Scan: ✅ 0 critical, 2 high (false positives documented)
• •Penetration Test: Manual testing results in journal
• •Defense-in-Depth: Multiple layers (IP-based, user-based, endpoint-based)

✅ Standard DoD:

• •Tests: Rate limit scenarios covered (100% of rate limit logic)
• •Review: Approved by @security-agent + @code-reviewer-agent
• •Documentation: Rate limit policies documented
• •Journal: 2025-11-14-rate-limiting-implementation.md
• •CI: All gates green including security gates

✅ ADR created:

• •ADR-042-rate-limiting-strategy.md documents algorithm choice

Assessment: Exemplary security change. ✅ All gates passed. </Good>

❌ Security-hardener failures:

• •Threat Model: "Encryption is obviously good" (no actual model)
• •Security Scan: Skipped "because I used a well-known library"
• •Penetration Test: None performed
• •Defense-in-Depth: Single layer only

❌ Code quality issues:

• •Using deprecated crypto algorithm (MD5 for hashing)
• •Hardcoded encryption keys in code
• •No key rotation mechanism
• •Error messages leak sensitive info

❌ Missing standard DoD:

• •Tests: Only happy path tested
• •Review: Only one approval (needs security-agent review)
• •Documentation: No encryption policy documented
• •Journal: No entry
• •ADR: No architecture decision documented

Assessment: Critical security issues. ❌ Must be blocked and reworked.

Why this is dangerous:

• •Wrong crypto creates false sense of security
• •Hardcoded keys = security theater
• •No threat model = don't understand what we're protecting against
• •Missing security-agent review = no domain expert validation </Bad>

Example 3: Refactoring

✅ Maintainability-refactorer archetype requirements:

• •Complexity Reduction: Cyclomatic complexity 15 → 6 (documented)
• •Test Coverage: Maintained at 85% (no regression)
• •Behavior Unchanged: All tests still pass (no behavior changes)

✅ Evidence-based changes:

• •Before metrics: 150 LOC, complexity 15, 4 code smells
• •After metrics: 95 LOC, complexity 6, 0 code smells
• •Performance: No degradation (latency unchanged)

✅ Standard DoD:

• •Tests: All existing tests pass + new tests for extracted functions
• •Review: Approved by @code-reviewer-agent
• •Documentation: Code comments improved, architecture notes updated
• •Journal: 2025-11-14-auth-middleware-refactor.md
  • •Decisions: Extracted 3 functions for clarity
  • •Learnings: Middleware composition patterns
• •CI: All gates green

Assessment: Clean refactoring. ✅ Improves maintainability without risk. </Good>

❌ Refactoring violations:

• •Behavior Changed: Added "small feature" during refactor
• •Test Coverage: Dropped from 85% → 60%
• •No Metrics: Can't prove complexity improved

❌ Mixed concerns:

• •Refactoring + feature + bug fix in one PR
• •847 lines changed across 23 files
• •No clear focus or archetype

❌ Missing DoD:

• •Tests: 12 tests now failing "will fix in follow-up"
• •Review: "Just cleanup, no review needed"
• •Documentation: Not updated to reflect changes
• •Journal: No entry

Assessment: Dangerous refactoring. ❌ Reject and split into focused PRs.

Why this fails:

• •Mixed refactor + feature = impossible to review safely
• •Dropping coverage during refactor = introducing bugs
• •Behavior change during refactor = violates maintainability-refactorer archetype
• •No metrics = can't prove improvement </Bad>

Process Requirements

Phase Lifecycle (Canonical)

Every phase MUST follow:

1. •

   Seed Brief 📋

   • •Problem statement
   • •Success criteria
   • •Risk assessment
   • •Resource allocation
2. •

   Pre-Phase Sweeps 🔍

   • •Dependency check
   • •Conflict resolution
   • •Environment preparation
   • •Baseline metrics
3. •

   Shard Work ⚡

   • •Incremental delivery
   • •Continuous validation
   • •Journal updates
   • •Progress tracking
4. •

   Close-Out Sweeps ✅

   • •Consolidation
   • •Verification
   • •Documentation
   • •Learning capture

Journal Requirements

MANDATORY for all work:

## Problems
- Issues encountered
- Blockers identified
- Unexpected behaviors

## Decisions
- Choices made
- Trade-offs accepted
- Rationale documented

## Learnings
- Patterns discovered
- Improvements identified
- Knowledge gained

Format: YYYY-MM-DD-<kebab-slug>.md

ADR (Architecture Decision Record)

Required for:

• •Architectural changes
• •Process modifications
• •Tool selections
• •Major refactoring

Format:

# ADR-XXX: Title

## Status
[Proposed | Accepted | Deprecated | Superseded]

## Context
[Problem description]

## Decision
[What was decided]

## Consequences
[Trade-offs and impacts]

Compliance Matrix

By Change Type

By Risk Level

Governance Enforcement

Automated Checks

Pre-commit:
  - Linting
  - Format validation
  - Secrets scanning

CI Pipeline:
  - Test execution
  - Coverage validation
  - Security scanning
  - Performance checks

Pre-merge:
  - Review approval
  - Gate validation
  - Documentation check
  - Journal verification

Manual Reviews

Required human validation:

• •Architecture alignment
• •Business logic correctness
• •Security implications
• •UX impact

Change Management

Canon Charter Changes

HIGHEST GOVERNANCE LEVEL

• •Research analysis required
• •ADR documentation mandatory
• •Multi-stakeholder review
• •30-day comment period

Lifecycle Changes

• •ADR required
• •Architect approval
• •Code Reviewer approval
• •Backward compatibility analysis

Policy Updates

• •Impact assessment
• •Migration plan if breaking
• •Communication plan
• •Grace period for adoption

Escalation Paths

Technical Escalation

Developer → Code Reviewer → Architect → CTO

Process Escalation

Agent → PM → Orchestrator → Product Owner

Security Escalation

ANY → Security Agent → CISO → Executive

Emergency Override

Only for production incidents:

1. •Document override reason
2. •Apply temporary fix
3. •Create follow-up ticket
4. •Conduct post-mortem

Anti-Patterns (Forbidden)

❌ Process Violations

• •Skipping quality gates
• •Merging own PRs
• •Bypassing security scans
• •Ignoring test failures

❌ Authority Violations

• •Exceeding role boundaries
• •Granting unauthorized exceptions
• •Overriding specialist objections
• •Ignoring escalation requirements

❌ Documentation Violations

• •Missing journal entries
• •No ADR for architecture changes
• •Outdated documentation
• •No evidence for decisions

Governance Metrics

Compliance Indicators

• •Gate pass rate: >95%
• •Review turnaround: <4 hours
• •Journal compliance: 100%
• •ADR coverage: All major changes

Health Metrics

• •CI reliability: >99%
• •Test stability: >95%
• •Security score: >80/100
• •Documentation currency: <7 days

Scripts Available

• •check.js - Validate compliance for current work
• •gates.js - List applicable quality gates
• •escalate.js - Determine escalation path

Integration with Other Skills

• •wolf-principles: Governance implements principles
• •wolf-archetypes: Archetypes follow governance rules
• •wolf-roles: Roles have governance boundaries

Red Flags - STOP

If you catch yourself thinking:

• •❌ "Skipping quality gates to save time" - STOP. Gates exist because skipping them costs MORE time in rework and incidents.
• •❌ "This change is too small for governance" - Wrong. Small changes compound. All work follows governance.
• •❌ "I'll create the journal entry later" - NO. Journal entry is part of Definition of Done. Create it NOW.
• •❌ "Tests are passing locally, CI doesn't matter" - CI is the source of truth. Local != production.
• •❌ "I'm just fixing a typo, no review needed" - ALL changes need review. Separation of concerns is non-negotiable.
• •❌ "We can make an exception this time" - Exceptions become habits. Follow Advisory-First Enforcement (Principle 4).
• •❌ "Documentation can wait until after merge" - NO. Documentation is part of DoD. Must be complete BEFORE merge.
• •❌ "Merging my own PR is faster" - FORBIDDEN. You cannot approve your own work (Authority Structure).

STOP. Use Skill tool to load wolf-governance to check compliance requirements BEFORE proceeding.

After Using This Skill

REQUIRED NEXT STEPS:

Sequential skill chain - DO NOT skip steps

1. •

   REQUIRED NEXT SKILL: Use wolf-roles to understand role-specific compliance requirements

   • •Why: Governance defines WHAT must be done. Roles define WHO does it and HOW.
   • •Gate: Cannot execute governance without understanding role boundaries
   • •Tool: Use Skill tool to load wolf-roles
   • •Example: pm-agent validates acceptance criteria, coder-agent implements, code-reviewer approves
2. •

   REQUIRED NEXT SKILL: Use wolf-verification to set up verification checkpoints

   • •Why: Governance gates require verification. Verification skill provides three-layer validation (CoVe, HSP, RAG).
   • •Gate: Cannot claim compliance without verification evidence
   • •When: Always - verification is mandatory for all governance gates
   • •Example: Security gate requires threat model verification + scan validation
3. •

   REQUIRED BEFORE COMPLETION: Create compliance artifacts

   • •Journal Entry: YYYY-MM-DD-<kebab-slug>.md documenting problems, decisions, learnings
   • •ADR (if applicable): For architectural/process changes
   • •Evidence: Test results, security scans, performance benchmarks
   • •Gate: Cannot merge without complete artifact set

DO NOT PROCEED to merge without completing steps 1-3.

Verification Checklist

Before claiming governance compliance:

• • Archetype selected (from wolf-archetypes)
• • Quality gates identified for this work type
• • Definition of Done requirements understood
• • Role boundaries confirmed (from wolf-roles)
• • All MUST-have DoD items completed (tests, review, docs, journal, CI)
• • SHOULD-have items evaluated (performance, security, a11y, metrics)
• • Approval from authorized reviewer (not self-approval)
• • CI/CD checks green (not just local)

Can't check all boxes? Governance compliance incomplete. Return to this skill.

Governance Examples by Change Type

Example 1: Bug Fix (reliability-fixer archetype)

DoD Requirements:
✅ Root cause documented in journal
✅ Regression test added
✅ All tests passing (Fast-Lane + Full-Suite)
✅ Code review approved
✅ CI checks green

Gates:
- Fast-Lane: <10 min, linting ≤5 errors, 60% coverage
- Full-Suite: 90% E2E success, rollback tested
- Review: Code reviewer approval (not self)

Example 2: Feature (product-implementer archetype)

DoD Requirements:
✅ Acceptance criteria met (PM validation)
✅ Tests pass (unit + integration + E2E)
✅ Documentation updated (README, API docs)
✅ Journal entry created
✅ Performance benchmarks met

Gates:
- PM: Acceptance criteria validation
- Code Review: Technical quality + tests
- Security: Scan clean (if data handling involved)
- CI: Fast-Lane + Full-Suite green

Example 3: Security Change (security-hardener archetype)

DoD Requirements:
✅ Threat model documented
✅ Security scan clean
✅ Penetration test passed
✅ Defense-in-depth applied
✅ Monitoring/alerting added

Gates:
- Security Review: Threat model approved
- Security Scan: 0 critical, ≤5 high vulns
- Code Review: Implementation quality
- CI: Security gates + standard gates
- ADR: If architectural security decision

Emergency Override Procedure

ONLY for production incidents:

1. Document override reason immediately
2. Apply minimum necessary temporary fix
3. Create follow-up ticket for proper fix
4. Conduct post-mortem within 48 hours
5. Update governance if process failed

Override does NOT mean skip governance. It means parallel governance with expedited review.

Source: docs/governance/, Canon Charter, ADRs* Last Updated: 2025-11-14 Phase: Superpowers Skill-Chaining Enhancement v2.0.0