change-publish
Skill145 starsChanged 22 days agoMITView on GitHub
Use when accepted ChDRs are ready for promotion from drafts to project memory at docs/adlc/memory/chdr/ and the boot-facing chdr/chdr.md index needs regenerating.
In this repository48 other files it gives its agents.
- architect-analyzeSkill
- architect-bootSkill
- architect-clarifySkill
- architect-implementSkill
- architect-initSkill
- architect-specifySkill
- writing-skillsSkill
- change-bootSkill
- change-clarifySkill
- change-initSkill
- change-specifySkill
- evals-analyzeSkill
- evals-clarifySkill
- evals-implementSkill
- evals-initSkill
- evals-specifySkill
- evals-validateSkill
- factory-cleanSkill
- factory-initSkill
- factory-intentSkill
- factory-learnSkill
- factory-missionSkill
- factory-orchestratorSkill
- factory-queueSkill
- factory-releaseSkill
- factory-reviewSkill
- factory-runbookSkill
- factory-setupSkill
- factory-ticketsSkill
- mission-briefSkill
- product-analyzeSkill
- product-bootSkill
- product-clarifySkill
- product-implementSkill
- product-initSkill
- product-roadmapSkill
- product-specifySkill
- team-bootSkill
- team-constitutionSkill
- team-diagnoseSkill
- team-discoverSkill
- team-initSkill
- team-levelupSkill
- team-repairSkill
- team-setupSkill
- team-skillsSkill
- workspaceSkill
- tech-radar-bootSkill
The file
We split this skill into the rules it gives an agent
11 rules. About 0 are common, 3 are distinctive, and 8 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.
8
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 14
Write each promoted ChDR to docs/adlc/memory/chdr/ChDR-{NNN}.md with OKF-style frontmatter
- Very specific: line 29
No accepted ChDRs: run /change-clarify first
- Very specific: line 30
Discovering ChDRs: use /change-init
- Very specific: line 31
Reviewing ChDRs: use /change-clarify
- Very specific: line 51
Write promoted records with frontmatter that team-boot can index
- Very specific: line 87
If ACCEPTED_CHDRS is empty:
- Distinctive: line 216
No PR created — user commits via normal flow
- Very specific: line 243
Commit the memory directory.
- Very specific: line 247
All accepted ChDRs with provenance promoted to docs/adlc/memory/chdr/ChDR-*.md.
- Distinctive: line 250
No unprovenanced ChDRs were promoted.
- Distinctive: line 251
No duplicate issue keys in memory.
≈ “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
change-publish
What this skill does
Compile accepted ChDRs into the project's memory layer at {REPO_ROOT}/docs/adlc/memory/chdr/:
- Validate accepted ChDRs (status + provenance on Decision claims)
- Write each promoted ChDR to
docs/adlc/memory/chdr/ChDR-{NNN}.mdwith OKF-style frontmatter - Regenerate
{REPO_ROOT}/docs/adlc/memory/chdr/chdr.md— the boot-facing index thatteam-bootinjects into the session-start context (inside the class dir, same convention asadr/adr.mdandpdr/pdr.md) - Mark source drafts
### Status: **Published**
Unlike /team-levelup (which opens a PR against team-ai-directives), change-publish writes project-local memory — ChDRs describe this repo's evolution and fail the team-wide signal gate. No PR is created; the user commits via their normal flow.
This skill does not run until ChDRs have been accepted via /change-clarify.
When to use
- After
/change-clarify: accepted ChDRs need promotion to memory - After re-running
/change-init: new accepted ChDRs to add to the memory index
When NOT to use
- No accepted ChDRs: run
/change-clarifyfirst - Discovering ChDRs: use
/change-init - Reviewing ChDRs: use
/change-clarify
Process
User Input
$ARGUMENTSExamples:
"ChDR-001 ChDR-003"— promote only specific ChDRs- Empty input: promote all accepted ChDRs
Role & Context
You are acting as a Memory Publisher — moving accepted ChDRs from local drafts to durable project memory. Your role:
- Validate provenance one more time (the poisoning circuit breaker — a promoted unprovenanced decision poisons every future session via team-boot)
- Write promoted records with frontmatter that
team-bootcan index - Regenerate the
chdr.mdindex so the next session start sees the new decisions
Outline
- Environment Setup (Phase 0): resolve paths, list accepted ChDRs
- Prerequisites Check (Phase 1): ensure accepted ChDRs exist
- Provenance Validation (Phase 2): re-verify every Decision claim has SHA/URL
- Duplicate Check (Phase 3): skip ChDRs already in memory with same issue key
- Memory Record Generation (Phase 4): write
docs/adlc/memory/chdr/ChDR-{NNN}.md - Index Regeneration (Phase 5): rebuild
docs/adlc/memory/chdr/chdr.md(boot-facing) - Draft Status Update (Phase 6): mark promoted drafts
Published - Summary (Phase 7): report results
Execution Steps
Phase 0: Environment Setup
Run:
scripts/bash/setup-change-publish.shParse JSON for REPO_ROOT, CHDR_DRAFTS_DIR, MEMORY_DIR, MEMORY_INDEX, ACCEPTED_CHDRS.
If the setup script is unavailable or fails, resolve manually:
REPO_ROOT— walk up to.adlc/, orgit rev-parse --show-toplevel.CHDR_DRAFTS_DIR—REPO_ROOT/.adlc/drafts/chdrMEMORY_DIR—REPO_ROOT/docs/adlc/memory/chdrMEMORY_INDEX—REPO_ROOT/docs/adlc/memory/chdr/chdr.md(inside the class dir, likedocs/adlc/memory/adr/adr.mdandpdr/pdr.md)ACCEPTED_CHDRS—grep -l '^### Status: \*\*Accepted\*\*' CHDR_DRAFTS_DIR/ChDR-*.md
Phase 1: Prerequisites Check
If ACCEPTED_CHDRS is empty:
No accepted ChDRs found.
Run /change-clarify to accept ChDRs first.Phase 2: Provenance Validation
For each accepted ChDR, re-verify: every non-trivial sentence in ### Decision references a SHA (\b[0-9a-f]{7,40}\b) or URL (https?://). Skip ChDRs that fail provenance — they cannot be promoted (poisoning risk):
## Provenance Validation
**Passing**: N | **Skipped**: M
### Skipped ChDRs
| ChDR | Reason |
|---|---|
| ChDR-XXX | Decision claim lacks SHA/URL provenance |Skipped ChDRs remain Accepted in drafts for the user to fix.
Phase 3: Duplicate Check
For each passing ChDR, check if a memory record already exists with the same ### Issue Links key. If so, skip (or offer to merge) — do not create duplicates.
Phase 4: Memory Record Generation
For each accepted ChDR, write {MEMORY_DIR}/ChDR-{NNN}.md:
---
type: ChDR
title: {title from heading}
description: {descriptor from draft}
resource: ./docs/adlc/memory/chdr/ChDR-{NNN}.md
tags: [chdr]
generated:
by: agent:change-publish
at: {today}T00:00:00Z
id: ChDR-{NNN}
created: {date from draft}
verified:
- by: agent:change-publish
at: {today}T00:00:00Z
status: stable
stale_after: 365d
sources:
- id: {sha}
resource: git:{sha}
title: {commit subject}
- id: {issue-key}
resource: {issue-url}
title: {issue title}
---
# {Title}
{Content from draft — Context, Decision, Consequences, Evidence verbatim}
## Source
Promoted from: .adlc/drafts/chdr/ChDR-{NNN}.mdPhase 5: Index Regeneration (boot-facing)
This is the integration point with team-boot. Regenerate {MEMORY_INDEX} ({REPO_ROOT}/docs/adlc/memory/chdr/chdr.md) by listing all ChDR-*.md files in {MEMORY_DIR} and building a markdown table whose rows start with | ChDR- (the awk filter team-boot uses):
# Change Decision Records (Memory)
## ChDR Index
| ID | Title | Status | Date | Issues | Commits | Descriptor |
|----|-------|--------|------|--------|---------|------------|
| ChDR-001 | Why payments retries are capped at 3 | stable | 2026-08-16 | PROJ-123 | abc1234 | Consult before changing retry config |
**Stats**: N entries | Last Updated: YYYY-MM-DDteam-boot's boot.sh/boot.ps1 reads this file and emits a ## ChDR Index section + CHDR_COUNT into the session-start context, alongside the PDR/ADR indexes.
Phase 6: Draft Status Update
For each promoted ChDR, update the draft file's status to ### Status: **Published** and add:
### Promotion
- **Date**: [YYYY-MM-DD]
- **Memory path**: docs/adlc/memory/chdr/ChDR-{NNN}.mdPhase 7: Summary
## Change-Publish Summary
**ChDRs Promoted**: N
**ChDRs Skipped (provenance)**: M
**ChDRs Skipped (duplicate)**: K
### Artifacts
| Type | Count |
|---|---|
| Memory records (docs/adlc/memory/chdr/) | N |
| Boot index (docs/adlc/memory/chdr/chdr.md) | 1 (regenerated) |
### Next Steps
The next session start (`team-boot`) will inject the ChDR index into context.
Commit `docs/adlc/memory/chdr/` (records + `chdr.md`) via your normal flow.Key Rules
Provenance Before Promotion
- A promoted unprovenanced Decision poisons every future session (team-boot injects it)
- Re-validate provenance at publish time, not just at clarify
Project-Local, Not Team-Wide
- ChDRs publish to
docs/adlc/memory/, not team-ai-directives - No PR created — user commits via normal flow
- ChDRs fail the team-levelup "team-wide applicability" signal gate by design
Index Format Must Match team-boot
- Rows MUST start with
| ChDR-(the awk/regex filter in boot.sh/boot.ps1) - File MUST be at
docs/adlc/memory/chdr/chdr.md(inside the class dir, likeadr/adr.mdandpdr/pdr.md); dual-read fallbacks aredocs/adlc/memory/chdr.md(older root-level placement) and.adlc/memory/chdr.md(legacy layout)
Workflow Guidance & Transitions
After /change-publish
/change-init → /change-clarify → /change-publish
↓
[team-boot] → injects docs/adlc/memory/chdr/chdr.md index at next session start
↓
[Agent consults ChDRs on demand when touching affected code]Re-run /change-init periodically to mine new history; new accepted ChDRs are added to memory and the index is regenerated.
Next Steps
Commit the memory directory. The next session automatically sees the ChDR index via team-boot.
Verification
- All accepted ChDRs with provenance promoted to
docs/adlc/memory/chdr/ChDR-*.md. docs/adlc/memory/chdr/chdr.mdindex regenerated with rows starting| ChDR-.- Promoted drafts marked
### Status: **Published**. - No unprovenanced ChDRs were promoted.
- No duplicate issue keys in memory.
Context
$ARGUMENTS
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.

