mcpField
T
technical-blog-doc

technical-blog-doc

github.com/full-stack-skillsドキュメント273 回インストール4 週間前に更新
リポジトリ

technical-blog-doc について

追跡可能な根拠に基づき、再現可能な技術記事を作成するためのスキルです。調査、執筆、検証、レビューを案内し、API ドキュメントや共同提案の作成は専用スキルへ振り分けます。

主な機能

  1. 01根拠の分類と出典追跡
  2. 02読者と環境の定義
  3. 03検証マトリクスと記事構成
  4. 04実行可能な例と安全上の指針
  5. 05コマンドとテストの検証
  6. 06初見読者による確認と品質チェック

活用シーン

  1. 01ローカル実装の技術手順を文書化
  2. 02バージョン依存のセットアップ手順を執筆
  3. 03検証済みコマンドを含むチュートリアルを公開
  4. 04記事の再現性をレビュー

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/full-stack-skills/document-skills --skill technical-blog-doc

インストール後、Claude Code で/technical-blog-docを入力して読み込まれたか確認します。

同梱ファイルagents/openai.yamlassets/technical-blog-template.md

詳細

技術ブログのドキュメント

主張、コード、コマンド、バージョンを根拠までたどれる、再現可能な技術コンテンツを作成します。

振り分け

  • 製品ドキュメント一式または PRD の階層構成：full-stack-doc スキルに引き継ぎます。次のコマンドでインストールします：npx skills add full-stack-skills/document-skills --skill full-stack-doc。
  • API のみのドキュメント：api-doc-generator スキルに引き継ぎます。次のコマンドでインストールします：npx skills add full-stack-skills/document-skills --skill api-doc-generator。
  • 共同での提案書／RFC の作成：doc-coauthoring スキルに引き継ぎます。次のコマンドでインストールします：npx skills add full-stack-skills/document-skills --skill doc-coauthoring。

根拠のモデル

執筆前に、情報を分類します。

ラベル意味
公式情報現在の公式ドキュメントまたはリリースノートで裏付けられている
ソースコードの確認結果調査対象のリポジトリで確認されている
実行による検証現在の環境で実行したコマンドまたはテストで確認されている
推論直接検証されていないが、妥当な解釈
要確認情報が欠落している、矛盾している、または不安定である

推論や要確認を、検証済みの事実として提示しないでください。バージョン、API、サポート対象の一覧、その他の時期により変わる主張が重要な場合は、信頼できる情報源を参照してください。

ワークフロー

1. 読者との前提を定義する

対象読者、想定する事前知識、約束する成果、対象環境、成果物の配置場所を特定します。記事でローカルの実装について説明する場合は、実際のリポジトリを調査してください。

2. 検証マトリックスを作成する

記事が依拠する情報を記録します。

  • OS とアーキテクチャ
  • 言語／ランタイムとパッケージマネージャーのバージョン
  • フレームワーク、SDK、モデル、またはサービスのバージョン
  • 必要な認証情報と外部サービス
  • 実行が必要なコマンド
  • 期待される出力と障害発生時の挙動
  • ベンチマーク、制限、互換性に関する主張の情報源
3. 構成を選択する

記事全体のひな型が役立つ場合は、assets/technical-blog-template.md をコピーします。一般的な文章で埋めるのではなく、関係のないセクションは削除してください。

一般的な構成：

  1. 成果と範囲
  2. 前提条件と検証済み環境
  3. アーキテクチャまたはリクエストの流れ
  4. 実装手順
  5. 設定とセキュリティ
  6. 実行と検証
  7. トラブルシューティング
  8. 制限事項と本番環境での考慮事項
  9. 検証記録と情報源
4. 実行可能な成果物をもとに執筆する
  • 再構成したコード断片より、現在のリポジトリにあるコードや設定を優先します。
  • コード断片は最小限にしつつ、構文的に完結させます。
  • シークレットにはプレースホルダーを使い、トークン、個人データ、内部エンドポイントは伏せます。
  • 手順を貼り付けるだけでなく、その手順が必要な理由も説明します。
  • スクリーンショットや図は、具体的な説明目的に結び付けます。
  • Markdown 標準のフロー図には Mermaid を、厳密な UML／C4 表記には PlantUML を使用します。
5. 検証する

許可されている場合は、安全なコマンドとテストを実行します。実際に実行したコマンドと結果を記録してください。実行できない場合はその旨を明記し、成功したと主張せずに、具体的な検証手順を示します。

検証セクションを追加します。

## 验证记录

- 验证日期：{YYYY-MM-DD}
- 操作系统：{系统与架构}
- 运行时版本：{版本}
- 框架/SDK 版本：{版本}
- 执行命令：`{命令}`
- 结果：{实际结果}
- 未验证内容：{无/列表}
- 官方资料：{链接列表}
6. 記事を前提知識なしで読み直す

会話の文脈を知らない読者が、前提条件を特定し、コマンドと出力を区別し、結果を再現し、一般的な障害から復旧し、外部情報に関する主張を検証できるかを確認します。

品質ルール

  • H1 は 1 つにし、見出し階層に一貫性を持たせます。
  • フェンス付きコードブロックには、すべてシェルまたは言語を指定します。
  • バージョンに左右される主張には、日付と情報源を明記します。
  • 再配布が許可されていない限り、公式画像をコピーしないでください。適切な場合は、説明用のオリジナル図をリンクするか、作成してください。
  • 相対リンクとローカル画像参照が有効か確認します。
  • 開発用の例だけを根拠に、あらゆる本番環境に当てはまると主張しないでください。
  • 変更によって理解が大きく改善される場合を除き、ユーザーが作成した既存の記事構成を維持します。

完了時の報告内容

出力ファイル、検証済みのコマンド／テスト、使用したソースリンク、テストした環境、残っているすべての 推断 または 待确认 項目を報告してください。

コメント

Markdown 対応