Run any Skill in Manus with one click

session-ritual

Stars0

Forks0

UpdatedJune 14, 2026 at 12:40

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.

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	session-ritual
description	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.

Session ritual — start handshake, end wrap-up, ADR scaffold

State lives on disk so the project survives context clears and model switches. This skill is the one canonical procedure; it formalizes the prose in CLAUDE.md.

Start handshake

Read in order: CLAUDE.md (conventions) → progress.md (where we are, what's next) → the highest-numbered file in docs/decisions/ (most recent decision).
State in 2–3 sentences: where we are, what we're about to do. Don't touch files until this handshake is done.
At a phase transition only: also read the ADR(s) that govern the new phase — the decision log + phase → ADR map in progress.md say which apply (this is how the older ADRs 001–005 get used). And remind the user of the recommended /model + /effort for the phase from roadmap.md (the running instance can't switch its own dial).

Read on demand, not every session: architecture.md (only when the task touches design), roadmap.md (phase transitions / "goal of Phase X?"), SETUP.md (Phase 0 / install steps), older ADRs (when working in their area), docs/conventions.md (per-module how-tos + testing/runtime/troubleshooting/style detail), docs/progress-archive.md (history only — old session logs, completed-phase evidence, resolved questions). Eager-loading everything burns the context window before useful work starts.

End-of-session wrap-up (trigger: "wrap up" / "update progress", or unprompted at session end)

Update progress.md:

## Current focus — only if the phase changed
## Last session — what we actually did
## Next concrete step — the specific next action, not a vague goal
## Open questions — anything that surfaced but isn't actionable yet
the affected phase's VERIFY EVIDENCE field — when a gate was met

Keep it lean (rotation): the live progress.md holds only the current state. When you prepend a new ## Last session entry, move the previous one to docs/progress-archive.md (## Last session (Verlauf)) — keep only the newest 1–2 live. Rotate ✅-resolved ## Open questions and just-completed phases (full VERIFY EVIDENCE → one-line summary live) there too. The ## Decision log and ### Phase → ADR map stay fully live (stable D## refs).

Silence here is the failure mode that breaks continuity. Do it even if not asked.

new-adr — scaffold the next decision record

Only when a decision weighed a real trade-off with alternatives seriously on the table (trivia stays in the progress.md decision log). Next sequential number, never reused: docs/decisions/NNN-short-title.md.

# ADR NNN — Title

- **Status:** Proposed | Accepted | Superseded by ADR NNN
- **Date:** YYYY-MM-DD
- **Refs:** decision log DX in progress.md, optionally architecture.md §Y

## Context
What problem was at hand? What constraints (hardware, style, effort)?

## Decision
What was chosen — in one sentence.

## Alternatives
What else was on the table and why not.

## Consequences
What follows — positive and negative. What does this bind for later work?

If a decision changes a prior one, set the old ADR's status to Superseded by ADR NNN and keep it. If the decision changes a design choice, update architecture.md in the same change.

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

to-prd

Pr0degie/dungeonmaster

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".

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

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	session-ritual
description	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.

Session ritual — start handshake, end wrap-up, ADR scaffold

State lives on disk so the project survives context clears and model switches. This skill is the one canonical procedure; it formalizes the prose in CLAUDE.md.

Start handshake

Read in order: CLAUDE.md (conventions) → progress.md (where we are, what's next) → the highest-numbered file in docs/decisions/ (most recent decision).
State in 2–3 sentences: where we are, what we're about to do. Don't touch files until this handshake is done.
At a phase transition only: also read the ADR(s) that govern the new phase — the decision log + phase → ADR map in progress.md say which apply (this is how the older ADRs 001–005 get used). And remind the user of the recommended /model + /effort for the phase from roadmap.md (the running instance can't switch its own dial).

End-of-session wrap-up (trigger: "wrap up" / "update progress", or unprompted at session end)

Update progress.md:

## Current focus — only if the phase changed
## Last session — what we actually did
## Next concrete step — the specific next action, not a vague goal
## Open questions — anything that surfaced but isn't actionable yet
the affected phase's VERIFY EVIDENCE field — when a gate was met

Silence here is the failure mode that breaks continuity. Do it even if not asked.

new-adr — scaffold the next decision record

# ADR NNN — Title

- **Status:** Proposed | Accepted | Superseded by ADR NNN
- **Date:** YYYY-MM-DD
- **Refs:** decision log DX in progress.md, optionally architecture.md §Y

## Context
What problem was at hand? What constraints (hardware, style, effort)?

## Decision
What was chosen — in one sentence.

## Alternatives
What else was on the table and why not.

## Consequences
What follows — positive and negative. What does this bind for later work?

If a decision changes a prior one, set the old ADR's status to Superseded by ADR NNN and keep it. If the decision changes a design choice, update architecture.md in the same change.