WolfMarkDown は何をしますか?
AI出力の乱雑なMarkdownを、レビューして保存可能なプロフェッショナルなMarkdownに変換するエージェント公開ワークフロー。
エージェントによる構造の判断と、決定的なツールによる検証。
AIエージェントは有用な調査、計画、ドキュメントを作成できる一方で、平坦化された比較、一貫性のない見出し、コピーされたチャットの足場、壊れたフェンス、改変された技術識別子を残すことがあります。
WolfMarkDownはエージェントに規律ある公開ワークフローを提供します:
- エージェントは意味、構造、サニタイズ、構成を決定します;
- 決定的なツールが結果のMarkdownをフォーマットし検証します;
- 保護されたコンテンツ、ロールバック、公開境界が、結果を保持する前にチェックされます。
結果は魔法のMarkdown修復エンジンではありません。成果物に対する決定的な証明を伴うエージェントワークフローです。
WolfMarkDownが存在する理由
Prettierは優れたMarkdownプリンターです。しかし、平坦化されたブロックが比較テーブルを含むかどうか、短い文が見出しかどうか、コピーされたエージェントメッセージがドキュメントに属するかどうかを判断できません。
WolfMarkDownはそれらの判断を明示的かつ保守的に行います。明確な構造を修復し、本質的に曖昧な素材はそのまま保持し、何が回復されたかを報告します。ソースのファクトチェックや公開の承認は行いません。
| 機能 | Prettier単独 | WolfMarkDown |
|---|---|---|
| 決定的なMarkdownフォーマット | はい | はい |
| セマンティックなドキュメント構造の修復 | いいえ | はい |
| コピーされたAI会話の足場の削除 | いいえ | はい |
| 不適切な比較テーブルの再構築 | いいえ | はい |
| URL、コード、ハッシュ、バージョン、識別子の保護 | いいえ | はい |
| GFMパースとフェンスバランスの検証 | いいえ | はい |
| 公開前のmarkdownlintの実行 | いいえ | はい |
| 冪等性のチェック | いいえ | はい |
| Clean失敗後の元の状態への復元 | いいえ | はい |
| Compose失敗時の公開拒否 | いいえ | はい |
WolfMarkDownは、すでに良いプローズを無理に言い換えることはしません。目標は、結果を安全に保存できるという決定的な証明とともに、最小限必要なセマンティッククリーンアップを行うことです。
インストール
npx skills add WolfMarkTools/WolfMarkDown --skill wolfmarkdown
skills CLIは、選択されたAgent Skills互換ホストに対して、標準の wolfmarkdown/ スキルをインストールします。リポジトリのチェックアウトからも以下を実行できます:
npm ci --prefix wolfmarkdown
node wolfmarkdown/scripts/install.mjs
非対話的なClaude Codeインストールの場合:
npx skills add WolfMarkTools/WolfMarkDown \
--skill wolfmarkdown \
-g \
-a claude-code \
-y
インストーラーは必要な場合にのみランタイム依存関係を修復し、共有の .agents/skills/wolfmarkdown ディスカバリを設定し、Claude Code互換パスを設定し、Windowsでは適切なディレクトリジャンクションを使用し、無関係なパスへの上書きを拒否します。
クイック使用法
WolfMarkDownを docs/architecture.md に使ってください。
WolfMarkDownを使ってこのリサーチをMarkdownとしてエクスポートしてください。
WolfMarkDownで docs/architecture.md を変更せずに検証してください。
ホストがスラッシュコマンドを公開している場合、同じワークフローは次のように呼び出せます:
/wolfmarkdown docs/architecture.md
/wolfmarkdown verify docs/architecture.md
自然言語による呼び出しがポータブルなインターフェースです。スラッシュコマンドの提示はホスト固有です。
操作
| 操作 | WolfMarkDownの動作 |
|---|---|
| Compose | ソースマテリアルから .md ファイルを作成し、チャット専用の足場を削除し、フォーマットし、検証し、PASSした場合のみ公開します。 |
| Clean | 既存のMarkdownファイルを最小限のセマンティック変更で修復し、検証に失敗した場合は元のファイルを復元します。 |
| Verify | Markdownを変更せずにチェックします。 |
| Doctor | インストールを変更せずにランタイム依存関係とスキルディスカバリを検査します。 |
| Setup | 必要な場合にのみランタイム依存関係を修復し、共有スキルディスカバリを設定します。 |
典型的なクリーンアップ対象には、見出し階層、不適切なリスト、壊れたGFMテーブル、閉じられていないコードフェンス、コピーされたエージェントのコメント、会話に依存した表現、ドキュメントに残すべきでない装飾ノイズが含まれます。
ビフォー・アフター
乱雑なエージェントのドラフトは、比較を1つのブロックに平坦化することがあります:
推奨 外部ウォレットフローには relay_v2 を使用。
比較 プロバイダー モード リスク Privy 外部承認 中 CDP 埋め込みウォレット 高。
実装ノート relay_v2 は送信後に getTransaction を確認。
エージェントが構造を明示した後、WolfMarkDownは以下のようなドキュメントを公開できます:
# ウォレットフローの決定
## 推奨
外部ウォレットフローには `relay_v2` を使用します。
## 比較
| プロバイダー | モード | リスク |
| --- | --- | --- |
| Privy | 外部承認 | 中 |
| CDP | 埋め込みウォレット | 高 |
## 実装ノート
`relay_v2` は送信後に `getTransaction` を確認します。
出力はテーブルと見出しを回復し、技術識別子をそのまま保持し、ソースに存在しなかった情報は追加しません。これは説明のための構造例です。セマンティックな判断はエージェントが所有します。
例
公開された例では、WolfMarkDownが実際のエージェント生成Markdownから、欠落した意味を捏造せずに構造を回復する様子を示しています。
- モバイルアプリ移行の例 — チャットラッパーのサニタイズ、タブ区切りテーブル、Unicode箇条書き、保護された環境変数、意図的に曖昧なデータベースメモを含む完全なビフォー・アフターフィクスチャ。
- 元の入力 — 修復前のAI出力ソース。
- 構造化出力 — 見出し、GFMテーブル、リスト、
envコードブロックを含む結果のMarkdown。
例のREADMEには、再現に使用されたOpenCodeハーネス、GLM-5.2 モデル、および正確なプロンプトが記録されています。
対応エージェント統合状況
WolfMarkDownには1つの標準実装があります。以下の表は、リポジトリでテストされたディスカバリパスと、まだ専用のスモークテストが必要なホストの受け入れを区別しています。
| ホスト | 統合状況 | ディスカバリパス |
|---|---|---|
| Codex | リポジトリディスカバリとインストーラーパスをテスト済み | 共有 .agents/skills |
| Cursor | リポジトリディスカバリとインストーラーパスをテスト済み | 共有 .agents/skills |
| Claude Code | 互換リンクパスをテスト済み | .claude/skills |
| OpenCode | ホスト受け入れ保留中 | ホストが有効化した場合、共有 .agents/skills |
| Gemini CLI | ホスト受け入れ保留中 | ホストが有効化した場合、共有 .agents/skills |
| GitHub Copilot | ホスト受け入れ保留中;プラグイン受付は過去のエビデンス | ホストが有効化したAgent Skillsまたはプラグインサポート |
ホストの受け入れは、バイナリやディレクトリの存在から推定されません。ホストモデルがセマンティック品質を決定します。WolfMarkDownはワークフローと決定的なチェックを提供します。
動作の仕組み
ユーザーの意図
↓
エージェントのセマンティック判断
↓
ソースマップとセマンティック修復
↓
GFMパース + 見出し/テーブルチェック
↓
フェンス、フロントマター + 空白チェック
↓
Prettierフォーマットチェック
↓
markdownlint
↓
保護トークン整合性(ソーススナップショット付き)+ 冪等性
↓
PASS → 保持・公開 FAIL → 復元・公開しない
フォーマットの前に、エージェントは平坦化されたセマンティック構造をチェックします。ドキュメントが有効なMarkdownであっても、テーブル、見出し、リスト、関係を失っている場合、変換に失敗したことになります。
セマンティック修復の境界
エージェントは、ソースが構造を明確にしている場合にのみ、見出し、リスト、テーブル、段落、兄弟セクションを再構築します。ヘッダーのないタブ実行は自動的にテーブルとは見なされません。短い文は自動的に見出しとは見なされません。孤立した ラベル: 値 のフレーズは自動的にリスト項目とは見なされません。長いドキュメントの場合、エージェントはソースマップを維持し、完全なアウトライン、セクション間の関係、テーブル境界、保護された値を公開前に調整します。ソースを完全にレビューできない場合は、推測する代わりに不確実性を保持し、その限界を報告します。
検証と品質の境界
WolfMarkDownのPASSは、成果物が該当する決定的なチェックに合格したことを意味します:
- Markdown成果物がフォーマット、パース、リント、フェンス、冪等性チェックに合格しました;
- エージェントがソースに基づいた構造決定を行い、報告しました;
- 保護された技術コンテンツは、CleanやCompose、または
--integrity-fromを使用した場合に、未変更のソーススナップショットに対して整合性がチェックされた場合にのみ保持されました; - 失敗したCleanおよびCompose操作は、未検証の公開結果を残しませんでした。
整合性ソースなしの単独Verifyは、整合性をスキップ済みとして報告します。そのPASSは、保護されたトークンが保持されたことを証明しません。
保護される詳細
未変更のソーススナップショットが利用可能な場合、整合性チェックは以下の技術コンテンツを保護します:
- URL、インラインコード、フェンスコード;
- 公開鍵、署名、ハッシュ、バージョン、識別子;
- ファイルシステムパスとコンテキスト環境変数;
- 日付、パーセンテージ、通貨値。
これはMarkdown品質のエビデンスであり、コンテンツの承認ではありません。PASSは、事実の正確性、完全性、最新性、ポリシー準拠、または公開の権限を確立しません。主張のファクトチェックは行いません。
決定的なチェックは、成果物の特性の証明です。それらはセマンティックオラクルではなく、すべての明確なソースシグナルを説明するエージェントの責任を置き換えるものでもありません。
v0.2.1 リリースエビデンス
- 82/82 のNodeテストが合格
- 実行可能なセマンティックプロパティチェックが、見出し、GFMテーブル、保護トークン、曖昧なテーブルの保持をカバー
skills-ref validate ./wolfmarkdownが合格- インストーラー、Doctor、ロールバック、ターゲット衝突、整合性、冪等性チェックはカバー済み
過去の外部プラグイン受付
v0.1.1 Agent Pluginsパッケージは、GitHub Awesome Copilotの自動外部プラグイン受付に合格しました。これは過去のパッケージングエビデンスであり、v0.2.1のホスト受け入れエビデンスではありません。
アーキテクチャ詳細
WolfMarkDown/
├── plugin.json
├── .agents/
│ └── skills/
│ └── wolfmarkdown → ../../wolfmarkdown
├── skills/
│ └── wolfmarkdown → ../wolfmarkdown
└── wolfmarkdown/
├── SKILL.md
├── config/
├── lib/
├── references/
├── scripts/
└── tests/
エージェントが所有する決定
エージェントは、インテントルーティング、ソースマッピング、セマンティック分類、会話サニタイズ、見出し/リスト/テーブルの回復、曖昧さの処理、および構成を所有します。
決定的な証明
スクリプトは、フォーマット、Markdownリント、GFMパース、フェンスバランス、フロントマターチェック、保護トークン整合性、冪等性、インストール、Doctorチェック、ロールバック、およびプロパティベースのセマンティック評価を所有します。これらはソースの意味を書き換えません。
Prettierは唯一の最終プリンターです。
マシンスキルIDとファイルシステムディレクトリは意図的に小文字の wolfmarkdown です。製品名は WolfMarkDown です。
セマンティック評価
評価コーパスは、脆弱な全文ドキュメントスナップショットではなく、合成ドキュメントと構造プロパティを使用します。通常の検証の後に、エージェントが生成した候補に対してケースを実行します:
node wolfmarkdown/scripts/evaluate-semantic.mjs \
--case ambiguous-structure-preservation \
source.md candidate.md
評価者は、期待される見出しとテーブル数、保護トークンの保持、および曖昧なヘッダーレス実行をテーブルに変換することを拒否するなどの安全性プロパティをチェックします。候補を推測したり修復したりはしません。
開発者コマンド
npm ci --prefix wolfmarkdown
npm test
npx --yes skills-ref validate ./wolfmarkdown
便利な直接コマンド:
node wolfmarkdown/scripts/doctor.mjs
node wolfmarkdown/scripts/format-markdown.mjs path/to/file.md
node wolfmarkdown/scripts/verify-markdown.mjs path/to/file.md
node wolfmarkdown/scripts/evaluate-semantic.mjs --help
セマンティックケースは wolfmarkdown/tests/evals/ にあります。クロスホスト受け入れ入力は wolfmarkdown/tests/acceptance/ にあります。
現在の境界
/wolfmarkdown setupは、スキルがホストからディスカバリ可能になった後にのみ機能します。--modeはサポートされていません。- ベンダー固有のスキルフォークは作成されません。
- Windowsでは、適切なディスカバリジャンクションを作成するための権限が必要です。
- セマンティックサニタイズは、設計上、エージェントが判断します。
- 検証者はMarkdown成果物の特性を証明します。任意の散文や公開準備状態を認定するものではありません。
- 長いドキュメントの修復は、エージェントがドキュメント台帳を保持し調整することに依存します。不完全なソースレビューは推測ではなく報告されなければなりません。
リポジトリメタデータ
推奨されるGitHubリポジトリトピック:
ai-agents agent-skills markdown documentation claude-code codex cursor github-copilot
トピックはGitHubリポジトリ設定で設定する必要があります。これらはディスカバリ可能性のメタデータであり、互換性のエビデンスではありません。
コントリビューティング
WolfMarkDownがより適切に処理すべきMarkdownエッジケースを見つけましたか? Issueを開いてください。
プルリクエストは、再現可能なMarkdown障害、整合性エッジケース、クロスプラットフォームインストールの問題、追加のホスト受け入れエビデンス、単一実装アーキテクチャを保持する焦点を絞った改善に特に有用です。
ライセンス
WolfMarkDownは MITライセンス の下で利用可能です。