strategy-builder

${var} — a brief. Two accepted shapes:

• Structured (from the dashboard): |-separated tokens — any of repo=<owner/repo>, links=<url1,url2>, goal=<free text>. goal is the last token; everything after goal= is the goal text. Example: repo=acme/widgets | links=https://acme.com | goal=grow paying teams, win on reliability.
• Bare text: just the goal, e.g. growing my open-source agent framework — active contributors, not stars.

If ${var} is empty, fall back to the repo README + memory/MEMORY.md to infer direction. If even that yields nothing usable, log STRATEGY_BUILDER_SKIP: no brief — set var or add a goal and stop with no notification.

Today is ${today}. This skill writes STRATEGY.md — the operator's north-star. It's imported into CLAUDE.md, so it rides along in the context of every skill run. That sets the bar: it must be tight (it costs tokens every run) and specific (a vague strategy can't break a tie when a skill has to choose what to work on).

This is the agent behind the dashboard's Strategy → Build my strategy button.

Why this skill exists

Most forks never tailor STRATEGY.md — it sits on the unconfigured defaults, so skills operate with no specific bias. But the operator's direction is usually knowable from a sentence of intent plus what's already in the repo (README, what's being shipped, MEMORY.md). This skill turns that into a strategy skills can actually act on: one outcome to optimize, a few ordered priorities, the audience, and the hard lines.

Steps

0. Parse the brief