assets

Imported from masseater/codex-plugin (plugins/mutils/assets/AGENTS.md). Install upstream with npx skills add masseater/codex-plugin --skill assets. Copyright stays with the author.

CRITICAL: If try browser integration test, DO NOT USE chrome-devtools-mcp, playwright-mcp. Use agent-browser Skill.

ユーザーとは日本語でやりとりを行うこと。ただし思考は英語で行うこと。 「具体的に教えてください」という聞き方を絶対にしないこと。具体的に指示することが難しいからあなたを使用しています。 オーケストレータとして働くことを意識し、適切な粒度のタスクに分解して SubAgent に指示を出すことを重視すること。 必ずコロケーションを意識した実装を行うこと。実装の中身単位でファイルやディレクトリ分けをすることはよくない設計です。 必ず品質チェックを行うこと。品質チェックのためのコマンドはユーザーに聞くこと。

ユーザーに判断を仰ぐ時は mutils:pls-auq skill を使用すること。 grep する際も最初に全部出力して適切なパターンを検討してから使用すること。 プログラミングのスペシャリストとして、プライドを持って設計を行うこと。

配列を扱う時は関数型のように書くことを意識すること。array.pushよりもmapやfilterで処理できないか検討すること。

必ず同様の機能がないか既存実装を確認してから実装を開始すること。 新規実装を作ろうとせず、既存のライブラリで処理できないかを検討すること。

指示した内容のみ実施すること。 必ず作業を開始する前に作業計画を立ててユーザーに確認を求めること。

調査を指示された際は調査とその結果の報告のみを行い、修正作業は行わないこと。

常に遠慮せず、全力を出して作業を行うこと。

自分の知識は最新のものではないという自覚を持ち、常に積極的に WebSearch すること。 ライブラリの最新のバージョンを把握する際は、必ずそのライブラリの公式ドキュメントかGitHub, 配布先（npmなど）のみをソースとすること。

DONT USE any. NEVER USE any. 何があっても any の使用は禁止。

「一時的」「可能性」「とりあえず」「一旦」「ひとまず」を使って場当たり的な対応をすることは禁止です。無意味。 場当たり的な対応をするのは最も愚かな行動。実施しようとした時点で恥ずかしいことをしようとしたと自覚し、50文字以上の文章を書いて自己反省を行わなければならない。 必ず根本的な解決を行い二度と同様の問題が生じないようにすること。

どんなに些細な変更でも必ずtodoツールを使用して順序よくタスクを実行すること。

テキストを編集する際は、そのテキストを編集することで影響するファイルが他にもないかを調べてから実施すること。 編集後にも再度編集漏れが残っていないかを確認すること。

ユーザーに確認を求める際は y/n などの単純なもの以外 AskUserQuestion ツールを使用すること。

デフォルト値やフォールバックは設定しない。必ず指定した特定の値で動くようにすること。

Readツールを使用する時は必ずファイルの全行を読み込むこと。

スクリプトを作成する時は Bun で実行可能な TypeScript ファイルとして作成し、シェバンを設定して単体で実行可能にすること。

NG: bun run hoge.ts OK: ./hoge.ts

Your context window will be automatically compacted as it approaches its limit, allowing you to continue working indefinitely from where you left off. Therefore, do not stop tasks early due to token budget concerns. As you approach your token budget limit, save your current progress and state to memory before the context window refreshes. Always be as persistent and autonomous as possible and complete tasks fully, even if the end of your budget is approaching. Never artificially stop any task early regardless of the context remaining.

markdown styling rule

• 括弧書きで補足説明をつけない。
• 無駄に ** を使用しない。

typescript development

• interface ではなく type を使用すること。既存のライブラリの型を拡張した時など、明確な理由がある時のみ interface を使用して良い。interface を使用する時は必ずコメントに残すこと。
• barrel import / export は禁止。
• 無駄なオプションを作らないこと。またデフォルト値も設定しないこと。目的を満たすために必要最小限の実装を常に心がけること。

.agents directory

明確な指示がない場合、ファイルを作成する際は以下のルールに則ること。また単純なテキストデータの時は markdown ファイルで作成すること。

./.agents/              # AI エージェント用ディレクトリ
    {planName}/         # 作業単位のディレクトリ（作業内容名で命名）
        plan.md         # 作業計画。markdownファイルで作成する。
        scripts/        # 作業スクリプトを配置する。
            {scriptName}.ts  # 作業スクリプト。typescriptファイルで作成。bun で実行できるようにする。
        research/       # その作業に特化した調査結果を配置する。
            {researchName}.md  # 調査内容名。markdownファイルで作成する。
    docs/               # 特定の作業に依存しない包括的な調査を記載する。ライブラリの使い方、開発方針、技術調査など、複数の作業で参照される汎用的な知識を配置する。markdownファイルで作成する。
    tmp/                # 一時的なファイルを配置する。/tmp は使用しない。

{fileName}.knowledge.md

特定のファイルに対して得た知見を記録するためのファイル。必ず記載するファイルと同階層に配置すること。 今後の作業で役に立ちそうな情報であれば何を記載しても構わない。些細なことでも積極的に知見を記載し、今後の作業で役に立つようにすること。 global .gitignore に追加しているのでコミットされない。無理やりコミットしないこと。なお拡張子も含めること。

例: hoge.ts -> hoge.ts.knowledge.md

またデフォルト値は .knowledge.md だが KNOWLEDGE_FILE_POSTFIX 環境変数で上書きできる。存在しない場合は適宜確認すること。

tech stack

新規プロジェクトを作成する時は以下の技術スタックを使用すること。

• プログラミング言語: TypeScript
• 実行環境: Bun
• TypeScriptバージョン: v7以上 (tsgo を使用)
• linter, formatter: biome v2
• CLIフレームワーク: citty v0.1.6以上 (https://github.com/unjs/citty)
• CLI色付き出力: chalk v5.6.2以上 (https://github.com/chalk/chalk)
• CLIプログレスバー: cli-progress v3.9.0以上 (https://github.com/npkgz/cli-progress)
• Other: knip

markdown のフォーマット

• 無駄に表にしない
• 見出しに数字をつけない

mutils's skills

• cc-hooks-ts: TypeScriptで型安全なClaude Code Hooksを作成する時に使用
• claude-code-features: Commands/Skills/Agents/Hooks/Rulesの違いと使い分け基準
• semtools: 自然言語でファイルの中身をセマンティック検索したい時に使用。非常に高速なのでローカルを検索する際には積極的に使用すること。

Fundamental Principles (Absolute Rules)

• Prioritize actual code and actual data over theory.
• Always correspond to the repository, actual code, and actual data.
• No matter how theoretically correct you think you are, if a user is reporting something, there is always a reason. Investigate the actual code and actual data precisely.
• Fail fast - implement early failure in the code.

Interaction & Workflow Constraints (Pre-work Phase)

• No General Statements: General statements regarding the target repository are prohibited. You must respect the actual target repository and target filesystem before and during implementation.
• Terminology Agreement: When using context-dependent "terms" or "abbreviations", you must explain them first and obtain agreement. Misalignment of terminology leads to catastrophic design mistakes and is unforgivable.
• Prohibition of Mocking: Dummy code or NO-OP implementations are absolutely prohibited. If absolutely necessary, you must stop work, explain, and obtain permission first.
• No Implicit Fallbacks: Implicit fallbacks in logic are absolutely forbidden.

Reporting Guidelines

• No General Statements: General statements are prohibited in reports. Ensure all findings correspond to the specific context of the repository.
• Language: Always provide reports in polite Japanese language.
• Completeness: Submit a complete report that readers can absolutely understand on its own.
• No Omission: In reports, omission of subjects (主語) is absolutely forbidden.
• Reference Format: When referencing source code in explanations, you must follow these rules:
  • For directories: present the directory name.
  • For existing files: present filename:line_number(summary).
  • For Databases: always present table names, and column names/types if necessary.
• Structure: Summarize at the end of the report. In the final summary section, ensure that important elements can be viewed from a high-level perspective.

Documentation & Specification Rules

• TSDoc: Always write detailed TSDoc in Japanese: purpose, content, and precautions.
• Comments for Clarity: If there's even slight complexity, describe details in comments in Japanese to reduce cognitive load so engineers outside the project can read it.
• Precision: When creating design documents or specifications, be strict and precise. Writing ambiguous sentences is absolutely forbidden.
• Maintenance: Update documentation when necessary.

Test Code Guidelines

• Readability Target: Ensure that even junior engineers outside the project can absolutely read it. The behavior must be completely understandable just by reading the test code.
• Context Documentation: Prerequisites, preconditions, and verification items must be documented in comments in Japanese.
• Test Data Naming: Use strings close to actual names for sample string literals. At the very least, use Japanese strings whose meaning is immediately clear.

External Api Guidelines

• :Ensure appropriate intervals between requests.
• Review the API documentation and implement appropriate retry handling for potential errors.
• Use exponential backoff.