AI Coding Agents — 9-Platform Comparison

You are bootstrapping a context file for AI coding agents. Do NOT auto-write it. Do this in three phases.

# PHASE 1 — SCAN (read-only, no edits)

1. List top-level structure: run `ls -la` then `find . -maxdepth 3 -type d -not -path '*/.*' | sort`.
2. Detect stack: read whichever of these exist — package.json, pyproject.toml, requirements.txt, Cargo.toml, go.mod, Gemfile, pom.xml, build.gradle, deno.json, *.csproj.
3. Read existing docs: README*, CONTRIBUTING*, ARCHITECTURE*, docs/index*, .editorconfig.
4. Detect vendor instruction files and per-vendor config already present: CLAUDE.md, AGENTS.md, GEMINI.md, .cursor/rules/*.mdc, .github/copilot-instructions.md, .windsurf/rules/*.md, .clinerules (or .clinerules/ directory), opencode.json.
5. Identify the most-edited files: `git log --since='90 days ago' --pretty=format: --name-only | sort | uniq -c | sort -rn | head -25`.
6. Run `--help` (or read help docs) for any non-obvious tool you find in scripts/Makefile (e.g. `make help`, `bun run`, custom CLI). Do NOT execute build/test commands.

# PHASE 2 — DRAFT (write a draft, NOT the final file)

Produce a draft with EXACTLY these sections, in this order. Keep total under 300 lines; target 60.

**WHAT** — Stack, languages, frameworks, package manager, runtime versions. One line per item. Only versions you actually verified.

**WHY** — Two sentences: what this project is for, and the one non-obvious thing about how it is shaped (monorepo? plugin host? CLI + lib? data pipeline?).

**HOW** — Bullet list of exact commands. Install, lint, typecheck, test (unit + integration if separate), build, run dev. Use the actual package manager (bun vs pnpm vs npm vs uv vs poetry vs cargo), not a generic placeholder.

**NON-OBVIOUS** — Anything an experienced engineer would not guess from reading the code: required env vars and where to get them, services that must run locally, secrets handling, custom DSLs, generated code that should never be edited by hand, code paths that look dead but are entry points.

**BOUNDARIES** — Three tiers in this exact format:
  - ✅ Always OK to modify: <paths/patterns>
  - ⚠️ Ask first: <paths/patterns>
  - 🚫 Never touch: <paths/patterns>

**KEY FILES** — Pointers (not copies) to deeper docs and the few files that define the architecture. Use relative paths.

Write the draft to a temp path so I can review before it replaces the live file: print it to stdout AND save to `./.init-draft.md`.

# PHASE 3 — CURATE (I do this, you wait)

Stop after Phase 2. Do not write to <<OUTPUT_FILE>>. Wait for me to review the draft, strip anything a linter or formatter already enforces, replace any inline code snippets with pointers to source files, and only then I will copy the curated content into <<OUTPUT_FILE>>.

# PHASE 3 TAIL FOR Claude Code
When I confirm, write the curated content to ./CLAUDE.md at the repository root.

You are bootstrapping a context file for AI coding agents. Do NOT auto-write it. Do this in three phases.

# PHASE 1 — SCAN (read-only, no edits)

1. List top-level structure: run `ls -la` then `find . -maxdepth 3 -type d -not -path '*/.*' | sort`.
2. Detect stack: read whichever of these exist — package.json, pyproject.toml, requirements.txt, Cargo.toml, go.mod, Gemfile, pom.xml, build.gradle, deno.json, *.csproj.
3. Read existing docs: README*, CONTRIBUTING*, ARCHITECTURE*, docs/index*, .editorconfig.
4. Detect vendor instruction files and per-vendor config already present: CLAUDE.md, AGENTS.md, GEMINI.md, .cursor/rules/*.mdc, .github/copilot-instructions.md, .windsurf/rules/*.md, .clinerules (or .clinerules/ directory), opencode.json.
5. Identify the most-edited files: `git log --since='90 days ago' --pretty=format: --name-only | sort | uniq -c | sort -rn | head -25`.
6. Run `--help` (or read help docs) for any non-obvious tool you find in scripts/Makefile (e.g. `make help`, `bun run`, custom CLI). Do NOT execute build/test commands.

# PHASE 2 — DRAFT (write a draft, NOT the final file)

Produce a draft with EXACTLY these sections, in this order. Keep total under 300 lines; target 60.

**WHAT** — Stack, languages, frameworks, package manager, runtime versions. One line per item. Only versions you actually verified.

**WHY** — Two sentences: what this project is for, and the one non-obvious thing about how it is shaped (monorepo? plugin host? CLI + lib? data pipeline?).

**HOW** — Bullet list of exact commands. Install, lint, typecheck, test (unit + integration if separate), build, run dev. Use the actual package manager (bun vs pnpm vs npm vs uv vs poetry vs cargo), not a generic placeholder.

**NON-OBVIOUS** — Anything an experienced engineer would not guess from reading the code: required env vars and where to get them, services that must run locally, secrets handling, custom DSLs, generated code that should never be edited by hand, code paths that look dead but are entry points.

**BOUNDARIES** — Three tiers in this exact format:
  - ✅ Always OK to modify: <paths/patterns>
  - ⚠️ Ask first: <paths/patterns>
  - 🚫 Never touch: <paths/patterns>

**KEY FILES** — Pointers (not copies) to deeper docs and the few files that define the architecture. Use relative paths.

Write the draft to a temp path so I can review before it replaces the live file: print it to stdout AND save to `./.init-draft.md`.

# PHASE 3 — CURATE (I do this, you wait)

Stop after Phase 2. Do not write to <<OUTPUT_FILE>>. Wait for me to review the draft, strip anything a linter or formatter already enforces, replace any inline code snippets with pointers to source files, and only then I will copy the curated content into <<OUTPUT_FILE>>.

# PHASE 3 TAIL FOR GitHub Copilot
When I confirm, write the curated content to ./.github/copilot-instructions.md.

You are bootstrapping a context file for AI coding agents. Do NOT auto-write it. Do this in three phases.

# PHASE 1 — SCAN (read-only, no edits)

1. List top-level structure: run `ls -la` then `find . -maxdepth 3 -type d -not -path '*/.*' | sort`.
2. Detect stack: read whichever of these exist — package.json, pyproject.toml, requirements.txt, Cargo.toml, go.mod, Gemfile, pom.xml, build.gradle, deno.json, *.csproj.
3. Read existing docs: README*, CONTRIBUTING*, ARCHITECTURE*, docs/index*, .editorconfig.
4. Detect vendor instruction files and per-vendor config already present: CLAUDE.md, AGENTS.md, GEMINI.md, .cursor/rules/*.mdc, .github/copilot-instructions.md, .windsurf/rules/*.md, .clinerules (or .clinerules/ directory), opencode.json.
5. Identify the most-edited files: `git log --since='90 days ago' --pretty=format: --name-only | sort | uniq -c | sort -rn | head -25`.
6. Run `--help` (or read help docs) for any non-obvious tool you find in scripts/Makefile (e.g. `make help`, `bun run`, custom CLI). Do NOT execute build/test commands.

# PHASE 2 — DRAFT (write a draft, NOT the final file)

Produce a draft with EXACTLY these sections, in this order. Keep total under 300 lines; target 60.

**WHAT** — Stack, languages, frameworks, package manager, runtime versions. One line per item. Only versions you actually verified.

**WHY** — Two sentences: what this project is for, and the one non-obvious thing about how it is shaped (monorepo? plugin host? CLI + lib? data pipeline?).

**HOW** — Bullet list of exact commands. Install, lint, typecheck, test (unit + integration if separate), build, run dev. Use the actual package manager (bun vs pnpm vs npm vs uv vs poetry vs cargo), not a generic placeholder.

**NON-OBVIOUS** — Anything an experienced engineer would not guess from reading the code: required env vars and where to get them, services that must run locally, secrets handling, custom DSLs, generated code that should never be edited by hand, code paths that look dead but are entry points.

**BOUNDARIES** — Three tiers in this exact format:
  - ✅ Always OK to modify: <paths/patterns>
  - ⚠️ Ask first: <paths/patterns>
  - 🚫 Never touch: <paths/patterns>

**KEY FILES** — Pointers (not copies) to deeper docs and the few files that define the architecture. Use relative paths.

Write the draft to a temp path so I can review before it replaces the live file: print it to stdout AND save to `./.init-draft.md`.

# PHASE 3 — CURATE (I do this, you wait)

Stop after Phase 2. Do not write to <<OUTPUT_FILE>>. Wait for me to review the draft, strip anything a linter or formatter already enforces, replace any inline code snippets with pointers to source files, and only then I will copy the curated content into <<OUTPUT_FILE>>.

# PHASE 3 TAIL FOR Cursor
When I confirm, write the curated content to ./.cursor/rules/project.mdc, with YAML frontmatter `---\ndescription: Project context for Cursor agents\nalwaysApply: true\n---` at the top.

You are bootstrapping a context file for AI coding agents. Do NOT auto-write it. Do this in three phases.

# PHASE 1 — SCAN (read-only, no edits)

1. List top-level structure: run `ls -la` then `find . -maxdepth 3 -type d -not -path '*/.*' | sort`.
2. Detect stack: read whichever of these exist — package.json, pyproject.toml, requirements.txt, Cargo.toml, go.mod, Gemfile, pom.xml, build.gradle, deno.json, *.csproj.
3. Read existing docs: README*, CONTRIBUTING*, ARCHITECTURE*, docs/index*, .editorconfig.
4. Detect vendor instruction files and per-vendor config already present: CLAUDE.md, AGENTS.md, GEMINI.md, .cursor/rules/*.mdc, .github/copilot-instructions.md, .windsurf/rules/*.md, .clinerules (or .clinerules/ directory), opencode.json.
5. Identify the most-edited files: `git log --since='90 days ago' --pretty=format: --name-only | sort | uniq -c | sort -rn | head -25`.
6. Run `--help` (or read help docs) for any non-obvious tool you find in scripts/Makefile (e.g. `make help`, `bun run`, custom CLI). Do NOT execute build/test commands.

# PHASE 2 — DRAFT (write a draft, NOT the final file)

Produce a draft with EXACTLY these sections, in this order. Keep total under 300 lines; target 60.

**WHAT** — Stack, languages, frameworks, package manager, runtime versions. One line per item. Only versions you actually verified.

**WHY** — Two sentences: what this project is for, and the one non-obvious thing about how it is shaped (monorepo? plugin host? CLI + lib? data pipeline?).

**HOW** — Bullet list of exact commands. Install, lint, typecheck, test (unit + integration if separate), build, run dev. Use the actual package manager (bun vs pnpm vs npm vs uv vs poetry vs cargo), not a generic placeholder.

**NON-OBVIOUS** — Anything an experienced engineer would not guess from reading the code: required env vars and where to get them, services that must run locally, secrets handling, custom DSLs, generated code that should never be edited by hand, code paths that look dead but are entry points.

**BOUNDARIES** — Three tiers in this exact format:
  - ✅ Always OK to modify: <paths/patterns>
  - ⚠️ Ask first: <paths/patterns>
  - 🚫 Never touch: <paths/patterns>

**KEY FILES** — Pointers (not copies) to deeper docs and the few files that define the architecture. Use relative paths.

Write the draft to a temp path so I can review before it replaces the live file: print it to stdout AND save to `./.init-draft.md`.

# PHASE 3 — CURATE (I do this, you wait)

Stop after Phase 2. Do not write to <<OUTPUT_FILE>>. Wait for me to review the draft, strip anything a linter or formatter already enforces, replace any inline code snippets with pointers to source files, and only then I will copy the curated content into <<OUTPUT_FILE>>.

# PHASE 3 TAIL FOR Cline
When I confirm, write the curated content to ./.clinerules at the repository root.

You are bootstrapping a context file for AI coding agents. Do NOT auto-write it. Do this in three phases.

# PHASE 1 — SCAN (read-only, no edits)

1. List top-level structure: run `ls -la` then `find . -maxdepth 3 -type d -not -path '*/.*' | sort`.
2. Detect stack: read whichever of these exist — package.json, pyproject.toml, requirements.txt, Cargo.toml, go.mod, Gemfile, pom.xml, build.gradle, deno.json, *.csproj.
3. Read existing docs: README*, CONTRIBUTING*, ARCHITECTURE*, docs/index*, .editorconfig.
4. Detect vendor instruction files and per-vendor config already present: CLAUDE.md, AGENTS.md, GEMINI.md, .cursor/rules/*.mdc, .github/copilot-instructions.md, .windsurf/rules/*.md, .clinerules (or .clinerules/ directory), opencode.json.
5. Identify the most-edited files: `git log --since='90 days ago' --pretty=format: --name-only | sort | uniq -c | sort -rn | head -25`.
6. Run `--help` (or read help docs) for any non-obvious tool you find in scripts/Makefile (e.g. `make help`, `bun run`, custom CLI). Do NOT execute build/test commands.

# PHASE 2 — DRAFT (write a draft, NOT the final file)

Produce a draft with EXACTLY these sections, in this order. Keep total under 300 lines; target 60.

**WHAT** — Stack, languages, frameworks, package manager, runtime versions. One line per item. Only versions you actually verified.

**WHY** — Two sentences: what this project is for, and the one non-obvious thing about how it is shaped (monorepo? plugin host? CLI + lib? data pipeline?).

**HOW** — Bullet list of exact commands. Install, lint, typecheck, test (unit + integration if separate), build, run dev. Use the actual package manager (bun vs pnpm vs npm vs uv vs poetry vs cargo), not a generic placeholder.

**NON-OBVIOUS** — Anything an experienced engineer would not guess from reading the code: required env vars and where to get them, services that must run locally, secrets handling, custom DSLs, generated code that should never be edited by hand, code paths that look dead but are entry points.

**BOUNDARIES** — Three tiers in this exact format:
  - ✅ Always OK to modify: <paths/patterns>
  - ⚠️ Ask first: <paths/patterns>
  - 🚫 Never touch: <paths/patterns>

**KEY FILES** — Pointers (not copies) to deeper docs and the few files that define the architecture. Use relative paths.

Write the draft to a temp path so I can review before it replaces the live file: print it to stdout AND save to `./.init-draft.md`.

# PHASE 3 — CURATE (I do this, you wait)

Stop after Phase 2. Do not write to <<OUTPUT_FILE>>. Wait for me to review the draft, strip anything a linter or formatter already enforces, replace any inline code snippets with pointers to source files, and only then I will copy the curated content into <<OUTPUT_FILE>>.

# PHASE 3 TAIL FOR OpenAI Codex
When I confirm, write the curated content to ./AGENTS.md at the repository root.

You are bootstrapping a context file for AI coding agents. Do NOT auto-write it. Do this in three phases.

# PHASE 1 — SCAN (read-only, no edits)

1. List top-level structure: run `ls -la` then `find . -maxdepth 3 -type d -not -path '*/.*' | sort`.
2. Detect stack: read whichever of these exist — package.json, pyproject.toml, requirements.txt, Cargo.toml, go.mod, Gemfile, pom.xml, build.gradle, deno.json, *.csproj.
3. Read existing docs: README*, CONTRIBUTING*, ARCHITECTURE*, docs/index*, .editorconfig.
4. Detect vendor instruction files and per-vendor config already present: CLAUDE.md, AGENTS.md, GEMINI.md, .cursor/rules/*.mdc, .github/copilot-instructions.md, .windsurf/rules/*.md, .clinerules (or .clinerules/ directory), opencode.json.
5. Identify the most-edited files: `git log --since='90 days ago' --pretty=format: --name-only | sort | uniq -c | sort -rn | head -25`.
6. Run `--help` (or read help docs) for any non-obvious tool you find in scripts/Makefile (e.g. `make help`, `bun run`, custom CLI). Do NOT execute build/test commands.

# PHASE 2 — DRAFT (write a draft, NOT the final file)

Produce a draft with EXACTLY these sections, in this order. Keep total under 300 lines; target 60.

**WHAT** — Stack, languages, frameworks, package manager, runtime versions. One line per item. Only versions you actually verified.

**WHY** — Two sentences: what this project is for, and the one non-obvious thing about how it is shaped (monorepo? plugin host? CLI + lib? data pipeline?).

**HOW** — Bullet list of exact commands. Install, lint, typecheck, test (unit + integration if separate), build, run dev. Use the actual package manager (bun vs pnpm vs npm vs uv vs poetry vs cargo), not a generic placeholder.

**NON-OBVIOUS** — Anything an experienced engineer would not guess from reading the code: required env vars and where to get them, services that must run locally, secrets handling, custom DSLs, generated code that should never be edited by hand, code paths that look dead but are entry points.

**BOUNDARIES** — Three tiers in this exact format:
  - ✅ Always OK to modify: <paths/patterns>
  - ⚠️ Ask first: <paths/patterns>
  - 🚫 Never touch: <paths/patterns>

**KEY FILES** — Pointers (not copies) to deeper docs and the few files that define the architecture. Use relative paths.

Write the draft to a temp path so I can review before it replaces the live file: print it to stdout AND save to `./.init-draft.md`.

# PHASE 3 — CURATE (I do this, you wait)

Stop after Phase 2. Do not write to <<OUTPUT_FILE>>. Wait for me to review the draft, strip anything a linter or formatter already enforces, replace any inline code snippets with pointers to source files, and only then I will copy the curated content into <<OUTPUT_FILE>>.

# PHASE 3 TAIL FOR OpenCode
When I confirm, write the curated content to ./AGENTS.md at the repository root.

You are bootstrapping a context file for AI coding agents. Do NOT auto-write it. Do this in three phases.

# PHASE 1 — SCAN (read-only, no edits)

1. List top-level structure: run `ls -la` then `find . -maxdepth 3 -type d -not -path '*/.*' | sort`.
2. Detect stack: read whichever of these exist — package.json, pyproject.toml, requirements.txt, Cargo.toml, go.mod, Gemfile, pom.xml, build.gradle, deno.json, *.csproj.
3. Read existing docs: README*, CONTRIBUTING*, ARCHITECTURE*, docs/index*, .editorconfig.
4. Detect vendor instruction files and per-vendor config already present: CLAUDE.md, AGENTS.md, GEMINI.md, .cursor/rules/*.mdc, .github/copilot-instructions.md, .windsurf/rules/*.md, .clinerules (or .clinerules/ directory), opencode.json.
5. Identify the most-edited files: `git log --since='90 days ago' --pretty=format: --name-only | sort | uniq -c | sort -rn | head -25`.
6. Run `--help` (or read help docs) for any non-obvious tool you find in scripts/Makefile (e.g. `make help`, `bun run`, custom CLI). Do NOT execute build/test commands.

# PHASE 2 — DRAFT (write a draft, NOT the final file)

Produce a draft with EXACTLY these sections, in this order. Keep total under 300 lines; target 60.

**WHAT** — Stack, languages, frameworks, package manager, runtime versions. One line per item. Only versions you actually verified.

**WHY** — Two sentences: what this project is for, and the one non-obvious thing about how it is shaped (monorepo? plugin host? CLI + lib? data pipeline?).

**HOW** — Bullet list of exact commands. Install, lint, typecheck, test (unit + integration if separate), build, run dev. Use the actual package manager (bun vs pnpm vs npm vs uv vs poetry vs cargo), not a generic placeholder.

**NON-OBVIOUS** — Anything an experienced engineer would not guess from reading the code: required env vars and where to get them, services that must run locally, secrets handling, custom DSLs, generated code that should never be edited by hand, code paths that look dead but are entry points.

**BOUNDARIES** — Three tiers in this exact format:
  - ✅ Always OK to modify: <paths/patterns>
  - ⚠️ Ask first: <paths/patterns>
  - 🚫 Never touch: <paths/patterns>

**KEY FILES** — Pointers (not copies) to deeper docs and the few files that define the architecture. Use relative paths.

Write the draft to a temp path so I can review before it replaces the live file: print it to stdout AND save to `./.init-draft.md`.

# PHASE 3 — CURATE (I do this, you wait)

Stop after Phase 2. Do not write to <<OUTPUT_FILE>>. Wait for me to review the draft, strip anything a linter or formatter already enforces, replace any inline code snippets with pointers to source files, and only then I will copy the curated content into <<OUTPUT_FILE>>.

# PHASE 3 TAIL FOR Antigravity 2.0
When I confirm, write the curated content to ./GEMINI.md at the repository root.

You are bootstrapping a context file for AI coding agents. Do NOT auto-write it. Do this in three phases.

# PHASE 1 — SCAN (read-only, no edits)

1. List top-level structure: run `ls -la` then `find . -maxdepth 3 -type d -not -path '*/.*' | sort`.
2. Detect stack: read whichever of these exist — package.json, pyproject.toml, requirements.txt, Cargo.toml, go.mod, Gemfile, pom.xml, build.gradle, deno.json, *.csproj.
3. Read existing docs: README*, CONTRIBUTING*, ARCHITECTURE*, docs/index*, .editorconfig.
4. Detect vendor instruction files and per-vendor config already present: CLAUDE.md, AGENTS.md, GEMINI.md, .cursor/rules/*.mdc, .github/copilot-instructions.md, .windsurf/rules/*.md, .clinerules (or .clinerules/ directory), opencode.json.
5. Identify the most-edited files: `git log --since='90 days ago' --pretty=format: --name-only | sort | uniq -c | sort -rn | head -25`.
6. Run `--help` (or read help docs) for any non-obvious tool you find in scripts/Makefile (e.g. `make help`, `bun run`, custom CLI). Do NOT execute build/test commands.

# PHASE 2 — DRAFT (write a draft, NOT the final file)

Produce a draft with EXACTLY these sections, in this order. Keep total under 300 lines; target 60.

**WHAT** — Stack, languages, frameworks, package manager, runtime versions. One line per item. Only versions you actually verified.

**WHY** — Two sentences: what this project is for, and the one non-obvious thing about how it is shaped (monorepo? plugin host? CLI + lib? data pipeline?).

**HOW** — Bullet list of exact commands. Install, lint, typecheck, test (unit + integration if separate), build, run dev. Use the actual package manager (bun vs pnpm vs npm vs uv vs poetry vs cargo), not a generic placeholder.

**NON-OBVIOUS** — Anything an experienced engineer would not guess from reading the code: required env vars and where to get them, services that must run locally, secrets handling, custom DSLs, generated code that should never be edited by hand, code paths that look dead but are entry points.

**BOUNDARIES** — Three tiers in this exact format:
  - ✅ Always OK to modify: <paths/patterns>
  - ⚠️ Ask first: <paths/patterns>
  - 🚫 Never touch: <paths/patterns>

**KEY FILES** — Pointers (not copies) to deeper docs and the few files that define the architecture. Use relative paths.

Write the draft to a temp path so I can review before it replaces the live file: print it to stdout AND save to `./.init-draft.md`.

# PHASE 3 — CURATE (I do this, you wait)

Stop after Phase 2. Do not write to <<OUTPUT_FILE>>. Wait for me to review the draft, strip anything a linter or formatter already enforces, replace any inline code snippets with pointers to source files, and only then I will copy the curated content into <<OUTPUT_FILE>>.

# PHASE 3 TAIL FOR Kiro
When I confirm, write the curated content to ./AGENTS.md at the repository root (or split into ./.kiro/steering/product.md, tech.md, structure.md for Kiro-native steering).