--- name: northstar-roadmap description: >- Read the project's NORTH_STAR / vision doc, measure current state against the goal, then propose a forward direction plus prioritized feature proposals — persisted as a durable roadmap in docs/plans + memory so the plan survives /compact and new sessions. Use when the user asks where the project should go next or wants a backlog grounded in the vision. Fires on the user's real phrasings: "앞으로 어떤 방향으로 개선·발전시킬지 고민해봐", "NORTH.md / NORTH_STAR 보고 나아갈 방향 + 기능 제안", "나아갈 방향 + 기능제안 (수용 → 계획 수립하고 메모리에 기록)", "북극성 정렬 로드맵", as well as the English equivalents: "what direction should we take next", "propose a roadmap / feature backlog from the north star", "plan the next milestones and save it to memory". Not for detecting bugs or auditing current quality (see gap-analysis-e2e / ultracode-service-audit) — this skill DIRECTS forward planning. --- # North-Star Roadmap (북극성 정렬 로드맵 + 기능 제안) Turn a vision document into a forward direction and a ranked feature backlog, then write it somewhere durable. The point is alignment, not idea generation: every proposal must trace upward to the north-star, and the result must outlive the conversation that produced it. ## When to use Reach for this skill when the user steps back from day-to-day work and asks where the project should head — typically with one of these (their actual phrasings): - "앞으로 어떤 방향으로 개선·발전시킬지 고민해봐" - "NORTH.md / NORTH_STAR 보고 나아갈 방향 + 기능 제안" - "(제안) 수용 → 계획 수립하고 메모리에 기록" - English: "what direction next", "propose a roadmap from the north star", "save the plan to memory" Do **not** use it to find what's broken right now. Detecting defects, gaps, or quality regressions is the job of the sibling skills below; this skill consumes their findings and points forward. ## Why these steps (the frameworks underneath) The workflow chains four established product-strategy methods so the output is defensible rather than vibes. Reason with each — don't just cite it: - **North Star Framework** (Amplitude) — a single North Star Metric is the destination; 3–5 directly-influenceable *Inputs* are the levers. You assess "current vs goal" against the inputs (leading indicators teams can move), not lagging vanity numbers. https://amplitude.com/books/north-star/about-north-star-framework - **Working Backwards / PR-FAQ** (Amazon) — for a major proposal, sketch the future end-state first (a one-line "press release" of the value the user gets), then derive the features. This forces clarity and stops "we can build X because we know how" reasoning. https://workingbackwards.com/concepts/working-backwards-pr-faq-process/ - **OKR lineage, not cascade** (Gothelf) — every roadmap item must have a *parent* it supports in the north-star. Items invented bottom-up that don't ladder up get cut. This is the core alignment test. https://jeffgothelf.com/blog/aligning-not-cascading-okrs-with-an-okr-lineage/ - **RICE / ICE scoring** (Intercom) — rank proposals by `(Reach × Impact × Confidence) / Effort` (RICE), or `Impact × Confidence × Ease` (ICE) when data is thin. Confidence is where you honestly discount exciting-but-unproven ideas. Scores are *inputs to a decision, not the verdict* — log every strategic override. https://www.intercom.com/blog/rice-simple-prioritization-for-product-managers/ · https://agileseekers.com/blog/feature-prioritization-using-rice-and-ice-models-in-product-roadmaps - **Theme-based Now / Next / Later** — organize the roadmap by outcome themes and horizons, not dated feature promises, so it ages gracefully and the why/what stays above the how/when. ## Core workflow ### 1. READ the north-star and restate it as Metric + Inputs Read the project's vision doc (here: `docs/NORTH_STAR.md` — it already defines the North Star Statement, the NSM, and measured Inputs). Restate the goal as **one North Star Metric + 3–5 influenceable Inputs**. If the doc already has them, lift them; if it only has a prose vision, derive a candidate set and show it for confirmation. Sanity-check the metric before trusting it: - Is it a **leading** indicator of value, or a lagging one (raw revenue, registered users, page views)? Lagging metrics are "what's done is done" — you can't steer by them. - Is it **gameable**? "If you can move it directly without delivering value, it's not a good north-star." Flag it instead of silently planning against a corrupt target. > In this repo the literal north-star is **GitHub stars** (per memory and the service-audit > roadmap), with the NORTH_STAR NSM (context cost per install, justified-asset ratio) as the *value* > the stars are supposed to reward. Plan toward stars **via** the value inputs, not by gaming the count. ### 2. ASSESS current state against each Input — expose the gap For each Input, state where the project is today vs target, using real evidence (existing plans, audit output, metrics, code state). The deliverable is the **gap**: the distance between now and the north-star, per lever. Be honest about unknowns — an unmeasured input is a gap too. ### 3. PROPOSE direction + features by working backwards First name the **forward direction** in a sentence or two — the theme(s) that close the biggest gaps. Then, for each significant proposal: - Write a one-line mini-PR (the future state: who gets what value once it ships). - List the concrete feature(s) that realize it. - State its **parent** — which Input / north-star pillar it supports. **No parent → cut it.** This is the alignment gate that prevents bottom-up feature churn. ### 4. PRIORITIZE with RICE (or ICE) and record overrides Score each proposal. Use RICE when you have reach/effort signal; ICE for a thin-data first pass. Write the numbers down so the ranking is auditable. Then apply judgment: dependencies, strategic table-stakes, and north-star fit may override a score — **log WHY** for every override (the same honesty the repo's `no-false-ship` and ADR/Decision-Log rules demand). Treat the score as a decision aid, never an autopilot. ### 5. PERSIST as a Now / Next / Later roadmap in docs + memory Write the result to a durable artifact so it survives `/compact` and new sessions: - **Update the existing roadmap SSOT** under `docs/plans/` (here: `service-audit-roadmap.md`) in place, organized by outcome themes in **Now / Next / Later** horizons — not dated commitments. Prefer one living doc over spawning a dated parallel (e.g. `northstar-roadmap-2026-06.md`): two roadmaps drift. Only create a separate dated horizon doc if the user explicitly asks for one. - A short anchor line in `memory/MEMORY.md` pointing at that doc, so it's re-referenced at session start as a Persistent Anchor (per CLAUDE.md "SPEC/PRD는 매 세션 시작 시 재참조"). - If a real architectural decision was made (e.g. dropping a direction), record an ADR under `docs/decisions/`, numbered as the next free integer (check the highest existing `ADR-NNN` first), per `change-management.md`. Then report back: the direction, the ranked table, and the file paths written. Mark it a **living document** — both the metric and the priorities are expected to be revised as strategy evolves. ## Worked example **Input (user):** `/northstar-roadmap NORTH_STAR 보고 나아갈 방향 + 기능 제안 → 계획 세워서 메모리에 기록` **Output (abridged):** > **1. Metric + Inputs** (from `docs/NORTH_STAR.md`) > North Star Metric: GitHub stars as the adoption signal that the harness delivers real value. > Inputs: (a) context cost per install (resident + fired tokens), (b) Promise = Implementation > (advertised assets 100% work), (c) first-run install success, (d) justified-asset ratio, > (e) 4-CLI parity. > *Leading-indicator check:* stars alone are gameable, so we plan against inputs (a)–(e), the value > the stars reward — not the raw count. > > **2. Gap** — (a) fired-body tokens unmeasured · (b) closed after no-false-ship work · (c) > install-matrix green but no post-publish telemetry · (e) plugins don't yet reach non-Claude CLIs. > > **3. Direction** — "Make the *first 60 seconds* prove the value before asking for a star." > Proposals: P1 first-run telemetry (parent: Input c); P2 plugin→codex/opencode equivalence > (parent: Input e); P3 public, continuously-tested compat+security matrix artifact (parent: Input d). > Each carries a one-line mini-PR. > > **4. RICE** — P1 (R 5·I 2·C .8·E 2 = 4.0) · P3 (R 4·I 3·C .7·E 3 = 2.8) · P2 (R 2·I 3·C .6·E 5 = 0.7). > *Override:* P3 promoted above its score — it's the repo's defensibility wedge (table-stakes for > a 0-star cold start). Logged here and in the ADR. > > **5. Persisted** — updated the SSOT `docs/plans/service-audit-roadmap.md` in place (Now: P1 · > Next: P3 · Later: P2), added the anchor to `memory/MEMORY.md`, opened the next free ADR > `docs/decisions/ADR-0NN-p3-override.md` for the strategic override. ## Pitfalls to design against - **Vanity / lagging / gameable north-star** — the two failure modes to refuse: picking a metric you can't influence (revenue, raw users) or one you can move without delivering value. - **False precision in RICE/ICE** — subjective Reach/Impact/Effort treated as exact truth. Confidence exists to discount shaky estimates; skipping it yields authoritative-looking wrong rankings. - **Score on autopilot** — shipping the top-RICE item while ignoring dependencies or strategic fit. - **Dated feature-list roadmap** — timeline promises rot; outcome themes in Now/Next/Later age better. - **Bottom-up idea dump** — proposals that don't ladder up to an Input. The alignment gate (step 3) is the cure. - **Plan that doesn't persist** — a great assessment that lives only in the chat and is lost at `/compact`. The artifact in step 5 is the whole point. ## Cross-references (siblings — do not duplicate) - **gap-analysis-e2e** — *detects* north-star gaps end-to-end. This skill consumes those gaps as the evidence in step 2. - **ultracode-service-audit** — produces a multi-dimension audit and roadmap of *current* problems. This skill takes that roadmap as input and points it forward. - **strategic-compact** / project ADR + plan-SSOT conventions — the persistence mechanism (step 5) reuses them rather than reinventing. > Audit and gap skills answer "what's wrong now?". This skill answers "where do we go, and in what > order?" — and makes the answer durable. ## Reference (progressive disclosure) This SKILL.md is the operating summary. If deeper method detail is ever needed — full RICE worked calculations, a PR-FAQ template, or a roadmap-doc skeleton — add a `reference.md` beside this file and link it here. Keep SKILL.md lean; the user dislikes verbose notepad docs.