repo-to-roadmaplisted

Analyze an entire software/product project and turn verified project truth into an evidence-based, dependency-aware, reusable roadmap. Use for first-time or delta whole-project baselines such as "analyze the whole repo/project", "what is left to build before target state", "create/update a roadmap from GitHub/Notion", "przeanalizuj całe repo", or "update the roadmap after recent changes". Inventory topology before searching, separate intent/presence/behavior/release/outcome truth, prove material absence instead of inferring it from search misses, expose coverage and contradictions, model capabilities/critical journeys, prioritize target blockers and gates, validate hard dependencies, and create immutable baseline/delta roadmap snapshots. Do not use for weekly sprint control, release-candidate GO/NO_GO gates, or "is build v1.2.3 ready to ship?" — use Product Operator or Release Readiness instead. Do not use as an implementation agent, narrow code review, or specialist security/SEO/CRO audit.
MaciejZet/agent-skills · ★ 1 · AI & Automation · score 74

Install: claude install-skill MaciejZet/agent-skills

# Repo to Roadmap v2 Turn project evidence into a defensible roadmap that another human or agent can execute and later revalidate. Keep the chain explicit: `target state -> project topology -> evidence -> claims -> capabilities/gaps -> roadmap items -> acceptance proof -> living snapshot` Default to read-only analysis. Do not create issues, edit repositories/docs, merge code, or trigger deployments unless the user separately asks for those side effects. ## 1. Select assessment mode Choose exactly one mode and state it: - **STANDARD** - default whole-project assessment. Account for every material project domain, then deep-read evidence-bearing surfaces. Do not imply every file was read. - **EXHAUSTIVE** - use only when the user explicitly asks for every file/module or equivalent. Account for the complete in-scope file set at a pinned ref or disclose `EXHAUSTIVE_NOT_PROVEN`. - **DELTA** - update a prior roadmap against a new commit/branch/release/date/assessment. Revalidate changed claims plus affected dependencies instead of starting over blindly. - **FOCUSED** - use only when the user explicitly narrows scope to a package/module/release objective. Do not label it whole-project. Never silently downgrade an explicit exhaustive request into sampling. ## 2. Establish the Assessment Contract Resolve from existing context when possible; do not ask unnecessary questions. Record: - project/repository scope, - target-state profile: `PROTOTYPE | INTERNAL_BETA | PUBLIC_BETA