mcpField
D
doc-condenser

doc-condenser

github.com/mathews-tomドキュメント33799 回インストール2 日前に更新
リポジトリ

doc-condenser について

技術文書を開発者向けの簡潔な仕様にまとめる、非推奨のスキルです。パス、指標、例示コードを残し、テキスト文書を定められた構成と分量に沿って整理します。

主な機能

  1. 01パスと指標を優先
  2. 02説明文を表に変換
  3. 03短いコード例を保持
  4. 04保持・圧縮・削除のルール
  5. 05所定の出力構成を適用

活用シーン

  1. 01長い技術仕様の短縮
  2. 02実装ファイル参照の整理
  3. 03チェックリストの状況表化

インストール

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

$npx skills add https://github.com/mathews-tom/armory --skill doc-condenser

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

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

assets/
template.md
evals/
cases.yaml
references/
style-guide.md

詳細

非推奨 — 最新の Claude モデルは、技術文書を同等の品質でネイティブに圧縮・要約できます。 ここで定められている出力形式の設定(長さの上限 40%、文章より表を優先、パスを先に記載)は汎用的すぎるため、スキルのオーバーヘッドに見合いません。アーカイブ参照用としてのみ保持しています。

ドキュメント圧縮

冗長な技術文書を、簡潔で開発者に焦点を当てた仕様書に変換します。

基本原則

  1. パスを先に記載 - ファイルを参照する際は、必ず絶対パスまたは相対パスを含めます
  2. 文章より表を優先 - 指標、カバレッジ、ファイル一覧には表を使います
  3. コードサンプルは残す - 小さく説明的なスニペットは残し、冗長な例は削除します
  4. 解説ではなく補足 - 段落ではなく、簡潔な背景説明を記載します
  5. 履歴は1行にまとめる - 過去のドキュメントを参照し、その内容は残しません

出力構成

# [path/to/output.md]

# [Title] - [Subtitle if needed]

## Purpose

[2-3 sentences: what this is, why it exists, key design principle]

## Status

[Table: metrics, rates, performance]

## Architecture Overview

[Optional diagram or brief flow description]
[Only if it aids understanding]

## Implementation Files

[Grouped by category with paths and one-line descriptions]

## [Domain-Specific Sections]

[Tables, code snippets, brief commentary as needed]

## Quick Reference

[Box or code block with key stats for scanning]

この構成をすぐに使えるひな形としてコピーするには、assets/template.md を参照してください。

変換ルール

残す
  • ファイルパス(必ず絶対パスまたはプロジェクト相対パス)
  • 指標と測定値
  • パターンを示す 15 行未満のコードスニペット
  • スキーマの例とデータ構造
  • カバレッジ/ステータス表
圧縮する
  • 複数段落の説明 → 1~2 文
  • 冗長な例 → 代表的なスニペットと「詳細は X を参照」
  • 実装チェックリスト → 完了状況の表
  • 長い根拠 → 「設計原則:X」の1行
  • 20 行を超えるコードスニペット → 主要なパターンと、ソースファイルを示す参照コメントに圧縮
  • 同じ点が 3 文を超えて繰り返される根拠セクション → 「設計原則:」の1行にまとめる
削除する
  • 1 行の参照を超える過去の背景
  • 達成や完了を祝う表現
  • 同じ概念についての重複した説明
  • 手順ごとのチュートリアル(代わりにリンクする)
  • 「学んだこと」の振り返り
書式
  • パスとコマンドには コードブロック を使います
  • 関連ファイルを見出しごとにまとめます
  • 構造化データには箇条書きより表を優先します
  • スキャンしやすいクイックリファレンスブロックで締めくくります

既存ドキュメントの扱い

既存の冗長なドキュメントを圧縮する場合:

  1. 中核となる目的を特定します(出力の最初の段落)
  2. すべてのファイルパスを抽出し、グループ別の表にまとめます
  3. パターンを示すコードサンプルを残します
  4. 可能な場合、文章のセクションを表に変換します
  5. 履歴への参照を1行追加します
  6. 検証時に重要な技術情報が失われていないことを確認します

スタイルガイド

詳細な書式ルール、表のパターン、コードサンプルのガイドラインについては、references/style-guide.md を参照してください。

変換例

変換前(冗長):

We have successfully achieved and EXCEEDED the original goals of this specification!
After many iterations and improvements, our automation rate reached 96.6% which is
above our target of 95%. The team worked hard on this and we're very proud...

変換後(簡潔):

**v31 PRODUCTION** | 96.6% automation (target: 95%)

調整ルール

  • 圧縮後の出力は、単語数で測定した元のドキュメントの 40%を超えてはなりません。
  • 元のドキュメントにあるすべてのファイルパスを、圧縮後の出力にも含めます。パスを削除してはいけません。
  • コードブロックを丸ごと削除してはいけません。代表的なパターンを抜き出し、ソースを示す参照コメントを追加して長さを短縮します。

エラー処理

  • ソースドキュメントの目的が明確でない場合:圧縮する前に、背景を1文で尋ねます。目的を推測して作業を進めてはいけません。
  • KEEP と REMOVE のどちらに該当するか曖昧な項目を含むセクション:KEEP を既定とし、出力内で `` コメントを付けてそのセクションを示します。
  • 検証時に必須の技術的詳細が失われている場合:省略した詳細を復元し、40%の長さ上限を超えていないか再測定します。上限を満たせない場合は、例外を本文中に記載します。
  • ソースにファイルパスが含まれていない場合:プレースホルダーのパスを生成するのではなく、「実装ファイル」セクション全体を省略します。
  • ソースがテキスト以外の形式(画像、図、スプレッドシート)の場合:その形式がサポートされていないことを報告し、出力せずに終了します。
  • スタイルガイドがソースの書式慣習と競合する場合:references/style-guide.md に従い、出力の先頭でその上書きを注記します。

制限事項

  • テキスト文書にのみ対応しています。画像、図、バイナリファイルは要約できません。
  • 圧縮率はソースの冗長さによって異なります。高度に構造化されたソースでは、削減量が少なくなります。
  • スタイルガイド(references/style-guide.md)がソースの書式より優先されるため、見出しレベルや表のレイアウトが変更される場合があります。
  • ハイパーリンクをたどったり、参照先の外部文書を取得したりしません。参照先の内容については記載しますが、本文には含めません。

コメント