메뉴
PRD template and authoring rules for Foreman. Synthesizes a PRD from the approved plan and the grilled decisions and writes it as a local file in the Foreman feature directory. Does not interview the user and does not publish to any external issue tracker.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Headless root-cause debugging loop for a Foreman worker whose tests, build, or acceptance check are failing — especially on a retry. Find the root cause before changing anything, fix at the source with a regression test, and never thrash on symptom patches. Used inside a foreman-tdd build session; emits no summary of its own.
Headless implementation-plan authoring for the Foreman planning stage. Explore the target repo first, then write a deep, decomposition-aware plan that the grill→ADR/PRD→issues pipeline can build on — goals, seams, data/interface changes, risks, sequencing, and testing strategy. No placeholders. Writes the plan body and stops.
Headless self-verification gate a Foreman worker runs before it claims an issue is done. Re-run the real commands, read the actual output, and only then write the FOREMAN-SUMMARY — evidence before claims, always. Used inside a foreman-tdd build session; emits no summary of its own.
Headless end-to-end / web-app testing for the Foreman e2e stage. Derive end-to-end tests from the PRD's User Flows, drive the real application the way a user would (browser flows, screenshots, accessibility checks for web apps), make them pass via the configured e2e command, and emit the FOREMAN-SUMMARY block Foreman parses.
Headless grilling pass that challenges an approved implementation plan against the existing codebase and domain model, then writes an ADR draft and a PRD draft into the Foreman feature directory. Self-answers every question it can from the code/docs and surfaces the rest as an "Open questions for reviewer" block instead of interviewing a live user.
Stack-agnostic test-driven development loop for a single Foreman issue. Implements one vertical slice with strict red-green-refactor (one test at a time, never horizontal slicing) using the foreman-test wrapper, saves completion evidence, then emits a machine-readable FOREMAN-SUMMARY block Foreman parses.
| name | foreman-to-prd |
| description | PRD template and authoring rules for Foreman. Synthesizes a PRD from the approved plan and the grilled decisions and writes it as a local file in the Foreman feature directory. Does not interview the user and does not publish to any external issue tracker. |
| foreman_skill_version | 1 |
(Adapted from mattpocock/skills to-prd — see NOTICE. Removed: live "check with
the user" seam confirmation and the GitHub publish + ready-for-agent label step.
Output is a local prd.md file, not a tracker post.)
This skill is the PRD template authority. The foreman-grill-docs skill calls
it to produce prd.md. Synthesize from the approved plan, the codebase, and the
grilled decisions — do NOT interview anyone.
Explore the target repo to understand the current state, if you haven't. Use
the project's domain glossary (CONTEXT.md) throughout, and respect ADRs in
the area you're touching.
Identify the seams at which the feature will be tested. Prefer existing
seams; use the highest seam possible. If a new seam is needed, propose it at
the highest point you can — and if whether that seam is acceptable is a genuine
product/architecture call you cannot settle from the code, add it to the
## Open questions for reviewer block rather than asking interactively.
Write prd.md into the feature directory using the template below. Begin the
file with the open-questions block (see foreman-grill-docs). Do not publish
anywhere and do not apply any labels.
<unresolved product/architecture questions, or "None — all resolved.">
The problem the user is facing, from the user's perspective.
The solution to the problem, from the user's perspective.
A LONG, numbered list of user stories, each: As an <actor>, I want a <feature>, so that <benefit>. Extremely extensive — cover all aspects of the feature. These
stories are the basis for the slicer (foreman-to-issues) and for the e2e flows,
so make each one concrete and verifiable.
For each end-to-end flow a user can perform, list the ordered steps and the observable outcome. These flows are what Foreman's e2e phase will turn into automated tests, so be precise about preconditions, steps, and expected results.
Modules built/modified, interfaces changed, technical clarifications, architectural decisions, schema changes, API contracts, specific interactions. No file paths or code snippets (they go stale) — exception: a prototype-derived snippet that encodes a decision more precisely than prose (state machine, reducer, schema, type shape) may be inlined, trimmed to the decision-rich parts.
What makes a good test here (test external behavior, not implementation details); which modules will be tested; prior art for the tests (similar tests already in the codebase); the test/lint/typecheck commands Foreman will run to verify work.
What is explicitly not part of this PRD.
Anything else worth recording.
