begin

begin: from fresh copy to working project

Run this once. When it's done, STATE.md carries real state and this skill never triggers again.

Which of the two entrances is this? Read it off the tree before doing anything, and say which one you read: a fresh copy holds nothing but Groundwork, while an existing project has its own .git history, source files, and a README that is not this one. Both take the route below; the existing project keeps everything it already has, and the steps say where the two differ. One skill, two doors: decision 0018 records why.

1. Clean the copy

Do this housekeeping silently: it is plumbing, not progress. Report on it only if something went wrong or needs the owner's action; a list of deleted template files is noise to them.

• If a MASTER_PROMPT.md or MASTER_PROMPT.local.md exists at the root: it is Groundwork's own origin brief, not part of any project. Delete it. (Fresh copies no longer carry it: it is gitignored at source. This clears it from older copies made while it was still tracked.)
• CHANGELOG.md at the root is Groundwork's release history, not this project's. Note which version this copy came from (its newest entry) in STATE.md at step 4, then empty the file down to its heading so this project's first release writes into it.
• Delete any non-archived spec folder: docs/specs/[0-9]* directories are in-flight Groundwork maintainer work, never the new owner's. Keep the worked example in docs/specs/archive/007-pickup-slots/ and the TEMPLATE*.md files.
• docs/product/VISION.md does not exist in a fresh copy, because Groundwork keeps its own purpose out of the copy entirely. Put this project's in place (cp docs/product/TEMPLATE-VISION.md docs/product/VISION.md); the interview at step 4 fills it, and it is the first document that step writes, because scope serves purpose.
• docs/product/BRIEF.md and docs/specs/archive/000-baseline/ hold Groundwork's own scope and the record of what the framework itself had already shipped. Counted against this project they would report someone else's work as done here. Put the blank brief back (cp docs/product/TEMPLATE-BRIEF.md docs/product/BRIEF.md) and delete the baseline folder.
• docs/PRODUCT.md is Groundwork's own record of the surfaces this framework renders, which the design method would read as this project's product truth. Delete it: the method's own init writes this project's, in the same place, from what the interview below already captured. docs/DESIGN.md stays: sections 1 and 2 ship with Groundwork and are input to that method.
• docs/standards/node.md is Groundwork's own stack and its own floor table, which stack-gates would hold this project to. Delete it: a copy has not chosen a stack yet, and the stack skill writes this project's own from docs/standards/TEMPLATE-STACK.md. GLOBAL.md and the template stay - they are the cross-stack floor and the shape, not Groundwork's answers.
• docs/operations/deploy.md holds Groundwork's own release route, which would read as this project's if it stayed. Put the blank runbook back (cp docs/operations/TEMPLATE-DEPLOY.md docs/operations/deploy.md). deliver fills it at first delivery.
• docs/state/DEBT.md carries Groundwork's own debt rows, which maintain would harvest and report as this project's. Put the blank ledger back (cp docs/state/TEMPLATE-DEBT.md docs/state/DEBT.md). The first accepted defer: marker fills it; on the existing-project door below, the check total lands here as the starting position.
• docs/compliance/REGISTER.md holds Groundwork's own compliance answers, which would read as this project's if they stayed. Put the blank register back (cp docs/compliance/TEMPLATE-REGISTER.md docs/compliance/REGISTER.md). Step 4 fills its header from the interview; comply fills the rest before first delivery. The two files beside it, docs/compliance/COMPLIANCE.md and docs/compliance/AI-LITERACY.md, are shared knowledge and stay as they are.
• Reset "denylist" in checks/config.json to []: its entries guard the origin repo's retired wording, never this project's. Keep styleBans intact (those are generic).
• Keep the numbered records in docs/decisions/: they document the system this project just inherited (why the rulebook, skills and checks work the way they do). This project's own decisions continue from the next free number. Naming a range here would go stale the next time the framework records one.
• Strip the data-derive attributes from the stat strip in index.html (leave the numbers and the page alone). They tie those numbers to a gate that counts this repo, and in a copy the numbers describe the framework, not the project: the first decision this project records would otherwise turn the gate red.
• Verify prerequisites: git --version and node --version (Node ≥ 20). Missing → tell the owner exactly what to install, then stop.