メニュー
Synthesise the grill session output into a structured Product Requirements Document. Use in the Architect sub-pipeline after grill-with-docs completes.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Act as the Archivist for an LFE-compliant project. Use when a change is approved and needs documentation sync, changelog updates, or pipeline status cleanup.
Act as the Architect for an LFE-compliant project. Design solutions and draft high-fidelity plans.
Act as the Builder for an LFE-compliant project. Use when implementing an approved plan, writing code in src/**, or running unit tests.
Inspector sub-skill. Analyses changed code for cyclomatic complexity, excessive nesting, oversized functions, and cognitive load indicators. Pure LLM reasoning — no external tooling. Writes .plans/checks/complexity_findings.md. Called by lfe-inspector when enabled in inspector-config.md.
Inspector sub-skill. Reviews dependency manifest files (package.json, requirements.txt, go.mod, Cargo.toml, pom.xml) changed in the current diff for risky version patterns and stale majors. Emits a human-run audit instruction rather than executing tools. Writes .plans/checks/dep_findings.md. Called by lfe-inspector when enabled in inspector-config.md.
Disciplined bug-diagnosis loop. Reproduce → Hypothesise → Fix. Use in the Inspector sub-pipeline (Step 3, conditional) when verification fails.
| name | lfe-to-prd |
| description | Synthesise the grill session output into a structured Product Requirements Document. Use in the Architect sub-pipeline after grill-with-docs completes. |
.plans/01_grill_summary.md.plans/02_prd.mdRead input: Read .plans/01_grill_summary.md as the source of truth — it carries this step's inputs, not the conversation.
Explore the repo to understand the current state of the codebase, if you haven't already. Use the project's domain glossary vocabulary throughout the PRD, and respect any ADRs in the area you're touching.
Sketch modules: Identify the major modules you will need to build or modify. Actively look for opportunities to extract deep modules that can be tested in isolation. Check with the human that these modules match their expectations.
Write the PRD using the template below and save it to .plans/02_prd.md.
---
phase: architect
step: 2_prd
status: complete
timestamp: <ISO-8601>
source: .plans/01_grill_summary.md
---
## Problem Statement
The problem the user is facing, from the user's perspective.
## Solution
The solution to the problem, from the user's perspective.
## User Stories
1. As an <actor>, I want a <feature>, so that <benefit>
## Implementation Decisions
- Modules that will be built/modified
- Interfaces that will be modified
- Architectural decisions
- Schema changes
- API contracts
Describe modules and interfaces generically; omit specific file paths or code snippets, which may become outdated.
## Testing Decisions
- Which modules will be tested
- What makes a good test (behavior, not implementation)
- Prior art for tests in the codebase
## Out of Scope
What is explicitly NOT part of this work.
Update pipeline_status.md coordination tracker to mark step 02 as ✅.