frostney/known-good-route

roadmap-review

Reviews a roadmap from fresh project evidence and produces a verified, throughput-anchored version plan, with execution gated on confirmation.

소스 보기

사용 방법

  1. 설치 명령을 복사하고 자신의 에이전트 환경에 설치하기 전에 소스 패키지를 확인하세요.
  2. 필요한 도구, 인증 정보, 지원 환경은 원본 문서에서 확인하세요.
  3. 입력과 원하는 산출물을 설명하고 출처와 결과를 대조하세요.
npx skills add https://github.com/frostney/known-good-route --skill roadmap-review

시작 전 확인

  • 설치에는 모델 구독, API 한도, 파일 접근 권한이 포함되지 않습니다.
  • 별점 수와 설치 수는 활동 지표이며 독립적인 품질·보안 검증이 아닙니다.
원본 Skill 문서

원본 저장소의 제목, 예시, 코드, 표, 링크, 이미지를 유지해 표시합니다.

Roadmap review

Produce a source-verified roadmap and throughput-anchored release plan. Analysis is the deliverable; issue, pull-request, milestone, and release changes are optional and confirmation-gated.

Evidence contract

  • Pull current issues, releases, milestones, merged PR history, and project

direction documents this run. Record missing sources and lower confidence rather than filling gaps from memory.

  • Measure 90-day merged-PR throughput and issue-created-to-PR-merged lead time.

Use PR-opened-to-merged only as a flagged fallback. Exclude closed triage with no implementation.

  • When a domain metric exists, measure its slope from spaced historical CI

artifacts. Allocation by label or area describes past effort, not capacity.

  • Before proposing or characterizing work, classify it against current code,

tests, or primary specifications as Done, Partial, or Absent with evidence. Propose only Partial or Absent work.

Delegate independent, sizeable evidence areas to context-isolated subagents by default when the host supports it; work directly on small or coupled areas. Synthesize before planning.

Workflow

  1. Ground the review in the evidence contract and reconcile issue, pull-request,

release, and milestone counts from the Git hosting service.

  1. Assess release cadence, merged-but-unreleased work, milestone-versus-commit

drift, vision, scope, and non-goals.

  1. Classify every candidate under the evidence contract and drop work already

delivered.

  1. Apply measured rates to the counted remaining backlog, with basis and

confidence. Never pad the timeline. When evidence cannot support calendar dates, report ranges and dependencies without a dated Gantt or placeholder dates.

  1. Plan themed releases across independent tracks, marking dependencies and the

longest pole. Surface genuine human decisions with a recommendation.

  1. Stop for those decisions and present:
  • current state, drift, and release-cadence recommendation;
  • measured velocity and confidence;
  • versioned, sized tracks;
  • throughput-anchored timeline with a Mermaid Gantt when available;
  • open decisions.
  1. Offer a date-stamped ROADMAP-YYMMDD.md; do not write it without the user's

request.

  1. Create or modify milestones, issues, due dates, or labels only after explicit

confirmation of the finalized plan. Create each issue through /create-issue and report exactly what changed.

  1. After the confirmed milestone and its tracked scope exist, offer

/milestone-rush <milestone> as an explicit next action. Never start the rush automatically; selecting it grants that skill's scoped implementation and merge authority.

Keep the report decision-relevant and snapshot-dated. Re-pull before acting on an old report.

관련 작업

같은 저장소의 Skills

더 많은 Skills

모든 Skills
frostney
커뮤니티

milestone-rush

Autonomously completes a confirmed milestone by reconciling existing work, coordinating work-item delivery and the configured milestone release, and closing the verified milestone. Use when the user runs /milestone-rush or asks to complete one exact, confirmed milestone, including selecting it after /roadmap-review.

설치 수
1
GitHub Stars
0
업데이트
10월 20일
frostney
커뮤니티

run-retro

Reviews a workstream and agrees process improvements, applying only the selected follow-up actions. Use when the user asks for, runs /run-retro, or accepts a retrospective.

설치 수
1
GitHub Stars
0
업데이트
10월 20일
frostney
커뮤니티

software-engineering-excellence

Applies the user's engineering standards during substantial technical work: preserve scope, use current evidence, delegate independent parts, and complete authorized outcomes. Use during substantial implementation, debugging, refactoring, or multi-part delivery work.

설치 수
1
GitHub Stars
0
업데이트
10월 20일
frostney
커뮤니티

test-against-spec

Tests observable behavior against explicit requirements through the real interface. Use when asked to test or verify that a change meets its specification or acceptance criteria, when the user runs /test-against-spec, or when a delivery workflow needs real-interface acceptance evidence.

설치 수
1
GitHub Stars
0
업데이트
10월 20일