luna/oh-my-opencode
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

.opencode to .agents

Browse Source
This commit is contained in:
YeonGyu-Kim
2026-05-13 11:08:08 +09:00
parent a0b46309b4
commit 21460713e3
84 changed files with 12006 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.agents/command/get-unpublished-changes.md
+148
View File
@@ -0,0 +1,148 @@
---
description: Compare HEAD with the latest published npm version and list all unpublished changes
---
<command-instruction>
IMMEDIATELY output the analysis. NO questions. NO preamble.
## CRITICAL: DO NOT just copy commit messages!
For each commit, you MUST:
1. Read the actual diff to understand WHAT CHANGED
2. Describe the REAL change in plain language
3. Explain WHY it matters (if not obvious)
## Steps:
1. Run `git diff v{published-version}..HEAD` to see actual changes
2. Group by type (feat/fix/refactor/docs) with REAL descriptions
3. Note breaking changes if any
4. Recommend version bump (major/minor/patch)
## Output Format:
- feat: "Added X that does Y" (not just "add X feature")
- fix: "Fixed bug where X happened, now Y" (not just "fix X bug")
- refactor: "Changed X from A to B, now supports C" (not just "rename X")
</command-instruction>
<version-context>
<published-version>
!`npm view oh-my-opencode version 2>/dev/null || echo "not published"`
</published-version>
<local-version>
!`node -p "require('./package.json').version" 2>/dev/null || echo "unknown"`
</local-version>
<latest-tag>
!`git tag --sort=-v:refname | head -1 2>/dev/null || echo "no tags"`
</latest-tag>
</version-context>
<git-context>
<commits-since-release>
!`npm view oh-my-opencode version 2>/dev/null | xargs -I{} git log "v{}"..HEAD --oneline 2>/dev/null || echo "no commits since release"`
</commits-since-release>
<diff-stat>
!`npm view oh-my-opencode version 2>/dev/null | xargs -I{} git diff "v{}"..HEAD --stat 2>/dev/null || echo "no diff available"`
</diff-stat>
<files-changed-summary>
!`npm view oh-my-opencode version 2>/dev/null | xargs -I{} git diff "v{}"..HEAD --stat 2>/dev/null | tail -1 || echo ""`
</files-changed-summary>
</git-context>
<output-format>
## Unpublished Changes (v{published} → HEAD)
### feat
| Scope | What Changed |
|-------|--------------|
| X | Description of actual changes |
### fix
| Scope | What Changed |
|-------|--------------|
| X | Description of actual changes |
### refactor
| Scope | What Changed |
|-------|--------------|
| X | Description of actual changes |
### docs
| Scope | What Changed |
|-------|--------------|
| X | Description of actual changes |
### Breaking Changes
None or list
### Files Changed
{diff-stat}
### Suggested Version Bump
- **Recommendation**: patch|minor|major
- **Reason**: Reason for recommendation
</output-format>
<oracle-safety-review>
## Oracle Deployment Safety Review (Only when user explicitly requests)
**Trigger keywords**: "safe to deploy", "can I deploy", "is it safe", "review", "check", "oracle"
When user includes any of the above keywords in their request:
### 1. Pre-validation
```bash
bun run typecheck
bun test
```
- On failure → Report "❌ Cannot deploy" immediately without invoking Oracle
### 2. Oracle Invocation Prompt
Collect the following information and pass to Oracle:
```
## Deployment Safety Review Request
### Changes Summary
{Changes table analyzed above}
### Key diffs (organized by feature)
{Core code changes for each feat/fix/refactor - only key parts, not full diff}
### Validation Results
- Typecheck: ✅/❌
- Tests: {pass}/{total} (✅/❌)
### Review Items
1. **Regression Risk**: Are there changes that could affect existing functionality?
2. **Side Effects**: Are there areas where unexpected side effects could occur?
3. **Breaking Changes**: Are there changes that affect external users?
4. **Edge Cases**: Are there missed edge cases?
5. **Deployment Recommendation**: SAFE / CAUTION / UNSAFE
### Request
Please analyze the above changes deeply and provide your judgment on deployment safety.
If there are risks, explain with specific scenarios.
Suggest keywords to monitor after deployment if any.
```
### 3. Output Format After Oracle Response
## 🔍 Oracle Deployment Safety Review Result
### Verdict: ✅ SAFE / ⚠️ CAUTION / ❌ UNSAFE
### Risk Analysis
| Area | Risk Level | Description |
|------|------------|-------------|
| ... | 🟢/🟡/🔴 | ... |
### Recommendations
- ...
### Post-deployment Monitoring Keywords
- ...
### Conclusion
{Oracle's final judgment}
</oracle-safety-review>
.agents/command/omomomo.md
+37
View File
@@ -0,0 +1,37 @@
---
description: Easter egg command - about oh-my-opencode
---
<command-instruction>
You found an easter egg! 🥚✨
Print the following message to the user EXACTLY as written (in a friendly, celebratory tone):
---
# 🎉 oMoMoMoMoMo···
**You found the easter egg!** 🥚✨
## What is Oh My OpenCode?
**Oh My OpenCode** is a powerful OpenCode plugin that transforms your AI agent into a full development team:
- 🤖 **Multi-Agent Orchestration**: Oracle (GPT-5.2), Librarian (Claude), Explore (Grok), Frontend Engineer (Gemini), and more
- 🔧 **LSP Tools**: Full IDE capabilities for your agents - hover, goto definition, find references, rename, code actions
- 🔍 **AST-Grep**: Structural code search and replace across 25 languages
- 📚 **Built-in MCPs**: Context7 for docs, Exa for web search, grep.app for GitHub code search
- 🔄 **Background Agents**: Run multiple agents in parallel like a real dev team
- 🎯 **Claude Code Compatibility**: Your existing Claude Code config just works
## Who Made This?
Created with ❤️ by **[code-yeongyu](https://github.com/code-yeongyu)**
🔗 **GitHub**: https://github.com/code-yeongyu/oh-my-opencode
---
*Enjoy coding on steroids!* 🚀
</command-instruction>
.agents/command/publish.md
+376
View File
@@ -0,0 +1,376 @@
---
description: Publish oh-my-opencode to npm via GitHub Actions workflow
argument-hint: <patch|minor|major>
---
<command-instruction>
You are the release manager for oh-my-opencode. Execute the FULL publish workflow from start to finish.
## CRITICAL: ARGUMENT REQUIREMENT
**You MUST receive a version bump type from the user.** Valid options:
- `patch`: Bug fixes, backward-compatible (1.1.7 → 1.1.8)
- `minor`: New features, backward-compatible (1.1.7 → 1.2.0)
- `major`: Breaking changes (1.1.7 → 2.0.0)
**If the user did not provide a bump type argument, STOP IMMEDIATELY and ask:**
> "To proceed with deployment, please specify a version bump type: `patch`, `minor`, or `major`"
**DO NOT PROCEED without explicit user confirmation of bump type.**
---
## STEP 0: REGISTER TODO LIST (MANDATORY FIRST ACTION)
**Before doing ANYTHING else**, create a detailed todo list using TodoWrite:
```
[
{ "id": "confirm-bump", "content": "Confirm version bump type with user (patch/minor/major)", "status": "in_progress", "priority": "high" },
{ "id": "check-uncommitted", "content": "Check for uncommitted changes and commit if needed", "status": "pending", "priority": "high" },
{ "id": "sync-remote", "content": "Sync with remote (pull --rebase && push if unpushed commits)", "status": "pending", "priority": "high" },
{ "id": "run-workflow", "content": "Trigger GitHub Actions publish workflow", "status": "pending", "priority": "high" },
{ "id": "wait-workflow", "content": "Wait for workflow completion (poll every 30s)", "status": "pending", "priority": "high" },
{ "id": "verify-and-preview", "content": "Verify release created + preview auto-generated changelog & contributor thanks", "status": "pending", "priority": "high" },
{ "id": "draft-summary", "content": "Draft enhanced release summary (mandatory for minor/major, optional for patch — ask user)", "status": "pending", "priority": "high" },
{ "id": "apply-summary", "content": "Prepend enhanced summary to release (if user opted in)", "status": "pending", "priority": "high" },
{ "id": "verify-npm", "content": "Verify npm package published successfully", "status": "pending", "priority": "high" },
{ "id": "wait-platform-workflow", "content": "Wait for publish-platform workflow completion", "status": "pending", "priority": "high" },
{ "id": "verify-platform-binaries", "content": "Verify all 7 platform binary packages published", "status": "pending", "priority": "high" },
{ "id": "final-confirmation", "content": "Final confirmation to user with links", "status": "pending", "priority": "low" }
]
```
**Mark each todo as `in_progress` when starting, `completed` when done. ONE AT A TIME.**
---
## STEP 1: CONFIRM BUMP TYPE
If bump type provided as argument, confirm with user:
> "Version bump type: `{bump}`. Proceed? (y/n)"
Wait for user confirmation before proceeding.
---
## STEP 2: CHECK UNCOMMITTED CHANGES
Run: `git status --porcelain`
- If there are uncommitted changes, warn user and ask if they want to commit first
- If clean, proceed
---
## STEP 2.5: SYNC WITH REMOTE (MANDATORY)
Check if there are unpushed commits:
```bash
git log origin/master..HEAD --oneline
```
**If there are unpushed commits, you MUST sync before triggering workflow:**
```bash
git pull --rebase && git push
```
This ensures the GitHub Actions workflow runs on the latest code including all local commits.
---
## STEP 3: TRIGGER GITHUB ACTIONS WORKFLOW
Run the publish workflow:
```bash
gh workflow run publish -f bump={bump_type}
```
Wait 3 seconds, then get the run ID:
```bash
gh run list --workflow=publish --limit=1 --json databaseId,status --jq '.[0]'
```
---
## STEP 4: WAIT FOR WORKFLOW COMPLETION
Poll workflow status every 30 seconds until completion:
```bash
gh run view {run_id} --json status,conclusion --jq '{status: .status, conclusion: .conclusion}'
```
Status flow: `queued` → `in_progress` → `completed`
**IMPORTANT: Use polling loop, NOT sleep commands.**
If conclusion is `failure`, show error and stop:
```bash
gh run view {run_id} --log-failed
```
---
## STEP 5: VERIFY RELEASE & PREVIEW AUTO-GENERATED CONTENT
Two goals: confirm the release exists, then show the user what the workflow already generated.
```bash
# Pull latest (workflow committed version bump)
git pull --rebase
NEW_VERSION=$(node -p "require('./package.json').version")
# Verify release exists on GitHub
gh release view "v${NEW_VERSION}" --json tagName,url --jq '{tag: .tagName, url: .url}'
```
**After verifying, generate a local preview of the auto-generated content:**
```bash
bun run script/generate-changelog.ts
```
<agent-instruction>
After running the preview, present the output to the user and say:
> **The following content is ALREADY included in the release automatically:**
> - Commit changelog (grouped by feat/fix/refactor)
> - Contributor thank-you messages (for non-team contributors)
>
> You do NOT need to write any of this. It's handled.
>
> **For a patch release**, this is usually sufficient on its own. However, if there are notable bug fixes or changes worth highlighting, an enhanced summary can be added.
> **For a minor/major release**, an enhanced summary is **required** — I'll draft one in the next step.
Wait for the user to acknowledge before proceeding.
</agent-instruction>
---
## STEP 6: DRAFT ENHANCED RELEASE SUMMARY
<decision-gate>
| Release Type | Action |
|-------------|--------|
| **patch** | ASK the user: "Would you like me to draft an enhanced summary highlighting the key bug fixes / changes? Or is the auto-generated changelog sufficient?" If user declines → skip to Step 8. If user accepts → draft a concise bug-fix / change summary below. |
| **minor** | MANDATORY. Draft a concise feature summary. Do NOT proceed without one. |
| **major** | MANDATORY. Draft a full release narrative with migration notes if applicable. Do NOT proceed without one. |
</decision-gate>
### What You're Writing (and What You're NOT)
You are writing the **headline layer** — a product announcement that sits ABOVE the auto-generated commit log. Think "release blog post", not "git log".
<rules>
- NEVER duplicate commit messages. The auto-generated section already lists every commit.
- NEVER write generic filler like "Various bug fixes and improvements" or "Several enhancements".
- ALWAYS focus on USER IMPACT: what can users DO now that they couldn't before?
- ALWAYS group by THEME or CAPABILITY, not by commit type (feat/fix/refactor).
- ALWAYS use concrete language: "You can now do X" not "Added X feature".
</rules>
<examples>
<bad title="Commit regurgitation — DO NOT do this">
## What's New
- feat(auth): add JWT refresh token rotation
- fix(auth): handle expired token edge case
- refactor(auth): extract middleware
</bad>
<good title="User-impact narrative — DO this">
## 🔐 Smarter Authentication
Token refresh is now automatic and seamless. Sessions no longer expire mid-task — the system silently rotates credentials in the background. If you've been frustrated by random logouts, this release fixes that.
</good>
<bad title="Vague filler — DO NOT do this">
## Improvements
- Various performance improvements
- Bug fixes and stability enhancements
</bad>
<good title="Specific and measurable — DO this">
## ⚡ 3x Faster Rule Parsing
Rules are now cached by file modification time. If your project has 50+ rule files, you'll notice startup is noticeably faster — we measured a 3x improvement in our test suite.
</good>
</examples>
### Drafting Process
1. **Analyze** the commit list from Step 5's preview. Identify 2-5 themes that matter to users.
2. **Write** the summary to `/tmp/release-summary-v${NEW_VERSION}.md`.
3. **Present** the draft to the user for review and approval before applying.
```bash
# Write your draft here
cat > /tmp/release-summary-v${NEW_VERSION}.md << 'SUMMARY_EOF'
{your_enhanced_summary}
SUMMARY_EOF
cat /tmp/release-summary-v${NEW_VERSION}.md
```
<agent-instruction>
After drafting, ask the user:
> "Here's the release summary I drafted. This will appear AT THE TOP of the release notes, above the auto-generated commit changelog and contributor thanks. Want me to adjust anything before applying?"
Do NOT proceed to Step 7 without user confirmation.
</agent-instruction>
---
## STEP 7: APPLY ENHANCED SUMMARY TO RELEASE
**Skip this step ONLY if the user opted out of the enhanced summary in Step 6** — proceed directly to Step 8.
<architecture>
The final release note structure:
```
┌─────────────────────────────────────┐
│ Enhanced Summary (from Step 6) │ ← You wrote this
│ - Theme-based, user-impact focused │
├─────────────────────────────────────┤
│ --- (separator) │
├─────────────────────────────────────┤
│ Auto-generated Commit Changelog │ ← Workflow wrote this
│ - feat/fix/refactor grouped │
│ - Contributor thank-you messages │
└─────────────────────────────────────┘
```
</architecture>
<zero-content-loss-policy>
- Fetch the existing release body FIRST
- PREPEND your summary above it
- The existing auto-generated content must remain 100% INTACT
- NOT A SINGLE CHARACTER of existing content may be removed or modified
</zero-content-loss-policy>
```bash
# 1. Fetch existing auto-generated body
EXISTING_BODY=$(gh release view "v${NEW_VERSION}" --json body --jq '.body')
# 2. Combine: enhanced summary on top, auto-generated below
{
cat /tmp/release-summary-v${NEW_VERSION}.md
echo ""
echo "---"
echo ""
echo "$EXISTING_BODY"
} > /tmp/final-release-v${NEW_VERSION}.md
# 3. Update the release (additive only)
gh release edit "v${NEW_VERSION}" --notes-file /tmp/final-release-v${NEW_VERSION}.md
# 4. Confirm
echo "✅ Release v${NEW_VERSION} updated with enhanced summary."
gh release view "v${NEW_VERSION}" --json url --jq '.url'
```
---
## STEP 8: VERIFY NPM PUBLICATION
Poll npm registry until the new version appears:
```bash
npm view oh-my-opencode version
```
Compare with expected version. If not matching after 2 minutes, warn user about npm propagation delay.
---
## STEP 8.5: WAIT FOR PLATFORM WORKFLOW COMPLETION
The main publish workflow triggers a separate `publish-platform` workflow for platform-specific binaries.
1. Find the publish-platform workflow run triggered by the main workflow:
```bash
gh run list --workflow=publish-platform --limit=1 --json databaseId,status,conclusion --jq '.[0]'
```
2. Poll workflow status every 30 seconds until completion:
```bash
gh run view {platform_run_id} --json status,conclusion --jq '{status: .status, conclusion: .conclusion}'
```
**IMPORTANT: Use polling loop, NOT sleep commands.**
If conclusion is `failure`, show error logs:
```bash
gh run view {platform_run_id} --log-failed
```
---
## STEP 8.6: VERIFY PLATFORM BINARY PACKAGES
After publish-platform workflow completes, verify all 7 platform packages are published:
```bash
PLATFORMS="darwin-arm64 darwin-x64 linux-x64 linux-arm64 linux-x64-musl linux-arm64-musl windows-x64"
for PLATFORM in $PLATFORMS; do
npm view "oh-my-opencode-${PLATFORM}" version
done
```
All 7 packages should show the same version as the main package (`${NEW_VERSION}`).
**Expected packages:**
| Package | Description |
|---------|-------------|
| `oh-my-opencode-darwin-arm64` | macOS Apple Silicon |
| `oh-my-opencode-darwin-x64` | macOS Intel |
| `oh-my-opencode-linux-x64` | Linux x64 (glibc) |
| `oh-my-opencode-linux-arm64` | Linux ARM64 (glibc) |
| `oh-my-opencode-linux-x64-musl` | Linux x64 (musl/Alpine) |
| `oh-my-opencode-linux-arm64-musl` | Linux ARM64 (musl/Alpine) |
| `oh-my-opencode-windows-x64` | Windows x64 |
If any platform package version doesn't match, warn the user and suggest checking the publish-platform workflow logs.
---
## STEP 9: FINAL CONFIRMATION
Report success to user with:
- New version number
- GitHub release URL: https://github.com/code-yeongyu/oh-my-opencode/releases/tag/v{version}
- npm package URL: https://www.npmjs.com/package/oh-my-opencode
- Platform packages status: List all 7 platform packages with their versions
---
## ERROR HANDLING
- **Workflow fails**: Show failed logs, suggest checking Actions tab
- **Release not found**: Wait and retry, may be propagation delay
- **npm not updated**: npm can take 1-5 minutes to propagate, inform user
- **Permission denied**: User may need to re-authenticate with `gh auth login`
- **Platform workflow fails**: Show logs from publish-platform workflow, check which platform failed
- **Platform package missing**: Some platforms may fail due to cross-compilation issues, suggest re-running publish-platform workflow manually
## LANGUAGE
Respond to user in English.
</command-instruction>
<current-context>
<published-version>
!`npm view oh-my-opencode version 2>/dev/null || echo "not published"`
</published-version>
<local-version>
!`node -p "require('./package.json').version" 2>/dev/null || echo "unknown"`
</local-version>
<git-status>
!`git status --porcelain`
</git-status>
<recent-commits>
!`npm view oh-my-opencode version 2>/dev/null | xargs -I{} git log "v{}"..HEAD --oneline 2>/dev/null | head -15 || echo "no commits"`
</recent-commits>
</current-context>
.agents/command/remove-deadcode.md
+221
View File
@@ -0,0 +1,221 @@
---
description: Remove unused code from this project with ultrawork mode, LSP-verified safety, atomic commits
---
<command-instruction>
Dead code removal via massively parallel deep agents. You are the ORCHESTRATOR — you scan, verify, batch, then delegate ALL removals to parallel agents.
<rules>
- **LSP is law.** Verify with `LspFindReferences(includeDeclaration=false)` before ANY removal decision.
- **Never remove entry points.** `src/index.ts`, `src/cli/index.ts`, test files, config files, `packages/` — off-limits.
- **You do NOT remove code yourself.** You scan, verify, batch, then fire deep agents. They do the work.
</rules>
<false-positive-guards>
NEVER mark as dead:
- Symbols in `src/index.ts` or barrel `index.ts` re-exports
- Symbols referenced in test files (tests are valid consumers)
- Symbols with `@public` / `@api` JSDoc tags
- Hook factories (`createXXXHook`), tool factories (`createXXXTool`), agent definitions in `agentSources`
- Command templates, skill definitions, MCP configs
- Symbols in `package.json` exports
</false-positive-guards>
---
## PHASE 1: SCAN — Find Dead Code Candidates
Run ALL of these in parallel:
<parallel-scan>
**TypeScript strict mode (your primary scanner — run this FIRST):**
```bash
bunx tsc --noEmit --noUnusedLocals --noUnusedParameters 2>&1
```
This gives you the definitive list of unused locals, imports, parameters, and types with exact file:line locations.
**Explore agents (fire ALL simultaneously as background):**
```
task(subagent_type="explore", run_in_background=true, load_skills=[],
description="Find orphaned files",
prompt="Find files in src/ NOT imported by any other file. Check all import statements. EXCLUDE: index.ts, *.test.ts, entry points, .md, packages/. Return: file paths.")
task(subagent_type="explore", run_in_background=true, load_skills=[],
description="Find unused exported symbols",
prompt="Find exported functions/types/constants in src/ that are never imported by other files. Cross-reference: for each export, grep the symbol name across src/ — if it only appears in its own file, it's a candidate. EXCLUDE: src/index.ts exports, test files. Return: file path, line, symbol name, export type.")
```
</parallel-scan>
Collect all results into a master candidate list.
---
## PHASE 2: VERIFY — LSP Confirmation (Zero False Positives)
For EACH candidate from Phase 1:
```typescript
LspFindReferences(filePath, line, character, includeDeclaration=false)
// 0 references → CONFIRMED dead
// 1+ references → NOT dead, drop from list
```
Also apply the false-positive-guards above. Produce a confirmed list:
```
| # | File | Symbol | Type | Action |
|---|------|--------|------|--------|
| 1 | src/foo.ts:42 | unusedFunc | function | REMOVE |
| 2 | src/bar.ts:10 | OldType | type | REMOVE |
| 3 | src/baz.ts:7 | ctx | parameter | PREFIX _ |
```
**Action types:**
- `REMOVE` — delete the symbol/import/file entirely
- `PREFIX _` — unused function parameter required by signature → rename to `_paramName`
If ZERO confirmed: report "No dead code found" and STOP.
---
## PHASE 3: BATCH — Group by File for Conflict-Free Parallelism
<batching-rules>
**Goal: maximize parallel agents with ZERO git conflicts.**
1. Group confirmed dead code items by FILE PATH
2. All items in the SAME file go to the SAME batch (prevents two agents editing the same file)
3. If a dead FILE (entire file deletion) exists, it's its own batch
4. Target 5-15 batches. If fewer than 5 items total, use 1 batch per item.
**Example batching:**
```
Batch A: [src/hooks/foo/hook.ts — 3 unused imports]
Batch B: [src/features/bar/manager.ts — 2 unused constants, 1 dead function]
Batch C: [src/tools/baz/tool.ts — 1 unused param, src/tools/baz/types.ts — 1 unused type]
Batch D: [src/dead-file.ts — entire file deletion]
```
Files in the same directory CAN be batched together (they won't conflict as long as no two agents edit the same file). Maximize batch count for parallelism.
</batching-rules>
---
## PHASE 4: EXECUTE — Fire Parallel Deep Agents
For EACH batch, fire a deep agent:
```
task(
category="deep",
load_skills=["typescript-programmer", "git-master"],
run_in_background=true,
description="Remove dead code batch N: [brief description]",
prompt="[see template below]"
)
```
<agent-prompt-template>
Every deep agent gets this prompt structure (fill in the specifics per batch):
```
## TASK: Remove dead code from [file list]
## DEAD CODE TO REMOVE
### [file path] line [N]
- Symbol: `[name]` — [type: unused import / unused constant / unused function / unused parameter / dead file]
- Action: [REMOVE entirely / REMOVE from import list / PREFIX with _]
### [file path] line [N]
- ...
## PROTOCOL
1. Read each file to understand exact syntax at the target lines
2. For each symbol, run LspFindReferences to RE-VERIFY it's still dead (another agent may have changed things)
3. Apply the change:
- Unused import (only symbol in line): remove entire import line
- Unused import (one of many): remove only that symbol from the import list
- Unused constant/function/type: remove the declaration. Clean up trailing blank lines.
- Unused parameter: prefix with `_` (do NOT remove — required by signature)
- Dead file: delete with `rm`
4. After ALL edits in this batch, run: `bun run typecheck`
5. If typecheck fails: `git checkout -- [files]` and report failure
6. If typecheck passes: stage ONLY your files and commit:
`git add [your-specific-files] && git commit -m "refactor: remove dead code from [brief file list]"`
7. Report what you removed and the commit hash
## CRITICAL
- Stage ONLY your batch's files (`git add [specific files]`). NEVER `git add -A` — other agents are working in parallel.
- If typecheck fails after your edits, REVERT all changes and report. Do not attempt to fix.
- Pre-existing test failures in other files are expected. Only typecheck matters for your batch.
```
</agent-prompt-template>
Fire ALL batches simultaneously. Wait for all to complete.
---
## PHASE 5: FINAL VERIFICATION
After ALL agents complete:
```bash
bun run typecheck # must pass
bun test # note any NEW failures vs pre-existing
bun run build # must pass
```
Produce summary:
```markdown
## Dead Code Removal Complete
### Removed
| # | Symbol | File | Type | Commit | Agent |
|---|--------|------|------|--------|-------|
| 1 | unusedFunc | src/foo.ts | function | abc1234 | Batch A |
### Skipped (agent reported failure)
| # | Symbol | File | Reason |
|---|--------|------|--------|
### Verification
- Typecheck: PASS/FAIL
- Tests: X passing, Y failing (Z pre-existing)
- Build: PASS/FAIL
- Total removed: N symbols across M files
- Total commits: K atomic commits
- Parallel agents used: P
```
---
## SCOPE CONTROL
If `$ARGUMENTS` is provided, narrow the scan:
- File path → only that file
- Directory → only that directory
- Symbol name → only that symbol
- `all` or empty → full project scan (default)
## ABORT CONDITIONS
STOP and report if:
- More than 50 candidates found (ask user to narrow scope or confirm proceeding)
- Build breaks and cannot be fixed by reverting
</command-instruction>
<user-request>
$ARGUMENTS
</user-request>