contract-ledger
Skill4 starsChanged 3 months agoApache-2.0View on GitHub
Own CCL admission, bounded owner decisions, immutable lookup, and append-only persistence.
In this repository51 other files it gives its agents.
- AGENTS.mdAGENTS.md
- architecture-remediationSkill
- attentionSkill
- classify-docSkill
- codebase-designSkill
- codebase-memory-mcpSkill
- codegraphSkill
- coding-standardsSkill
- conventional-commitsSkill
- database-migrationsSkill
- deduplicate-codeSkill
- diagnosing-bugsSkill
- domain-modelingSkill
- format-codeSkill
- github-issue-dependenciesSkill
- graphifySkill
- grillingSkill
- grill-meSkill
- grill-with-docsSkill
- handoffSkill
- implement-ticketSkill
- improve-codebase-architectureSkill
- project-delivery-managementSkill
- project-trackingSkill
- prototypeSkill
- repowiseSkill
- researchSkill
- resolving-merge-conflictsSkill
- review-architectureSkill
- review-specSkill
- setup-matt-pocock-skillsSkill
- spec-contractSkill
- spec-merge-cleanupSkill
- tddSkill
- teachSkill
- to-adr-docSkill
- to-docSkill
- to-specsSkill
- to-ticketsSkill
- triageSkill
- verify-architectureSkill
- verify-codeSkill
- verify-spec-closureSkill
- verify-specSkill
- verify-ticket-closureSkill
- verify-ticket-decompositionSkill
- wayfinderSkill
- wiki-lintSkill
- wiki-syncSkill
- wiki-synthesizeSkill
- writing-great-skillsSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
13 rules. About 0 are common, 8 are distinctive, and 5 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈8
Distinctive · estimate
This author's own choices. Worth a look.
5
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 37
every assertion is addressed as <contract-id>@<revision>#<assertion-id>.
- Distinctive: line 39
Never edit, replace, rename, or delete an accepted transaction to change its meaning.
- Distinctive: line 45
Read-only exact/latest contract or assertion lookup:
- Distinctive: line 55
When an exact CCL address exists, consume it instead of reinterpreting source prose.
- Distinctive: line 62
No new semantic choice or human decision is legal here.
- Very specific: line 74
If normalization requires any such choice, return CCL ADMISSION: UNSUPPORTED.
- Very specific: line 100
After the Wayfinder records acceptance of that exact hash, validate/persist the accepted transaction.
- Distinctive: line 116
Only governing/constraint sources establish material semantics.
- Distinctive: line 119
When governing/constraint sources normalize differently at the same coordinate, return:
- Distinctive: line 129
Do not choose a winner.
- Very specific: line 163
When this skill owns persistence, use a clean isolated worktree from frozen current origin/main, validate candidate + ledger, create only …
- Very specific: line 168
When an authorized parent already owns an isolated canonical-main authority transaction, $contract-ledger may contribute the exact admitted …
- Distinctive: line 202
Keep the CCL boring: one typed semantic truth, immutable revisions, one writer.
≈ “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
Contract Ledger
$contract-ledger is the sole writer for Canonical Contract Ledger (CCL) transactions:
contracts/ccl/transactions/Schema and deterministic mechanics:
contracts/ccl/schema/ccl-v1.schema.json
scripts/ccl.py
scripts/ccl_ledger.pyThe CCL records material semantics. It does not plan projects, write Specs, decompose tickets, implement code, or perform review.
Invariants
- accepted transaction files are append-only and immutable;
- semantic change creates a new full-snapshot revision;
retireis terminal in CCL v1;- typed assertions are semantic authority;
display/annotationsare non-authoritative and excluded from the proposal hash;- absence of an assertion never authorizes downstream semantic invention;
- one transaction may revise several coupled contracts atomically, but never more than one revision of the same contract;
- every assertion is addressed as
<contract-id>@<revision>#<assertion-id>.
Never edit, replace, rename, or delete an accepted transaction to change its meaning.
Modes
lookup
Read-only exact/latest contract or assertion lookup:
python -m scripts.ccl_ledger lookup \
contracts/ccl/transactions \
<contract-id> \
[--revision <n>] \
[--assertion <assertion-id>]When an exact CCL address exists, consume it instead of reinterpreting source prose.
existing-authority
Register semantics already fixed completely by current durable governing/constraint authority.
No new semantic choice or human decision is legal here. Every proposed assertion must be entailed at exactly the proposed strength.
Illegal strengthening includes:
may→must;- examples → required/closed taxonomy;
- optional → required relationship/cardinality;
- general durability → invented required public field;
- open vocabulary → closed enum;
- unspecified dimension → chosen default.
If normalization requires any such choice, return CCL ADMISSION: UNSUPPORTED.
owner-decision
Resolve one bounded independent semantic coupling group through explicit human acceptance.
Legal only when all are true:
Unresolved semantic coupling groups: 1
Dependent material choices after this decision: 0
Cross-domain planning required: no
Research/prototype campaign required: no
Project partition/dependency planning required: no
One acceptance transaction can completely close the choice: yesOtherwise return CCL DECISION REQUIRES WAYFINDER.
A durable source artifact must host the proposal and acceptance receipt. Conversational acceptance alone is not durable authority.
wayfinder-decision
Support, but never replace, a Wayfinder decision. Prepare the exact typed semantic
revisions, proposal hash, and generated human-readable rendering before the human gate.
After the Wayfinder records acceptance of that exact hash, validate/persist the accepted
transaction. $contract-ledger never chooses the Wayfinder answer.
Authority admission
For every proposed assertion establish:
Contract/assertion: <coordinate>
Typed candidate: <kind + subject + exact constraint>
Applicable source: <exact durable source>
Source role: governing | constraint | rationale | evidence
Normalized claim: <typed claim | unsupported>
Entailment: exact | unsupportedOnly governing/constraint sources establish material semantics. Rationale/evidence may explain them but cannot strengthen them.
When governing/constraint sources normalize differently at the same coordinate, return:
CCL SOURCE CONFLICT
Contract/assertion: <coordinate>
Sources: <exact conflicting sources>
Normalized claims: <typed difference>
Routing owner: <governing semantic owner>Do not choose a winner.
Proposal and human gate
CCL revisions are complete snapshots, not semantic patches. The semantic proposal is the
exact revisions payload and deterministic hash. Human-facing prose is a generated view.
For owner-decision and wayfinder-decision, human acceptance binds the exact proposal
hash. Approval of nearby prose is never approval of a different hash.
existing-authority has no new human semantic gate because it is registration, not a new
decision.
Ledger admission
Before writing:
python -m scripts.ccl_ledger validate-ledger contracts/ccl/transactions
python -m scripts.ccl_ledger admit \
contracts/ccl/transactions <candidate.json>Admission requires valid hash-derived filenames, unique proposal hashes, one revision per
contract per transaction, revision 1 = create, contiguous revisions, exact immediate
supersedes_revision, and no revision after retire.
ALREADY-PRESENT is idempotent success. Malformed accepted history is
CCL LEDGER CORRUPTION; stop rather than normalizing it.
Persistence
CCL authority is canonical on main.
When this skill owns persistence, use a clean isolated worktree from frozen current
origin/main, validate candidate + ledger, create only the admitted transaction file,
commit under repository policy, recheck canonical-main concurrency, push without force,
read back, rerun ledger validation, and prove the caller checkout unchanged.
When an authorized parent already owns an isolated canonical-main authority transaction,
$contract-ledger may contribute the exact admitted transaction file and return its
path/hash/revisions without committing. The parent may commit that file but may not alter
its semantic payload.
Return
Success:
CCL TRANSACTION: PERSISTED | ALREADY-PRESENT | CONTRIBUTED
Proposal hash: <sha256:...>
Mode: existing-authority | owner-decision | wayfinder-decision
Contracts: <contract@revision list>
Path: <transaction path>
Ledger validation: PASSUnsupported registration:
CCL ADMISSION: UNSUPPORTED
Contract/assertion: <coordinate>
Missing semantic authority: <exact missing choice>
Routing: owner-decision | wayfinderHard non-semantic failure:
CCL HARD BLOCKER
Reason: <ledger corruption | persistence/concurrency/tool failure>Keep the CCL boring: one typed semantic truth, immutable revisions, one writer.
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.

