スキル一覧に戻る

generate-status-report

pjt222
更新日 2 days ago
7 閲覧
17
2
17
GitHubで表示
メタdata

について

このスキルは、既存のチャーター、バックログ、スプリント計画などの成果物を分析し、メトリクスの算出、ブロッカーの特定、RAG指標を用いた進捗状況の要約を行うことで、プロジェクトステータスレポートを生成します。スプリント終了時、ガバナンス会議前、または新たなリスクが発生した際の使用を想定しています。主な機能には、スケジュール、範囲、予算、品質に関するメトリクスの自動算出とRAGステータス評価が含まれます。

クイックインストール

Claude Code

推奨
メイン
npx skills add pjt222/agent-almanac -a claude-code
プラグインコマンド代替
/plugin add https://github.com/pjt222/agent-almanac
Git クローン代替
git clone https://github.com/pjt222/agent-almanac.git ~/.claude/skills/generate-status-report

このコマンドをClaude Codeにコピー&ペーストしてスキルをインストールします

ドキュメント


name: generate-status-report description: > Einen Projektstatusbericht erstellen durch Lesen vorhandener Artefakte (Charter, Backlog, Sprint-Plan, PSP), Berechnen von Kennzahlen, Identifizieren von Blockaden und Zusammenfassen des Fortschritts mit RAG-Indikatoren fuer Zeitplan, Umfang, Budget und Qualitaet. Verwenden am Ende eines Sprints oder Berichtszeitraums, wenn Stakeholder ein Gesundheitsupdate anfragen, vor Steuerungsausschuss- oder Governance-Sitzungen oder wenn eine neue Blockade oder ein Risiko mitten im Projekt auftaucht. license: MIT allowed-tools: Read Write Edit Bash Grep Glob metadata: author: Philipp Thoss version: "1.0" domain: project-management complexity: intermediate language: multi tags: project-management, status-report, metrics, rag, progress, blockers locale: de source_locale: en source_commit: 6f65f316 translator: claude-opus-4-6 translation_date: "2026-03-16"

Projektstatusbericht erstellen

Einen periodischen Statusbericht erstellen, indem Projektartefakte analysiert, Fortschrittskennzahlen berechnet und Leistungen, Blockaden und bevorstehende Arbeit mit RAG-Gesundheitsindikatoren (Rot/Gelb/Gruen) zusammengefasst werden.

Wann verwenden

  • Ende eines Sprints oder Berichtszeitraums (woechentlich, zweiwochentlich, monatlich)
  • Stakeholder-Anfragen nach einem Projektgesundheitsupdate
  • Vor Steuerungsausschuss- oder Governance-Sitzungen
  • Wenn sich Projektgesundheitsindikatoren aendern (z.B. neue Blockade oder Risiko taucht auf)
  • Periodischer Checkpoint gegen Charter-Meilensteine

Eingaben

  • Erforderlich: Berichtszeitraum (Startdatum, Enddatum)
  • Erforderlich: Mindestens ein Projektartefakt (BACKLOG.md, SPRINT-PLAN.md, WBS.md oder PROJECT-CHARTER.md)
  • Optional: Vorherige Statusberichte (fuer Trendvergleich)
  • Optional: Budget- oder Ressourcentracking-Daten
  • Optional: Risikoregister-Aktualisierungen

Vorgehensweise

Schritt 1: Vorhandene Artefakte lesen

Das Projektverzeichnis nach PM-Artefakten durchsuchen:

  • PROJECT-CHARTER.md — Meilensteine, Erfolgskriterien
  • BACKLOG.md — Eintragsanzahlen nach Status, Burn-down-Daten
  • SPRINT-PLAN.md — Sprint-Ziel, zugesagte Eintraege, Aufgabenabschluss
  • WBS.md — Abschlussprozentzahlen von Arbeitspaketen
  • Vorherige STATUS-REPORT-*.md-Dateien — Trenddaten

Verfuegbare Dateien lesen. Nicht alle werden vorhanden sein — den Bericht an verfuegbare Daten anpassen.

Erwartet: Mindestens ein Artefakt erfolgreich gelesen, Schluesseldaten extrahiert.

Bei Fehler: Wenn keine Artefakte vorhanden sind, kann kein Bericht erstellt werden. Zuerst eine Charter oder einen Backlog mit den Skills draft-project-charter oder manage-backlog erstellen.

Schritt 2: Fortschrittskennzahlen berechnen

Kennzahlen aus verfuegbaren Daten berechnen:

Agile Kennzahlen (aus BACKLOG.md / SPRINT-PLAN.md):

  • Velocity: in diesem Sprint abgeschlossene Story Points
  • Sprint-Abschluss: erledigte Eintraege / zugesagte Eintraege
  • Backlog-Burn-down: verbleibende Gesamtpunkte vs. vorherigem Zeitraum
  • Durchlaufzeit: durchschnittliche Tage von In Progress bis Done

Klassische Kennzahlen (aus WBS.md):

  • % abgeschlossen: erledigte Arbeitspakete / Gesamtarbeitspakete
  • Zeitplanabweichung: geplante Meilensteindaten vs. tatsaechliche
  • Aufwandsabweichung: geschaetzter Aufwand vs. tatsaechlich verbrauchter Aufwand
## Metrics
| Metric | Value | Previous | Trend |
|--------|-------|----------|-------|
| Velocity | [N] pts | [N] pts | ↑/↓/→ |
| Sprint Completion | [N]% | [N]% | ↑/↓/→ |
| Backlog Remaining | [N] pts | [N] pts | ↓ (good) |
| Schedule Variance | [+/-N days] | [+/-N days] | |

Erwartet: 3-5 Kennzahlen berechnet mit Vergleich zum Vorjahreszeitraum.

Bei Fehler: Wenn keine historischen Daten vorhanden sind (erster Bericht), die Spalten "Previous" und "Trend" weglassen. Wenn Daten unvollstaendig sind, Luecken in der Berichtsfussnote mit Massnahmen zur Etablierung des Trackings vermerken.

Schritt 3: Blockaden, Risiken und Probleme identifizieren

Aktive Blockaden und Risiken auflisten:

## Blockers & Risks
| ID | Type | Description | Severity | Owner | Status | Action Required |
|----|------|------------|----------|-------|--------|----------------|
| R-001 | Risk | [Description] | High | [Name] | Open | [Action] |
| B-001 | Blocker | [Description] | Critical | [Name] | Active | [Action by date] |
| I-001 | Issue | [Description] | Medium | [Name] | Investigating | [Action] |

Mit dem Charter-Risikoregister abgleichen. Alle neu identifizierten Risiken markieren.

Erwartet: Alle aktiven Blockaden und Top-Risiken mit Verantwortlichen und Massnahmen dokumentiert.

Bei Fehler: Wenn keine Blockaden vorhanden sind, explizit "Keine aktiven Blockaden" angeben — den Abschnitt nicht leer lassen. Wenn einer Blockade ein Verantwortlicher fehlt, an den Projektmanager zur Zuweisung eskalieren.

Schritt 4: Leistungen und Plan fuer naechsten Zeitraum zusammenfassen

Zwei Abschnitte schreiben:

## Accomplishments (This Period)
- [Completed item/milestone with evidence]
- [Completed item/milestone with evidence]
- [Completed item/milestone with evidence]

## Planned (Next Period)
- [Planned item/milestone with target]
- [Planned item/milestone with target]
- [Planned item/milestone with target]

Erwartet: 3-5 Leistungen mit konkreten Belegen, 3-5 geplante Eintraege fuer den naechsten Zeitraum.

Bei Fehler: Wenn keine Leistungen vorhanden sind, den Grund berichten (blockiert, Neuplanung, Team nicht verfuegbar). Wenn der Plan fuer den naechsten Zeitraum unklar ist, "Planungssitzung geplant fuer [Datum]" als Haupteintrag auffuehren.

Schritt 5: RAG-Indikatoren zuweisen und Bericht schreiben

Projektgesundheit in vier Dimensionen bewerten:

DimensionGruenGelbRot
ZeitplanIm Plan oder voraus1-2 Wochen zurueck>2 Wochen zurueck oder Meilenstein verpasst
UmfangKeine unkontrollierten AenderungenGeringfuegige UmfangsanpassungenScope Creep beeintraechtigt Lieferergebnisse
BudgetInnerhalb 5% des Plans5-15% ueber Plan>15% ueber Plan oder nicht nachverfolgt
QualitaetTests bestehen, Kriterien erfuelltGeringfuegige QualitaetsproblemeKritische Maengel oder Abnahmefehler

Den vollstaendigen Bericht schreiben:

# Status Report: [Project Name]
## Report Date: [YYYY-MM-DD]
## Reporting Period: [Start] to [End]
## Document ID: SR-[PROJECT]-[YYYY-MM-DD]

### Overall Health
| Dimension | Status | Notes |
|-----------|--------|-------|
| Schedule | 🟢/🟡/🔴 | [One-line explanation] |
| Scope | 🟢/🟡/🔴 | [One-line explanation] |
| Budget | 🟢/🟡/🔴 | [One-line explanation] |
| Quality | 🟢/🟡/🔴 | [One-line explanation] |

### Executive Summary
[2-3 sentences: overall status, key achievement, biggest risk]

### Metrics
[From Step 2]

### Accomplishments
[From Step 4]

### Blockers & Risks
[From Step 3]

### Planned Next Period
[From Step 4]

### Decisions Needed
- [Decision 1 — needed by date, from whom]

---
*Report prepared by: [Name/Agent]*

Als STATUS-REPORT-[YYYY-MM-DD].md speichern.

Erwartet: Vollstaendiger Statusbericht gespeichert mit RAG-Indikatoren, Kennzahlen und Narrativ.

Bei Fehler: Wenn Daten fuer die RAG-Bewertung ungenuegend sind, ⚪ (Grau) verwenden mit dem Hinweis "ungenuegend Daten" und auflisten, welche Daten fuer den naechsten Bericht gesammelt werden muessen.

Validierung

  • Statusberichtsdatei mit korrektem datumsgestempeltem Dateinamen erstellt
  • RAG-Indikatoren fuer alle vier Dimensionen mit Begruendung zugewiesen
  • Mindestens 3 Kennzahlen aus Projektartefakten berechnet
  • Blockaden-Abschnitt vorhanden (auch wenn "Keine aktiven Blockaden")
  • Leistungen mit Belegen aufgelistet
  • Plan fuer naechsten Zeitraum enthalten
  • Executive Summary ist 2-3 Saetze, kein Absatz
  • Jede Blockade und jedes Risiko hat einen Verantwortlichen und eine Massnahme mit Frist

Haeufige Stolperfallen

  • Bericht ohne Daten: Statusberichte muessen evidenzbasiert sein. Jede Aussage sollte ein Artefakt oder eine Kennzahl referenzieren.
  • Alles immer Gruen: Dauerhaftes Gruen ohne Belege deutet darauf hin, dass der Bericht nicht ehrlich ist. Gruen-Bewertungen hinterfragen.
  • Blockade ohne Verantwortlichen: Jede Blockade braucht einen Verantwortlichen und eine Massnahme. Unbesitzte Blockaden werden nicht geloest.
  • Kennzahl ohne Kontext: "Velocity = 18" bedeutet nichts ohne Vergleich. Immer den Vorjahreszeitraum oder das Ziel einbeziehen.
  • Zu lang: Ein Statusbericht sollte in 2 Minuten ueberschaubar sein. Auf 1-2 Seiten beschraenken.
  • Fehlender Entscheidungsabschnitt: Wenn das Projekt Stakeholder-Entscheidungen benoetigt, diese mit Fristen explizit machen.
  • Veraltete Daten: Veraltete Artefakte fuehren zu irrefuehrenden Berichten. Artefaktdaten auf den Berichtszeitraum abgleichen.
  • Fehlende Trenddaten: Erstberichte koennen keine Trends zeigen, aber nachfolgende Berichte muessen mit vorherigen Zeitraeumen vergleichen.

Verwandte Skills

  • draft-project-charter — Charter liefert Meilensteine und Erfolgskriterien fuer das Status-Tracking
  • manage-backlog — Backlog-Kennzahlen speisen den Statusbericht
  • plan-sprint — Sprint-Ergebnisse liefern Velocity- und Abschlussdaten
  • create-work-breakdown-structure — PSP-Abschluss treibt klassische Fortschrittskennzahlen
  • conduct-retrospective — Statusberichtsdaten speisen die Retrospektive

GitHub リポジトリ

pjt222/agent-almanac
パス: i18n/de/skills/generate-status-report
0
agentsagentskillsai-assisted-developmentclaude-codeskillsteams

関連スキル

content-collections

メタ

このスキルは、Content Collections(Markdown/MDXファイルを型安全なデータコレクションに変換するTypeScriptファーストのツール)の本番環境でテストされた設定を提供します。Zodバリデーションによる型安全性を実現し、ブログ、ドキュメントサイト、コンテンツ重視のVite + Reactアプリケーション構築時にご利用ください。Viteプラグインの設定、MDXコンパイルから、デプロイ最適化、スキーマバリデーションまで、すべてを網羅しています。

スキルを見る

polymarket

メタ

このスキルは、開発者がPolymarket予測市場プラットフォームを活用したアプリケーション構築を可能にします。API統合による取引や市場データの取得に加え、WebSocketを介したリアルタイムデータストリーミングにより、ライブ取引や市場活動を監視できます。取引戦略の実装や、ライブ市場更新を処理するツールの作成にご利用ください。

スキルを見る

creating-opencode-plugins

メタ

このスキルは、開発者がコマンド、ファイル、LSP操作など25種類以上のイベントタイプにフックするOpenCodeプラグインを作成することを支援します。JavaScript/TypeScriptモジュール向けに、プラグイン構造、イベントAPI仕様、および実装パターンを提供します。カスタムイベント駆動ロジックでOpenCode AIアシスタントのライフサイクルをインターセプト、監視、または拡張する必要がある場合にご利用ください。

スキルを見る

sglang

メタ

SGLangは、高性能なLLMサービングフレームワークであり、RadixAttentionプレフィックスキャッシュを活用したJSON、正規表現、エージェントワークフロー向けの高速で構造化された生成を特長とします。特にプレフィックスが繰り返されるタスクにおいて、大幅に高速な推論を実現し、複雑な構造化出力やマルチターン対話に最適です。制約付きデコードが必要な場合や、広範なプレフィックス共有を伴うアプリケーションを構築する場合は、vLLMなどの代替案ではなくSGLangを選択してください。

スキルを見る