スキル一覧に戻る
sunbluesome

weekly-report

by sunbluesome

0🍴 0📅 2026年1月13日
GitHubで見るManusで実行

SKILL.md


name: weekly-report description: | This skill should be used when the user asks to "週報", "weekly report", "作業レポート", "進捗報告", "週次報告", "レポート作成", "発信用レポート", "全体発信".

MUST USE this skill for:

  • Creating weekly work reports for team-wide communication
  • Summarizing development progress for non-technical audiences
  • Generating IMRaD format documentation with executive summary
  • Any work in _docs/weekly-report/ directory

Weekly Report Skill

指定期間の作業レポートを作成する。全体発信用の箇条書き + IMRaD形式のドキュメント。

概要

このスキルは以下を生成する:

  1. 発信用サマリー: DS以外の部署向け、専門用語を避けた箇条書き
  2. IMRaD形式レポート: 詳細な技術レポート

実行フロー

Step 1: 情報収集

対象期間のコミット履歴、ドキュメント、実験記録を収集:

# コミット履歴
git log --since="{start_date}" --until="{end_date}" --oneline

# 変更ファイル
git diff --stat {start_commit}..{end_commit}

確認すべきディレクトリ:

  • _docs/experiments/ - 実験記録
  • _docs/processing-flow/ - 処理フロードキュメント
  • _docs/charter/ - プロジェクト憲章
  • src/ - 実装コード

Step 2: ユーザーへの確認

AskUserQuestion:
  question: "レポート対象期間を教えてください"
  header: "期間"
  options:
    - label: "今週"
      description: "今週の月曜日から今日まで"
    - label: "先週"
      description: "先週の月曜日から日曜日まで"
    - label: "カスタム"
      description: "開始日・終了日を指定"

Step 3: レポート生成

ドキュメント構造

_docs/weekly-report/{YYYYMMDD}.md:

# 週報: {プロジェクト名}

**期間**: YYYY/MM/DD - YYYY/MM/DD
**作成日**: YYYY-MM-DD

---

## 発信用サマリー

====={カテゴリ}=====
{プロジェクト名}: {一行サマリー}
- {成果・発見1}
- {成果・発見2}
- {課題・次のステップ}

---

## 1. Introduction(背景・目的)

### 1.1 プロジェクト概要
{プロジェクト憲章のWhyを簡潔に}

### 1.2 今週の目標
{今週取り組んだ目標}

---

## 2. Methods(アプローチ)

### 2.1 実施内容
{具体的に何をしたか}

### 2.2 技術的アプローチ
{採用した手法・技術}

---

## 3. Results(結果)

### 3.1 完了した作業
- {作業1}
- {作業2}

### 3.2 定量的成果
| 指標 | 値 | 備考 |
|------|-----|------|
| {指標} | {値} | {備考} |

### 3.3 発見・知見
- {発見1}
- {発見2}

---

## 4. Discussion(考察・次のステップ)

### 4.1 成果の解釈
{結果の意味、当初目標との比較}

### 4.2 残課題
- {課題1}
- {課題2}

### 4.3 来週の予定
- {予定1}
- {予定2}

---

## Appendix

### コミット履歴
{期間中のコミット一覧}

### 参照ドキュメント
- {リンク}

発信用サマリーの書き方【重要】

原則

  1. 専門用語を避ける: DS以外の部署が理解できる表現を使う
  2. 自然な日本語で書く: 「〜した。」「〜である。」の文体で書く
  3. 1行は短く: 長くなる場合は改行して複数行に分ける
  4. 事実を正確に: 安易な考察・解釈を入れない(ミスリードを避ける)
  5. 数値の説明に注意: 「誤差」「精度」など、解釈が分かれる表現は避けるか補足する

文体ルール

  • 「〜した。」「〜である。」「〜する予定。」で終わる
  • 「〜しました。」「〜です。」は使わない
  • 箇条書きの1行が長くなる場合は改行して分ける

良い例:

- 精度計算モデルの実装が完了した
- タビオ99店舗のデータで動作検証を行った
- 売れ筋商品はデータが豊富なため精度良く予測できていることを確認した

悪い例:

- 精度計算モデルの実装が完了しました
- タビオ99店舗のデータで動作検証を行い、売れ筋商品はデータが豊富なため精度良く予測できていることを確認した(1行が長すぎる)

専門用語の言い換え例

専門用語言い換え
WMAPE予測と実績のずれ率
Bias予測の偏り(過大/過小)
パイプライン処理の流れ
モデル計算モデル / 予測モデル
DTOデータの型定義
リファクタリングコードの整理・改善
テストカバレッジテストの網羅率
CI/CD自動テスト・デプロイ
Docker/ECR実行環境のパッケージ
SageMakerAWS上の計算サービス
自動テスト「テストコード」と表現(「自動」は省略可)

数値・精度に関する注意

  • 「誤差」という表現は「単純な引き算」と誤解されやすい
  • 「精度が高い/低い」は「どう計測したか」の説明が必要
  • 数値を出す場合は、何を意味するかを補足する

良い例:

- 売れ筋商品はデータが豊富なため精度良く予測できていることを確認した

悪い例:

- 売れ筋商品は予測誤差27-36%と高精度(「誤差」の定義が不明瞭)
- 全体は86-104%で改善余地あり(安易な考察、ミスリード)

成果の表現パターン

問題発見 → 解決:

- {問題}を発見した({原因の簡潔な説明})
- {解決策}で問題を回避した

検証結果:

- {データ}を使って{検証内容}を行った
- {発見した事実}を確認した

次のステップ:

- 現在{状態}である
- 次は{アクション1}を行い、その後{アクション2}を行う予定

ファイル配置

_docs/weekly-report/{YYYYMMDD}.md

日付は期間終了日を使用。

注意事項

  • プロジェクト憲章を参照: Why/What/Howを踏まえてレポートを書く
  • 実験記録を活用: 定量的な結果は実験記録から引用
  • コミットメッセージを活用: 作業内容の洗い出しに使用
  • 来週の予定を明確に: 次のアクションが見えるように

詳細ガイド

スコア

総合スコア

40/100

リポジトリの品質指標に基づく評価

SKILL.md

SKILL.mdファイルが含まれている

+20
LICENSE

ライセンスが設定されている

0/10
説明文

100文字以上の説明がある

0/10
人気

GitHub Stars 100以上

0/15
最近の活動

3ヶ月以内に更新がある

0/10
フォーク

10回以上フォークされている

0/5
Issue管理

オープンIssueが50未満

+5
言語

プログラミング言語が設定されている

+5
タグ

1つ以上のタグが設定されている

0/5

レビュー

💬

レビュー機能は近日公開予定です