agentic-rules-writer

エージェントルール作成ツール

あらゆる AI コーディングエージェント向けに、用途に合わせたルールファイルまたは指示ファイルを生成します。このスキルは対話形式の質問を行い、using-ecosystem メタスキルからインストール済みスキルとエージェントの一覧を受け取り、選択されたエージェントと適用範囲に必要な形式および場所で出力を書き込みます。

使用する場面

• AI コーディングエージェントを初めてセットアップするとき
• 開発者が一貫した動作を得られるよう、チーム共有のプロジェクトルールを作成するとき
• プロジェクトに個人用の開発ルールを追加するとき（gitignore 対象）
• 新しいスキルをインストールした後、スキルへの参照をルールファイルに追加するとき

クイックスタート

/agentic-rules-writer claude
/agentic-rules-writer cursor
/agentic-rules-writer codex
/agentic-rules-writer              # asks which agent

---

フェーズ 1：エージェントの選択

$ARGUMENTS が指定されている場合は、以下の表から該当するエージェントを選択します（大文字と小文字は区別せず、部分一致も可。たとえば「wind」または「devin」は Windsurf に、「gemini」または「anti」は Gemini と Antigravity に一致します）。引数がない場合、または一致するものがない場合は、AskUserQuestion（またはエージェントに相当する対話型プロンプトツール）を使って選択メニューを表示します。

ティア 1：専用の形式とパスによる完全サポート

エージェント	形式に関する注意事項
Claude Code	プレーンな Markdown。ファイルあたり 200 行未満。CLAUDE.md がない場合は AGENTS.md を読み込みます
Cursor	YAML フロントマターが必要です：alwaysApply: true、拡張子は .mdc
Windsurf（現在の Devin Desktop）	プレーンな Markdown。グローバルファイルは 6,000 文字未満、ワークスペースルールファイルは 12,000 文字以下。ワークスペースルールは .devin/rules/ に置き、trigger フロントマターフィールドを指定します
GitHub Copilot	プレーンな Markdown。.github/copilot-instructions.md
Gemini CLI と Antigravity CLI	プレーンな Markdown。2026-06-18 に、無料ユーザーおよび Google AI Pro と Ultra のユーザー向けに Antigravity CLI が Gemini CLI に置き換わりました
Roo Code	プレーンな Markdown
Amp	Claude Code と同じ形式
Codex (OpenAI)	プレーンな Markdown。AGENTS.md を使用し、合計サイズの上限は 32 KiB です
Cline	プレーンな Markdown
OpenCode	プレーンな Markdown
Continue	プレーンな Markdown
Trae	プレーンな Markdown

ティア 2：汎用 Markdown 形式でサポート

エージェント	形式に関する注意事項
Goose	プレーンな Markdown
Augment	プレーンな Markdown
Kilo Code	プレーンな Markdown

その他／汎用

一覧にないエージェントの場合は、ユーザー指定のパスにプレーンな Markdown を書き込みます。出力パスをユーザーに尋ねてください。

各エージェントの形式、パス、制限、テスト方法については、references/agent-targets.md を参照してください。

---

フェーズ 2：適用範囲の選択

ルールを生成する適用範囲を、選択メニュー（AskUserQuestion またはエージェントに相当する対話型プロンプトツール）を使ってユーザーに尋ねます。

適用範囲	説明	代表的なパス（Claude Code の例）
グローバル	すべてのプロジェクトに適用されるユーザーレベルのルール。個人のワークフロー設定です。	~/.claude/CLAUDE.md
プロジェクト（チーム共有）	リポジトリにコミットします。チーム全体が従う共通の規約です。	.claude/rules/team-rules.md
プロジェクト（開発者固有）	この開発者のローカル環境に適用し、gitignore 対象とします。チームルールに個人の設定を重ねます。	.claude/rules/dev-rules.md

各エージェントと適用範囲の組み合わせに応じた正確なパスについては、references/agent-targets.md を参照してください。

対象のファイルがすでに存在する場合は、ユーザーに尋ねる選択メニューを表示します。

1. 上書き：ファイル全体を生成した内容に置き換えます
2. マージ：既存の内容の下に、--- で区切って生成した内容を追加します
3. 中止：キャンセルし、ファイルを変更せずに残します

---

フェーズ 3：ワークフローに関する質問

質問は必ず構造化された対話型メニューで提示し、通常のテキストだけで尋ねてはいけません。AskUserQuestion が利用できる場合はそれを使います。利用できない場合は、エージェントの CLI に相当する対話型プロンプトツールを使います。ユーザーが大量のテキストを読み解いて回答を入力するのではなく、一覧から選べるようにしてください。ツールが対応している場合は、互いに独立した質問を最大 4 つまでまとめて提示します。質問の選択肢が 4 つを超える場合は、よく選ばれる 4 つを提示し、残りは「その他」または自由記述で受け付けます。

次の質問を提示する前に、ユーザーの回答を待ってください。

スコープマトリックス

スコープによって、質問する項目が決まります。

#	質問	グループ	全体	チーム共通	開発者固有
Q1	主要な技術スタック	A：プロジェクトのコンテキスト	はい	はい	スキップ
Q2	ディレクトリ構成	A：プロジェクトのコンテキスト	はい	はい	スキップ
Q3	ビルド／実行コマンド	A：プロジェクトのコンテキスト	はい	はい	スキップ
Q4	コード品質の基準	B：コード規約	はい	はい	スキップ
Q5	テストに関する方針	B：コード規約	はい	はい	スキップ
Q6	エラー処理	B：コード規約	はい	はい	スキップ
Q7	セキュリティとシークレット	B：コード規約	はい	はい	スキップ
Q8	依存関係の管理	B：コード規約	はい	はい	スキップ
Q9	ブランチ規約	C：バージョン管理	はい	はい	スキップ
Q10	コミット規約	C：バージョン管理	はい	はい	スキップ
Q11	PR／MR の作成	C：バージョン管理	はい	はい	スキップ
Q12	計画の進め方	D：エージェントのワークフロー	はい	スキップ	はい
Q13	自律性のレベル	D：エージェントのワークフロー	はい	スキップ	はい
Q14	境界（決して行わないこと）	D：エージェントのワークフロー	はい	スキップ	はい
Q15	エージェントの並列化	D：エージェントのワークフロー	はい	スキップ	はい
Q16	タスクの追跡	D：エージェントのワークフロー	はい	スキップ	はい
Q17	自己改善	D：エージェントのワークフロー	はい	スキップ	はい
Q18	コミュニケーションのスタイル	E：コミュニケーション	はい	スキップ	はい
Q19	ペルソナ／ロールプレイ	E：コミュニケーション	はい	スキップ	はい
Q20	その他のコメント	F：自由記述	はい	はい	はい

チーム共通ルールでは、チーム全体で合意する技術基準（技術スタック、ディレクトリ構成、コマンド、品質、テスト、エラー処理、セキュリティ、依存関係、ブランチ、コミット、PR）を扱います。開発者固有ルールでは、個人のワークフローに関する好み（計画の進め方、自律性、境界、並列化、タスクの追跡、自己改善、コミュニケーションのスタイル、ペルソナ）を扱います。全体にはすべてが含まれます。

説明、選択肢の対応関係、出力例を含む質問のリファレンスについては、references/questionnaire.md を参照してください。

推奨されるバッチ分け

全体スコープ（全20問）の場合は、次のようにバッチ分けします。

• バッチ1（グループA）：Q1（技術スタック）、Q2（ディレクトリ）、Q3（コマンド、自由記述）
• バッチ2（グループB、その1）：Q4（品質）、Q5（テスト）、Q6（エラー処理）、Q7（セキュリティ）
• バッチ2a（追加質問）：Q4 ドキュメントに関する追加質問
• バッチ3（グループB+C）：Q8（依存関係）、Q9（ブランチ）、Q10（コミット）、Q11（PR）
• バッチ3a（追加質問）：Q10 共著者に関する追加質問
• バッチ4（グループD、その1）：Q12（計画）、Q13（自律性）、Q14（境界）、Q15（並列化）
• バッチ5（グループD+E）：Q16（タスクの追跡）、Q17（自己改善）、Q18（コミュニケーション）、Q19（ペルソナ）
• バッチ5a（追加質問）：Q16 外部ツールに関する追加質問
• 最後：Q20（その他のコメント、自由記述）

ほかのスコープでは、スコープマトリックスで「スキップ」とされている質問を除くように、バッチを調整します。

質問の参照先

質問する前に、references/questionnaire.mdを読んでください。各質問には、正確な質問文、目的、選択肢の表、各回答によって生成されるルールが記載されています。各メニューは、それらの選択肢の表に基づいて作成してください。

単一のメニュー選択だけでは回答できない質問：

質問	対応
Q1 主要なスタック	関連性が最も高い4つのスタック（PHP+Symfony、TypeScript+React、Python+Django、Go、Rust、Java+Spring）を提示します。「その他」は自動的に追加されます。「その他」が選ばれた場合は、ユーザーに内容を指定してもらいます
Q3 ビルド／実行コマンド	自由記述です。空欄でもかまいません。## Commandsセクションに一字一句そのまま含め、空欄の場合はセクションを省略します
Q4 コード品質の基準	追加質問：ドキュメントのレベル
Q10 コミット規約	追加質問：エージェントを共著者として追加するか
Q14 境界	「カスタム」の場合は、絶対に行わないことのリストをユーザーに尋ね、NEVERを前置きして含めます
Q16 タスク管理	追加質問：外部ツール（Jira、Linear、GitHub Issues、なし）。いずれかが選択された場合は、それを参照するルールを生成します
Q19 ペルソナ	「はい」の場合は、ユーザーにペルソナを説明してもらいます（入力は自由形式）。珍しいペルソナの場合はウェブ検索を使用します。1段落の説明、5～8個の決め台詞、そして「正確さを常に優先し、ペルソナは内容ではなく表現である」という厳守事項を生成します（回答ごとに決め台詞は最大1つまで使用し、連続して同じ決め台詞を使わないでください）
Q20 追加コメント	自由記述です。ユーザーが回答を省略しない場合は、最後に## Additional Rulesセクションを作成し、一字一句そのまま含めます。ユーザーが回答を省略した場合は、セクションを省略します

---

フェーズ4：エコシステムの調査

実行時に、インストール済みのスキル、エージェント、チームをスキャンします。ハードコードされた一覧に依存しないでください。

スキャン手順

プラットフォーム標準の場所を使って、インストール済みのスキル、エージェント、チームをスキャンします。AI コーディングツールごとに、スキルの保存場所は異なります。フェーズ1で選択したエージェントのユーザーレベルとプロジェクトレベルのディレクトリを確認してください。

SKILL.mdファイル（スキル）、*.md形式のエージェント定義、*.md形式のチーム定義をスキャンする一般的な場所：

• ユーザーレベルのスキル／エージェント／チームのディレクトリ（プラットフォームによって異なります）
• プロジェクトレベルの.{agent}/skills/、.{agent}/agents/、.{agent}/teams/
• プラグインキャッシュディレクトリ（プラットフォームがプラグインシステムを使用している場合）

using-ecosystemスキルがインストールされている場合は、呼び出してください。このスキルは、プラットフォームに対応した検出コマンドを提供します。

見つかった各ファイルについて、YAML フロントマター（name、description）を読み取り、次のルールセクションを作成します。

1. スキルセクション：インストール済みのスキルごとに1つの箇条書きを作成します。[description]に該当する場合 -> /skill-nameを使用
2. カスタムエージェントセクション：能力の概要（読み取り専用かワークツリーか、専門特化型か役割型か）を含むエージェント
3. エージェント役割セクション：担当分野を持つ役割エージェント
4. チームセクション：リーダーと用途を含む、あらかじめ構成されたチーム

AI コーディングエージェント自体が、スキルを見つけるための主要な手段です。スキルのフロントマター（name、description）を読み取り、いつ各スキルを有効化するかを判断します。using-ecosystemスキルは、どのスキルやエージェントが適切かエージェント自身で判断できない場合に役立つ、補助的なアドバイザーです。インストールされている場合は、マッチングのヒューリスティックと連携パターンを提供します。

並列化の追加項目

Q15で「常に並列化」または「大規模なタスクでは並列化」を選択した場合は、この行をカスタムエージェントセクションに追加します。

When delegating to agent teams, prefer using custom agents over general-purpose when a matching agent exists.

---

フェーズ5：組み立てて書き込む

質問票の回答からルールファイルの内容を生成します。構成は対象範囲によって異なります。

出力を小さく保つ

指示ファイルは毎回読み込まれ、長いファイルほど遵守されにくくなります。リポジトリのコンテキストファイルに関する調査では、生成ファイルも手書きファイルも、一般にタスクの成功率を高めず、推論コストが20％以上増加する一方、具体的な指示はよく守られていました。context-engineering スキルがインストールされている場合は適用してください。要点は次のとおりです。

• すべての行は、その記述がなければエージェントが起こす間違いを防ぐものでなければなりません。エージェントがそのまま従う行や、リンターまたはフォーマッターで強制される内容は削除してください。
• エージェント自身が確認できるリポジトリ概要、ディレクトリツリー、技術スタックの一覧は追加しないでください。コマンド、わかりにくい規約、厳格な禁止事項には記載する価値があります。
• 以下のテンプレートにある汎用ブロック（Core Principles、Code Change Hygiene、Don't Guess、Knowledge Sources）は任意として扱ってください。末尾に配置し、ファイルが予算に近づいたら最初に削除してください。
• Claude Code：ファイルごとに約200行未満にしてください。@path によるインポートはファイルを整理できますが、コストは削減されません。リポジトリの一部にのみ適用される重要なルールは、パスを対象にしたルール（.claude/rules/*.md に paths: のフロントマターを付けたもの）に移してください。一致するファイルを編集するときだけ読み込まれます。他のツールにも同様のスコープ指定機能があります（Cursor の .cursor/rules、Copilot の .github/instructions、glob トリガーを使う Devin の .devin/rules）。
• 毎回必ず守る必要があるルールは、このファイルではなくフック、リンター、またはテストに設定してください。
• コンパクション後も保持する必要があるルールは、常時読み込まれるファイルに残してください。
• 対象ツールの予算を agent-targets で確認し、Phase 6 でサイズを報告してください。
• 既存の指示ファイルについて、サイズ、矛盾、古いルール、シークレット、不可視の Unicode を監査するには、instruction-auditor エージェントを案内してください。

グローバルスコープの構成

# Global Rules

## Commands
[Build/run commands from Q3, only if provided; omit section if blank]

## Code Quality
[Quality bar from Q4 + documentation follow-up]
[Stack conventions from Q1]
[Directory structure from Q2]
[Error handling from Q6]
[Elegance check: "For non-trivial changes, pause and ask: is there a more elegant way?"]

## Testing
[Testing rules from Q5]

## Security
[Security practices from Q7]
[Dependency management from Q8]

## Version Control
[Branch rules from Q9]
[Commit rules from Q10 + co-authorship follow-up]
[PR creation from Q11]

## Workflow
[Planning rules from Q12]
[Autonomy rules from Q13]
[Boundaries from Q14]
[Parallelization rules from Q15]
[Re-plan rule: "If an approach fails or hits unexpected complexity, stop and re-plan immediately"]

## Communication
[Communication style from Q18]

## Task Management
[Tracking from Q16 + external tool follow-up]
[Self-improvement from Q17]

## Core Principles
- Simplicity first: make every change as simple as possible
- Root causes only: no temporary fixes, find and fix the real problem
- Minimal blast radius: touch only what's necessary
- Prove it works: never mark done without verification

## Code Change Hygiene
- Read before editing: always read and understand existing code before modifying it
- Minimal diffs: make the smallest change that solves the problem, no drive-by cleanups
- Follow existing patterns: match the codebase's style, naming, and structure
- One task at a time: complete the requested task, don't fix unrelated issues or "improve" adjacent code
- Prefer editing over creating: always prefer modifying an existing file over creating a new one
- Search before creating: before creating a new file, search for an existing one that serves a similar purpose
- Never create documentation files unless explicitly asked
- No premature abstractions: don't introduce interfaces, base classes, or design patterns unless the current task demands them
- No backwards-compatibility shims: when replacing code, remove the old version entirely
- Remove dead code: don't leave commented-out code, unused imports, or orphaned functions

## Don't Guess
- Don't fabricate URLs, file paths, API endpoints, or names. Search or ask if unsure
- Don't assume unstated requirements: implement only what was requested
- Don't assume project architecture: explore and verify before making decisions
- Ask when stuck: a clarifying question is cheaper than a wrong implementation
- If an approach fails or hits unexpected complexity, stop and re-plan immediately

## Safety Baseline
- Never commit secrets, .env files, API keys, or credentials to version control
- Never force push to main/master
- Never delete branches without explicit approval
- Never modify CI/CD pipelines without explicit approval

## Knowledge Sources
- When a topic is covered by an installed skill, use the skill first. It contains curated, verified content
- When a topic is NOT covered by installed skills, search the web for the official documentation of the technology (e.g., symfony.com for Symfony, php.net for PHP, react.dev for React)
- Prefer official docs over blog posts, Stack Overflow, or AI-generated summaries. Official sources are the most accurate and current
- When recommending MCPs, skills, or packages to install, always prefer official providers (e.g., Anthropic, Vercel, framework authors) over community alternatives
- When no official option exists, prefer well-maintained community options with high adoption and recent activity

## Skills

CRITICAL: When a situation matches an installed skill, you MUST use it. Do not rely on general knowledge when a dedicated skill exists. Skills contain curated reference material that is more precise than answers generated from scratch. Skipping a relevant skill is like ignoring documentation you already have open.

[Auto-generated from Phase 4 runtime scan. One line per installed skill.]
When [trigger from description] -> use /skill-name
...

## Custom Agents
[If specialist agents are found during Phase 4 scan, list them with descriptions and capabilities. If none found, omit this section entirely.]

## Agent Roles
[If role agents are installed (per Phase 4), list them here with the domain they own. If none, omit this section entirely.]

## Persona
[If Q19 = Yes: persona description, catchphrases, and constraint. If No, omit this section entirely.]

## Recommended (not installed)
- Install [skill] from krzysztofsurdy/code-virtuoso: [what it helps with]

プロジェクト共通の構成

# Project Rules

## Commands
[Build/run commands from Q3, only if provided]

## Stack & Conventions
[Stack conventions from Q1]
[Quality bar from Q4 + documentation follow-up]
[Directory structure from Q2]
[Error handling from Q6]

## Testing
[Testing rules from Q5]

## Security
[Security practices from Q7]
[Dependency management from Q8]

## Version Control
[Branch rules from Q9]
[Commit rules from Q10 + co-authorship follow-up]
[PR creation from Q11]

## Core Principles
- Simplicity first: make every change as simple as possible
- Root causes only: no temporary fixes, find and fix the real problem
- Minimal blast radius: touch only what's necessary
- Prove it works: never mark done without verification

## Code Change Hygiene
- Read before editing: always read and understand existing code before modifying it
- Minimal diffs: make the smallest change that solves the problem, no drive-by cleanups
- Follow existing patterns: match the codebase's style, naming, and structure
- One task at a time: complete the requested task, don't fix unrelated issues or "improve" adjacent code
- Prefer editing over creating: always prefer modifying an existing file over creating a new one
- Search before creating: before creating a new file, search for an existing one that serves a similar purpose
- Never create documentation files unless explicitly asked
- No premature abstractions: don't introduce interfaces, base classes, or design patterns unless the current task demands them
- No backwards-compatibility shims: when replacing code, remove the old version entirely
- Remove dead code: don't leave commented-out code, unused imports, or orphaned functions

## Don't Guess
- Don't fabricate URLs, file paths, API endpoints, or names. Search or ask if unsure
- Don't assume unstated requirements: implement only what was requested
- Don't assume project architecture: explore and verify before making decisions
- Ask when stuck: a clarifying question is cheaper than a wrong implementation

## Safety Baseline
- Never commit secrets, .env files, API keys, or credentials to version control
- Never force push to main/master
- Never delete branches without explicit approval
- Never modify CI/CD pipelines without explicit approval

## Knowledge Sources
- When a topic is covered by an installed skill, use the skill first. It contains curated, verified content
- When a topic is NOT covered by installed skills, search the web for the official documentation of the technology
- Prefer official docs over blog posts, Stack Overflow, or AI-generated summaries
- When recommending MCPs, skills, or packages to install, always prefer official providers over community alternatives
- When no official option exists, prefer well-maintained community options with high adoption and recent activity

プロジェクト固有の構成

# Dev Rules

## Workflow
[Planning rules from Q12]
[Autonomy rules from Q13]
[Boundaries from Q14]
[Parallelization rules from Q15]

## Communication
[Communication style from Q18]

## Task Management
[Tracking from Q16 + external tool follow-up]
[Self-improvement from Q17]

## Persona
[If Q19 = Yes: persona description, catchphrases, and constraint. If No, omit.]

エージェント固有の形式

書き込む前に、次の変換を適用してください。

Cursor：コンテンツ全体を YAML フロントマターで囲みます。

---
alwaysApply: true
---

[content here]

Windsurf（Devin Desktop）：文字数を確認してください。グローバルファイルの上限は6,000文字、各ワークスペースルールファイルの上限は12,000文字です。上限を超える場合は、セクションを簡潔にして（例を削除し、説明を短くして）上限未満にしてください。ワークスペースルールファイルは、フロントマター trigger: always_on で始めます。グローバルファイルとルートの AGENTS.md にはフロントマターを付けません。

Antigravity CLI：AGENTS.md と GEMINI.md にはフロントマターを付けません。.agents/rules/ 内のファイルは、trigger（これらのルールでは always_on）を宣言するフロントマターで始める必要があります。そうしないと Antigravity に破棄されます。24 KB を超えるルールファイルは切り詰められます。

Claude Code / Amp（グローバル）：200行未満にしてください。末尾に次の注記を追加します：プロジェクト固有のルールには、.claude/rules/*.md ファイルを使用してください。

Claude Code（プロジェクト）：リポジトリにすでに AGENTS.md があり、CLAUDE.md がない場合、Claude Code は AGENTS.md をそのまま読み込みます。CLAUDE.md または CLAUDE.local.md を追加すると、CLAUDE.md ファイルのみを読み込むようになります。そのため、新しい CLAUDE.md からは @AGENTS.md をインポートしてください。

Codex：プロジェクトルートでは AGENTS.md のファイル名規則を使用してください。Codex は、読み込むファイルの合計が32 KiBに達すると、それ以上のファイルを追加しません。

その他すべて：プレーンな Markdown のまま書き込みます。

ルール生成の例

各回答は、2～5個の短いルール箇条書きに対応します。references/questionnaire.md には、全20問のすべての回答に対して生成されるルールと、ペルソナ出力の完全な例（海賊船長、不機嫌なシニアエンジニア）が記載されています。上記のセクションを組み立てる際に読み込み、文言を独自に考えるのではなく、そこから箇条書きを使用してください。

フェーズ 6：確認

ファイルを書き込んだ後、次の操作を行います。

1. 生成した全文をユーザーに表示します
2. 書き込んだファイルパスを示します
3. 行数と文字数を示します
4. エージェント固有の制限（Windsurf の文字数制限、Claude の行数制限など）を適用した場合は、簡略化した内容を説明します
5. ファイルがツールの予算に対してどの程度のサイズかを伝え、後で監査するために instruction-auditor エージェントを提案します
6. 次のように尋ねます。「完了する前に、何か編集しますか？」

---

エラー処理

• 出力先ディレクトリが存在しない場合は、作成します
• ユーザーが質問への回答中に中止した場合は、すべての作業を破棄し、部分的なファイルを書き込みません
• Phase 4 で、インストール済みの code-virtuoso プラグインがないとユーザーが報告した場合は、Skills、Custom Agents、Agent Roles のセクションをすべて省略し、tool-using-ecosystem と agents-virtuoso を最初にインストールする候補として示す短い「推奨（未インストール）」リストを含めます
• using-ecosystem がインストールされていない場合は、エコシステムの一覧を捏造せず、ユーザーに利用中のものを尋ねます
• プロジェクトのスコープでは、書き込む前に Git リポジトリ内にいることを確認します

---

参照ファイル

参照	内容
agent-targets	各エージェントとスコープの出力パス、形式要件、制限、テスト手順（Phase 1、2、5）
questionnaire	Q1〜Q20 の質問文、選択肢の表、回答とルールの対応、ペルソナの例（Phase 3、5）