agentleFS
Sign inStart free
nseney1nseney1/Soma-Governance/skills/governance-auditor/SKILL.md

Governance Auditor

Skill4 starsChanged 12 days agoApache-2.0View on GitHub

Audits session transcripts against governance rules to produce a per-rule PASS/FAIL verdict table.

  • Deletes or force-pushes
  • Commits and pushes

1 other project uses a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

5 rules. About 0 are common, 3 are distinctive, and 2 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈3

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 2

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Ingest Session Transcript: Read transcript.jsonl (and transcript_full.jsonl if deep step inspection is required) for the specified session …

    line 15
  2. Distinctive:

    Load Active Governance Rules: Read all applicable rule files from the project or global governance directory.

    line 16
  3. Very specific:

    Inapplicable Penalties: Do not mark N/A rules as FAIL (e.g., scoring desktop-automation as failed on a backend CLI or headless project).

    line 52
  4. Distinctive:

    Fabricated Step Citations: Never fabricate or approximate step numbers—cite exact, observable transcript indices.

    line 53
  5. Distinctive:

    Auditing Uninstalled Rules: Do not audit against rules that were not active or installed during the session under review.

    line 54

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Governance Auditor

Role: Rule compliance auditor for agent sessions. Inspects session transcripts against installed governance rules, validates adherence across all critical sections, and produces a definitive PASS/FAIL scorecard with grounded step citations.

Workflow

  1. Ingest Session Transcript: Read transcript.jsonl (and transcript_full.jsonl if deep step inspection is required) for the specified session ID.
  2. Load Active Governance Rules: Read all applicable rule files from the project or global governance directory.
  3. Audit Rule Adherence: For each auditable rule section, evaluate transcript actions, tool calls, and command executions against compliance criteria.
  4. Produce Audited Scorecard: Generate a per-rule verdict table documenting verdict, empirical evidence, and concrete step numbers.

Audit Checks Matrix

RuleCheck Method
providence §2 (dependencies)Grep for pip/npm install without prior dependency file (package.json, requirements.txt) verification
providence §3 (read-before-write)Check if a read (${SLOT.TOOL_READ} or equivalent) strictly precedes an edit (${SLOT.TOOL_EDIT} / ${SLOT.TOOL_WRITE}) of the same file
providence §8 (env verification)Check for which python / shebang / config checks before any environment mutation
cost-optimization §3 (model tiers)Check subagent dispatches (${SLOT.TOOL_SUBAGENT}) to verify proper model tiering (${SLOT.MODEL_FAST} for research, etc.)
subagent-delegation §2 (parallel)Check for concurrent subagents targeting overlapping or identical files
git-workflow §2 (pre-push gate)Check if make test / pytest ran and succeeded before any git push
testing §4 (no ast.parse)Check for ast.parse or syntax-only checks without subsequent test execution
destructive-ops §1 (dry-run)Check for rm -rf / DROP TABLE or destructive mutations without preceding dry-run / user confirmation
desktop-automation §2 (coordinates)Check for hardcoded UI coordinates without screenshot verification or UI bounds checks

Output Format

## Governance Audit — Session [ID]

| Rule | Verdict | Evidence | Steps |
|:-----|:-------:|:---------|:------|
| providence §2 | ✅ PASS | No unverified package installs | — |
| providence §3 | ✅ PASS | All target files viewed before mutation | 12, 18, 34 |
| testing §4 | ❌ FAIL | ast.parse executed at steps 61-62 without subsequent test run | 61, 62 |
| desktop-automation §2 | ➖ N/A | Non-GUI project; desktop automation not applicable | — |

**Overall Score**: 8/9 applicable rules passed (88.9%)
**Critical Violations**: 1

Anti-Patterns & Failure Modes

  • Inapplicable Penalties: Do not mark N/A rules as FAIL (e.g., scoring desktop-automation as failed on a backend CLI or headless project).
  • Fabricated Step Citations: Never fabricate or approximate step numbers—cite exact, observable transcript indices.
  • Auditing Uninstalled Rules: Do not audit against rules that were not active or installed during the session under review.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

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.

Check your setup, free