Pilot a lightweight decision-log skill in Grand Central

Problem

When Claude Code picks up a story in one of our repos, it has no memory of why
prior implementations landed the way they did. Commit messages and PR descriptions
capture the what, but the rationale for choosing approach A over B — the
tradeoffs we weighed, the constraints we discovered mid-implementation, the
"don't refactor this, it's load-bearing" notes — is lost between sessions.

This costs us in two ways:

1. Claude re-derives context every session, and sometimes derives it wrong.
2. New team members (and future-us) lose the same context for the same reasons.

Proposed approach

A lightweight Architecture Decision Record (ADR) pattern, paired with a
plugin that prompts at PR-creation time:

• Decisions live in docs/decisions/NNNN-short-title.md in each repo.
• Format is short and standard: Context, Decision, Consequences, Alternatives
  Considered. Aim for ~1 page, not an essay.
• A new plugin (working name: log-decision) triggers during the PR flow and
  asks "was a non-obvious choice made on this branch?" — only logs when the
  answer is yes. No auto-logging every PR.
• The plugin's primary value is the prompt itself; the ADR file is the
  durable artifact Claude reads on future sessions.

The signal-to-noise bar is intentionally high: routine bug fixes, mechanical
refactors, and obvious choices don't get an ADR. Tradeoffs, reversals,
load-bearing weirdness, and "we tried X first and it didn't work" do.

Why Grand Central as the pilot

GC is our most active repo right now (Umbraco upgrade, ROC application work),
which means:

• Highest volume of real decisions to test the pattern against.
• Fastest feedback on whether the prompt fires at the right moments.
• If it works in GC's complexity, it'll work anywhere.

Pilot scope

• Add the plugin to tzander-skills marketplace.
• Seed docs/decisions/ in GC with 2–3 backfilled ADRs from recent Umbraco/ROC
  decisions so the pattern has examples to reference.
• Run for ~4 weeks of normal GC work.

Success criteria — does this roll out?

Roll out broadly if, at the end of the pilot:

• At least 3–5 ADRs were written and at least one was referenced by Claude
  in a later session to avoid re-deriving context (or by a teammate during
  review).
• The prompt didn't feel like noise — measured by "did anyone start ignoring
  it / disable it."
• Backfilling effort wasn't disproportionate to value.

Don't roll out if it became another thing-people-skip, or if the ADRs went
stale faster than they were referenced.

Open questions

• Where exactly should ADRs live in GC's tree? docs/decisions/ is the
  default but GC may already have a docs convention worth matching.
• Do we want the plugin to suggest the ADR title/skeleton based on the diff,
  or stay fully manual to avoid template-fatigue?
• Do we link ADRs back to the originating ADO work item / PR? (I'd lean yes —
  cheap to add, makes the "why" trail navigable.)

References

Pattern inspired by the decision log in
https://github.com/Csmith954/tcg-assistant — Claude has used those entries
across sessions there to good effect on a much smaller codebase

Start by inspecting the tzander-skills marketplace and Grand Central's existing documentation convention to decide where the ADRs belong. Define the log-decision plugin flow and seed docs/decisions/ with 2–3 examples from recent Umbraco or ROC work. Done means the four-week pilot can measure ADR creation, later references, prompt noise, and backfilling effort against the stated rollout criteria.