# North Star > Collapse a project to its North Star — the one defensible sentence that makes every roadmap decision easy — then restructure its roadmap file (TASKS.md or equivalent) around it (re-cut phases, promote the moat, archive shipped work, preserve any machine-read anchors). Trigger with /north-star , or when the user asks "what's the why of this / what's our North Star / reshape the roadmap around why this exists." - Skill: `davemaynard/north-star` (Agent Skill) - Install (CLI): `npx skillmds@latest add davemaynard/north-star` - Raw SKILL.md: https://api.skillmd.com/api/skills/davemaynard/north-star/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Product & Planning - Author: davemaynard (https://skillmd.com/u/davemaynard) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/davemaynard/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 **** — defined here so every priority has something to ladder up to. **The moat that makes this survive AI.** .> **Proof metrics — what winning looks like.** - **North Star metric: ** — . - . - The money ladder: → → . ``` 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. **** — ` — 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: … 👈 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/.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.