change-request: a Before-building read, and the admin's job in the operating model (plugin 0.39.0)

[seth-with-zest]

What

The change-request plan gains a Before building section, and the operating model's Role section gains the passage it comes from, The admin's job, and yours. Plugin 0.39.0, with the CHANGELOG entry.

• templates/operating-model.md: how a good CS Ops admin thinks about a change before building it, and that the session's job is the same thinking one level down. This is the one canonical statement; the skill points at it. Existing workspaces pick it up through the scaffold's .new offer at the next setup or refresh.
• skills/change-request/SKILL.md: step 4 does that thinking with the KB open and holds every line of the section to one test (would the admin build, roll out, or say something different after reading it?); step 7's chat summary gains a Heads-up: line carrying the one line the admin most needs before opening the file.
• references/plan-template.md: the section, its render rule, and one exact line for when there is nothing to add.
• test/fixtures/change-request/expected-plan.md: the section worked through on the fixture ticket (the fixture's playbook decision moves from Risk notes into this section, where it belonged).
• test/change-request-fixtures.mjs: locks the section across the skill, the template, the operating model, and the fixture.
• README and CHANGELOG.

Skill prose only. No script, hook, guard, or generated file changes.

Why

Plans from /change-request today answer the question the ticket asks: can this be built, what does it touch, what should the assets be called, what are the commands, how do we roll it back. That's the part of the admin's job the CLI and the KB do well. The part that separates a senior CS Ops admin from a newer one comes before any of that.

A ticket arrives with the feature already picked, by someone who picked from the features they know about. The experienced admin asks what the CS team is trying to do, whether the CSMs will work the thing or learn to ignore it, whether the data is good enough to drive it, what changes for the customer on the other end, whether the tenant can already do this, who keeps it running after the requester moves on, and whether the process behind the ask should exist at all. Then they say the one or two things that matter and let the business decide. Under queue pressure that thinking is the first thing skipped, and a newer admin hasn't had the years that make the questions automatic. That's the gap I wanted the plugin to close: a session running it should do for the admin what a seasoned CS Ops person does for the business, so that a junior admin can bring that level of thinking to the table before they've grown into it themselves.

Two constraints shaped the form. First, it had to be taught as judgment, not as a checklist. A list of questions the session answers in full on every ticket produces a memo nobody working a queue reads, and it teaches the admin that the section is skippable. So the mindset lives in the operating model as the admin's own thinking, the skill holds each line to a single test, a small change gets a small think, and there's an honest one-line way to say nothing applies. Second, nothing can wait on an answer. Admins resent questions that hold up the work, so the plan is always written on the ask as stated, with the better route and its cost next to it, and any question sits beside the default the plan already took so the admin can confirm it in a glance or pass it to the requester. The plan never argues the admin out of what the business needs. It shows the best way there and what it costs, and leaves the decision with them.

Review notes

Read in this order: the operating-model passage (the canon), then SKILL.md step 4 (the method and the test), then the fixture's Before building section. The fixture is the one worked example and the thing to judge the register against: is that what you'd want a senior admin to say to you about that ticket, in that many words?

Verified locally on this commit: test/change-request-fixtures.mjs, test/guard-fixtures.mjs, build/build-plugin-gs-superadmin.mjs with no drift under plugins/gs-superadmin/reference, check-stale-facts, check-doc-drift, check-instance-data. Cross-document consistency: neither the managed CLAUDE.md block nor the cheatsheet renderer describes what a change-request plan contains, so the operating model and the skill are the only two documents that state this, and the skill points at the operating model rather than restating it.

The walk is owed. change-request is slash-only and there's no tenant in the contributor session, so the skill was not run for real. What the walk should measure, on a real ticket: is the Before building section proportionate to the change (a small, well-specified ticket should get one line, or the exact empty line); does the Heads-up: line carry the thing you'd actually want to know first; and does the section stay on the ask as stated rather than holding up the draft. Banking it in dev/VALIDATION.md for the next tester round is fine by me.

• Plugin version bumped in .claude-plugin/plugin.json with a CHANGELOG entry.
• Safety boundary: this PR does not touch hooks/gs-admin-guard.mjs or ask-rules generation.
• Skill edits: cross-document consistency checked (yes, above); walked for real: no. Session / verdict: not walked, no tenant in the contributor session; walk owed, see Review notes.
• No test or dev step touched real gs-admin state.
• No tenant/instance/org-specific data in commit messages or this PR body.

🤖 Generated with Claude Code