North Star

/north-star — from a goals list to a defensible "why"

Take a project (a repo, given as $ARGUMENTS or the current directory) whose roadmap file (TASKS.md, ROADMAP.md, or the plan section of README.md/PRODUCT.md; below, "the roadmap") is a phase/week checklist, and come back with a North Star — one defensible sentence + the one ownable thing "winning" means + the moat that answers why this survives AI + the single metric that proves it — and then restructure the roadmap around it so every priority has something to ladder up to.

The tell that a project needs this: its plan lists goals (G1/G2/G3, "great design + monetization + autopilot") but never collapses to a single why. Goals are how; the North Star is why. This skill forces the collapse, then rewrites the roadmap so the north-star work is the current focus.

Match this altitude. Two shapes the method has produced, for calibration:

• A niche directory site: goal sentence → "best" defined as two ownable things (be the cited answer for the niche + own the best finder tool) → moat paragraph (original field data no scraper has) → proof metrics + money ladder.
• A vetted-registry product: the same shape (the trusted verdict, not breadth; the audit process as the moat; "trust-query wins" as the metric). Its shipped Phase 0 archived to docs/archive/.

If the user has a previous North Star block from another project, read it first and reuse the exact block shape.

The output is a reshaped file, not a document

The deliverable is an edited roadmap (+ an archive file + a status note in the project's own docs), plus a short chat summary of what changed and the one tension the exercise surfaced. Not an essay. The North Star lives in the repo, where it steers work, not in a note that rots.

Phase 1 — Recon (local, parallel, before any writing)

Delegate the broad read to an Explore/general-purpose agent so the main context stays lean. Gather:

• The repo's positioning: its CLAUDE.md / AGENTS.md / README.md (what it claims to be, its hard rules — hard rules are often an implicit "why" already) and its current roadmap (phase shape, what's shipped vs open, the current proto-goals).
• The idea's origin notes, if the user keeps any (a product doc, a notes folder, an idea file): the origin metaphor, the monetization thinking, the competitive read, any "why" already half-articulated. Look for a pain the founder personally hit — that's a moat no scraper can fake.
• Any existing score or scorecard for the idea (a pillar scorecard, a kill-check, an idea-check output): its weakest pillar is the lever. The lever is the tension the North Star must confront (for the vetted-registry example it was feasibility: mechanize the vet loop without hollowing trust).

Phase 2 — Diagnose the thin "why"

In one or two honest sentences, name where the current plan is a goals-list masquerading as a North Star. Point at the specific artifact (e.g. "G1/G2/G3 is a list of goals, not a single why"). This is the setup that makes the forking questions land — don't skip it.

Phase 3 — Force the collapse (the forking questions)

Ask 3-4 questions via AskUserQuestion — the forks you genuinely can't derive, each with a recommended option first, labeled "(Recommended)". These are the standard forks; adapt the options to the domain:

1. For whom — the ONE user the project serves first (directory example: "the person/AI asking about one specific place"). Everything ladders to this. Offer the plausible users as options.
2. The one ownable win — what "winning" concretely means, pinned to 1-2 things the project can own (directory: "be the cited answer" + "own the best finder"; registry: "the trusted verdict"). Name the LOSING lane explicitly in the question (breadth, commodity synthesis) so the choice is real.
3. The North Star metric — the single number that, going up, means the why is being served. Kill vanity metrics in the option descriptions (for a directory, "tools listed" is the trap; "trust-query wins" is the real one). Prefer a metric already measurable (Search Console impressions, product analytics engagement).
4. (Optional) The moat / lever tension — only if the recon didn't already settle it. Usually the moat is derived from the first three + the lever, so don't over-ask.

Phase 4 — Draft the North Star block

Write it into a ## North Star block at the very top of the roadmap, in this fixed shape. Match the file's own voice — internal roadmap prose may use em dashes freely; reader-facing site copy may not, so this rule is per-repo, not global.

## North Star

The goal is **<one defensible sentence>** — defined here so every priority has something to
ladder up to.

<One paragraph pinning "winning" to the 1-2 ownable things, in priority order. Mark which is
"now, the whole game" and which is "later / half the north star, parked." Name the losing lane
you are NOT competing on and why (a competitor owns it / AI demotes it).>

**The moat that makes this survive AI.** <The proprietary data / community / freshness / brand
that AI can't synthesize — never the commodity synthesis itself. Tie it to the lever: the
central tension is <the feasibility/defensibility problem the roadmap must solve>.>

**Proof metrics — what winning looks like.**
- **North Star metric: <the single number>** — <how it's measured, already-tracked if possible>.
- <The input metric that is NOT the score — name the vanity trap it's often confused with>.
- The money ladder: <first prove-or-kill signal> → <first respectful dollar> → <the passive target>.

Confirm the block reads right before doing the surgical rewrite — the whole reshape depends on it.

Phase 5 — Reshape the roadmap around it

First check whether anything machine-reads the roadmap (a dashboard, a script, a CI step that parses headings). If so, find its parser and preserve every anchor it matches. A typical anchor set, for a roadmap that a dashboard parses:

• ## Where things stand — YYYY-MM-DD — keep it dated, right under the North Star block.
• **🎯 The next N moves** then 1. **<lead>** — <detail> — the bold leads get extracted. Re-order so the north-star move leads (the highest-leverage move for the metric), and re-frame each so it visibly ladders to the North Star.
• ## Phase N: <name> … 👈 CURRENT FOCUS — the Phase word + the marker are what gets matched. Move the marker to the phase that IS the north-star work — a shipped phase must not keep the marker.

The moves:

1. Re-cut phases by theme, not decayed calendar labels. Rename the active phase to the north-star work (registry example: "The trust-query engine"). Promote whatever is the North Star into active work (the directory example promoted its finder tool up a phase because it was "half the north star").
2. Demote the old goals (G1/G2/G3) from why to how — one line saying they ladder under the North Star, not the top of the file.
3. Promote a standalone ## Defensibility & Moat — why this survives AI section from wherever the moat is currently buried. This is the answer to "why doesn't a scraper / AI Overview eat this."
4. Archive shipped phases to docs/archive/<name>.md (create the dir if needed). Carry every still-open sub-item forward into the active phase — never drop an open item. Leave a pointer line in the roadmap ("… shipped and archived → docs/archive/…").
5. Keep the ## Rules that outlive any phase block (or add one) — the non-negotiables.

After writing, if a parser exists, verify the anchors against it (grep its regexes) so it still parses the date, the next moves, and the current phase. Don't assume — check.

Phase 6 — Record it in the project + summarize

• Write the outcome into the project's own docs so it's visible without hunting: a status line in PRODUCT.md / README.md (or the project's status file, if it keeps one) carrying the North Star in one line + the current focus + the next move.
• In chat, a short summary: the North Star sentence, the 4-5 structural changes, and the one tension the exercise surfaced (usually the lever, now with a name and a home). End there — this is a chat message, not a report.

Tone + house rules

• Direct, evidence-backed, in the project's own vocabulary (moat, lever, autopilot, the cited answer).
• The North Star must be defensible, not aspirational — if it doesn't survive "why doesn't a competitor / AI just do this," it's not done.
• Respect the project's cost rules (e.g. no metered API spend before revenue) in every phase.
• Map phases to the real calendar — when the founder's time is constrained, time-to-autopilot beats time-to-launch.
• Never delete shipped history; archive it. Never break a parser anchor. Never set a "done" marker on work that isn't.