mcpField
R
report-generation

report-generation

github.com/seb1nドキュメント233129 回インストール12 週間前に更新
リポジトリ

report-generation について

構造化データからデータに基づくレポートを作成する、AIエージェント向けスキルです。テンプレートの選択やカスタマイズ、指標計算、洞察の文章化に対応し、Markdown、HTML、PDFで出力します。

主な機能

  1. 01入力データの検証と正規化
  2. 02組み込み・カスタムレポートテンプレート
  3. 03指標計算と洞察の文章化
  4. 04表とチャート仕様の生成
  5. 05Markdown、HTML、PDFでの出力
  6. 06ソースデータに基づく品質チェック

活用シーン

  1. 01スプリント振り返りレポートの作成
  2. 02財務・分析サマリーの準備
  3. 03インシデント事後分析の記録
  4. 04定期的な週次ステータスレポートの作成

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/seb1n/awesome-ai-agent-skills --skill report-generation

インストール後、Claude Code で/report-generationを入力して読み込まれたか確認します。

詳細

レポート生成

このスキルを使用すると、AI エージェントは構造化された入力から、洗練されたデータ駆動型レポートを作成できます。エージェントは JSON、CSV、または API レスポンス形式のデータを受け取り、レポートテンプレートを適用し、表やグラフの仕様とともに文章による分析結果を生成して、最終レポートを Markdown、HTML、または PDF で出力します。スプリントの振り返り、財務サマリー、分析ダッシュボード、インシデントの事後分析など、一般的なレポート形式に対応しています。

ワークフロー

  1. ソースデータを取り込み、検証します。 JSON、CSV、YAML、または生の API レスポンス形式の入力データファイルやペイロードを受け付けます。スキーマを検証し、必須フィールド、データ型の正しさ、欠損値、外れ値を確認します。データが不完全な場合(例:スプリントの振り返り用 JSON にベロシティのフィールドがない場合)は、不足している項目を示し、デフォルト値を推定するか、不足している値を求めるか、レポート内に欠落を記載します。日付形式、通貨記号、単位を統一して、一貫性を保ちます。

  2. レポートテンプレートを選択またはカスタマイズします。 ユーザーが指定したレポートの種類に基づいて、データに適したレポートテンプレートを選びます。組み込みテンプレートには、sprint_retrospective、financial_summary、analytics_dashboard、incident_postmortem、weekly_status があります。各テンプレートでは、セクションの順序、必須のデータマッピング、グラフの種類、文体(財務レポートでは分析的、振り返りでは建設的、事後分析では緊急性の高い表現)が定義されています。ユーザーは、セクションの上書き、フィールドの追加、ビジュアルテーマの変更によってテンプレートをカスタマイズできます。

  3. 指標を計算し、分析結果を生成します。 生データから、変化率、平均、順位、傾向の方向、異常フラグなどの計算指標を導き出します。スプリントの振り返りでは、ベロシティの分散とコミットメントの達成精度を計算します。分析レポートでは、コンバージョン率とセグメントごとの内訳を算出します。次に、「コンバージョン率は 3.2%でした」と述べるだけでなく、「コンバージョン率は前期から 0.8 ポイント低下しました。主な要因は、モバイルトラフィックが 15%減少したことです」のような文章による分析結果を生成します。

  4. レポートの構成に内容を入力します。 計算指標、文章による分析結果、書式を整えたデータ表をテンプレートの各セクションに入力します。テンプレート内の各ビジュアライゼーション枠に対して、グラフの仕様(棒、折れ線、円、または表)を生成します。インラインの表には Markdown の表構文を使用し、ビジュアルグラフにはグラフ仕様の形式(例:Mermaid、Vega-Lite、または Chart.js JSON)を使用します。セクション見出し、エグゼクティブサマリー、付録があれば追加します。

  5. 出力を整形してレンダリングします。 要求された形式で最終レポートを作成します。Markdown の場合は、表とグラフのコードブロックを含む、整った .md ファイルを出力します。HTML の場合は、Markdown 出力を、印刷に適したレンダリング用 CSS を含むスタイル付きテンプレートで囲みます。PDF の場合は、ヘッドレスブラウザーまたは Puppeteer や WeasyPrint などのツールを使用して HTML 版を変換します。すべての形式でグラフが正しくレンダリングされ、PDF で表がページをまたいで分割されないことを確認します。

  6. 確認して仕上げます。 品質チェックを実施します。レポート内のすべてのデータポイントがソースデータに遡れること、テンプレート変数が未解決のまま残っていないこと(例:{{quarter}})、分析結果が数値によって裏付けられていること、レポートの長さがレポートの種類に応じた想定範囲に収まっていることを確認します。生成した内容を簡潔にまとめてレポートを納品します。

使用方法

レポートの種類、ソースデータ、カスタマイズの希望、希望する出力形式をエージェントに指定します。エージェントは、書式を整えた完全なレポートを返します。

プロンプト形式:

Generate a [report type] report.
Data source: [path to JSON/CSV file, or inline data]
Time period: [date range or sprint number]
Template: [built-in template name or "custom"]
Output format: [markdown / html / pdf]

例

例 1:構造化データからのスプリント振り返りレポート

入力データ(JSON):

{
  "sprint": {
    "number": 14,
    "start_date": "2026-01-27",
    "end_date": "2026-02-07",
    "goal": "Ship checkout flow redesign and analytics instrumentation"
  },
  "velocity": {
    "committed": 34,
    "completed": 29,
    "previous_sprints": [31, 28, 33, 30]
  },
  "stories": {
    "total": 12,
    "completed": 10,
    "carried_over": 2,
    "carried_over_items": [
      "CHECKOUT-142: Edge case handling for international addresses",
      "ANALYTICS-89: Cross-domain tracking for subdomain events"
    ]
  },
  "what_went_well": [
    "Checkout redesign shipped 2 days early",
    "Zero P1 bugs in production release",
    "Effective pairing sessions between frontend and backend teams"
  ],
  "what_could_improve": [
    "Sprint scope increased mid-sprint with 3 unplanned tickets",
    "QA bottleneck on Thursday caused idle time for 2 developers",
    "Standup meetings ran over 15 minutes on 3 of 10 days"
  ],
  "action_items": [
    { "owner": "Priya", "action": "Add a mid-sprint scope freeze policy" },
    { "owner": "James", "action": "Schedule a dedicated QA window on Wednesdays" },
    { "owner": "Dana", "action": "Timekeeper rotation for standups" }
  ]
}

出力(Markdown レポート):

# Sprint 14 Retrospective

**Sprint dates:** January 27 – February 7, 2026
**Sprint goal:** Ship checkout flow redesign and analytics instrumentation

---

## Executive Summary

Sprint 14 delivered 85% of committed story points (29 of 34), slightly below
the team's rolling average velocity of 30.5. The primary sprint goal was
partially met: the checkout redesign shipped ahead of schedule, but two
analytics stories carried over due to mid-sprint scope changes and a QA
bottleneck. Zero P1 bugs were introduced, reflecting strong code quality.

## Velocity

| Metric               | Sprint 14 | 4-Sprint Average |
|----------------------|-----------|------------------|
| Committed            | 34 pts    | 31.0 pts         |
| Completed            | 29 pts    | 30.5 pts         |
| Commitment accuracy  | 85%       | 98%              |

The team over-committed by 3 points relative to the historical average.
The shortfall is attributable to 3 unplanned tickets added mid-sprint,
which consumed approximately 5 story points of capacity.

## Story Completion

- **Completed:** 10 of 12 stories (83%)
- **Carried over:** 2 stories
  - CHECKOUT-142: Edge case handling for international addresses
  - ANALYTICS-89: Cross-domain tracking for subdomain events

Both carried-over stories are estimated at 2-3 points each and will be
prioritized at the top of Sprint 15.

## What Went Well

- Checkout redesign shipped 2 days ahead of the sprint end date, allowing
  extra time for integration testing.
- Zero P1 bugs in the production release — the team's pairing sessions
  caught issues early in development.
- Cross-functional pairing sessions were cited by 3 team members as the
  highlight of the sprint.

## What Could Improve

- **Mid-sprint scope creep:** 3 unplanned tickets were added after sprint
  planning, consuming capacity and contributing to the 2 carried-over stories.
- **QA bottleneck:** All completed stories landed in QA on Thursday, creating
  a pileup that left 2 developers idle on Friday morning.
- **Standup duration:** Standups exceeded 15 minutes on 3 of 10 days.

## Action Items

| Owner | Action                                           | Target Date |
|-------|--------------------------------------------------|-------------|
| Priya | Add a mid-sprint scope freeze policy             | Feb 10      |
| James | Schedule a dedicated QA window on Wednesdays     | Feb 10      |
| Dana  | Implement timekeeper rotation for standups       | Feb 10      |

---

*Report generated from sprint data. Source: sprint-14-retro.json*
例 2:分析結果と推奨事項を含む分析レポート

入力:

Generate an analytics report for the marketing website.
Data source: /data/website-analytics-jan-2026.json
Time period: January 2026
Output format: markdown

出力:

# Website Analytics Report — January 2026

**Reporting period:** January 1–31, 2026
**Compared to:** December 2025

---

## Executive Summary

Website traffic increased 12% month-over-month to 284,000 sessions, driven
primarily by organic search growth (+18%). However, overall conversion rate
declined from 4.0% to 3.2%, with the sharpest drop on mobile devices. The
pricing page continues to be the highest-converting entry point, while the
blog showed strong traffic growth but low conversion intent.

## Traffic Overview

| Metric             | January 2026 | December 2025 | Change  |
|--------------------|-------------|---------------|---------|
| Total sessions     | 284,000     | 253,500       | +12.0%  |
| Unique visitors    | 198,600     | 179,400       | +10.7%  |
| Pages per session  | 3.2         | 3.4           | -5.9%   |
| Avg session dur.   | 2m 48s      | 3m 05s        | -9.2%   |
| Bounce rate        | 42%         | 38%           | +4pp    |

## Traffic by Channel

| Channel        | Sessions | Share | MoM Change |
|----------------|----------|-------|------------|
| Organic Search | 142,000  | 50%   | +18.3%     |
| Direct         | 62,500   | 22%   | +5.1%      |
| Paid Search    | 39,800   | 14%   | +8.7%      |
| Social         | 25,600   | 9%    | +2.3%      |
| Referral       | 14,100   | 5%    | -3.8%      |

**Insight:** Organic search growth (+18.3%) was the primary traffic driver,
likely attributable to the 6 new blog posts published in January. However,
the drop in pages-per-session and increased bounce rate suggest this new
organic traffic has lower engagement intent than existing visitors.

## Conversion Funnel

| Stage                  | Visitors | Rate   | MoM Change |
|------------------------|----------|--------|------------|
| Homepage to Pricing    | 84,200   | 29.6%  | -1.2pp     |
| Pricing to Signup      | 15,400   | 18.3%  | -2.1pp     |
| Signup to Activation   | 9,100    | 59.1%  | +0.8pp     |
| **Overall conversion** | **9,100**| **3.2%** | **-0.8pp** |

**Insight:** The conversion drop is concentrated in the Pricing to Signup
step (-2.1pp). A/B test data shows the new pricing page variant (launched
Jan 15) underperforms the control by 1.8pp. Recommendation: revert to the
control pricing page and redesign the variant.

## Recommendations

1. **Revert the pricing page A/B test.** The new variant is underperforming
   by 1.8pp on the key Pricing to Signup conversion step.
2. **Add conversion-intent CTAs to blog posts.** The 18% organic traffic
   growth is not converting. Embed contextual product CTAs within blog
   content to capture high-intent readers.
3. **Investigate mobile conversion drop.** Mobile sessions grew 15% but
   mobile conversion fell 1.2pp. Audit the mobile signup flow for UX
   friction, particularly form field usability and page load speed.
4. **Double down on organic content.** The SEO investment is paying off
   in traffic. Publish 8 posts in February targeting mid-funnel keywords
   with stronger commercial intent.

---

*Report generated from website-analytics-jan-2026.json. Data: Google Analytics.*

ベストプラクティス

  • エグゼクティブサマリーを最初に示します。 意思決定者は最初の段落を読み、残りはざっと目を通します。最も重要な調査結果と提言は、レポートの途中に埋もれさせず、冒頭に記載します。
  • 数値だけでなく比較も示します。 生の指標だけでは背景がわかりません。数値が良いのか悪いのか読者が判断できるよう、必ず比較基準(前期、目標、業界ベンチマーク、過去の平均など)を含めます。
  • データを並べるだけでなく、分析に基づく示唆を示します。 数値の表だけでは、読者が自分で分析しなければなりません。すべてのデータ表に、そのデータが何を意味し、なぜ重要なのかを説明する一文を添えます。
  • 全体を通じて書式を統一します。 表の列を揃え、日付の書式を統一し、見出しの階層を一貫させます。書式が統一されていないと、データへの信頼が損なわれます。
  • レポートをざっと読める構成にします。 セクション見出し、箇条書き、重要な数値の太字、十分な余白を活用します。レポートの文章が壁のように続く状態は、メールに長文が続くのと同じくらい効果的ではありません。
  • データソースを明記します。 データの出所、取得日時、適用したフィルターや除外条件を記載するフッターまたは付録を含めます。これにより、レポートの監査と再現が可能になります。

エッジケース

  • データ項目が不完全または欠落している場合。 ソースデータに想定された項目がない場合は、セクションを黙って省略したり、数値を捏造したりせず、その不足をレポートに明記します(例:「ベロシティデータを利用できないため、コミットメントの精度は算出していません」)。
  • 外れ値や異常値を含むデータ。 通常と異なるデータポイント(例:ボット攻撃によるトラフィックの10倍増)に印を付け、集計計算に含めたか除外したかを記載します。
  • 複数のデータソースが食い違う場合。 2つのソースで数値が一致しない場合(例:CRMでは成約件数が120件、財務部門では118件)、不一致を記載し、どちらのソースを使用したかを明示したうえで、照合作業を提案します。
  • データセットが非常に大きい場合。 数千行あるデータファイルは、すべての行を列挙するのではなく、適切な粒度(日別、週別、セグメント別など)で要約します。依頼に応じて詳細な付録を作成できることも案内します。
  • 機密性の高い財務データや人事データ。 作成したレポートにアクセス制御を適用します。チーム単位のレポートでは、個人別の報酬額を伏せます。PIIまたは財務データを含むレポートには、配布制限があることを明記します。

コメント