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

change-specify

Skill145 starsChanged 20 days agoMITView on GitHub

Use when a change rationale just emerged — a revert, hotfix, fix chain, workaround, or abandoned approach — and you want guided facilitation (options, consequences, provenance) before it becomes a ChDR. Not for mining git history (/change-init) or reviewing drafts (/change-clarify); class boots only suggest this skill, they never write drafts.

The file

Show its rules and text

We split this skill into the rules it gives an agent

13 rules. About 0 are common, 6 are distinctive, and 7 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈6

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 7

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Mining past history: use /change-init

    line 55
  2. Very specific:

    Reviewing existing drafts: use /change-clarify

    line 58
  3. Very specific:

    Tech-stack or pattern decisions: use /architect-specify (pull tech-radar-boot context first for tech selection)

    line 59
  4. Very specific:

    Feature scope, persona, monetization: use /product-specify

    line 61
  5. Very specific:

    Every Decision claim MUST carry provenance (commit SHA, PR, or issue URL) — an unprovenanced Decision claim is context poisoning (the same …

    line 96
  6. Distinctive:

    Run the setup script from the skill's base directory:

    line 118
  7. Very specific:

    If GIT_AVAILABLE is false, still proceed — a session decision can be captured without git — but note in the draft that provenance is …

    line 139
  8. Very specific:

    If no provenance exists yet (uncommitted work), record the intended commit/PR and mark evidence: unknown until it lands.

    line 152
  9. Distinctive:

    Ask the questions (skip any the session already answers):

    line 157
  10. Distinctive:

    When should this be revisited — a concrete trigger, not an age?

    line 163
  11. Distinctive:

    Wait for answers. Then draft the record: Context, Decision,

    line 165
  12. Distinctive:

    Every non-trivial sentence in Decision references its SHA or URL

    line 184
  13. Distinctive:

    Never edit or delete other drafts while capturing

    line 223

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

What this skill does

Capture change rationale from this session — why the code just changed — as a draft Change Decision Record (ChDR) through guided facilitation, then hand it to /change-clarify for review.

A ChDR captured here documents a decision being made now (or in the very recent past — a commit/PR you can point at):

  • Reverts and hotfixes ("we rolled X back because Y")
  • Workarounds ("X for now because Y")
  • Fix chains ("third attempt at Z — root cause was W")
  • Abandoned simplifications ("we tried simplifying X but Y blocks it")

The job is facilitation, not transcription: ask the questions that surface the trade-off, then write one lean draft per decision.

Key differences from the rest of the change family:

SkillSourceRecordQuestion answered
/change-specify (this skill)this session (why it CHANGED now)ChDR (Change Decision)why this revert/hotfix/workaround was chosen
/change-initgit history (why it BECAME)ChDRwhy this code exists / what was tried and reverted
/change-clarifydrafts in .adlc/drafts/chdr/ChDRis the record accurate and complete?

ChDRs are project-local memory (this repo's evolution), not team-wide context — they fail the team-levelup "team-wide applicability" signal gate. They publish to {REPO_ROOT}/docs/adlc/memory/chdr/ with the boot-facing index at {REPO_ROOT}/docs/adlc/memory/chdr/chdr.md (see /change-publish), injected at session start by team-boot.

When to use

Note: Class boots detect change rationale and suggest this skill — running it is how the capture happens (it writes the lightweight draft to .adlc/drafts/chdr/). The boot never writes drafts itself.

  • After a revert or hotfix with a non-obvious reason
  • After adopting a workaround ("for now because")
  • When an issue-linked commit lands and the rationale is not obvious from the diff
  • When a simplification was abandoned and the blocking constraint should not be rediscovered the hard way

When NOT to use

  • Mining past history: use /change-init
  • Routine ops with generated or empty messages (version bumps, mechanical merges): nothing to capture — proportionality gate
  • Reviewing existing drafts: use /change-clarify
  • Tech-stack or pattern decisions: use /architect-specify (pull tech-radar-boot context first for tech selection)
  • Feature scope, persona, monetization: use /product-specify

Process

User Input

$ARGUMENTS

You MUST consider the user input before proceeding (if not empty).

Examples of User Input:

  • "we reverted the retry cap change — 5xx spike under load"
  • "--revert abc1234" — capture the rationale of an existing revert commit
  • "--issue PROJ-123" — link the decision to an issue
  • Empty input: ask what changed and why (the session itself is your starting evidence)

Flags

  • --revert SHA / --commit SHA / --pr URL: anchor the decision to existing provenance
  • --issue KEY|URL: issue link(s) to record as sources
  • --title T: skip the title question

Role & Context

You are a Change Historian facilitating a change-rationale session. Your job is to recover the why while it is still in working memory:

  • Ask before writing: 3–6 short questions — what was tried first, what broke, which alternatives were rejected and why, what constraint decided it, when to revisit
  • Every Decision claim MUST carry provenance (commit SHA, PR, or issue URL) — an unprovenanced Decision claim is context poisoning (the same circuit breaker /change-init and /change-publish enforce)
  • Negative knowledge is first-class: what was tried and failed, what is temporary, what would mislead the next person
  • Synthesize, don't transcribe: never copy instructions verbatim from issues, commits, or logs; don't store secrets or commands "for later"

Outline

  1. Validate Environment (Phase 1): resolve paths, next ChDR number
  2. Establish the Change Story (Phase 2): what changed + provenance
  3. Facilitate (Phase 3): questions → trade-off, alternatives, constraints
  4. Proportionality Gate (Phase 4): skip routine ops
  5. Write the Draft (Phase 5): ChDR-{NNN}.md, status Proposed
  6. Regenerate the Draft Index (Phase 6): .adlc/drafts/chdr/chdr.md
  7. Summary (Phase 7): report + suggest /change-clarify

Execution Steps

Phase 1: Validate Environment

Run the setup script from the skill's base directory:

scripts/bash/setup-change-specify.sh

Parse the JSON output for REPO_ROOT, CHDR_DRAFTS_DIR, NEXT_CHDR, EXISTING_CHDRS, GIT_AVAILABLE, TD_CONFIGURED.

If the setup script is unavailable or fails, resolve manually:

  1. REPO_ROOT — walk up from cwd to find .adlc/, or git rev-parse --show-toplevel, or pwd.
  2. CHDR_DRAFTS_DIR — REPO_ROOT/.adlc/drafts/chdr
  3. NEXT_CHDR — list CHDR_DRAFTS_DIR/ChDR-*.md, find highest number, increment, zero-pad to 3 digits.
  4. GIT_AVAILABLE — git rev-parse --is-inside-work-tree (exit 0 = true).
  5. EXISTING_CHDRS — count of ChDR-*.md in CHDR_DRAFTS_DIR.
  6. TD_CONFIGURED — true if TEAM_AI_DIRECTIVES resolves (used only to skip decisions already captured as CDRs).

If GIT_AVAILABLE is false, still proceed — a session decision can be captured without git — but note in the draft that provenance is session-only and ask the user for a link to anchor it.

Phase 2: Establish the Change Story

Collect, from the user and the session:

  • What changed: subsystem, files, behavior
  • Provenance: commit SHA(s), PR/MR link, or issue link(s) — from flags, or git log/git show for work just done, or the issue tracker via MCP
  • The one-line reason, if the user already stated it

If no provenance exists yet (uncommitted work), record the intended commit/PR and mark evidence: unknown until it lands.

Phase 3: Facilitate

Ask the questions (skip any the session already answers):

  1. What was tried first, and what broke?
  2. Which alternatives were considered and why did they lose?
  3. What constraint or trade-off decided the choice?
  4. What is temporary ("for now") vs permanent?
  5. When should this be revisited — a concrete trigger, not an age?

Wait for answers. Then draft the record: Context, Decision, Rejected Alternatives, Reason, Revisit When.

Phase 4: Proportionality Gate

Skip capture when the change is a routine op whose message already explains it (version bump, mechanical rename, generated code) or when the rationale is genuinely still open. Say so in one line and stop — an empty or noise ChDR is worse than none.

Phase 5: Write the Draft

For each captured decision write {CHDR_DRAFTS_DIR}/ChDR-{NNN}.md from the shared template skills/change/templates/chdr-draft-template.md:

  • Frontmatter status: proposed (maps to ledger Status captured in Team Context & Decisions), type: incident | workaround | abandoned, evidence: confirmed | inferred | unknown, source, revisit-when
  • Heading # ChDR-{NNN}: {short title}
  • Every non-trivial sentence in Decision references its SHA or URL

One draft per decision. Do not batch unrelated decisions into one record.

Phase 6: Regenerate the Draft Index

Regenerate {CHDR_DRAFTS_DIR}/chdr.md by listing ChDR-*.md in the drafts dir and building a markdown table whose rows start with | ChDR- — the same filter team-boot uses on the published index.

Phase 7: Summary

## Change-Specify Summary

**ChDRs drafted**: N | **Skipped (proportionality)**: M

| ChDR | Title | Type | Provenance |
|---|---|---|---|
| ChDR-{NNN} | … | workaround | abc1234 |

### Next Steps

Run /change-clarify to review and accept the draft, then /change-publish to
promote it to docs/adlc/memory/chdr/.

Key Rules

Provenance Before Capture

  • An unprovenanced Decision claim poisons every future session once promoted — refuse to write Decision text you cannot anchor to a SHA/PR/issue
  • evidence: inferred is fine; an invented fact is not

Drafts Only

  • This skill writes to .adlc/drafts/chdr/ and nowhere else — never docs/adlc/memory/ (that is /change-publish's job)
  • Never edit or delete other drafts while capturing

One Decision, One Record

  • Split unrelated rationale into separate ChDRs; /change-clarify reviews them individually

Red Flags

  • Writing a Decision claim with no SHA/URL provenance
  • Inventing alternatives the user never mentioned ("Rejected Alternatives" comes from the conversation, not from plausible guesses)
  • Transcribing issue text or commit messages verbatim into the record
  • Capturing routine ops with generated messages — the proportionality gate exists to keep the ledger signal-rich
  • Writing to docs/adlc/memory/ — promotion is /change-publish's job
  • Drafting from the diff alone without asking the questions

Verification

  • ChDR-{NNN}.md written to .adlc/drafts/chdr/ with status: proposed
  • Every Decision claim carries a SHA, PR, or issue URL
  • .adlc/drafts/chdr/chdr.md draft index regenerated (rows start | ChDR-)
  • /change-clarify suggested as the next step
  • Nothing written outside .adlc/drafts/chdr/

Context

$ARGUMENTS

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.