ascii-art-diagrams
Unicodeの罫線文字を使用してASCIIアート図を作成するためのルールです。ボックス、ツリー構造、フローチャート、その他の視覚的表現を描画できます。
description の原文を見る
Rules for creating ASCII art diagrams with Unicode box-drawing characters. Covers boxes, trees, flow charts, and visual representations.
SKILL.md 本文
ASCII アート図スキル
自動インストール
このスキルはインストール不要です。フォーマッティングガイドであり、システムではありません。
アクティベーション方法: 図を作成する必要があるときに、このスキルを読み込みます:
skill({ name: "ascii-art-diagrams" })
自動読み込み対象:
- アーキテクチャドキュメント作成時
- 複雑なフローまたはアルゴリズムの説明時
- コードコメントやマークダウン内の視覚的表現を構築する場合
このスキルを使用する時機
以下を作成するときにこのスキルを使用します:
- アーキテクチャ図
- フローチャート
- ツリー構造(ファイルツリー、判定木、階層図)
- ボックス図(注釈、警告、情報ボックス)
- 境界線付きテーブル
- Unicodeボックス描画文字を使用した視覚的表現
前提条件
フォント要件
Unicodeブロック文字とボックス描画文字が等幅フォントで正しくレンダリングされるようにするには:
/* Google Fonts - Fira Code */
@import url('https://fonts.googleapis.com/css2?family=Fira+Code:wght@400;500;700&display=swap');
/* コードブロックに適用 */
pre, code, .ascii-art {
font-family: 'Fira Code', Menlo, Monaco, Consolas, 'Courier New', monospace;
}
行の高さ
ASCIIダイアグラムには行の高さ1を使用します(追加の間隔は不要):
.ascii-art {
line-height: 1;
}
ルール1: ボックス構築
1.1 すべての行の長さが等しくなければならない
ボックス内のすべての行は、文字数が同じである必要があります。短い行はスペースで埋めてください。
間違い(行の長さが不均等)
┌───────────────┐
│ short │
│ this is longer text │
└───────────────┘
正しい(すべての行が等しい)
┌─────────────────────┐
│ short │
│ this is longer text │
└─────────────────────┘
1.2 コンパクトテキスト - コンテンツ間に空行なし
行の高さ1では、コンテンツはコンパクトです。テキスト行間に空行は不要です:
正しい(コンパクト、スペーサーなし)
┌───────────────────────────────────────────────────────┐
│ イテレーションループ中の状態変更 │
│ は同時変更例外を引き起こします │
│ -> ループ完了後に変更を収集して適用 │
└───────────────────────────────────────────────────────┘
1.3 最小パディング
常にコンテンツと境界線の間に少なくとも1〜2文字のスペースを配置します:
正しい(2文字のパディング)
┌───────────────────────────────────────────────────────┐
│ │
│ バッチ処理中: │
│ │
│ - アイテムは順序付きで処理されます │
│ - キャッシュは無効化されません │
│ - 以前の結果は古い可能性があります │
│ │
└───────────────────────────────────────────────────────┘
注: ボックスコンテンツの上下の空行はオプションですが、読みやすさのため推奨します。
ルール2: セクションタイトル
2.1 タイトルに下線を使用
疑似コードブロックでは、タイトル下線に下線文字を使用します:
正しい
フルビルド
___________________________________________________
1. 出力ディレクトリをクリア
2. 依存関係を優先度でソート
主要ポイント:
- 下線の後に1行の空行
- クリーンな視覚的区切りを作成
2.2 サブセクションタイトル
ボックス内の小さいサブセクションの場合、細い水平線を使用します:
モード1: 単一結果(デフォルト)
- 最初にマッチしたアイテムを返す
- 使用: findFirst()
- 最高パフォーマンス
モード2: すべての結果
- マッチしたすべてのアイテムの配列を返す
ルール3: ツリー構造(手順フロー)
3.1 基本パターン
番号付きステップとサブステップ用のツリーブランチ:
1. 設定ファイルをロード
2. タスクを優先度でソート(低 -> 高)
3. ソート済みの各タスクに対して:
│
├── タスクを実行
│
└── IF task.hasCallback AND task.succeeded:
│
└── IF callback.isAsync:
│
└── 後で実行するため、コールバックをキューに追加
4. コールバックを処理:
│
├── IF pending_callbacks.length > 0:
│ │
│ └── 各コールバックを実行
│
└── IF errors.length > 0:
│
└── ファイルにエラーをログ出力
3.2 主要ルール
│は垂直継続用├──はより下にもブランチがあるブランチ用└──は最後のブランチ用(下に兄弟なし)- ネストレベルを4スペースでインデント
- メジャーステップ間に1行の空行
- サブブランチは空行なしで接続
3.3 複数の兄弟がある場合は │ を継続
正しい
├── ネストされたコンテンツ付きチャイルド
│ │
│ └── ネストされたアイテム
│
└── 最後の兄弟
ルール4: フローダイアグラム
4.1 ボックス付きの垂直フロー
各ステップはボックスを取得します。ボックス間に │ と ▼ を使用します:
┌───────────────────────┐
│ │
│ processRequest() │
│ │
└───────────────────────┘
│
│
▼
┌───────────────────────┐
│ │
│ validateInput │
│ │
└───────────────────────┘
│
│
▼
┌───────────────────────┐
│ │
│ needsAuth? │
│ │
└───────────────────────┘
4.2 分岐判定
YES/NOラベルと戻り線付きのサイドブランチを使用します:
┌───────────────────────┐
│ │ YES
│ needsAuth? │──▶───────────┐
│ │ │
└───────────────────────┘ │
│ │
│ NO │
│ │
▼ │
┌───────────────────────┐ │
│ │ │
│ レート制限を適用 │ │
│ │ │
└───────────────────────┘ │
│ │
│ │
▼ ▼
┌───────────────────────┐ ┌────────┴──────────┐
│ │ YES │ │
│ cache.isValid? │──▶──┤ returnCached() │──▶─┐
│ │ │ │ │
│ │ └───────────────────┘ │
└───────────────────────┘ │
│ │
│ NO │
│ │
▼ │
4.3 戻り線
戻りフロー用に < を使用します:
│ │
│ ◀─────────────────────────────────────────┘
│
▼
┌──────────────────────┐
│ │
│ 完了 │
│ │
└──────────────────────┘
ルール5: グラフィックスとテキスト
5.1 グラフィックス(ピクセルアート) - コンパクト
コンテンツが視覚的/グラフィカルな場合、行間に空行を置きません:
┌────────────────────────┐
│░░░░░░░░░░░░░░░░░░░░░░░░│
│░░░░░░░░░░░░░░░░░░░░░░░░│
│░░░░░░░░░░░░░░░░░░░░░░░░│
│░░░░░░████░░░░░░░░░░░░░░│
│░░░░░░████░░░░░░░░░░░░░░│
│░░░░░░████░░░░░░░░░░░░░░│
│░░░░░░░░░░░░░░░░░░░░░░░░│
└────────────────────────┘
5.2 視覚的文字の選択肢
█ = 全ブロック(ソリッド、プライマリ)
▓ = 濃いシェード(ハイライト)
▒ = 中程度のシェード
░ = 薄いシェード(背景、セカンダリ)
= 空き/クリア領域
ルール6: 特殊ボックスフォーマット
6.1 ラベル付き注釈ボックス
┌────────┬───────────────────────────────────────────────────┐
│ │ キャッシュはバッチ操作中に無効化されません! │
│ 注釈 │ リフレッシュまで、結果が古い可能性があります。 │
│ │ │
└────────┴───────────────────────────────────────────────────┘
6.2 ツリー内蔵の情報ボックス
┌─────────────────────────────────────────────────────────┐
│ │
│ ステップN: イベント受信 │
│ │ │
│ │ │
│ └── 変更をキューに追加(まだ適用しない) │
│ │
│ pendingChanges = { │
│ toRemove: previousItem, │
│ toAdd: newItem │
│ } │
│ │
└─────────────────────────────────────────────────────────┘
ルール7: ラベル付きセクション
7.1 内部はコンパクト、セクション間は間隔あり
問題:
┌─────────────────────────────────────────────────────────┐
│ イテレーションループ中のコレクション変更 │
│ は ConcurrentModificationException を引き起こします │
│ -> ループ終了後に変更を収集して適用 │
└─────────────────────────────────────────────────────────┘
解決策:
┌─────────────────────────────────────────────────────────┐
│ ...コンテンツ... │
└─────────────────────────────────────────────────────────┘
ルール:
- ラベルの後に1行の空行(ボックス前)
- セクション間に2行の空行
- ボックス内のコンテンツはコンパクト(視覚的グループ化を除き内部に空行なし)
ルール8: ボックスコンテンツ行内にツリー文字を配置しない
重大: ツリー文字はGitHubで視覚的ズレを引き起こす
ボックスコンテンツ行内に ├──、└──、│ をツリーコネクタとして混在させないでください。 これらの文字はGitHubのモノスペースフォントで視覚的幅が不均一にレンダリングされ、文字数が一致していても列がズレてしまいます。
間違い(ボックス内のテキストにツリー文字混在)
┌───────────────────────────────────────────┐
│ Server (localhost:8899) │
│ ├── Qwen3.5-4B-MLX-8bit │
│ ├── TurboQuant KV cache │
│ └── Tool calling │
└───────────────────────────────────────────┘
正しい(ネストされたボックスと区切り記号)
┌───────────────────────────────────────────┐
│ ┌───────────────────────────────────┐ │
│ │ Server (localhost:8899) │ │
│ │ Qwen3.5-4B-MLX-8bit │ │
│ │ TurboQuant KV cache │ │
│ │ Tool calling │ │
│ └───────────────────────────────────┘ │
└───────────────────────────────────────────┘
正しい(プレーンなインデントテキスト、ツリー文字なし)
┌───────────────────────────────────────────┐
│ Server (localhost:8899) │
│ Qwen3.5-4B-MLX-8bit │
│ TurboQuant KV cache │
│ Tool calling │
└───────────────────────────────────────────┘
正しい(箇条書きリスト)
┌───────────────────────────────────────────┐
│ Server (localhost:8899) │
│ - Qwen3.5-4B-MLX-8bit │
│ - TurboQuant KV cache │
│ - Tool calling │
└───────────────────────────────────────────┘
例外: ツリー文字は │...│ ボックス境界内にない独立したツリー(ルール3)内で問題ありません。また、ツリーコネクタが独自の行にあり、説明的テキストと混在していない場合、ルール6.2(ツリー内蔵の情報ボックス)でも問題ありません。
ルール9: 文字数検証(必須Bashチェック)
重大: すべてのボックスをBashで検証
任意のボックスダイアグラムを生成した後、ユーザーに提示する前に、以下の検証コマンドを実行する必要があります。 視覚的カウントに依存しないでください — LLMは文字数を一貫して誤カウントします。代わりに実際のツールを使用してください。
ステップ1: ダイアグラムを通常通り生成
ルール1〜8に従い、通常通りダイアグラムを作成します。
ステップ2: 実際の文字数で検証(バイト数ではなく)
重大: 実Unicode文字をカウントし、バイト数ではないカウント方法を使用する必要があります。─ │ ┌ ┐ └ ┘ ├ ┤ ──▶ ◀── などのUnicode文字は複数バイトですが、視覚的には1列です。バイト数でカウントすると誤ったズレが生じ、正しく配列されたボックスが壊れてしまいます。
これらを使用しないでください (バイト数をカウント):
wc -c— バイト数をカウントawk '{print length}'— ほとんどのシステムでバイト数をカウント${#var}(bash、LC_ALL=en_US.UTF-8とロケール対応ツール無しの場合)
以下のいずれかを使用してください (実文字数カウント):
オプションA — wc -m (bash、最もシンプル):
echo '┌─────────────────────────┐
│ your content here │
│ more content │
└─────────────────────────┘' | while IFS= read -r line; do printf "%d: %s\n" "$(echo -n "$line" | wc -m)" "$line"; done
オプションB — Python(最も信頼性が高い、確実な場合に使用):
python3 -c "
import sys
for ln in sys.stdin:
ln = ln.rstrip('\n')
print(f'{len(ln):3d}: {ln}')
" <<'EOF'
┌─────────────────────────┐
│ your content here │
│ more content │
└─────────────────────────┘
EOF
またはファイル範囲で直接:
python3 -c "
with open('/path/to/file.md') as f:
for i, ln in enumerate(f.readlines()[START:END], START+1):
ln = ln.rstrip('\n')
print(f'L{i} chars={len(ln):3d} |{ln}|')"
ボックスのすべての行は、同じ数値 を示す必要があります。出力例:
27: ┌─────────────────────────┐
27: │ your content here │
27: │ more content │
27: └─────────────────────────┘
ステップ3: 数値が異なる場合は修正
行ごとに異なるカウントが表示される場合:
27: ┌─────────────────────────┐
27: │ your content here │
28: │ more content │ ← 28 ≠ 27, 余分なスペース
27: └─────────────────────────┘
- 右の
│前のスペースを追加または削除してターゲット幅に合わせます - 検証コマンドを再実行
- すべての行が同じ数値を示すまで繰り返します
注記
- 実文字数をカウントしてください。バイト数ではありません。
wc -c、awk '{print length}'、${#var}(適切なロケール無し)はバイト数をカウントし、Unicodeダイアグラムで誤った結果を与えます。 wc -m(bash)またはlen()(Python)を使用 — どちらもUnicode文字を正しくカウントします。█ ░ ▒ ▓ ─ │ ┌ ┐ └ ┘ ├ ┤ ┬ ┴ ▼ ▲ ◀ ▶のそれぞれは1文字でカウントします。──▶のような複数バイト矢印は3文字(2つの─+ 1つの▶)であり、5または6バイトではありません。- このチェックは1ツール呼び出しを要しますが、すべての再試行ループを排除します。
ルール10: 文字リファレンス
ボックス描画 — 常にUnicodeボックス描画文字を使用
ボックス境界に +、-、| を使用しないでください。 常にUnicodeボックス描画を使用してください:
コーナー: ┌ ┐ └ ┘
線: ─ │
T字接合: ┬ ┴ ├ ┤
交差: ┼
二重: ═ ║ ╔ ╗ ╚ ╝ ╠ ╣ ╦ ╩ ╬
例:
┌───────────────────────┐
│ ここにコンテンツ │
├───────────────────────┤
│ さらにコンテンツ │
└───────────────────────┘
シェードブロック(グリッド、ヒートマップ、カバレッジダイアグラム用)
░ = 薄いシェード(部分的、セカンダリ)
▒ = 中程度のシェード
▓ = 濃いシェード
█ = 全ブロック(ソリッド、プライマリ)
= 空き(スペース)
矢印
下: ▼ (またはテキストフロー内で v)
上: ▲ (またはテキストフロー内で ^)
左: ◀ (または <)
右: ▶ (または >)
フロー: → ← (テキスト内)
ブランチ: ──▶── (水平コネクタ)
箇条書きと記号
箇条書き: - *
チェック: [x] [ ]
クイックリファレンス
下線付きタイトル
____________________
1. ステップ1
2. ステップ2:
│
├── サブステップA
│
└── サブステップB
┌───────────────────────┐
│ │
│ ボックスコンテンツ │
│ さらにコンテンツ │
│ │
└───────────────────────┘
┌────────┬──────────────┐
│ ラベル │ コンテンツ │
└────────┴──────────────┘
│
│
▼
┌───────────────────────┐
│ 次のステップ │
└───────────────────────┘
│
│ ◀──────────┐ (戻り線)
│
▼
ライセンス: MIT(寛容ライセンスのため全文を引用しています) · 原本リポジトリ
詳細情報
- 作者
- microbians
- リポジトリ
- microbians/AI.SKILLS
- ライセンス
- MIT
- 最終更新
- 2026/5/8
Source: https://github.com/microbians/AI.SKILLS / ライセンス: MIT
関連スキル
nature-response
Nature系ジャーナルの原稿修正に対する査読者への回答文について、下書き、チェック、または修正を行うことができます。査読者からのコメント、編集者の決定文、修正指示、回答案の作成、または大幅修正・軽微修正の対応方法に関するご相談があれば、対応いたします。査読報告書や回答文作成のサポートが必要な場合にご利用ください。
microsoft-docs
公式のMicrosoft文書を参照して、Azure、.NET、Agent Framework、Aspire、VS Code、GitHubなど様々な分野の概念、チュートリアル、コード例を検索します。デフォルトではMicrosoft Learn MCPを使用し、learn.microsoft.com外のコンテンツについてはContext7およびAspire MCPを使用します。
API Documentation Lookup
このスキルは、ユーザーが「Effect APIを調べる」「Effectドキュメントを確認する」「Effect関数のシグネチャを探す」「Effect.Xは何をするのか」「Effect.Xの使い方」「Effect APIリファレンス」「Effectドキュメントを取得する」といった質問をした場合や、公式のEffect-TS APIドキュメントから特定の関数シグネチャ、パラメータ、使用例を調べる必要がある場合に使用します。
knowledge-base
このスキルは、ヘルプセンターのアーキテクチャ設計、サポート記事の執筆、検索とセルフサービスの最適化が必要な場合に活用できます。ナレッジベース、ヘルプセンター、サポート記事、セルフサービス、記事テンプレート、検索最適化、コンテンツ分類、ヘルプドキュメントの設計・管理に関するあらゆるタスクで動作します。
markdown
GitHub Flavored Markdown標準に従ったMarkdownファイルのフォーマットと検証ができます。自動的なlinting処理と手動による意味的なレビューを組み合わせることで、ファイルの品質を確保します。
claude-md-enhancer
CLAUDE.mdファイルをプロジェクトタイプに合わせて分析・生成・改善します。ベストプラクティス、モジュール設計対応、技術スタックのカスタマイズに対応しています。新規プロジェクトの立ち上げ、既存のCLAUDE.mdファイルの改善、またはAI支援開発の標準化を図る際にご活用ください。