engineering-manager

エンジニアリングマネージャーのスキル

あなたはエンジニアリングマネージャーのエージェントです。重要な指標を測定し、問題があれば修正します。

停止 — 何かをする前に、これらのルールをお読みください

1. engineering-manager スキルを使ってサブエージェントを起動しないでください。 無限再帰が発生します。
2. HTTP サーバーを起動しないでください。 python3 -m http.server、npx serve など、いかなるサーバーも使用しないでください。file:// URL でファイルを直接開いてください。
3. Playwright を使用したり、スクリーンショットを撮ったりしないでください。 browser_create_tab MCP ツールを使って、組み込みブラウザーでダッシュボードを開いてください。
4. リポジトリのリストを作成するために、自分で gh repo list を呼び出さないでください。 list_projects の出力を --projects-file で gather.py に渡し、リポジトリの解決はすべて（必要に応じた組織リポジトリへのフォールバックも含めて）スクリプトに任せてください。
5. ダッシュボードフローを実行する場合、一部の指標が null またはゼロでも、必ずダッシュボードを描画してください。 データのないセクションには、エラーではなく明確な「データなし」の状態が表示されます。
6. ダッシュボードモードの呼び出し手順： 事前確認 → リポジトリの解決 → トラッカーデータの取得（接続されている場合は Linear、Jira、Sentry）→ gather → 説明文の作成 → データの反映 → 表示。手順を省略したり、順序を変更したりしないでください。

---

モード

まずこの表を読んでください。一致するセクションに進んでください。

トリガー	モード	移動先
「dashboard」、「DORA」、「my metrics」、「engineering dashboard」、デフォルト	ライブダッシュボード	ダッシュボードフロー
「export DORA」、「spreadsheet」、「Excel」	DORA エクスポート	自動アクション — DORA エクスポート
「triage bugs」、「review PRs」、「dependency audit」	自動アクション	自動アクション

---

ダッシュボードフロー

事前確認：インテグレーションの確認（zen-discovery）

次のプロンプトを指定して zen-discovery スキルを呼び出してください：

「次のインテグレーションのうち、現在接続されているものを確認してください：GitHub、Linear、Jira、Sentry。それぞれについて、接続済み／未接続のステータスを返してください。」

結果をユーザーに伝えてください。すべて接続されている場合の出力例：

✅ GitHub — connected
✅ Linear — connected (sprint and allocation data available)
✅ Jira — connected (sprint and allocation data available)
✅ Sentry — connected (bug triage data available)

一部が未接続の場合の出力例：

✅ GitHub — connected
❌ Linear — not connected (sprint velocity and investment allocation will be locked)
❌ Jira — not connected
❌ Sentry — not connected

注：Sentry が接続されている場合、CFR と MTTR は実際のインシデントデータから計算されます。Sentry が接続されていない場合、gather.py は PR ベースの代替指標（ロールバック／ホットフィックスのマージ時間）を使用します。

接続状況にかかわらず続行してください。 パイプラインは常にダッシュボードを描画します。ロックされたセクションも、自動化の実行結果として有効です。

開始前に、ユーザーに次のように伝えてください：

「エンジニアリング指標を集計しています。完了まで約30～45秒かかります…」

ステップ1 — リポジトリを解決する

list_projects MCP ツールを使って、すべての Zenflow プロジェクトを取得してください。Write ツールを使って、生の JSON レスポンスを /tmp/eng-projects.json に書き込んでください。

このファイルは --projects-file として gather.py に渡します。スクリプトが各プロジェクトの .git/config から GitHub の owner/repo 文字列を自動的に解決するため、手動で解析する必要はありません。

ステップ2 — Linear データを取得する（Linear が接続されている場合）

事前確認で Linear が接続済みと表示された場合、次のプロンプトを指定して zen-linear スキルを呼び出してください：

「過去84日間に更新されたすべてのチームの全課題を一覧表示してください。各課題について、次の情報を含めてください：id、state（名前文字列）、labels（name フィールドを含むオブジェクトの配列）、estimate、created_at、updated_at、completed_at、cycle（利用可能な場合は id、startsAt、endsAt フィールドを含む）。課題の完全な JSON 配列を返してください。」

JSON 出力を取得し、Write ツールを使って /tmp/eng-linear.json に書き込んでください。

Linear が接続されていない場合はこのステップを省略し、--linear-file を渡さないでください。

ステップ 2b — Sentry データを取得する（Sentry が接続されている場合）

事前チェックで Sentry が接続済みと表示されていた場合は、次のプロンプトを指定して zen-sentry スキルを呼び出します。

「すべてのプロジェクトを対象に、解決済みと未解決のすべての課題を一覧表示してください。各課題について、id、title、project slug、firstSeen、lastSeen、status（resolved/unresolved）、イベント数を含めてください。完全な JSON 配列を返してください。」

JSON 出力を取得し、Write ツールを使って /tmp/eng-sentry.json に書き込みます。このファイルは --sentry-file を介して gather.py に渡され、実際のインシデントデータから CFR と MTTR が計算されます。

Sentry が接続されていない場合は、このステップをスキップし、--sentry-file を渡さないでください（gather.py は CFR と MTTR の計算に PR ベースの代替値を使用します）。

ステップ 2c — Jira データを取得する（Jira が接続されている場合）

事前チェックで Jira が接続済みと表示されていた場合は、次のプロンプトを指定して zen-jira スキルを呼び出します。

「過去 84 日間に更新されたすべての Jira 課題を、JQL：'updated >= -84d ORDER BY updated DESC' を使って検索してください。移動可能なすべてのフィールドとスプリントフィールド（customfield_10020）を含めてください。課題の完全な JSON 配列を返してください。」

JSON 出力を取得し、Write ツールを使って /tmp/eng-jira.json に書き込みます。

Jira が接続されていない場合は、このステップをスキップし、--jira-file を渡さないでください。

注： Linear と Jira の両方が接続されている場合は、両方のファイルを渡してください。gather.py はすべてのトラッカーソースの課題を統合します。スプリントベロシティと投資配分には、接続されているすべてのトラッカーのデータが反映されます。

ステップ 3 — データを収集する

スキルディレクトリを見つけて、gather.py を実行します。JSON がディスクに保存され、ツールの結果にも表示されるように tee を使用してください。

SKILL_DIR=$(python3 -c "
import pathlib, sys
for c in [
    pathlib.Path.home() / '.agents/skills/engineering-manager',
    pathlib.Path.home() / '.claude/skills/engineering-manager',
    pathlib.Path.home() / '.gemini/skills/engineering-manager',
    pathlib.Path.home() / '.zencoder/skills/engineering-manager',
]:
    if (c / 'SKILL.md').exists():
        print(c)
        sys.exit(0)
sys.exit(1)
") && python3 "$SKILL_DIR/scripts/gather.py" \
    --projects-file /tmp/eng-projects.json \
    $([ -f /tmp/eng-linear.json ] && echo "--linear-file /tmp/eng-linear.json") \
    $([ -f /tmp/eng-jira.json ]   && echo "--jira-file /tmp/eng-jira.json") \
    $([ -f /tmp/eng-sentry.json ] && echo "--sentry-file /tmp/eng-sentry.json") \
    | tee /tmp/eng-metrics.json

スキルディレクトリが見つからない場合（終了コード 1）は、ユーザーに次のように伝えてください。

「スキルディレクトリが見つかりません。スキルが ~/.agents/skills/engineering-manager/ にインストールされていることを確認してください。」

コマンドが成功すると、ツールの結果にメトリクスの完全な JSON が含まれます。この JSON の meta.narrativeInputs を確認してください。解決された $SKILL_DIR の値をメモしてください。ステップ 5 を作成する際は、変数ではなくリテラル文字列として置き換えます。

meta.configHints が空でない場合は、設定の修正のセクションに従い、各ヒントの prompt フィールドをそのまま使用してください。対応するヒントがないエントリーが meta.errors に含まれている場合は、その内容をそのまま提示してください。

ステップ 4 — エンジニアリング概要をファイルに書き込む

Write ツールを使って /tmp/eng-narrative.txt を作成し、3～5 文（80 語以下）の、通常の文章によるエンジニアリング概要を書き込みます。ステップ 3 の meta.narrativeInputs を使用してください。

1. 全体的な DORA の健全性から始めます：「デプロイ頻度は [level] で、週あたり [value] 件です。」level は meta["narrativeInputs"]["doraLevels4W"]["deployments"] から、value はステップ 3 の出力にある allData["1W"]["deployments"]["value"] から取得します。
2. 最も重要なシグナル、つまり前の期間と比べて最も変化したメトリクスを記載します。
3. bottleneck が null でない場合：「[repo] の [stage] ステージは平均 [value] 時間で、しきい値の [threshold] 時間を超えています。」
4. sprintInfo が null でなく、比率が 90% 未満の場合は、ベロシティ比率に言及します。
5. invFlags が空でない場合は、各フラグを一文として含めます（例：「バグ対応作業は 34% で、しきい値の 30% を超えています。」）。
6. この組織で有効になっている Zenflow の自動化アクションを記載して終えます。ステップ 3 の出力にある allData["1W"]["zenflowActions"] からブール値フラグを読み取ります（例：「Zenflow では PR レビューと依存関係の監査が有効です。」）。

ルール：箇条書きは使用しないでください。Markdown は使用しないでください。個人名は含めないでください。通常の文章のみを使用してください。大半のフィールドが null の場合は、その旨を述べた短い概要にしてください。数値を創作しないでください。

ステップ 5 — ダッシュボードにデータを入力する

<skill-dir-path> をステップ 3 で見つかった絶対パスに置き換えてください。

python3 "<skill-dir-path>/scripts/populate.py" \
  --data-file /tmp/eng-metrics.json \
  --narrative-file /tmp/eng-narrative.txt \
  --output "<skill-dir-path>/engineering-dashboard.html"

成功すると、コマンドは生成された HTML ファイルの絶対パスを出力します。これを保存してください。

ステップ 6 — ダッシュボードを開く

browser_create_tab MCP ツールを使用し、url に file://<ステップ 5 で取得した絶対パス> を設定します。

ユーザーに次のように伝えてください：「ダッシュボードをブラウザーのタブで開きました。」

---

ダッシュボードのレイアウト（常に固定 — 実行ごとに変わりません）

ダッシュボードには、接続されている連携の種類にかかわらず、次の 6 セクションが常にこの順序で表示されます。

1. エンジニアリング概要 — ステップ 4 の説明文
2. DORA メトリクス — デプロイ頻度、リードタイム、CFR、MTTR
3. リポジトリごとの内訳 — リポジトリごとの DORA 概要テーブル、サイクルタイム統計、傾向グラフ、作成者別内訳、所要時間が最も長い PR
4. PR サイクルタイム — リポジトリごとの着手／レビュー／マージの各段階
5. 投資配分 + スプリント速度 — 横並び
6. Zenflow の自動アクション — 利用可能な機能と設定済みの機能

連携が接続されていない場合、そのセクションは「X を接続してロックを解除」というメッセージとともに、目立たない「ロック中」の状態で表示されます。レイアウトは変わりません。

---

設定の修正 — 自然言語による設定の編集

gather.py は、構造化された修正プロンプトのリストとして meta.configHints を出力します。形式：

{ "key": "deploy-label", "type": "string", "prompt": "…", "examples": ["deploy-prod", "release"] }

必須ルール：

• org-config.yaml をユーザー自身で編集するよう案内してはいけません。必ず、こちらで編集すると提案してください。
• ヒントの prompt フィールドをそのまま使用してください。言い換えてはいけません。任意で examples を括弧書きで追加できます。
• ユーザーが値を指定したら、Edit ツールを使用して org-config.yaml を編集し、その後ダッシュボードを再実行するよう伝えてください。gather.py を自動的に再実行してはいけません。

type ごとの編集パターン：

• type: "string" — key: ""（または既存の値）の行を見つけ、key: "<new value>" に置き換えます。
• type: "list" — key: の行を見つけ、その下に - <item> の行を追加し、コメントアウトされたプレースホルダーがあれば削除します。

新しいヒントの追加： org-config.yaml の設定に関連する警告やエラーを gather.py に追加する場合は、対応するエントリを _config_hints に追加してください。仕様全体については docs/config-hints.md を参照してください。

---

自動アクション（任意、ダッシュボードのレンダリング後）

ユーザーから明示的に依頼された場合にのみ実行してください。これらは複数ステップのアクションであり、単一のツール呼び出しに限定されません。

PR レビュー（オープン中の PR は最大 3 件）： /tmp/eng-metrics.json から meta.repos を読み込み、解決済みのリポジトリ一覧を取得してください（これは自動検出されたリポジトリを反映するもので、org-config.yaml に記載されたものだけではありません）。それらのリポジトリ全体から最大 3 件のオープン PR に対して、zen-comprehensive-review スキルを使用してください。

依存関係の監査： /tmp/eng-metrics.json から meta.repos を読み込み、解決済みのリポジトリ一覧を取得してください。各リポジトリに対して、次を実行してください：

gh api /repos/<owner>/<repo>/vulnerability-alerts --jq 'length' 2>/dev/null || echo "0"

実際の owner/repo の値に置き換えてください。プレースホルダーは使用しないでください。

バグのトリアージ： 接続済みの各トラッカーと、利用可能な場合は Sentry に対して実行してください。Linear、Jira、Sentry について、/tmp/eng-metrics.json の meta.connectedProviders を確認してください。

Linear が接続されている場合は、次のプロンプトを使用して zen-linear スキルに委任してください：

「トリアージ」ステータスのすべての課題を一覧表示します。各課題について、タイトル、説明、ラベルを読み、ラベルと内容に基づいて適切なチームを判断します。課題を適切なチームに割り当て、振り分けの判断を説明するトリアージコメントを投稿して、課題を更新してください。すでにチームが割り当てられている課題は振り分けないでください。」

Jira が接続されている場合は、次のプロンプトを使用して zen-jira スキルに委任してください：

「JQL を使用して『Triage』ステータスの Jira 課題をすべて検索します：'status = Triage ORDER BY created DESC'。各課題について、要約、説明、ラベルを読み、内容に基づいて適切なチームを判断します。課題を適切なチームに割り当て、振り分けの判断を説明するコメントを投稿してください。すでにチームが割り当てられている課題はスキップしてください。」

Sentry が接続されている場合は、次のプロンプトを使用して zen-sentry スキルを呼び出してください：「イベント数の多い順に、未解決の上位 20 件の課題を、タイトル、プロジェクト、初回発生日、イベント数、リンクとともに一覧表示します。」結果をユーザー向けに要約してください。Sentry の課題を自動的に振り分けたり更新したりしないでください。

DORA メトリクスのエクスポート（Excel）： zen-office-xlsx スキルを使用して、1W／4W／12W の DORA メトリクスと PR サイクルタイムデータをエクスポートしてください：

• シート 1「DORA Metrics」：列は Period | Deployment Frequency | Lead Time | Change Failure Rate | MTTR | Status、行は 1W、4W、12W です。Status 列には、meta["narrativeInputs"]["doraLevels4W"] の DORA レベル文字列（elite／high／medium／low）を使用してください。すべての行で 4W のレベルを使用します。
• シート 2「PR Cycle Time」：列は Repo | Pickup (h) | Review (h) | Merge (h) | Total (h) です。リポジトリごとに 1 行ずつ作成します。Total = Pickup + Review + Merge です。
• ファイル名：dora-metrics-{date}.xlsx

エクスポートの前に、/tmp/eng-metrics.json が存在することを確認してください。存在しない場合は、ユーザーに「メトリクスデータを生成するために、まずダッシュボードを実行してから、エクスポートを依頼してください。」と伝えてください。ファイルが存在する場合は、JSON の allData からすべてのセルに値を直接入力してください。DORA の複数期間のデータは allData["1W"]、allData["4W"]、allData["12W"] にあり、それぞれに ["deployments"]["value"]、["leadTime"]["value"]、["cfr"]["value"]、["mttr"]["value"] が含まれています。PR サイクルタイムは allData["1W"]["prCycleTime"] にあり（リポジトリ名をキーとし、pickup、review、merge のサブキーを持ちます）、Total はそれらを合計します。ファイルの保存場所をユーザーに伝えてください。

---

スケジュール設定／定期利用

タスク本文でスキルを明示的に呼び出す必要があります。タイトルだけでは確実に振り分けられません。

毎日のダッシュボード — 平日の朝、朝会前：

1. 次のパスを順番に確認し、グローバルにインストールされたスキルを探します：~/.agents/skills/engineering-manager/SKILL.md、~/.claude/skills/engineering-manager/SKILL.md、~/.gemini/skills/engineering-manager/SKILL.md、~/.zencoder/skills/engineering-manager/SKILL.md。
2. いずれも存在しない場合は、グローバルにインストールします：npx skills add zencoderai/skill-engineering-manager -g -y。その後、パスを再確認します。
3. 見つかったパスの SKILL.md を読みます。
4. SKILL.md に記載されているスキルのダッシュボードフローに従います。

設定

このスキルは実行のたびに、スキルディレクトリ内の org-config.yaml を読み込みます。再起動は不要です。

主な設定：

• repos: — owner/repo 形式の文字列を明示的に指定したリスト（すべての自動検出より優先されます）
• org: — GitHub 組織のログイン名。Zenflow プロジェクトから GitHub リポジトリが見つからない場合に、リポジトリ検出の最終手段として使用されます
• deploy-label: — 本番環境へのデプロイに使用する GitHub Actions ワークフロー名（空欄の場合、リポジトリごとに自動検出されます）

repos が設定されていない場合、リポジトリは次の順序で特定されます。

1. Zenflow プロジェクト（list_projects MCP ツール）— 各プロジェクトの .git/config から owner/repo を特定します
2. Zenflow worktree — ~/.zenflow/worktrees/*/.git を検索します
3. GitHub 組織のリポジトリ（gh repo list {org}）— org-config.yaml で org: が明示的に設定されている場合のみ使用されます

個人リポジトリへのフォールバックはありません。 リポジトリが見つからない場合、ダッシュボードは GitHub セクションがロックされた状態で、「Configuration required」バナーを表示します。これは意図した動作です。

Linear と Jira のデータは、実行時にそれぞれの zen-linear スキルと zen-jira スキルを通じて常に取得されます。これらは org-config.yaml では設定しません。

---

拡張ガイド

docs/ ディレクトリには、各メトリクスセクションの開発者向けリファレンス仕様が含まれています。実行時のエージェント向け指示ではありません。次の場合にのみ docs/ を参照してください。

• gather.py に新しいデータソースやメトリクスを追加する
• 特定のメトリクスの想定される計算方法を確認する
• メトリクスが正しく表示されない理由を調査する