| 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:
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 (HITO ≤ 3/feature, low re-clarification) 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) HITO ≤ 3 / feature, (b) Promise = Implementation (advertised assets 100% work),
(c) first-run install success, (d) vetted+security-audited asset count, (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) HITO unmeasured in fresh installs · (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.
