document-writer
技術文書、設計意思決定記録、RFCなどの作成を専門とし、構造化された知識管理とシステム文書化を行うSkill。
📜 元の英語説明(参考)
Expert in creating technical documentation, architectural decision records (ADRs), and RFCs. Specializes in structured knowledge management and system documentation. Use when writing technical docs, ADRs, RFCs, or system design documents.
🇯🇵 日本人クリエイター向け解説
技術文書、設計意思決定記録、RFCなどの作成を専門とし、構造化された知識管理とシステム文書化を行うSkill。
※ jpskill.com 編集部が日本のビジネス現場向けに補足した解説です。Skill本体の挙動とは独立した参考情報です。
⚠️ ダウンロード・利用は自己責任でお願いします。当サイトは内容・動作・安全性について責任を負いません。
🎯 このSkillでできること
下記の説明文を読むと、このSkillがあなたに何をしてくれるかが分かります。Claudeにこの分野の依頼をすると、自動で発動します。
📦 インストール方法 (3ステップ)
- 1. 上の「ダウンロード」ボタンを押して .skill ファイルを取得
- 2. ファイル名の拡張子を .skill から .zip に変えて展開(macは自動展開可)
- 3. 展開してできたフォルダを、ホームフォルダの
.claude/skills/に置く- · macOS / Linux:
~/.claude/skills/ - · Windows:
%USERPROFILE%\.claude\skills\
- · macOS / Linux:
Claude Code を再起動すれば完了。「このSkillを使って…」と話しかけなくても、関連する依頼で自動的に呼び出されます。
詳しい使い方ガイドを見る →- 最終更新
- 2026-05-17
- 取得日時
- 2026-05-17
- 同梱ファイル
- 1
📖 Skill本文(日本語訳)
※ 原文(英語/中国語)を Gemini で日本語化したものです。Claude 自身は原文を読みます。誤訳がある場合は原文をご確認ください。
ドキュメントライター
目的
ソフトウェアシステムの構造化された技術文書作成に関する専門知識を提供します。アーキテクチャ上の意思決定記録、RFC、設計文書、およびナレッジベース記事を専門としています。
使用する状況
- アーキテクチャ上の意思決定記録 (ADR) を作成する場合
- RFC (Request for Comments) ドキュメントを作成する場合
- システム設計を文書化する場合
- 技術仕様書を作成する場合
- ランブックおよびプレイブックを作成する場合
- 社内ナレッジベースを構築する場合
- インシデントを文書化する場合 (ポストモーテム)
クイックスタート
このスキルを呼び出す状況:
- アーキテクチャ上の意思決定記録 (ADR) を作成する場合
- RFC ドキュメントを作成する場合
- システム設計を文書化する場合
- 技術仕様書を作成する場合
- ランブックおよびプレイブックを作成する場合
呼び出さない状況:
- API ドキュメントを作成する場合 (api-documenter を使用してください)
- ユーザー向けドキュメントを作成する場合 (technical-writer を使用してください)
- Word ドキュメントを作成する場合 (docx-skill を使用してください)
- マーケティングコンテンツを作成する場合 (content-marketer を使用してください)
意思決定フレームワーク
Document Type Selection:
├── Decision needed → ADR
├── Proposal for review → RFC
├── System explanation → Design doc
├── How to operate → Runbook
├── Incident occurred → Post-mortem
├── Process definition → SOP
└── Knowledge capture → Wiki article主要なワークフロー
1. ADR 作成
- 行うべき意思決定を特定します
- コンテキストと制約をリストアップします
- 検討されたオプションを列挙します
- 長所と短所を分析します
- 意思決定と根拠を述べます
- 結果を文書化します
- 関係者のレビューを受けます
2. RFC プロセス
- 問題提起を作成します
- 解決策のアプローチを提案します
- 実装計画を詳細に記述します
- リスクと軽減策に対処します
- 成功指標を定義します
- コメントを募集します
- フィードバックに基づいて反復します
- 承認済み/却下済みに移行します
3. 設計文書
- 目的と範囲を述べます
- 現状を記述します
- 提案された設計を提示します
- 図 (C4、シーケンス) を含めます
- 非機能要件に対処します
- 検討された代替案をリストアップします
- ロールアウト計画を定義します
ベストプラクティス
- 一貫性のためにテンプレートを使用します
- 複雑なシステムには図を含めます
- 自分のためではなく、読者のために書きます
- ドキュメントを最新の状態に保ちます
- 関連するドキュメントをリンクします
- すべてのドキュメントをバージョン管理します
アンチパターン
| アンチパターン | 問題 | 正しいアプローチ |
|---|---|---|
| テンプレートなし | ドキュメントの一貫性がない | 標準テンプレートを使用する |
| 書きっぱなしのドキュメント | 更新されない | レビューをスケジュールする |
| コンテキストの欠如 | 読者が混乱する | 背景を含める |
| 冗長すぎる | 誰も読まない | 簡潔にし、詳細にリンクする |
| 発見できない | ドキュメントが使われない | 整理してインデックスを作成する |
📜 原文 SKILL.md(Claudeが読む英語/中国語)を展開
Document Writer
Purpose
Provides expertise in creating structured technical documentation for software systems. Specializes in architectural decision records, RFCs, design documents, and knowledge base articles.
When to Use
- Writing architectural decision records (ADRs)
- Creating RFC (Request for Comments) documents
- Documenting system designs
- Writing technical specifications
- Creating runbooks and playbooks
- Building internal knowledge bases
- Documenting incidents (post-mortems)
Quick Start
Invoke this skill when:
- Writing architectural decision records (ADRs)
- Creating RFC documents
- Documenting system designs
- Writing technical specifications
- Creating runbooks and playbooks
Do NOT invoke when:
- Writing API documentation (use api-documenter)
- Writing user-facing docs (use technical-writer)
- Creating Word documents (use docx-skill)
- Writing marketing content (use content-marketer)
Decision Framework
Document Type Selection:
├── Decision needed → ADR
├── Proposal for review → RFC
├── System explanation → Design doc
├── How to operate → Runbook
├── Incident occurred → Post-mortem
├── Process definition → SOP
└── Knowledge capture → Wiki articleCore Workflows
1. ADR Creation
- Identify decision to be made
- List context and constraints
- Enumerate options considered
- Analyze pros and cons
- State decision and rationale
- Document consequences
- Get stakeholder review
2. RFC Process
- Write problem statement
- Propose solution approach
- Detail implementation plan
- Address risks and mitigations
- Define success metrics
- Open for comments
- Iterate based on feedback
- Move to accepted/rejected
3. Design Document
- State purpose and scope
- Describe current state
- Present proposed design
- Include diagrams (C4, sequence)
- Address non-functional requirements
- List alternatives considered
- Define rollout plan
Best Practices
- Use templates for consistency
- Include diagrams for complex systems
- Write for the reader, not yourself
- Keep documents updated
- Link related documents
- Version control all documentation
Anti-Patterns
| Anti-Pattern | Problem | Correct Approach |
|---|---|---|
| No template | Inconsistent docs | Use standard templates |
| Write-only docs | Never updated | Schedule reviews |
| Missing context | Readers confused | Include background |
| Too verbose | Nobody reads | Be concise, link details |
| Undiscoverable | Docs go unused | Organize and index |