setup

setup — initialise a project for Strategy Skills

What this skill does

Writes ${CLAUDE_PROJECT_DIR}/.strategy-skills/config.json, the single per-project config that every other strategy-skills skill reads. Without it the other skills refuse to run. Re-run any time to change a value.

It is the only strategy-skills skill that does NOT require a config to already exist, and the only one that writes one.

Locate the plugin

If ${CLAUDE_PLUGIN_ROOT} is set, the plugin assets are under it. Otherwise they are under the vendored path the user will confirm below. The canonical schema ships at <plugin-root>/reference/config.schema.json.

If a config already exists

Read ${CLAUDE_PROJECT_DIR}/.strategy-skills/config.json, show a short summary (organisation, output folders, brand colour, stage count), and ask what the user wants to change. Edit only the keys they name. Re-confirm and rewrite. Do not wipe values they did not mention.

If no config exists (first launch)

Run a short two-way Q&A. Lead with open questions, offer strong defaults, and never bombard. Group the questions, do not ask all at once. Confirm the assembled config before writing.

1. The organisation

• Name (required): the organisation or product these skills are for. Used in prose and document titles.
• Short name: an informal reference. Default: the first word of the name.
• Products / services: the offerings the skills reason about. Ask the user to list them. May be empty for now.
• Target market: one line on the target customer. Used for importance calls. Optional.
• Voices: the buyer voices pain-point and wwwh capture. Default Founder, C-Level, Engineer; confirm or change.

2. Where documents live

Offer 2 to 3 layout options with a small visual, then let the user pick or give their own:

• Single base folder (default): a <slug>/ folder with north-star/, brainstorming/, pain-points/, wwwh/, tasks/ under it, where <slug> is a kebab-case of the org name.
• Flat at repo root: the five folders directly at the project root.
• Custom: the user names each folder.

Record each as paths.outputs.<skill>, relative to the project root. Also ask, optionally, for a paths.research corpus folder and a primaryTranscript; leave them out if the user has none.

3. Where the plugin is vendored

Set paths.pluginRoot to the plugin location relative to the project root (used when ${CLAUDE_PLUGIN_ROOT} is not set, e.g. in Cowork). Detect it from where this skill is running and confirm with the user. If the plugin is installed (not vendored in-repo), still record the best-known path so Cowork copies work.

4. Brand

• Primary colour (hex): default #00adbb (teal). The renderer derives the rest of the palette from sensible defaults unless the user supplies more. A user who wants a full palette can give primary, primaryDeep, ink, tint, border, body, muted.
• Author line: printed on generated HTML. Default <Name> Strategy.

5. Voice rules

Defaults: noEmDashes: true, noOxfordCommas: true, concisionFirst: true. Confirm. Ask optionally whose voice prose is drafted for (draftFor); leave unset if none.

6. Work stages

Offer the default four-stage model as a starting point, and let the user keep, rename, reorder or replace them:

1. Define the services — the portfolio.
2. Service contents — what each service contains.
3. Business implementation — how it is delivered and run.
4. Marketing direction — positioning, messaging, channels.

For each stage record id, name, summary, and optionally a research list and crossCheck list (these can be filled later as the corpus grows). Leave the research maps empty if the user has no corpus yet.

7. Ground truth

Start groundTruth empty unless the user wants to lock facts now. Explain that settled facts can be added here later, and that every session will respect them.

Confirm, then write

Show the assembled config as a compact summary (a table or a fenced JSON preview). Ask explicitly: "Write this config?" Only on the user's yes:

1. Create ${CLAUDE_PROJECT_DIR}/.strategy-skills/.
2. Copy the schema: <plugin-root>/reference/config.schema.json → .strategy-skills/config.schema.json, and set "$schema": "./config.schema.json" in the config.
3. Write .strategy-skills/config.json.
4. Create each paths.outputs.<skill> folder.
5. Seed the tasks folder. In paths.outputs.tasks, if they do not already exist, write register.json as {"items": []} and people.json as {}. The tasks.py helper itself ships in the plugin (<plugin-root>/scripts/tasks.py) and reads these files via the config, so there is nothing to copy: the tasks skill is ready as soon as these two data files exist.
6. Keep operator identity out of the shared folder. The tasks skill records who is operating per-user, in ~/.claude/strategy-skills/identity.json (outside the project), so it is never carried to teammates — by git, or by a Dropbox/OneDrive folder that syncs everything and ignores .gitignore. As belt-and-suspenders for the optional project-local override, ensure the project .gitignore contains .strategy-skills/identity.local.json (add the line if missing; create .gitignore if there is none). Do NOT ignore .strategy-skills/config.json or the tasks data: those are shared and committed.
7. Optionally set the operator's identity now. Ask the user, optionally, who they are in this project and whether to add others to people.json. If they give their own name, add a people.json entry and run tasks.py whoami --set <their-key> so the tasks skill knows the requester without asking later. This is per-user, so each teammate sets it once on their own machine; skip if they would rather set it on first use.
8. Confirm what was written and tell the user they can now run north-star, brainstorm, pain-point, wwwh or tasks.

Hard rules

• Required minimum: organisation.name, paths.pluginRoot, and at least one paths.outputs.<skill>. Do not write a config missing these.
• Do not invent the organisation's facts. Products, target market and ground truth come from the user. Empty is fine; invented is not.
• Confirm before writing. Never write or overwrite the config without an explicit yes.
• On reconfigure, preserve unmentioned keys. Edit only what the user names.
• Valid JSON only. The config must parse. Validate against the schema's required keys before writing.

Red flags — stop

• Writing a config the user has not confirmed.
• Filling products, targetMarket or groundTruth with guesses instead of leaving them empty.
• Overwriting an existing config wholesale when the user only asked to change one value.
• Pointing paths.pluginRoot at a guess. Detect it or ask.