chore: add AGENTS.md and make skills runtime-agnostic (#160)

## Summary

This PR prepares the repository for development with Codex in addition
to Claude Code by introducing Codex-facing entrypoints and making
existing skill instructions runtime-agnostic.

### What changed

1. Added agent compatibility symlinks
- Added `AGENTS.md` as a symlink to `CLAUDE.md`
- Added `.agents/skills` as a symlink to `.claude/skills`

2. Updated skill docs to be runtime-agnostic
- `.claude/skills/golden-test-reviewer/SKILL.md`
- Replaced Claude-specific interaction/tool wording (e.g.
AskUserQuestion, Task tool)
- Clarified isolated subtask execution model and parallelization
requirements
- Added explicit guidance to defer cross-case synthesis to aggregation
step
- `.claude/skills/test-pruning-advisor/SKILL.md`
  - Updated references from `CLAUDE.md` to `AGENTS.md / CLAUDE.md`
- Replaced Claude-specific interaction/tool wording with
runtime-agnostic guidance
- Clarified isolated subtasks, minimal context passing, and aggregation
responsibilities

3. Simplified base guidance document
- `CLAUDE.md`
- Removed the Kiro-specific "Development Workflow / AI-DLC and
Spec-Driven Development" section to keep project instructions
tool-agnostic and focused on repository conventions

## Notes

- Documentation/configuration only (symlinks + markdown updates)
- No production code or test behavior changes

Author: izumin5210

.agents/skills

@@ -0,0 +1 @@
+../.claude/skills

.claude/skills/golden-test-reviewer/SKILL.md

@@ -15,7 +15,7 @@ Systematically evaluate golden test cases under `packages/cli/src/gen-orchestrat
 
 ### Step 1: Select Review Target
 
-When the review target is not explicitly specified, use AskUserQuestion to present the following options:
+When the review target is not explicitly specified, ask the user (using the runtime's available interaction mechanism) to choose from the following options:
 
 1. **All**: Review all test cases
 2. **Category**: Review test cases in a specific category only
@@ -110,9 +110,13 @@ This analysis will be included in the final report (Step 3).
 
 ### Step 2: Launch Subagents for Parallel Evaluation
 
-For each test case to be reviewed, launch a subagent using the Task tool with `subagent_type: "general-purpose"`.
+For each test case to be reviewed, create a separate subtask with an isolated context (subagent/subtask model) using the runtime's available execution mechanism.
 
-**IMPORTANT**: Launch all subagents in a single response with multiple Task tool calls to enable parallel execution.
+**IMPORTANT**:
+- Treat each test case as an independently designed subtask with clear inputs/outputs.
+- Execute independent subtasks in parallel when supported by the runtime.
+- Pass only minimal required context to each subtask (target test case, relevant diff, and evaluation criteria) to keep context isolated.
+- Normalize and aggregate subtask outputs in the final report.
 
 #### Subagent Prompt
 
@@ -132,25 +136,29 @@ Read the prompt template from **`references/subagent-prompt.md`** and use it for
   - `{test-case-diff}` - diff content for the specific test case
 - Evaluates against 7 criteria (standard 6 + change appropriateness)
 
-#### Example: Launching Multiple Subagents (Standard Mode)
+#### Example: Launching Multiple Analysis Tasks (Standard Mode)
 
 When reviewing test cases `interface-basic`, `union-type`, and `field-resolver`:
 
-```
-// In a single response, make 3 Task tool calls in parallel:
-Task(subagent_type="general-purpose", prompt="Review the golden test case 'interface-basic'...")
-Task(subagent_type="general-purpose", prompt="Review the golden test case 'union-type'...")
-Task(subagent_type="general-purpose", prompt="Review the golden test case 'field-resolver'...")
-```
+Use the runtime's parallel task mechanism to evaluate these test cases as isolated subtasks concurrently:
+- `interface-basic`
+- `union-type`
+- `field-resolver`
 
-#### Example: Launching Subagents (PR/Branch Review Mode)
+#### Example: Launching Analysis Tasks (PR/Branch Review Mode)
 
 When reviewing test cases modified in PR #123:
 
-```
-// In a single response, make Task tool calls for each modified test case:
-Task(subagent_type="general-purpose", prompt="Review the golden test case 'interface-basic' modified in PR #123. Context: Changes in this PR... [diff-summary]. Test case diff: [test-case-diff]...")
-```
+Create one isolated subtask per modified test case (`1 test case = 1 isolated subtask`).
+
+For each subtask, provide only:
+- target test case name
+- PR number or branch name
+- diff summary limited to files relevant to that test case
+- per-test-case diff
+- required evaluation criteria
+
+Do not share full PR/branch-wide cross-case context with every subtask. Cross-case reasoning (e.g., coverage gaps across categories) must be performed only in Step 3 aggregation.
 
 ### Step 3: Aggregate Results and Generate Report
 
@@ -183,6 +191,8 @@ After all subagents complete:
 
 4. **Provide detailed reports** for test cases with issues (expand from JSON)
 
+   Note: Perform repository-wide or cross-case synthesis only at aggregation time, not inside isolated subtasks.
+
 5. **(PR/Branch Review mode only) Include Test Coverage Analysis**:
 
 ```markdown

.claude/skills/test-pruning-advisor/SKILL.md

@@ -13,7 +13,7 @@ Analyze test files to identify redundant, low-value, or obsolete tests that may
 
 ## Deletion Consideration Criteria
 
-Based on project testing guidelines (CLAUDE.md):
+Based on project testing guidelines (AGENTS.md / CLAUDE.md):
 
 1. **Golden file test replaceable unit tests**: Function-level unit tests for code analysis, schema generation, or code generation logic that could be covered by testdata golden file tests
 2. **Trivial tests**: Tests for simple getters/setters, direct value passthrough, or obvious behavior that provides minimal value
@@ -24,7 +24,7 @@ Based on project testing guidelines (CLAUDE.md):
 
 ### Step 1: Select Review Target
 
-When the review target is not explicitly specified, use AskUserQuestion to present the following options:
+When the review target is not explicitly specified, ask the user (using the runtime's available interaction mechanism) to choose from the following options:
 
 1. **Branch/PR changes**: Review only test files added/modified in current branch vs main
 2. **All tests**: Review all `*.test.ts` files in the codebase
@@ -60,9 +60,14 @@ Group test files by their purpose:
 
 ### Step 3: Launch Subagents for Analysis
 
-For each test file (or batch of related files), launch a subagent using the Task tool with `subagent_type: "general-purpose"`.
+For each test file (or cohesive batch of closely related files), create a separate subtask with an isolated context (subagent/subtask model) using the runtime's available execution mechanism (`1 review unit = 1 isolated subtask`).
 
-**IMPORTANT**: Launch all subagents in a single response with multiple Task tool calls to enable parallel execution.
+**IMPORTANT**:
+- Design each review unit as an independent subtask with explicit input/output.
+- Execute independent subtasks in parallel when supported by the runtime.
+- Pass only minimal required context to each subtask (target file(s), related source files, and evaluation criteria) to keep context isolated.
+- Do not provide full repository-wide context to every subtask; keep context scoped to the review unit.
+- Normalize and aggregate subtask outputs in the final report.
 
 #### Subagent Prompt
 
@@ -91,6 +96,8 @@ After all subagents complete:
 
 3. **List deletion candidates by reason**:
 
+   Note: Cross-file synthesis (e.g., overlap and priority decisions across multiple categories) must be done during aggregation, not inside isolated subtasks.
+
 ```markdown
 ## Deletion Candidates
 

AGENTS.md

@@ -0,0 +1 @@
+CLAUDE.md

CLAUDE.md

@@ -41,37 +41,6 @@ pnpm test -- --coverage
 
 **Package manager**: pnpm (v10.28.0)
 
-## Development Workflow
-
-### AI-DLC and Spec-Driven Development
-
-This project follows Kiro-style Spec-Driven Development.
-
-**Paths**:
-- Steering: `.kiro/steering/` - Project-wide rules and context
-- Specs: `.kiro/specs/` - Individual feature specifications
-
-**Minimal workflow**:
-- Phase 0 (optional): `/kiro:steering`, `/kiro:steering-custom`
-- Phase 1 (Specification):
-  - `/kiro:spec-init "description"`
-  - `/kiro:spec-requirements {feature}`
-  - `/kiro:validate-gap {feature}` (optional: for existing codebase)
-  - `/kiro:spec-design {feature} [-y]`
-  - `/kiro:validate-design {feature}` (optional: design review)
-  - `/kiro:spec-tasks {feature} [-y]`
-- Phase 2 (Implementation): `/kiro:spec-impl {feature} [tasks]`
-  - `/kiro:validate-impl {feature}` (optional: after implementation)
-- Progress check: `/kiro:spec-status {feature}`
-
-**Development rules**:
-- 3-phase approval workflow: Requirements → Design → Tasks → Implementation
-- Human review required each phase; use `-y` only for intentional fast-track
-- Keep steering current and verify alignment with `/kiro:spec-status`
-- Follow user instructions precisely; act autonomously within that scope; ask questions only when essential information is missing or instructions are critically ambiguous
-
-**Language**: Think in English, generate responses in Japanese. All Markdown content written to project files (e.g., requirements.md, design.md, tasks.md) MUST be written in the target language configured for the specification (see spec.json.language).
-
 ## Testing
 
 Uses **golden file testing** for CLI validation: