agentleFS
tikalktikalk/adlc-team-skills/skills/change/change-boot/SKILL.md

change-boot

Skill145 starsChanged 20 days agoMITView on GitHub

Use when past-change rationale matters (refactoring unfamiliar code, revert or hotfix analysis, issue-linked commit archaeology, session authors git changes with human-authored messages) — injects the published ChDR index (docs/adlc/memory/chdr/chdr.md, legacy .adlc/memory/chdr.md fallback) as session context; pairs history mining (/change-init) with in-session capture suggested via /change-specify (never writes drafts itself), clarified via /change-clarify; invoked from team-boot's Class Boots catalog.

The file

We split this skill into the rules it gives an agent

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

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈2

    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
  1. Distinctive:

    Never defer to session end.

    line 27
  2. Very specific:

    If the index is missing but docs/adlc/memory/chdr/ChDR-*.md or legacy .adlc/memory/chdr/ChDR-*.md files exist, synthesize a lean table from …

    line 54
  3. Very specific:

    When no local memory index exists in the current working directory and the directory sits inside a workspace (detected via a .gitmodules …

    line 59
  4. Very specific:

    Check .adlc/drafts/chdr/ for ChDR-*.md files with status: proposed or status: discovered in frontmatter.

    line 67
  5. Very specific:

    If the directory is empty or absent, report 0 pending drafts.

    line 72
  6. Very specific:

    Never write a draft (or any file) yourself — /change-specify writes the .adlc/drafts/chdr/ draft when the user runs it, and /change-clarify …

    line 126
  7. Distinctive:

    Add/refresh rows in Team Context & Decisions (ID | Name | Type | Rel | Status | Clarify) for every ChDR-class decision detected this …

    line 130

≈ “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

change-boot

Overview

One of the five class boots surfaced by team-boot's Class Boots catalog. team-boot injects the always-relevant team context (constitution, CDR index, skills registry) at session start; this skill loads the change history layer on demand — the published ChDR index mined from git history — and pairs it with a capture suggestion so change rationale is recovered (/change-init for mined history, /change-specify for decisions made this session) rather than living only in commit messages. The boot never writes files: it suggests the capture skill, and the user runs it.

Reading past rationale and recording new rationale are one loop: published ChDRs explain why the code looks the way it does; rationale discovered during the work flows back into the same record system through the capture skills.

When to Use

Invoke at the START of a matching task — before planning the todo list and before implementation — so the ChDR context informs planning. Never defer to session end.

Invoke when:

  • Refactoring or modifying unfamiliar code — check whether a ChDR explains the current shape before changing it.
  • Analyzing reverts, hotfixes, or fix chains ("why was this reverted?").
  • The session authors git changes with human-authored messages (commit/merge/ revert/rebase/cherry-pick/tag with an authored message, authored PR title/body, CHANGELOG edit) — evaluate at session end whether the rationale is non-obvious enough for a ChDR; routine ops with generated or empty messages are not ChDRs (proportionality gate).
  • The session produces change rationale: a revert/hotfix explanation, or a commit that links to an issue tracker (the /change-init mining signal).

Core Process

Step 1: Locate the ChDR Index

From the current working directory (do NOT walk up parent directories):

  • Primary: docs/adlc/memory/chdr/chdr.md (generated by /change-publish, inside the class dir like adr/adr.md and pdr/pdr.md; rows start with | ChDR)
  • Fallback: docs/adlc/memory/chdr.md (older root-level placement)
  • Fallback: .adlc/memory/chdr.md (legacy layout, legacy)

If the index is missing but docs/adlc/memory/chdr/ChDR-*.md or legacy .adlc/memory/chdr/ChDR-*.md files exist, synthesize a lean table from each file (ID from filename; Title/Status from frontmatter or first heading). If nothing exists, report 0 ChDRs — never fabricate rows.

When no local memory index exists in the current working directory and the directory sits inside a workspace (detected via a .gitmodules marker in an ancestor), read the workspace root's docs/adlc/memory/ index instead (the dual-read order applies: docs/adlc/memory first, legacy .adlc/memory fallback).

Step 1b: Read the ChDR Drafts Index

Check .adlc/drafts/chdr/ for ChDR-*.md files with status: proposed or status: discovered in frontmatter. These are draft ChDRs pending clarification — frontmatter proposed/discovered maps to ledger Status captured, and both feed the Unclarified count. Collect ID / Title / Type / Status / Date from each file. If the directory is empty or absent, report 0 pending drafts.

Absent Context

If team-boot injected no team context this session (no Team Context & Decisions section in the first user message — unconfigured project or hook failure): say so in one line, emit the section heading with a 0 ChDRs matched (no team context injected — run /team-setup) source line, and continue the task on the directly-read ChDR index. Never treat a missing injection as an empty record set. Recovery: run /team-diagnose.

Step 2: Inject ChDR Context (Output Contract)

Emit before the task answer:

## ChDR Context

| ID | Title | Status | Date |
|--|--|--|--|
| ChDR-001 | Why payments retries are capped at 3 | stable | 2026-08-16 |

_Searched N ChDRs, K matched._

## Drafts Pending Review

| ID | Title | Type | Status | Date |
|----|-------|------|--------|------|
| (from .adlc/drafts/chdr/) |

_Unclarified: N ChDR drafts — run /change-clarify to review._
  • Render ID / Title / Status / Date from the index (the full index also carries Issue, Commit, Note — read the individual ChDR-*.md when a task matches a row).
  • N = total index rows; K = rows relevant to the current task. K MUST equal the table rows shown. 0 rows matched → emit the section heading + the _Searched N ChDRs, K matched._ line only — no table. A 0-row table header collapses into unrendered single-line markdown; never emit one. Emit the section as markdown blocks — heading, table rows, and counts line each on their own lines.

Step 3: Suggest Change Rationale Capture

TriggerAction
Revert or hotfix performed/analyzed with rationaleChDR → suggest /change-specify
Commit authored that links to an issue trackerChDR → suggest /change-specify post-merge
Git command authored in-session with a human-authored message, authored PR title/body, or CHANGELOG editevaluate at session end: non-obvious rationale → suggest /change-specify; routine ops skipped (proportionality gate)
Fix chain discovered in historyChDR → suggest /change-init (history mining)
ChDR-class decision already in the ledgerverify the suggestion was surfaced; if not, re-surface

Emit one line per detected decision, in the visible response:

_Suggested capture: <decision name> → run /change-specify._

Never write a draft (or any file) yourself — /change-specify writes the .adlc/drafts/chdr/ draft when the user runs it, and /change-clarify gates it afterwards.

Add/refresh rows in Team Context & Decisions (ID | Name | Type | Rel | Status | Clarify) for every ChDR-class decision detected this session — including ones from before this boot was invoked. Mirror each decision as a task-list todo (suggest /change-specify → matching clarify skill at session end for drafts that exist); after code-modifying tasks, add a trailing todo to sweep Team Context & Decisions until Unrecorded: 0 pending · Unclarified: 0 drafts (a draft leaves Unclarified only via its clarify skill or an explicit user handoff to a named clarify or execute skill). At session end, deliver the clarify prompt naming each uncaptured decision (ID + capture skill) and each captured ChDR draft in .adlc/drafts/chdr/ (ID + clarify skill), covering post-merge issue-linked commits too; if the user defers clarify, mark those rows handed off.

Failure Handling

  • Missing index + missing records → emit the section heading + _Searched 0 ChDRs, 0 matched._ only — no table — and continue the user's task; never block.
  • Unparseable index rows → skip malformed rows, note the skip count.

Red Flags

  • Fabricating ChDR rows or inflating K beyond the table shown.
  • Injecting the index but ignoring the capture suggestion — the pairing is the point.
  • Writing a draft (or any file) yourself — the boot only suggests; /change-specify writes.
  • Walking up parent directories to find .adlc/.
  • Mining rationale without SHA/URL provenance — /change-clarify will reject Decision claims that lack it.

Verification

  • ChDR Context table emitted with _Searched N ChDRs, K matched._ (K = table rows).
  • Detected ChDR-class decisions added as Team Context & Decisions rows.
  • No files written; each detected ChDR-class decision carries a _Suggested capture: … → run /change-specify._ line (mined-history signals name /change-init).

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.