Derive PRDs, ADRs, PRPs from git history, docs, and codebase. Use when onboarding a project to blueprint, generating a PRD or ADRs retroactively, or extracting features from conventional commits.
Standardmäßig ist der Prompt ausgewählt, der zuerst die Quelle prüft. Sie können zu einem direkten Befehl wechseln oder eine lokale Kopie herunterladen.
Quelldateien prüfen
Lesen Sie SKILL.md und alle von SkillsMP angezeigten Begleitdateien, bevor Sie sich für eine Installation entscheiden.
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Ein direkter Befehl überspringt den Prüf-Prompt. Prüfen Sie die Quelle, bevor Sie ihn ausführen.
Derive PRDs, ADRs, PRPs from git history, docs, and codebase. Use when onboarding a project to blueprint, generating a PRD or ADRs retroactively, or extracting features from conventional commits.
args
[--quick] [--since DATE]
argument-hint
--quick for fast scan, --since 2024-01-01 for date range
Retroactively generate Blueprint documentation (PRDs, ADRs, PRPs) from an existing established project by analyzing git history, codebase structure, and existing documentation.
Use case: Onboarding established projects into the Blueprint Development system when PRD/ADR/PRP documents don't exist but the project has implementation history.
When to Use This Skill
Use this skill when...
Use alternative when...
Project has git history but no PRDs/ADRs/PRPs
Starting a brand new project with no history
Onboarding an established project to Blueprint
Creating a fresh PRD from scratch with user guidance
Need to extract features from commit history
Project lacks conventional commits and clear history
Want to document architecture decisions retroactively
Extract feature boundaries from conventional commit scopes
Identify architecture decisions (migrations, major dependencies, breaking changes)
Find issue references and future work items (TODOs, skipped tests)
Identify release boundaries from git tags
Collect findings in structured format for user confirmation.
Step 5: Analyze codebase and existing documentation
Use Explore agent to analyze architecture: directory structure, components, frameworks, patterns, entry points, data layer, API layer, testing structure
Extract dependencies from manifest files (package.json, pyproject.toml, Cargo.toml, go.mod, etc.)
Read and extract from existing documentation: README.md, docs/, ARCHITECTURE.md, DESIGN.md, CONTRIBUTING.md
Detect future work: TODOs in code, open GitHub issues, skipped tests
Step 6: Clarify project context with user
Ask for clarifications via AskUserQuestion. For the full question templates
(problem statement, target users, project phase, stakeholder scale), see
REFERENCE.md.
Project purpose (if not clear from README): present the inferred description for confirmation, or ask the user to provide one
Target users: developers, end users, or both — steers the PRD's framing
Project phase: MVP / active development / maintenance / planning major changes — sets feature-vs-stability emphasis
Stakeholders: scale (solo / small team / larger org / OSS community) → drives the depth of the PRD's stakeholder matrix (see REFERENCE.md)
Feature confirmation: present {N} features extracted from git for review/prioritization
Architecture rationale: for each identified decision, ask the main driver
Generation confirmation: show the summary below and ask if ready to generate
For each document type, use templates and patterns from REFERENCE.md:
Generate PRD as docs/prds/project-overview.md
Use sections and structure from REFERENCE.md
Include extracted features with priorities and sources
Mark sections with confidence scores
Generate ADRs as docs/adrs/{NNNN}-{title}.md (one per decision)
Use ADR template from REFERENCE.md
Include git evidence (commit SHA, date, files changed)
Mark with confidence score
Conflict & supersede check: after writing the ADRs, run
/blueprint:adr-relationships to detect same-domain conflicts and
/blueprint:adr-validate to enforce bidirectional supersede consistency.
Do not re-implement conflict scoring here — those skills own it.
Create ADR index at docs/adrs/README.md
Table of all ADRs with status and dates
Link to MADR template for new ADRs
Generate PRPs as docs/prps/{feature}.md (one per future work item)
Step 8.5: Offer GitHub issues for generated docs (optional)
For the generated PRD (and optionally each PRP), prompt with AskUserQuestion
whether to open a tracking GitHub issue. See
REFERENCE.md for the prompt template and
the gh issue create command. When the user accepts:
Create the issue with title [{PRD-NNN}] {Project Name}.
Add the issue number to the doc's github-issues frontmatter.
Record it in the manifest id_registry (documents[ID].github_issues and the github_issues map).
Skip silently when no gh remote is configured or the user declines.
Step 9: Update task registry
Update the task registry entry in docs/blueprint/manifest.json: