@arthai/agents 1.0.4 → 1.0.6

package/dist/plugins/forge/templates/CLAUDE.md.template

@@ -0,0 +1,111 @@
+# CLAUDE.md — {{PROJECT_NAME}}
+
+<!-- Generated by claude-agents install.sh --init -->
+<!-- TODO: Replace {{placeholders}} with your project details -->
+
+## Project Overview
+
+{{PROJECT_NAME}} is a {{DESCRIPTION}}.
+
+## Tech Stack
+
+- **Frontend**: <!-- TODO: e.g., Next.js 14, React 18, TypeScript, Tailwind -->
+- **Backend**: <!-- TODO: e.g., FastAPI, SQLAlchemy, PostgreSQL -->
+- **Auth**: <!-- TODO: e.g., Stytch, Auth0, Clerk -->
+- **Deploy**: <!-- TODO: e.g., Railway, Vercel, AWS -->
+
+## Project Structure
+
+```
+{{PROJECT_NAME}}/
+├── frontend/          <!-- TODO: Frontend directory -->
+├── backend/           <!-- TODO: Backend directory -->
+└── ...
+```
+
+## Key Architecture
+
+<!-- TODO: Describe your auth flow, API patterns, database schema, etc. -->
+
+## Local Dev Services
+
+<!-- TODO: Auto-populated by /scan or fill manually -->
+
+| Service  | Port | Directory | Start Command |
+|----------|------|-----------|---------------|
+| Frontend | <!-- TODO --> | frontend/ | <!-- TODO: e.g., npm run dev --> |
+| Backend  | <!-- TODO --> | backend/  | <!-- TODO: e.g., uvicorn app.main:app --reload --> |
+
+## Test Commands
+
+<!-- TODO: Auto-populated by /scan or fill manually -->
+
+| What | Command | Directory |
+|------|---------|-----------|
+| Backend tests | <!-- TODO: e.g., pytest --> | backend/ |
+| Backend lint | <!-- TODO: e.g., ruff check . --> | backend/ |
+| Frontend tests | <!-- TODO: e.g., npm test --> | frontend/ |
+| Frontend lint | <!-- TODO: e.g., npm run lint --> | frontend/ |
+| Type check | <!-- TODO: e.g., npx tsc --noEmit --> | frontend/ |
+| E2E tests | <!-- TODO: e.g., npx playwright test --> | frontend/ |
+
+## Infrastructure
+
+<!-- TODO: Auto-populated by /scan or fill manually -->
+
+| Platform | Service | Domain |
+|----------|---------|--------|
+| <!-- TODO: e.g., Railway --> | <!-- TODO --> | <!-- TODO --> |
+
+Health endpoints: <!-- TODO: e.g., /health, /api/health -->
+
+## Environments
+
+<!-- TODO: Auto-populated by /scan environments or /calibrate -->
+
+| Name | Type | URL | Health | Deploy | Branch |
+|------|------|-----|--------|--------|--------|
+| local | development | <!-- TODO --> | <!-- TODO: e.g., /health --> | manual | — |
+| <!-- TODO --> | <!-- TODO: staging/production/preview/canary --> | <!-- TODO --> | <!-- TODO --> | <!-- TODO --> | <!-- TODO --> |
+
+Access notes: <!-- TODO: e.g., Railway MCP for staging/prod. Env vars: .env.local, .env.staging -->
+
+## Domain
+
+<!-- TODO: Auto-populated by /scan or fill manually -->
+<!-- Describe what this app does, its core entities, and business rules. -->
+<!-- Used by qa-domain agent for domain-aware testing. -->
+
+## Running Locally
+
+```bash
+# TODO: Add your local development commands
+# Frontend
+cd frontend && npm run dev
+
+# Backend
+cd backend && source .venv/bin/activate && uvicorn app.main:app --reload
+```
+
+## Critical Rules
+
+<!-- TODO: Add project-specific rules, e.g.: -->
+- Never push to main directly — always create a PR
+- Secrets in .env.local only — never committed
+
+## Agent Customization
+
+The following agents/skills are managed by `claude-agents` (symlinked):
+- Run `~/.claude-agents/install.sh --status` to see what's linked
+- To override any portable file, replace the symlink with a regular file
+- Your override won't be touched by future syncs
+
+### Project-Specific Agents
+
+Add project-specific agents as regular files in `.claude/agents/`:
+- See `~/.claude-agents/examples/agents/` for templates (frontend, backend, ops, sre, qa)
+
+### Project-Specific Skills
+
+Add project-specific skills as regular directories in `.claude/skills/`:
+- See `~/.claude-agents/examples/skills/` for templates (ci-fix, qa, restart)

package/dist/plugins/prime/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "prime",
   "description": "Everything — all agents, skills, and hooks in one plugin",
-  "version": "1.0.4",
+  "version": "1.0.6",
   "author": {
     "name": "Arth AI"
   }

package/dist/plugins/prime/VERSION

@@ -0,0 +1 @@
+1.0.6

package/dist/plugins/prime/agents/troubleshooter.md

@@ -0,0 +1,132 @@
+---
+name: troubleshooter
+description: "Specialized debugging agent for when other agents get stuck. Performs root cause analysis using error context, knowledge base, git history, and CLAUDE.md. Produces structured diagnosis with confidence level and recommended fix."
+model: sonnet
+---
+
+# Troubleshooter Agent
+
+You are a specialized debugging agent. You are called when another agent or workflow
+has failed multiple times and needs expert diagnosis.
+
+## When You Are Spawned
+
+Another agent has hit a wall — they've tried 2-3 fixes and keep failing. Your job
+is to diagnose the root cause and provide a fix with confidence rating.
+
+## Your Process (follow in order)
+
+### 1. Understand the Problem (DO NOT SKIP)
+
+Read the error context provided in your spawn prompt. Extract:
+- **Exact error message** (not paraphrased)
+- **What was being attempted** (the goal, not just the command)
+- **What has already been tried** (and why each attempt failed)
+- **The file(s) involved**
+
+### 2. Consult Knowledge Base (BEFORE forming any hypothesis)
+
+Check these sources in order:
+
+```
+.claude/knowledge/qa-knowledge/         → past incidents with error signatures
+.claude/knowledge/shared/conventions.md → project-specific gotchas and rules
+.claude/knowledge/shared/patterns.md    → architecture patterns that may explain the error
+.claude/knowledge/agents/               → per-agent learning files
+CLAUDE.md                               → project configuration, test commands, services
+```
+
+Search for:
+- The exact error message (or key phrases)
+- The file/module involved
+- The command that failed
+- Similar past incidents
+
+**If you find a match:** Follow the documented fix. Do not reinvent.
+**If no match:** Proceed to step 3.
+
+### 3. Gather Fresh Evidence
+
+Read the actual source code around the error:
+- The file mentioned in the error (read 50+ lines of context, not just the error line)
+- Related files (imports, callers, configuration)
+- Recent changes: `git log --oneline -10 -- <file>` and `git diff HEAD -- <file>`
+
+Check the environment:
+- `git status` — are there uncommitted changes that might cause the issue?
+- Check if the right dependencies are installed (node_modules, venv, etc.)
+- Check if services are running (ports, Docker containers)
+- Check environment variables that the code expects
+
+### 4. Form Hypothesis (evidence-based only)
+
+Based on steps 2-3, form ONE primary hypothesis and optionally one alternative.
+Each hypothesis MUST cite evidence:
+
+```
+HYPOTHESIS: [what I think is wrong]
+EVIDENCE:
+  - [source]: [what I found that supports this]
+  - [source]: [what I found that supports this]
+CONFIDENCE: HIGH / MEDIUM / LOW
+  - HIGH: evidence directly explains the error, fix is clear
+  - MEDIUM: evidence is consistent but not conclusive
+  - LOW: best guess based on limited evidence
+```
+
+### 5. Recommend Fix
+
+Provide a specific, actionable fix:
+
+```
+RECOMMENDED FIX:
+  File: [exact file path]
+  Change: [what to modify — be specific, not vague]
+  Why: [how this addresses the root cause]
+  Verify: [command to run to confirm the fix works]
+
+ALTERNATIVE FIX (if confidence < HIGH):
+  File: [exact file path]
+  Change: [what to modify]
+  Why: [different hypothesis this addresses]
+```
+
+### 6. Output Format
+
+Always produce this structured output:
+
+```markdown
+## Troubleshooter Diagnosis
+
+**Error:** [exact error]
+**Root Cause:** [1-2 sentence explanation]
+**Confidence:** HIGH / MEDIUM / LOW
+
+### Evidence
+- [source 1]: [finding]
+- [source 2]: [finding]
+- Knowledge base: [match found / no match]
+
+### Recommended Fix
+- File: [path]
+- Change: [specific change]
+- Verify: [command]
+
+### What Was Wrong With Previous Attempts
+- Attempt 1: [why it didn't work — specific reason]
+- Attempt 2: [why it didn't work — specific reason]
+
+### If This Doesn't Work
+- [Next diagnostic step to try]
+- [What data to gather]
+- [Whether to escalate to user — and what to ask them]
+```
+
+## Rules
+
+1. **Never guess.** Every claim must cite evidence from code, logs, KB, or git history.
+2. **Check KB first.** If a past incident matches, use that fix. Don't reinvent.
+3. **Be specific.** "Check the config" is not a fix. "Change line 42 of config.ts from X to Y" is.
+4. **Explain why previous attempts failed.** This is as valuable as the fix itself.
+5. **Know when to escalate.** If confidence is LOW and you can't gather more evidence, say so. Recommend what data to ask the user for.
+6. **Don't try the fix yourself.** Your job is diagnosis. The calling agent implements the fix.

package/dist/plugins/prime/commands/calibrate.md

@@ -72,6 +72,26 @@ This goes far deeper than `/scan`. Read **actual source code** to understand HOW
 
 #### Step 1.1: Foundation Scan
 
+**Managed block check (belt-and-suspenders — runs before anything else):**
+
+Check if CLAUDE.md has the toolkit managed block. If missing, inject it before proceeding:
+
+```bash
+MANAGED_START="<!-- >>> claude-agents toolkit (DO NOT EDIT THIS BLOCK) >>> -->"
+if [ -f "$CLAUDE_PROJECT_DIR/CLAUDE.md" ]; then
+    grep -qF "$MANAGED_START" "$CLAUDE_PROJECT_DIR/CLAUDE.md" || echo "MISSING_BLOCK"
+fi
+```
+
+If the managed block is missing:
+1. Read `~/.claude-agents/templates/CLAUDE.md.managed-block` (or `$CLAUDE_PROJECT_DIR/.claude/hooks/../templates/CLAUDE.md.managed-block` if installed via plugin)
+2. Inject it at the end of CLAUDE.md using the markers:
+   - Start: `<!-- >>> claude-agents toolkit (DO NOT EDIT THIS BLOCK) >>> -->`
+   - End: `<!-- <<< claude-agents toolkit <<< -->`
+3. Report: "Injected toolkit managed block into CLAUDE.md (was missing)"
+
+This catches any install path that missed the injection — clone installs, manual setups, or projects that predate the managed block feature.
+
 Run `/scan` first if CLAUDE.md has `<!-- TODO -->` placeholders or doesn't exist. This populates
 the basics (tech stack, services, test commands, infrastructure). Then proceed to deep scan.
 

package/dist/plugins/prime/commands/ci-fix.md

@@ -160,6 +160,42 @@ gh run view <FAILED_RUN_ID> --log-failed 2>&1 | tail -200
 | **Build failures** | build errors | Read error, fix import/export/config |
 | **Migration** | Alembic/Django errors | Fix migration file |
 | **Dependency** | pip/npm install failures | Fix requirements/package.json |
+| **Toolkit tests** | 15/20-skill-runtime-safety, manifest-coverage | See Toolkit Test Fixes below |
+
+#### Toolkit-Specific Test Fixes (claude-agents repo)
+
+When CI fails on the mechanical test suite (`tests/run.sh`), these are the common failures and auto-fixes:
+
+| Test | Failure message | Root cause | Auto-fix |
+|------|----------------|-----------|----------|
+| `20-skill-runtime-safety` | "regex-unsafe [brackets] in descriptions" | SKILL.md `description:` or `arguments:` field contains `[text]` | Replace `[text]` with `<text>` in the frontmatter field. Brackets break regex matching in Claude Code. |
+| `20-skill-runtime-safety` | "Skills missing required frontmatter fields" | SKILL.md missing `user-invocable: true` or `arguments:` | Add missing field to the YAML frontmatter between `---` markers. Check `git show HEAD~1:path/to/SKILL.md` for the original. |
+| `15-manifest-coverage` | "entries mapped to categories" | New file in `portable.manifest` not listed in any `get_category_items()` category in `install.sh` | Add the manifest entry to the appropriate category in `install.sh:get_category_items()`. |
+| `15-manifest-coverage` | "Install creates all expected symlinks" | New file in `portable.manifest` but install didn't create the symlink | Usually follows from the category mapping fix above. |
+| `15-manifest-coverage` | "Entry counts are consistent" | Mismatch between manifest entries and installed files | Check that new manifest entries have matching source files. |
+| `19-brownfield-assessment` | "classify_file returns IDENTICAL" | Agent fixture is stale after editing an agent `.md` file | Update fixture: `cp agents/{name}.md tests/fixtures/claude-setups/poweruser/.claude/agents/` |
+
+**Auto-fix sequence for toolkit tests:**
+
+```bash
+# 1. Get the exact failure
+gh run view <ID> --log-failed 2>&1 | grep -E "FAIL|✗" | head -5
+
+# 2. For bracket issues — find and fix ALL bracket descriptions
+grep -rn 'description:.*\[' skills/*/SKILL.md
+# Replace [text] with <text> in each match
+
+# 3. For missing frontmatter — compare against last known good
+git show HEAD~1:path/to/SKILL.md | head -6
+# Restore missing fields
+
+# 4. For manifest coverage — add to install.sh categories
+grep "get_category_items" install.sh
+# Add new entries to the right category
+
+# 5. Verify locally before pushing
+bash tests/run.sh --suite 15,20 --scenario a
+```
 
 **Attempt escalation:**
 - Attempt 1: Apply the obvious fix (auto-fix tools, direct code fix)

package/dist/plugins/prime/commands/fix.md

@@ -476,6 +476,29 @@ Select the right agent based on which layer the bug is in:
 If `.claude/project-profile.md` exists, read it to determine the platform and pick the right agent.
 If `/calibrate` generated custom agents (e.g., `ios-developer.md`), use those for platform-specific bugs.
 
+**4.2b: Escalation protocol for fix agents**
+
+Include this in the implementation agent's prompt:
+
+```
+## When Your Fix Doesn't Work (MANDATORY)
+
+1. After first failed attempt: re-read the root cause analysis from Step 1.
+   Is the root cause correct? If not, go back to Step 1.
+2. After second failed attempt: consult knowledge base:
+   - .claude/knowledge/qa-knowledge/ (error keywords)
+   - .claude/knowledge/shared/conventions.md (project gotchas)
+   - git log --all --grep="<error keyword>" --oneline -10
+3. After third failed attempt: STOP. Do not try another fix.
+   Generate a STUCK REPORT and send to team-lead:
+   - Error: [exact message]
+   - Root cause hypothesis: [from Step 1]
+   - Fix attempts: [1, 2, 3 with results]
+   - KB consultation results: [what you found]
+   - Recommendation: [re-investigate root cause / ask user for X / try different approach]
+4. If a troubleshooter agent is available, team-lead may spawn one.
+```
+
 **Agent prompt includes:**
 ```
 1. Root cause analysis from Step 1

package/dist/plugins/prime/commands/implement.md

@@ -27,9 +27,15 @@ If no feature name is provided, use AskUserQuestion to get it.
 If the plan file exists:
 - Read it with the Read tool.
 - Parse the YAML frontmatter to extract the `layers` array (`frontend`, `backend`, or both).
+- Parse the `spec` field from frontmatter (e.g., `spec: specs/feature-name.md`).
 - Use `layers` to determine which agents to spawn (see Agent Selection below).
 - Use the full file content as `PLAN`.
 
+**Also check for a spec file** at `.claude/specs/{feature-name}.md` (written by `/planning` Phase 0):
+- If it exists, read it and store as `FEATURE_SPEC`.
+- Extract `USER_STORIES` (the ## User Stories section) and `EDGE_CASES` (the ## Edge Cases section).
+- These are passed to implementation agents and QA for better coverage.
+
 If the plan file does NOT exist:
 - Check conversation history for a recent `/planning` output. If found, use it as `PLAN` and infer layers from task breakdown.
 - If neither exists, ask the user with AskUserQuestion:
@@ -134,6 +140,43 @@ Include the results in the shared context block below so agents match existing
 patterns instead of inventing new ones. This is 60x cheaper than having each
 Sonnet agent independently explore the codebase.
 
+### 3c. Consult Knowledge Base (before agents start)
+
+Before spawning implementation agents, check the knowledge base for relevant context:
+
+```
+1. .claude/knowledge/shared/conventions.md — coding rules and project gotchas
+2. .claude/knowledge/shared/patterns.md — architecture patterns to follow
+3. .claude/knowledge/qa-knowledge/ — past incidents in the same area
+4. git log --all --grep="fix:" --oneline -10 — recent bug fixes that may be relevant
+```
+
+Include any relevant findings in the shared context block as `KNOWLEDGE_CONTEXT`.
+This prevents agents from repeating past mistakes or contradicting established patterns.
+
+### 3d. Escalation Protocol for Implementation Agents
+
+Add this to every implementation agent's prompt:
+
+```
+## When You Get Stuck (MANDATORY PROTOCOL)
+
+If a command fails or a fix doesn't work:
+1. DO NOT retry the same approach more than twice
+2. After 2 failures with same error: STOP and consult knowledge base
+   - .claude/knowledge/shared/conventions.md
+   - .claude/knowledge/qa-knowledge/ (search for error keywords)
+   - git log --all --grep="<error keyword>" --oneline -10
+3. After 3 failures: escalate with a STUCK REPORT:
+   - Error: [exact message]
+   - Attempts: [what you tried, why each failed]
+   - Evidence: [logs, state, KB results]
+   - What you need: [access/data/decision]
+   - Recommendation: [your best option]
+4. Send the stuck report to team-lead via SendMessage
+5. If a troubleshooter agent is available, team-lead may spawn one to help
+```
+
 ### 4. Build Shared Context Block
 
 ```
@@ -146,6 +189,16 @@ Auth: {AUTH_APPROACH}
 ## Implementation Plan
 {PLAN}
 
+## User Stories (from spec — trace your work to these)
+{USER_STORIES}
+
+(If no spec exists, this section is omitted.)
+
+## Edge Cases (from spec — handle these in your implementation)
+{EDGE_CASES}
+
+(If no spec exists, this section is omitted.)
+
 ## API Contract
 {API_CONTRACT}
 
@@ -204,7 +257,7 @@ Check `.claude/project-profile.md` first (if /calibrate has run). Otherwise the
 
 **Always spawn:**
 - **qa** (subagent_type="qa", model="sonnet", name="qa")
-  - Prompt: "{SHARED_CONTEXT}\n\nYou are QA. Your job: (1) Review backend and frontend implementations as they complete. (2) Ask teammates 'why did you do X?' when something looks wrong. (3) Run validation checks (linters, type checkers, build commands). (4) Report issues back to the responsible teammate. (5) Mark your tasks done when all checks pass. Do NOT write code — only review and validate."
+  - Prompt: "{SHARED_CONTEXT}\n\nYou are QA. Your job: (1) Review backend and frontend implementations as they complete. (2) Verify each user story from the spec is covered by the implementation — flag any story that has no corresponding code. (3) Verify each edge case from the spec is handled — flag any unhandled edge case. (4) Ask teammates 'why did you do X?' when something looks wrong. (5) Run validation checks (linters, type checkers, build commands). (6) Report issues back to the responsible teammate. (7) Mark your tasks done when all checks pass. Do NOT write code — only review and validate.\n\nWhen reviewing, trace each acceptance criterion back to its user story ID (US-1, US-2, etc.) and confirm the implementation satisfies it. Check edge cases (EC-1, EC-2, etc.) have explicit handling in the code."
 
 ### 5b. Red Team Phase
 
@@ -339,6 +392,7 @@ After PASS (or user override of BLOCK):
 
 ### 6. Monitor + Coordinate
 
+**Standard coordination:**
 - Watch TaskList for progress.
 - If backend finishes API endpoints, nudge frontend to unblock.
 - If a teammate is stuck, relay context from the other teammate.
@@ -347,6 +401,50 @@ After PASS (or user override of BLOCK):
 - If `REDTEAM_MODE=once`, defer Step 5b until all implementation steps are complete.
 - Track `REDTEAM_CYCLE`. If a BLOCK verdict is returned from Step 5b.4, pause all progress and escalate to the user before continuing.
 
+**Escalation handling (when an agent sends a STUCK REPORT):**
+
+When an agent reports they're stuck (via SendMessage with stuck report format):
+
+1. **Assess scope:** Is this a local issue (one file, one test) or systemic (architecture problem, wrong approach)?
+
+2. **If local issue (single file/test failure):**
+   - Check if another teammate can help (e.g., backend stuck on a frontend integration → ask frontend agent)
+   - Spawn a troubleshooter agent with the stuck report + error context
+   - Relay the troubleshooter's diagnosis back to the stuck agent
+   - If troubleshooter confidence is LOW → escalate to user with structured options
+
+3. **If systemic issue (architecture problem, multiple agents affected):**
+   - PAUSE all agents (don't let them keep building on a broken foundation)
+   - Escalate to user immediately:
+     ```
+     IMPLEMENTATION BLOCKED
+
+     What happened: [agent] hit [error] after [N] attempts
+     Scope: [local/systemic] — [why you think so]
+     Impact: [which tasks are blocked]
+     Troubleshooter says: [diagnosis if spawned]
+
+     Options:
+       [1] Fix the root cause (I'll explain what needs to change)
+       [2] Adjust the plan (scope down to avoid this area)
+       [3] Abort implementation (save work done so far)
+     ```
+
+4. **If two agents are stuck simultaneously:**
+   - This is almost always a systemic issue → treat as systemic
+   - Do NOT spawn two troubleshooters — diagnose once, fix at the root
+
+5. **If a task shows no progress for 3+ consecutive idle cycles:**
+   - Check in with the agent: "What's your status on Task #N?"
+   - If no meaningful progress → treat as stuck (even without explicit stuck report)
+
+**Red team finding escalation:**
+
+When red team finds issues that the developer can't fix:
+- If the fix requires changes outside their file ownership → orchestrator makes the cross-cutting change
+- If the fix requires a plan change → escalate to user: "Red team found [issue] that requires changing the plan. Original plan said [X], but we need [Y]. Approve?"
+- If the fix is beyond the team's capability → acknowledge, log it, and add to the PR description as a known limitation
+
 ### 7. Cleanup Implementation Team
 
 - Send shutdown_request to all teammates.