Menü
Synthesise a status, standup, or situation-report from current work state. Trigger when a team member needs a concise summary of where things stand, what is blocked, and what is next.
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.
Basierend auf der SOC-Berufsklassifikation
| name | sitrep |
| description | Synthesise a status, standup, or situation-report from current work state. Trigger when a team member needs a concise summary of where things stand, what is blocked, and what is next. |
Situation reports are for the person who was not in the room. Write for them.
A sitrep is not a diary of activity. It is a compressed, actionable picture of current state. Three questions: what is done, what is blocked, what is next. Anything that does not answer one of those three questions does not belong in the sitrep.
Gather the current work state — read from available sources:
docs/operating-model/PROJECT-OPERATING-PROFILE.md, docs/ROADMAP.md, or equivalent per project structure)Classify items into three buckets:
Write the sitrep — structure:
## Sitrep — <date> [<scope: sprint / incident / handoff>]
**Done**
- <item> — <one sentence on what was delivered and its evidence>
**Blocked**
- <item> — blocked on <specific dependency / owner / ETA if known>
**Next**
- <item> — <priority order, most important first>
**Risks / flags** (optional — only if material)
- <risk> — <impact if unresolved> — <owner>
Apply the compression test — for each line: if removing it changes nothing that the reader needs to act on, remove it.
Name blockers precisely — "blocked on backend" is not a blocker entry. "Blocked on API contract for /v2/orders — waiting on @owner, ETA unknown" is.
Do not editorialise progress — "made good progress" is noise. "Delivered X, which unblocks Y" is signal.
Bootstrap or harden a project's operating model for mixed human and AI delivery teams. Use when starting a repository, adopting an agent harness, defining authority and risk tiers, coordinating parallel agents safely, binding evidence and review to an exact candidate, or correcting fragmented rules that prevent coherent, consistent, complete delivery.
Architecture decisions, trade-off analysis, and ADR authoring. Trigger when a significant technical decision needs to be made, documented, and owned — not when an implementation detail needs a choice.
Decompose an epic into atomic parallelizable tasks and route each task to the right skill. Use this as a meta-router when you have more than one skill available and need to decide which applies. Trigger at the start of any multi-track epic or when the skill count in your harness exceeds ~12.
Check proposed stack, data flows, cloud choices, and delivery controls against declared enterprise policies, compliance frameworks, and security controls. Trigger at R2/R3 risk classification, before locking architecture decisions, or when the operating profile names a governance pointer.
Govern the SemVer release process — versioning discipline, tag-based GitHub releases, changelog hygiene, and the ADR that confirms the release strategy is agreed. Trigger when setting up a release process, before a first public release, or when release practice has become inconsistent. Owned by delivery-orchestrator.
Session-start orientation for this team harness. Load first, before any work. Explains the operating contract, when each skill triggers, and how installed companion plugins supply agent-craft capabilities while this harness supplies the team contract. Trigger at the start of every session and whenever unsure which skill applies.