Run any Skill in Manus with one click

to-prd

Stars0

Forks0

UpdatedJune 15, 2026 at 23:26

Turn the current conversation context — ideally after a /grill-me session — into a PRD written to the repo. Do NOT interview; synthesize what's already been decided. Use when Tobi wants to turn a grilled-out plan into a written spec, or says "to-prd" / "schreib den Plan".

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

Pr0degie

Pr0degie/dungeonmaster

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

SKILL.md

readonly

name	to-prd
description	Turn the current conversation context — ideally after a /grill-me session — into a PRD written to the repo. Do NOT interview; synthesize what's already been decided. Use when Tobi wants to turn a grilled-out plan into a written spec, or says "to-prd" / "schreib den Plan".

Synthesize the grilled context into a PRD

The companion to /grill-me: grill-me builds the shared understanding, this writes it up. Do NOT interview — synthesize what's already been decided in this conversation and the codebase. If the context is thin (no grilling happened), say so and suggest /grill-me first.

Process

Explore. Read the current state of the area in code, plus architecture.md and the ADRs in docs/decisions/ governing it (decision log + phase→ADR map in progress.md). Use architecture.md's domain vocabulary throughout the PRD; respect the ADRs — don't re-decide what they settled.
Sketch the test seams. Name the seams the feature will be tested at. Prefer existing seams; use the highest seam possible. For this repo the natural high seam is the deterministic engine boundary — pure functions in dmbot/rules/ (dice = code, golden rule #2). Check with Tobi that the seams match his expectation before writing.
Write the PRD to docs/plans/<feature-slug>.md using the template below. Then point progress.md's ## Next concrete step at it. No issue tracker — the file is the artifact.

## Problem Statement — the problem, from the user's perspective (player / GM / Tobi-as-operator) ## Solution — the solution, from the user's perspective ## User Stories — a LONG numbered list, "As a , I want , so that "; cover all aspects ## Implementation Decisions — modules/interfaces/architecture/schema/data-shape/marker contracts. NO file paths or code snippets (they rot fast). Exception: a prototype-derived snippet that pins a decision more precisely than prose (state machine, schema, dataclass) — inline just the decision-rich bit, noting it came from a prototype. ## Testing Decisions — what makes a good test here (assert external behaviour, fixed-seed, exact bands — golden rule #2); which modules get tested; prior art (e.g. tests/test_psyker.py) ## Out of Scope ## Further Notes

Hand-offs

Build the result test-first with /tdd if it's deterministic-core work.
A real architectural trade-off uncovered while writing → /session-ritual scaffolds an ADR (the PRD is the plan; the ADR records the decision — different artifacts, both on disk).

More from this repository

same repository

improve-architecture

Pr0degie/dungeonmaster

Find deepening opportunities across the codebase — refactors that turn shallow pass-through modules into deep ones, for testability and AI-navigability. Informed by architecture.md and the ADRs in docs/decisions/; never re-litigates a decided ADR. Use when Tobi wants to improve architecture, find refactoring opportunities, consolidate tightly-coupled modules, or make a part of the bot more testable. Whole-codebase altitude — not /simplify or /code-review (those are diff-scoped).

2026-06-150

grill-me

Pr0degie/dungeonmaster

Interview Tobi relentlessly about a plan or design decision until reaching shared understanding, resolving each branch of the decision tree one fork at a time. Use when he wants to stress-test a plan before building, asks to "get grilled", or says "grill me". For design/architecture forks — not for mechanical edits.

2026-06-150

tdd

Pr0degie/dungeonmaster

Use when changing the deterministic core (dmbot/rules/, engine.py, marker.py, any new pure function with verifiable behaviour) and you want the change driven by a failing test first. Enforces red-green-refactor against the repo's fixed-seed pytest setup: write one failing test, confirm red, implement minimal green, refactor. Not for prose/persona/prompt edits or RAG ingestion.

2026-06-150

playtest-triage

Pr0degie/dungeonmaster

Use when the user pastes a live Discord session log, transcript, or annotated complaints from a play session and wants a fix round. Diagnoses the failure chain from the logs, extracts player improvement-wishes, applies deterministic fixes, runs the test suite, commits per round, and updates progress.md (and an ADR when a real trade-off was decided).

2026-06-140

session-ritual

Pr0degie/dungeonmaster

Use at the start of a working session for the handshake (read CLAUDE.md → progress.md → the latest ADR, then state where we are and what's next), and at the end of a session or on "wrap up" / "update progress" to update progress.md and scaffold the next-numbered ADR. Keeps continuity across context clears and model switches.

2026-06-140

character-build

Pr0degie/dungeonmaster

Use when a player's Imperium Maledictum character JSON comes in and needs validating + deploying, when building a new IM character from scratch, or when backfilling backstory onto an existing sheet. Validates budgets/formulas/psyker powers/augmetics against the active profile, writes data/party/<player>.json, generates the PDF sheet, and proposes (confirm first) the merge into the session characters.json + aliases.

2026-06-130

name	to-prd
description	Turn the current conversation context — ideally after a /grill-me session — into a PRD written to the repo. Do NOT interview; synthesize what's already been decided. Use when Tobi wants to turn a grilled-out plan into a written spec, or says "to-prd" / "schreib den Plan".

Synthesize the grilled context into a PRD

Process

Explore. Read the current state of the area in code, plus architecture.md and the ADRs in docs/decisions/ governing it (decision log + phase→ADR map in progress.md). Use architecture.md's domain vocabulary throughout the PRD; respect the ADRs — don't re-decide what they settled.
Sketch the test seams. Name the seams the feature will be tested at. Prefer existing seams; use the highest seam possible. For this repo the natural high seam is the deterministic engine boundary — pure functions in dmbot/rules/ (dice = code, golden rule #2). Check with Tobi that the seams match his expectation before writing.
Write the PRD to docs/plans/<feature-slug>.md using the template below. Then point progress.md's ## Next concrete step at it. No issue tracker — the file is the artifact.

Hand-offs

Build the result test-first with /tdd if it's deterministic-core work.
A real architectural trade-off uncovered while writing → /session-ritual scaffolds an ADR (the PRD is the plan; the ADR records the decision — different artifacts, both on disk).