writing-documentation

sekka's avatarfrom sekka

技術ドキュメント、機能仕様書、ビジネスコミュニケーション資料を作成します。セットアップガイド、ユーザーマニュアル、要件定義書、ステークホルダー向けレポート、インシデント報告など、あらゆるドキュメント作成をカバーします。

⭐0stars🔀0forks📁View on GitHub🕐Updated Jan 2, 2026

When & Why to Use This Skill

This Claude skill provides a comprehensive framework for generating high-quality technical documentation, functional specifications, and professional business communications. It streamlines the writing process by utilizing industry-standard methodologies like INVEST for user stories, Gherkin for acceptance criteria, and the BLUF (Bottom Line Up Front) principle for executive reporting, ensuring clarity, consistency, and actionable insights across all organizational document types.

Use Cases

  • Technical Documentation: Creating comprehensive setup guides, user manuals, and FAQs to improve product onboarding and self-service support.
  • Product Specification: Drafting detailed functional requirements, user stories, and acceptance criteria to align engineering and product teams.
  • Business Reporting: Generating professional stakeholder reports, progress summaries, and incident post-mortems for clear executive communication.
  • Standard Operating Procedures: Developing technical instructions and internal documentation to ensure operational consistency and knowledge sharing.
namewriting-documentation
description技術ドキュメント、機能仕様書、ビジネスコミュニケーション資料を作成します。セットアップガイド、ユーザーマニュアル、要件定義書、ステークホルダー向けレポート、インシデント報告など、あらゆるドキュメント作成をカバーします。

ドキュメント作成統合スキル

概要

あらゆるタイプのドキュメント作成を統合的に支援するスキルです。3つの主要カテゴリを提供:

  1. 技術ドキュメント: セットアップガイド、ハウツー、FAQ、ユーザーマニュアル
  2. 機能仕様書: ユーザーストーリー、要件定義、受け入れ条件
  3. ビジネスコミュニケーション: ステークホルダー報告、インシデント対応、チーム共有

Quick Start

技術ドキュメント作成

  1. ドキュメントの種類と対象読者を確認
  2. 適切なテンプレートを選択
  3. 品質チェックリストで検証

詳細は TECHNICAL-DOCS.md を参照。

機能仕様書作成

  1. ステークホルダーの要求を収集
  2. ユーザーストーリーを作成(INVEST原則)
  3. 受け入れ条件を定義(Gherkin形式)
  4. 優先順位付け(RICE、MoSCoW)

詳細は SPECIFICATIONS.md を参照。

ビジネスコミュニケーション

  1. 対象を特定(経営層/同チーム/他チーム/外部)
  2. 適切なトーンとフォーマットを選択
  3. BLUF原則で構成(結論→詳細→アクション)

詳細は COMMUNICATIONS.md を参照。

実行フロー

Phase 1: 要件確認

  • ドキュメントタイプ(技術/仕様/コミュニケーション)
  • 対象読者とその前提知識レベル
  • ドキュメントの目的と期待される成果

Phase 2: テンプレート選択

各タイプ別のテンプレート:

技術ドキュメント:

  • セットアップガイド
  • ハウツーガイド
  • FAQ

機能仕様書:

  • ユーザーストーリー(As a / I want / So that)
  • 受け入れ条件(Given/When/Then)
  • API仕様

ビジネスコミュニケーション:

  • 進捗報告
  • インシデント報告
  • ステークホルダー向けサマリー

Phase 3: 執筆

共通原則:

  1. 明確性: 曖昧さを排除、専門用語は定義
  2. 簡潔性: 不要な情報は省略、箇条書き活用
  3. 実用性: 具体例とコード/コマンド例を含む
  4. 検証可能性: テスト可能な基準を明示

Phase 4: 品質確認

  • 目的が明確に述べられている
  • 対象読者に適したレベル
  • 具体的で再現可能
  • エッジケース/エラー処理を含む
  • 次のアクションが明確

出力成果物

技術ドキュメント

  • セットアップガイド
  • ユーザーマニュアル
  • 技術手順書
  • FAQ

機能仕様書

  • 機能仕様書(完全版)
  • ユーザーストーリー
  • 受け入れ条件
  • 優先順位表(RICEスコア付き)

ビジネスコミュニケーション

  • 進捗報告
  • インシデント報告(ポストモーテム)
  • ステークホルダー向けサマリー
  • チーム共有メッセージ

ベストプラクティス

  1. 読者中心: 読者の課題と目標を起点に構成
  2. 段階的詳細化: 概要から詳細へ、必要に応じて深掘り
  3. コラボレーション: ステークホルダーを早期に巻き込む
  4. 継続的更新: 実装中の学びや変更を反映
  5. 一貫性: 用語、フォーマット、トーンを統一

関連ファイル