mif-provenance
Skill1 starsChanged 35 days agoMITView on GitHub
Stamp witnessed provenance into a MIF document's frontmatter from the hook-observed session ledger, verify an existing provenance block against it, or check whether capture is actually active for the current session — hook-observed facts only (agent, agentVersion, session activity URN), never model-asserted. Use after authoring a MIF document in a session with capture enabled, to make its provenance witnessed rather than asserted; use verify to detect drift between a document's provenance block and what the ledger actually observed; use status when you just enabled capture or updated this plugin and want to confirm hooks are actually wired before trusting anything gets stamped. Anti-trigger; for writing the rest of the frontmatter use mif-frontmatter (asserted provenance from drafting context), and for schema/level/round-trip conformance use mif-validate.
In this repository46 other files it gives its agents.
- academicSkill
- adrSkill
- ai-architecture-docSkill
- arc42-arch-docSkill
- audit-docsSkill
- briefingSkill
- business-planSkill
- c4-model-diagramSkill
- changelogSkill
- clinical-submissionSkill
- competitive-quadrantSkill
- compliance-auditSkill
- computing-paperSkill
- diataxis-explanationSkill
- diataxis-how-toSkill
- diataxis-referenceSkill
- diataxis-tutorialSkill
- doc-set-plannerSkill
- ears-acceptance-criteriaSkill
- engineeringSkill
- exec-summarySkill
- feature-specSkill
- google-design-docSkill
- humanities-chicagoSkill
- humanities-mlaSkill
- kiro-designSkill
- kiro-requirementsSkill
- kiro-tasksSkill
- legal-memoSkill
- market-research-reportSkill
- mif-corpusSkill
- mif-frontmatterSkill
- mif-to-pdfSkill
- mif-validateSkill
- nist-spSkill
- playbookSkill
- prdSkill
- python-pepSkill
- regulatory-disclosureSkill
- rust-rfcSkill
- security-pentestSkill
- sre-runbookSkill
- sustainability-reportSkill
- svg-chartsSkill
- systematic-reviewSkill
- trend-analysisSkill
The file
We split this skill into the rules it gives an agent
1 rule. About 0 are common, 1 is distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈1
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 91
Stamp never trades conformance for provenance: if stamping would drop the document below the MIF level it already satisfies, it declines …
≈ “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.
Files
mif-provenance
The suite's witnessed provenance helper — the fifth authoring helper,
closing the gap the other four cannot: mif-frontmatter writes provenance
asserted from drafting context, and mif-validate passes any schema-valid
block regardless of whether the named agent ever touched the document. This
skill stamps only what the plugin's capture hooks actually observed, and the
model being described is never the source of the facts describing it.
What it does
stamp <file>— writes ONLY ledger-witnessed fields into the document's frontmatterprovenanceblock:agent,agentVersion(only when witnessed; omitted, never invented) andwasGeneratedBy(the session activity URNurn:mif:activity:claude-code-session:<id>), plustrustLevelfrom fixed policy. It modifies only theprovenanceblock and themodifiedtimestamp (set to the latest witnessed touch, so stamping is byte-idempotent), preserves every unowned provenance field, and declines when the ledger records no touch of the document by the selected session — provenance naming a session that did not touch the document is the defect class this whole helper exists to prevent.verify <file>— deterministically re-derives the expected block from the ledger and reports match or per-field drift. It never restamps; reconciliation is an explicitstamp. No LLM judgment is in the path (themif-validateprecedent): identical document + ledger + config yield an identical verdict.status— answers "is capture actually active for THIS session right now," from inside the session, without touching any document. Reports the resolvedmifProvenance.capture/stampconfig, and — when capture is on — whether the session ledger has asession_startline for the current session. Enabling capture mid-session, or updating this plugin mid-session, is not guaranteed to wire hooks into an already-running session's dispatch (issue #90, confirmed by direct repro: Claude Code snapshots the set of hook commands per matcher at session/plugin-load time and does not re-readhooks.jsonfor that set on later dispatches);statusis the fail-loud check for exactly that gap, since the capture hooks themselves are deliberately silent on both success and failure. If it reports no session_start line, the fix is to restart the Claude Code session, not to keep authoring and hoping. Beyond that,statusalso hashes this plugin's ownhooks.jsonat everysession_startand compares it against the current on-disk copy: if they differ, this plugin was updated after this session started and the running session may still be dispatching the stale hook set — same fix, restart the session.
Trust ceiling — say this plainly when reporting results
The ledger is a local, unsigned witness, so stamped trustLevel is fixed
at user_stated — never verified, and not configurable. confidence
is never written under any configuration: the witness proves presence,
never extent. State this ceiling when reporting a stamp result.
Consent model
Everything here is opt-in and fail-closed (ADR-0005): capture and stamping
are off by default, configured under the mifProvenance settings key
(capture: true/false, stamp: "auto"/"ask"/"off"), and an explicit
disable at ANY settings scope defeats an enable at every other scope. A
malformed settings file disables rather than enables. Stamping is defined
over the capture ledger, so stamp without capture: true resolves to
"off". With stamp: "ask",
the hook only surfaces the exact command — run it solely on the user's
explicit approval; in CI/headless, "ask" behaves as "off".
Commands
node scripts/mif-provenance.mjs stamp <file> [--session <id>] [--ledger <path>]
node scripts/mif-provenance.mjs verify <file> [--session <id>] [--ledger <path>]
node scripts/mif-provenance.mjs status [--session <id>] [--ledger <path>]Session selection: --session, else $CLAUDE_CODE_SESSION_ID, else — only when
exactly one session ever touched the file — that session (status has no file
to infer from, so it needs --session or the environment variable). Several
witnessing sessions is an error demanding --session, never a guess. Exit
codes: 0 stamped/match/status-healthy, 1 verify drift (including
unwitnessed) or status found no session_start yet, 2 usage error, 3 stamp
declined.
Failure postures (deliberately asymmetric)
- Config resolution fails closed: any config error resolves to disabled.
- Capture hooks fail open: an observation error never blocks a Write or a session; outside a git repository capture disables (no alternative store).
- Stamp never trades conformance for provenance: if stamping would drop
the document below the MIF level it already satisfies, it declines and
leaves the file untouched. A stamped document remains
mif-validate-valid at its prior level with a lossless round-trip.
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
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.

