skill-update

スキルの更新

Anthropic のベストプラクティスに従って、Claude Code のスキルを作成または改善します。

上限（scripts/skill_linter.py による強制）

• SKILL.md は 150 行以下
• reference/*.md は 200 行以下（reference/scenarios/*.md は 400 行以下）
• README.md は 100 行以下
• すべての SKILL.md に、name と description を含む YAML フロントマターがあること
• ## Anti-Patterns セクション以外では、DO NOT／MUST NOT／NEVER を使わないこと
• チャレンジ固有の識別子（マシン名、ラボ ID、ラボ IP、保持されたフラグ）がないこと
• すべての Markdown リンクが既存のファイルを参照していること
• すべてのリファレンスファイルが、少なくとも 1 つの他のファイルからリンクされていること（孤立ファイルがないこと）

原則

• 簡潔さを最優先。 すべてのファイルを短く、シンプルで、読みやすくします。あらゆるトークンの必要性を検討します。
• 段階的な開示。 SKILL.md は案内役です。詳細は reference/ に、具体的なエクスプロイトの手順は reference/scenarios/ に記載します。
• 関心の分離。 SKILL.md = 何をするか、いつ行うか。reference/role-*.md = エージェント起動時の振る舞い方。
• 横断的なルール（出力規律、認証情報の読み込み、ブルートフォースなど）は、それぞれ単一の正規の配置先に記載します。他のファイルでは再記述せず、参照します。

ファイル構成

skills/<skill-name>/
├── SKILL.md           # ≤150 lines, YAML + navigation
├── reference/
│   ├── *-principles.md  # ≤150 lines (decision tree)
│   ├── INDEX.md
│   ├── *.md             # patterns, ≤200 lines
│   └── scenarios/
│       └── <category>/
│           └── *.md     # ≤400 lines, self-contained
└── README.md          # optional, ≤100 lines

SKILL.md のテンプレート

---
name: <skill-name>
description: What it does AND when to use. Include trigger phrases.
---

# <Skill Name>

<one-paragraph scope>

## When to use

- <bullet>

## Workflow / Quick start

<≤30 lines>

## References

- [reference/...](reference/...)

## Anti-Patterns

- <when negative framing is genuinely needed, put it here>

実行方法

この手順はワークフローであり、各ステップはコードによって強制されるため、省略できません。

Workflow('skill-update', { output_dir: 'projects/<engagement>' })   // harvest an engagement
Workflow('skill-update', { learnings: [{ text, technique_type }] }) // judge a known set
Workflow('skill-update', { mode: 'audit' })                         // read-only, writes nothing

書き込みを行わずに書き込み計画を確認するには、dryRun: true を追加します。親オーケストレーター専用です。

フェーズ。 受付（ベースラインの skill_linter.py --json）→ 収集（学びを再構成）→ 判定（4 つのゲート＋ブラインド反証）→ 振り分け（ブロックを作成）→ 書き込み（そのまま保存）→ 精査（機密性ガード）→ 検証（絶対的なクリーンツリーではなく、リンターの差分を確認。ベースには既存の違反が含まれています）。

すべての昇格／却下／書き込みの判断は、.claude/workflows/lib/wf-helpers.mjs の純粋な JS 関数（promotionGate、capBudget、writeGate、lintDelta、skillUpdateGate）で行います。学びを昇格させるか、書き込みを許可するかをエージェントが判断することはありません。

4 つのゲートによる昇格テスト

完了したエンゲージメントから、テクニックと失敗パターンを処理します。以下の 4 つすべてを満たす場合に限り、学びをスキルベースに昇格させます。

1. 汎用性がある。 ターゲット固有の知識ではなく、再利用可能なパターンであること。マシン名、ラボ ID、ターゲット IP、保持されたフラグ、レポートの帰属情報を含めないでください。
2. 実質的な改善になる。 今後のエンゲージメントに向けて、網羅性、効率性、または判断の質が向上すること。
3. 他の場所に記載されていない。 スキルベース内の他の場所ですでに記載されていないこと（重複は scripts/skill_linter.py が検出します）。
4. 最小限の追加にとどめる。 新しいファイルを追加するより、既存の項目を拡張します。ベースは簡潔で、重要な情報だけに絞ります。

再構成の手順

常に再利用可能なパターンとして記述します。「X の条件に遭遇したら、Y の方法を試す」のようにし、「box-N では Y が有効だった」のようには記述しません。ツールの例では <TARGET_IP>、<DC_FQDN>、<DOMAIN> のプレースホルダーを使います。

出力

実行で行っていない編集を行ったと主張できないよう、3 つの分類をコードで構築します。 更新済み。／スキップ。（失敗したゲートを併記）／変更なし。

リファレンス

• STRUCTURE.md — ディレクトリレイアウトの要件。
• FRONTMATTER.md — YAML のルール。
• CONTENT.md — 執筆ガイドライン。
• ROUTING.md — テクニックの種類から対象ファイルへの振り分け。

アンチパターン

• CHANGELOG.md／SUMMARY.md／VERIFICATION.md などの補助ファイルを作成する。
• スキル自体に、作成プロセスに関するメタドキュメントを記載する。
• 詳細なインラインテンプレートや例を記載する（代わりに reference/ にリンクする）。
• 重複するルールの説明（ブルートフォース、出力ディレクトリ、環境変数リーダー）を再導入する。
• 上限を超えるファイルを放置する。直ちに reference/ に分割する。