Happy Path Works
Document Ops · setup guide · last updated October 29, 2026

Change records

Writes up a system change for the business owner who has to sign it off: what was asked for, what was changed, what was decided and by whom, what was tested, and how to undo it. A Word document in your brand, in short bullets rather than paragraphs. The skill calls it a requirement document, or reqdoc.

Before you start

A Claude plan with code execution turned on (Setup, step 1), the brand setup run once, and a change that is already built and tested, with someone waiting to sign it off. It records work that was done; it does not write a plan.

Add the skill

In the Claude web or desktop app, select Customize, then Skills › Add › Upload skill, and upload reqdoc-builder.skill from your download. Every upload tested so far used the file renamed to reqdoc-builder.zip; if the .skill file is not accepted, rename it and upload again. Setup walks through the screens.

Tested in Claude Code, the claude.ai web app and the Claude desktop app. See compatibility.

Ask for a change record

Type reqdoc: at the start of a message, then describe the change. “Write this change up” works too. Include what you have of:

  • the change reference and a short description;
  • the request, in the words of the person who asked, and who asked;
  • what was configured, with the names as they appear on screen;
  • the teams or departments it touches;
  • questions that came up, the answers, who gave each one, and when;
  • what was tested, including the thing next to it that should not have changed;
  • anything you could not show in testing;
  • how to undo it, and the values before the change.

It asks once for anything missing. If the brand setup gave you brand.json and logo.png to keep, attach both, with their names unchanged.

It does not invent test results or answers. Something you could not demonstrate goes into the testing section as a stated gap: what could not be shown, why, and how it will be confirmed.

What comes back

A Word file named with your change reference, such as ROAST_OPS_Batch_Disposition_Code_CR1042_REQDOC.docx: a cover, then fourteen sections in a fixed order, starting with Request. A section with nothing in it prints N/A, which says someone looked. Claude also says whether it rendered the pages to look at them.

Worked example

One request, typed into a new claude.ai chat with brand.json attached. ROAST WORKS is an invented coffee roastery.

What was typed

reqdoc: CR1042, a new SMPL disposition code for the Packing line. I'm Dana Whitaker, Business Analyst. Date it April 9, 2026. The request: Packing can't record sample and cupping batches separately from sellable output. Both get entered as standard disposition and corrected at the inventory close. It came in as a reporting change, but the real need is separating them at entry; a report can't separate batches that were never coded apart. Who it touches: Packing line 12, 11 operators, and the first release is that line only. The weekly inventory close picks up the new ledger class. No other line shares the disposition group. What I built: - There was no sample or cupping code under Maintenance > Production Settings > Disposition Codes. The nearest, WSTE, is waste-only and on a different ledger class. - Created disposition code SMPL, description "Sample and Cupping", non-sellable, counts toward yield: No. - Added SMPL to disposition group DG-PACK, which is assigned to line 12 only (checked on Line Details). - Mapped SMPL to ledger class SAMPLE on the nightly export. Carol Jensen confirmed the class is active on 04/04. Questions we settled: - Should SMPL count toward line yield? No. Carol Jensen, 04/02. Non-sellable, same as WSTE. - Can operators pick it, or lead entry only? Lead entry only for the first release. Greg Hollis, Packing line lead, 04/02. - Recode the current period retroactively? No. Carol Jensen, 04/03. Forward from 04/13 only; earlier corrections stay with the close. Scheduling: promote after the 04/11 period close, so the new code doesn't land on batch records already under review. Dependency: ledger class SAMPLE has to be active first, which it is as of 04/04. Interfaces: one new class on the nightly inventory export, a new value in an existing field, no layout change. Testing, in the test environment: - Before: SMPL not in the disposition picker, line 12 batch record, 04/06. - After: SMPL selectable, 4 batches coded on 04/07. - After: line 12 totals for 04/07 leave the 4 SMPL batches out of the yield figure. - Line 9's picker, before and after (04/06 and 04/07): unchanged, no SMPL. - Export preview 04/07: SMPL rows land as ledger class SAMPLE against the right line and date. What I couldn't show: how it behaves at the yield threshold across a full production week. The test environment has no Packing line with volume near the threshold, so that's inferred from how WSTE behaves, not observed. We'll check it against the first live week. Undoing it: taking SMPL out of DG-PACK stops new entries, but batches already coded SMPL and exported have to be found and recoded in the ledger: pull disposition code SMPL for the affected period, recode to STD, re-export. It hasn't been promoted yet. I've attached our brand file (brand.json).

What came back

[…] The CR1042 requirement doc is built, branded Roast Works, and dated April 9, 2026 under Dana Whitaker’s name. Requirement doc for CR1042, the SMPL disposition code on Packing line 12: ROAST_OPS_Batch_Disposition_Code_CR1042_REQDOC.docx. reqdoc_check result: PASS, clean, exit 0. All 14 sections present in order, 24 bullets, 1 evidence gap. The longest item runs 4 lines, and that is the gap, which has a soft cap of 4. Rendered and checked by eye: a cover page, two pages of body, then the Promotion table on page 4. The table moves as one block, so it landing on its own page is expected. Reversibility is classed R2, with your SMPL→STD recode as the remediation. Error Notice Setups is N/A. The Promotion table is blank because the change hasn’t promoted yet. Fill it in after 04/13. Every Processing Considerations answer has a name and a date: Carol Jensen (×2) and Greg Hollis. […]

The file: ROAST_OPS_Batch_Disposition_Code_CR1042_REQDOC.docx, 4 pages.

Page 2 of the change record that request produced, where the sections begin

Page 2 of what came back.

What gets checked

Before you get the file, the skill checks it:

  • every section is there, in order, and none is left empty;
  • each bullet stays short: a warning above two lines, a failure above three, with a little more room for a stated gap;
  • every answer to a question carries a date, and a missing one is flagged;
  • the page is US Letter with one-inch margins, and the promotion table has not been changed in Word;
  • the file name follows your brand’s pattern and carries the change reference.

What no check can tell you: whether a person named beside an answer is real, whether the testing covers the thing that should not have changed, and whether the evidence is true. Nothing can tell a real test result from an invented one, which is why the skill stops rather than fills one in.

If it says no

It says the skill’s files are missing. Once in testing, a chat loaded the skill’s instructions without its files. Claude stopped and said so rather than build an unchecked copy. The same request in a new chat worked.

The change is not built or tested yet. It stops. Come back when it is: the document records what was done.

Nobody has to sign it off. It says you want a build note or a ticket comment instead, and builds nothing.

Your organization has its own template with different sections. It says so before building, rather than hand you a document that will be sent back for its shape.

You wanted step-by-step instructions. That is a procedure; it hands you to the SOP builder.

Using Claude Code instead

Extract the .skill file into your skills folder: ~/.claude/skills/ for every project, or .claude/skills/ inside one. A skill in that folder does not reach your claude.ai account, and one on your account does not reach that folder.

Needs Node on the machine; the pack is tested on Node 20 and Node 24. Nothing else to install: the one library the skill uses ships inside it.

The skill reads your brand from brand.json and logo.png, looking in this order and stopping at the first hit: the path in HPW_BRAND_KIT, the folder you build from, any folder above it, then the neutral defaults.

To confirm the install, run this from the folder you will build in. Exit 0 means every file is present:

$ node <skill folder>/check_deps.js

To prove it end to end, build the shipped sample from a folder outside the skill. It builds the sample and checks it; expect PASS — clean:

$ node <skill folder>/examples/reqdoc-sample/build_sample_reqdoc.js