agentsclimarketplace

Stakeholder translation

Skill thinkyou0714/claude-lab-skills/lab-communication-translation/skills/stakeholder-translation

THINK YOU LAB thinking-OS skills for Claude Code — reusable judgment/design/automation/communication skill packs (tech-agnostic, MIT)

Install
npx -y skills add thinkyou0714/claude-lab-skills --skill stakeholder-translation

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

技術的な実装内容・判断・リスクを、非エンジニアのステークホルダーが理解できる言葉に変換する。「何が起きているか」「何が必要か」「何を決めてほしいか」を明確に伝える。非エンジニアへ報告・説明するときに使う。

SKILL.md

5.6 KB, as published. Nobody here has run it

Purpose

「エンジニアの報告が技術用語ばかりで意思決定できない」を防ぐ。 施工AIや開発者が出力した技術的な内容を、意思決定者・事業担当者が行動できる形式に翻訳する。

Use When

  • 実装結果・進捗を非エンジニアに報告する場合
  • ブロッカーや技術的リスクについて承認・判断を求める場合
  • 設計決定（ADR）の背景・トレードオフを説明する場合
  • インシデント・障害の原因と対処を報告する場合

Inputs

以下を準備すること。不足している場合は推測せず、不足を明示する。

  • 原文（技術内容）: 翻訳元の技術的な説明・レポート・コード変更サマリー
  • 受け手の役割: 誰に向けた翻訳か（経営者 / 事業担当者 / 顧客 / チームメンバー）
  • 目的: 報告のみ / 判断を求める / 承認を求める / 理解を促す
  • 背景: 受け手がすでに知っていること・知らないこと

Output Contract

以下の順で出力すること。順序を変えない。

  1. 論点: この翻訳で最も重要な伝達すべき核心
  2. 根拠: その論点をそう判断した理由
  3. 翻訳結果: ステークホルダー向けの説明文
  4. 含意: この内容を正確に伝えないと起きうる意思決定ミス・誤解
  5. 改善案: 翻訳の明確さ・簡潔さを高めるための調整案
  6. 代替案: 受け手の役割・目的が異なる場合の別バージョン
  7. 判断材料: 「この翻訳で送る / 追加確認が必要 / 別の形式にする」を選ぶための情報

翻訳結果 フォーマット

状況（What）: 何が起きているか（1〜2文）

影響（Impact）: 事業・ユーザー・スケジュールへの影響（箇条書き）

必要なこと（Need）: 受け手に求めること（判断 / 承認 / 情報提供 / なし）

期限（Deadline）: 判断・対応が必要な期限（あれば）

Review Lens

  • 目的妥当性: 受け手の役割に対して適切な言葉・粒度か
  • 範囲の過不足: 技術詳細が不要に含まれていないか / 必要な文脈が省略されていないか
  • 中長期リスク: 翻訳による情報の歪み・誤解のリスクはないか
  • LAB全体との整合性: 主力プロダクト（LMS）の事業文脈と一致しているか
  • 非エンジニア理解可能性: 受け手が追加質問なく行動できるか
  • 他LLM移植耐性: 翻訳フレームワークが Claude 固有の解釈に依存していないか

Instructions

  1. 原文の技術内容を「事実 / 影響 / 必要なアクション」に分解する
  2. 受け手の役割に合わせて専門用語を日常語に置き換える
  3. 「何を決めてほしいか」が明確でない場合は明示的に記載する
  4. 数値・日付・条件は具体的に保つ（「近日中」「大幅に」は使わない）
  5. 感情的なトーン（緊急感の誇張・過小評価）を排除する
  6. 受け手が「次に何をすべきか」で終われるよう構成する
  7. 最終判断は人間に委ねる

Guardrails

  • 技術的正確性を犠牲にして分かりやすさを優先しない
  • 「問題ない」「大丈夫」等の曖昧な安心文句を使わない
  • 受け手を不安にさせないために不都合な情報を省略しない
  • 翻訳者（AI）の意見・推奨を受け手の判断として混同させない
  • 期限・影響範囲が不明な場合は「未確定」と明示する

LAB Cross-Check

観点状態備考
自動化フロー—自動化フローの状態変化が含まれているか
データ / 認証 / ログ—DB・認証・ログの問題が事業影響として説明されているか
実装 / 運用フロー—実装進捗・ブロッカーが行動可能な形で伝わるか
非エンジニア理解可能性—追加質問なく行動できる説明か
会員共有 / 再利用耐性—翻訳フォーマットが他の報告にも転用できるか
他LLM移植耐性—フレームワークが Claude 固有に依存していないか

状態は OK / 注意 / NG / 対象外 で記入すること。

Handoff Notes

  • 要件: 翻訳結果（What / Impact / Need / Deadline を含む）
  • 成功条件: 受け手が追加質問なく判断・行動できる
  • 失敗条件: 受け手が内容を誤解し、誤った判断を下す
  • 実行範囲: 翻訳・言い換えのみ（情報の追加・削除は行わない）
  • 影響範囲: 受け手の意思決定・アクションへの影響
  • ロールバック方針: 誤訳・誤解が判明した場合は即座に訂正文を送付
  • コスト比較: 翻訳コスト vs 技術的誤解による意思決定ミスのコスト

Further Reading

  • summary-structuring skill — 長文の技術内容を構造化して要約する
  • onboarding-readability skill — ドキュメントの読みやすさチェック
  • docs/CONTEXT.md — 主力プロダクト（LMS）の事業文脈
  • docs/DECISIONS.md — 設計決定記録（ADR）

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.