content-ledger
Skill4 starsChanged 5 months agoMITView on GitHub
Track what was published, where it was published, and what follow-up context should persist.
In this repository10 other files it gives its agents.
The file
We split this skill into the rules it gives an agent
9 rules. About 0 are common, 8 are distinctive, and 1 is 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.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 9
Use this skill to normalize publish-history facts for one project and one network without inventing analytics or storing private exports in …
- Distinctive: line 36
Keep reusable ledger structure separate from network-local working notes.
- Distinctive: line 37
Use only fake/demo values in repository-facing examples.
- Distinctive: line 38
Follow ADR 0002 for all namespace references.
- Distinctive: line 78
Do not write a new durable ledger entry or modify an existing one until a human confirms that the content identity and status are correct.
- Distinctive: line 98
Do not invent analytics that were not measured.
- Distinctive: line 99
Do not store credentials, private exports, or secrets in the ledger contract.
- Very specific: line 100
Do not use discord-project-manager/runtime/discord/<guild-id>/<channel-id> for durable publish history.
- Distinctive: line 101
Keep examples fake unless the source is intentionally public and approved.
≈ “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
Content Ledger
Use this skill to normalize publish-history facts for one project and one network without inventing analytics or storing private exports in git.
This is a skill contract, not a live analytics or publishing integration.
Inputs
Required inputs:
project_slugnetwork_slugcontent_id_or_titlepublish_statuspublish_dateorunknownasset_referencesornone
Optional inputs:
campaignsource_linkfollow_up_notesmeasured_outcomes
Behavior
- Normalize one content record at a time.
- Preserve enough detail to avoid duplicates and support later analytics joins.
- Mark unknown values explicitly instead of fabricating them.
- Keep reusable ledger structure separate from network-local working notes.
- Use only fake/demo values in repository-facing examples.
- Follow ADR 0002 for all namespace references.
Output shape
Return a YAML-like structure similar to this:
project: <project-slug>
network: <network-slug>
content_entry:
id: <stable-id-or-title>
status: <draft|queued|published|archived>
published_at: <date-or-unknown>
assets:
- <asset-reference>
source_link: <url-or-none>
measured_outcomes:
- metric: <name>
value: <value-or-unknown>
follow_up:
action: <next-step>
notes:
- <note>Memory behavior
Read candidates
discord-project-manager/project/<project-slug>/content-ledgerdiscord-project-manager/project/<project-slug>/network/<network-slug>- approved repo artifacts that define ledger conventions or identifiers
Write candidates
- durable ledger state under
discord-project-manager/project/<project-slug>/content-ledger - network-local overlays under
discord-project-manager/project/<project-slug>/network/<network-slug>when queue state or temporary workflow notes are needed
Approval gate
Do not write a new durable ledger entry or modify an existing one until a human confirms that the content identity and status are correct.
Namespace target
Use ADR 0002 exactly:
discord-project-manager/project/<project-slug>/content-ledgerdiscord-project-manager/project/<project-slug>/network/<network-slug>
Canonical ADR examples that this skill may mirror when using fake/demo values:
discord-project-manager/project/egdev/content-ledgerdiscord-project-manager/project/egdev/network/x
Promotion to repo artifact
Promote ledger conventions, identifier rules, and reusable workflow behavior into repo artifacts when they become review-facing or implementation-critical. Raw operational entries may remain in Engram until they are summarized.
Safety rules
- Do not invent analytics that were not measured.
- Do not store credentials, private exports, or secrets in the ledger contract.
- Do not use
discord-project-manager/runtime/discord/<guild-id>/<channel-id>for durable publish history. - Keep examples fake unless the source is intentionally public and approved.
Demo example (fake)
project: egdev
network: x
content_entry:
id: x-post-001-demo
status: published
published_at: 2026-05-30
assets:
- asset://demo/cover-001
source_link: https://example.invalid/posts/x-post-001-demo
measured_outcomes:
- metric: impressions
value: unknown
follow_up:
action: compare against future X queue posts after analytics validation
notes:
- fake demo entry for contract review onlyThis example is fake/demo data only and must not be treated as real publish history.
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.

