UB Governance

Overview

Use this skill as the owner for governance in the current repository or project where it is adopted.

This skill should stay lean for ordinary workflow-backed work and should only activate heavier controls when the selected mode or scope actually requires them.

Embedded Contract

These rules are the base contract of this skill and must not depend on a secondary document to be applied correctly.

Default to the
```
lean
```
profile unless the user explicitly requests
```
advanced
```
with rationale.
Use only these governance gate states:
```
pass
```
,
```
fail
```
,
```
blocked
```
.
Every bounded exception must include
```
owner
```
,
```
rationale
```
,
```
created_at
```
,
```
expires_at
```
, and
```
follow_up
```
.
For ordinary Level 1 workflow-backed work, treat workflow artifacts as the default durable operational record.
Escalate to ADR and claim machinery only when the decision is durable beyond one initiative, repository-wide, high-risk, or explicitly governed at Level 2.
Keep blocking governance decisions tied to deterministic artifacts.

Operating Modes

```
repository mode
```
: repository hygiene, CI and release governance, branch or ruleset policy, deterministic tooling
```
testing mode
```
: behavior-first TDD governance and low-signal testing anti-pattern review
```
evidence mode
```
: evidence lifecycle, ADR alignment, claim verification, and gate readiness
```
core-contract mode
```
: shared profile, gate, exception, and report semantics
```
full governance audit mode
```
: run repository, testing, and evidence checks in one deterministic sequence

Testing Signal Model

Use descriptive names in normal guidance. Keep the numeric IDs as stable internal codes for tooling and compatibility.

Blocking signals:

```
Type Redundancy
```
(
```
TG001
```
): runtime tests that restate type-system guarantees
```
Interaction Without Outcome
```
(
```
TG002
```
): interaction assertions without observable outcome assertions
```
Pass-Through Test
```
(
```
TG003
```
): trivial getter or setter pass-through tests
```
Happy-Path-Only Suite
```
(
```
TG004
```
): repeated happy-path focus without boundary or error representation

Warning-only signal:

```
Internal-Detail Bias
```
(
```
TG005
```
): probable verification of internal details over public behavior

Functional-realism signals use risk-scaled guidance rather than automatic new gates:

```
Local Source Mocking
```
(
```
TG006
```
): a test replaces local application source involved in the behavior under review
```
Uncontracted Test Double
```
(
```
TG007
```
): a mock, stub, fake, fixture, or route intercept has no visible boundary reason or contract evidence
```
Mock-Dominant Test
```
(
```
TG008
```
): the test is mostly double setup or call assertions instead of observable outcomes
```
Missing Functional Guard
```
(
```
TG009
```
): risky behavior lacks a public-surface functional, integration, contract, component, or E2E check
```
Mutation Survivor on Changed Logic
```
(
```
TG010
```
): changed critical logic has unreviewed surviving mutants when mutation evidence is already in scope
```
Snapshot/Coverage-Only Proof
```
(
```
TG011
```
): behavior change relies only on snapshots, render smoke, coverage, or does-not-throw proof

Load References By Trigger

Use these load tiers literally. If a trigger is not active, do not read the reference just because it exists.

```
[phase:decision-boundary]
```
Read
```
references/decision-memory-and-claims.md
```
when deciding whether workflow artifacts are sufficient or ADR and claim escalation is required.
```
[phase:testing-mode]
```
Read
```
references/testing-policy-and-signals.md
```
when reviewing testing policy or applying the testing anti-pattern model.
```
[phase:testing-mode]
```
Read
```
references/execution-playbook.md
```
when the task is about TDD execution order, regression-first bug fixing, or testing workflow hygiene.
```
[phase:command-or-audit]
```
Read
```
references/governance-commands.md
```
when the user asks how to run checks or an audit path is being executed.
```
[edge:glossary-or-normalization]
```
Read
```
references/vocabulary.md
```
only when glossary help or wording normalization matters.

[edge:repository-mode]

Read

references/repository-baseline.md

references/github-implementation-playbook.md

, and

references/release-please-playbook.md

only when repository governance is actually in scope.

[edge:evidence-level-2]

Read

references/evidence-baseline.md

references/evidence-lifecycle.md

references/evidence-artifact-taxonomy.md

references/ci-artifact-contract.md

, and

references/stack-baseline.md

only when explicit Level 2 or evidence-heavy governance is active.

[edge:schema-or-data]

Read

references/high-risk-paths.yaml

references/agent-validation-record.schema.json

references/adr-registry.schema.json

references/claim-register.schema.json

, and

references/adr-template-madr.md

only when those concrete artifacts are being authored or validated.

[edge:authoring-conventions]

Read

../ub-authoring/references/authoring-conventions.md

only when adjusting routing or shared authoring structure.

Core Workflow

Detect the requested governance mode and evaluated scope from repository truth.
Select profile:
```
lean
```
by default,
```
advanced
```
only with explicit rationale.
For ordinary workflow-backed work, prefer the Level 1 fast path and keep the durable record in workflow artifacts.
Escalate only when the decision scope, risk, or explicit governance run requires it.
Run the selected mode's controls and keep outputs deterministic.
Apply bounded exceptions only through the canonical exception contract.
Emit a traceable gate outcome with artifact paths.

Quick Examples

```
Does this auth change need an ADR or claim work?
```
Use
```
evidence mode
```
and the decision-boundary reference to decide whether ordinary workflow artifacts are sufficient or whether the change is truly repository-wide, high-risk, or Level 2.
```
Are these tests mostly checking mock calls without user-visible outcome assertions?
```
Use
```
testing mode
```
, apply the test-signal model, and treat likely
```
TG002
```
findings as blocking only when the suite is asserting interaction without externally observable outcome.
```
Show me the host repository's maintenance checks for README, AGENTS, and skill schema.
```
Do not route that through governance. Those checks belong to the host repository's own maintenance/check surface.

When Not To Use

Do not use this skill for workflow intake, PRD shaping, roadmap generation, sprint preparation, or resumable initiative orchestration; defer those to
```
ub-workflow
```
.
Do not use this skill as the primary surface for framework-specific implementation guidance when the task is about code changes rather than governance policy or gate semantics.
Do not use this skill as a generic documentation-normalization layer when
```
ub-quality
```
is the actual owner of the task.

Mode Workflows

Repository Mode

verify repository baseline artifacts and deterministic tooling policy
verify CI, permissions, and merge-gate controls
verify release policy with Conventional Commits and
```
release-please
```

Testing Mode

detect stack and test runner
treat reported defects as regression-first work before code fixes are accepted
enforce
```
TG001
```
through
```
TG004
```
as blocking and
```
TG005
```
as warning-only
apply
```
TG006
```
through
```
TG011
```
as functional-realism guidance, escalating only when risk, evidence level, or explicit gate scope justifies it
require behavior-first TDD flow for behavior-changing work
keep testing guidance readable, boundary-aware, and deterministic without turning advisory guidance into new gates

Evidence Mode

classify
```
changeType
```
,
```
evidenceLevel
```
, and
```
profile
```
detect high-risk path impact when the scope requires it
choose the lightest durable record that matches the decision scope
treat workflow-backed initiative artifacts as the default operational record for ordinary Level 1 work
escalate to ADR alignment only when Level 2, repository-wide durable decisions, or explicit high-risk governance applies
require claim-register validation only when blocking rationale depends on claims
validate required artifacts and freshness for the selected path

Core-Contract Mode

apply canonical profile, gate, exception, and report semantics
normalize status language and report contract usage
reject duplicate or conflicting schema definitions

Full Governance Audit Mode

execute
```
repository mode
```
execute
```
testing mode
```
execute
```
evidence mode
```
consolidate output under canonical report sections

Rules

Keep defaults lean and activate advanced controls explicitly.
Do not imply that repository ADR machinery is the default record for ordinary Level 1 workflow-backed work.
Exception metadata must stay bounded, explicit, and time-limited.
Do not duplicate canonical contract definitions across files when the main skill already embeds the short rule.
Repository-maintenance tooling is not automatically the same thing as lean governance guidance.

Output Requirements

When producing non-trivial governance output, include:

```
environment_note
```
```
scope_note
```
```
decision_note
```
```
gate_note
```
```
exception_note
```
```
validation_note
```

Add mode-specific sections when applicable:

```
quality_gate_note
```
for testing mode
```
evidence_inventory
```
and
```
claim_note
```
for evidence mode

Completion Checklist

Selected mode is explicit.
Profile choice is explicit (
```
lean
```
or
```
advanced
```
).
The ordinary Level 1 fast path versus Level 2 escalation path is explicit.
Required deterministic artifacts are present or explicitly missing.
Gate result is traceable and reproducible.
Exceptions use the canonical fields and remain bounded.
Governance guidance stays self-contained and internally consistent.

ub-governance

NPX Install

Tags

SKILL.md Content

UB Governance

Overview

Embedded Contract

Operating Modes

Testing Signal Model

Load References By Trigger

Core Workflow

Quick Examples

When Not To Use

Mode Workflows

Repository Mode

Testing Mode

Evidence Mode

Core-Contract Mode

Full Governance Audit Mode

Rules

Output Requirements

Completion Checklist