@vpxa/aikit 0.1.1

package/scaffold/flows/aikit-advanced/skills/task/SKILL.md

@@ -0,0 +1,99 @@
+---
+name: task
+description: Break the implementation plan into ordered, atomic tasks with dependencies and agent assignments.
+---
+
+# Task Breakdown
+
+## Purpose
+
+Decompose the implementation plan into small, atomic tasks that agents can execute independently, with clear dependency ordering and acceptance criteria per task.
+
+## Inputs
+
+- `.spec/<slug>/plan.md` — the phased implementation plan
+
+## Process
+
+1. **Load plan** — Read phases, file scope, and dependency graph
+2. **Decompose phases into tasks** — Each task should:
+   - Touch 1–3 files maximum
+   - Have a single, testable outcome
+   - Take one agent one focused session
+3. **Define dependencies** — Map task-to-task dependencies (not just phase-to-phase)
+4. **Assign agents** — Match each task to the best-fit agent based on scope
+5. **Identify parallelism** — Mark which tasks can run simultaneously
+6. **Architecture review** — Have Architect-Reviewer validate task ordering won't create integration issues
+
+## Outputs
+
+Produce `.spec/<slug>/tasks.md` with:
+
+```markdown
+# Task Breakdown: <feature title>
+
+## Task Graph
+
+### Phase 1: <name>
+- [ ] **T1.1**: <description>
+  - Files: <list>
+  - Agent: <agent name>
+  - Depends on: none
+  - Acceptance: <testable criterion>
+
+- [ ] **T1.2**: <description>
+  - Files: <list>
+  - Agent: <agent name>
+  - Depends on: T1.1
+  - Acceptance: <testable criterion>
+
+### Phase 2: <name>
+- [ ] **T2.1**: <description> (can parallel with T1.2)
+  ...
+
+## Parallelism Map
+| Batch | Tasks | Agents |
+|-------|-------|--------|
+| 1 | T1.1 | Implementer |
+| 2 | T1.2, T2.1 | Implementer, Frontend |
+| 3 | T2.2 | Implementer |
+| ... | ... | ... |
+
+## Estimated Batches: <N>
+```
+
+## Agents
+
+| Agent | Role |
+|-------|------|
+| **Planner** | Decomposes plan phases into atomic tasks with dependency ordering |
+| **Architect-Reviewer-Alpha** | Validates task decomposition won't cause integration issues |
+
+Planner does the decomposition, then Architect-Reviewer validates the task graph.
+
+## Foundation Integration
+
+Load these skills BEFORE executing this step:
+
+| Skill | Purpose | When |
+|-------|---------|------|
+| `aikit` | Core MCP tools — search, analyze, remember, validate | Always (auto-loaded) |
+| `present` | Rich rendering for any structured output — assessments, reports, comparisons, reviews, status boards, tables, charts, and all artifact content | Use for ANY output that benefits from rich rendering, not just dashboards |
+| `multi-agents-development` | Dispatch templates, task decomposition, review pipeline patterns | Before dispatching any subagent |
+| `brainstorming` | Structured ideation for design/creative decisions | Before any design choice or new feature exploration |
+
+### Presentation Rules
+- Use `present` for **any output** that benefits from rich rendering — not limited to dashboards
+- Assessments, reports, comparisons, reviews, status boards → `present({ format: "html" })`
+- Tables, charts, progress tracking, code review findings → always present
+- Artifact content and summaries → present with structured layout
+- Only use plain text for brief confirmations and simple questions
+
+## Completion Criteria
+
+- [ ] Every plan phase maps to ≥1 task
+- [ ] Each task touches ≤3 files
+- [ ] Dependencies form a DAG (no cycles)
+- [ ] Parallelism opportunities identified
+- [ ] Architect review confirms no integration risks
+- [ ] `.spec/<slug>/tasks.md` written

package/scaffold/flows/aikit-advanced/skills/verify/SKILL.md

@@ -0,0 +1,122 @@
+---
+name: verify
+description: Dual code review, architecture review, security review, and comprehensive test validation.
+---
+
+# Verification (Advanced)
+
+## Purpose
+
+Perform thorough multi-perspective validation of all changes through parallel dual code review, architecture review, and security analysis.
+
+## Inputs
+
+- `.spec/<slug>/spec.md` — original requirements and acceptance criteria
+- `.spec/<slug>/plan.md` — architecture decisions and phase design
+- `.spec/<slug>/tasks.md` — task breakdown with per-task acceptance criteria
+- `.spec/<slug>/progress.md` — implementation status and changes made
+
+## Process
+
+1. **Load all artifacts** — Read spec, plan, tasks, and progress
+2. **Dual code review** (parallel):
+   - Code-Reviewer-Alpha: focus on correctness, conventions, quality
+   - Code-Reviewer-Beta: focus on edge cases, error handling, maintainability
+3. **Architecture review** (parallel with code review):
+   - Architect-Reviewer-Alpha: validate changes align with plan and ADRs
+   - Architect-Reviewer-Beta: assess long-term maintainability and evolution
+4. **Security review**:
+   - Security agent: OWASP Top 10, auth/authz, input validation, secrets
+5. **Quality gates** — `check({})` + `test_run({})` must pass
+6. **Blast radius** — `blast_radius({ changed_files: [...] })` on all modified files
+7. **Acceptance criteria** — Verify each spec acceptance criterion is met
+8. **FORGE gate** — `evidence_map({ action: "gate" })` for final quality assessment
+9. **Synthesize report** — Merge all reviewer findings into unified verdict
+
+## Outputs
+
+Produce `.spec/<slug>/verify-report.md` with:
+
+```markdown
+# Verification Report: <feature title>
+
+## Verdict: PASS | FAIL
+
+## Acceptance Criteria
+- [x] <criterion> — verified by <method>
+- [ ] <criterion> — FAILED: <reason>
+
+## Quality Gates
+- check: PASS/FAIL
+- test_run: PASS/FAIL (<N> passed, <M> failed)
+- blast_radius: <impact summary>
+- FORGE gate: YIELD/HOLD/HARD_BLOCK
+
+## Code Review (Alpha)
+<findings with severity: critical/major/minor/suggestion>
+
+## Code Review (Beta)
+<findings with severity>
+
+## Architecture Review
+<alignment assessment, any concerns>
+
+## Security Review
+<vulnerabilities found, OWASP compliance>
+
+## Recommendation
+APPROVE | REQUEST CHANGES
+
+### Required Changes (if any)
+1. <change needed>
+2. ...
+```
+
+## Agents
+
+| Agent | Role |
+|-------|------|
+| **Code-Reviewer-Alpha** | Primary code review — correctness, quality, conventions |
+| **Code-Reviewer-Beta** | Secondary code review — edge cases, error handling, maintainability |
+| **Architect-Reviewer-Alpha** | Primary architecture review — alignment with plan and ADRs |
+| **Architect-Reviewer-Beta** | Secondary architecture review — long-term evolution |
+| **Security** | Security analysis — OWASP, auth, input validation |
+
+**Parallelism**: All 5 reviewers can run in parallel — they are read-only.
+
+## Foundation Integration
+
+Load these skills BEFORE executing this step:
+
+| Skill | Purpose | When |
+|-------|---------|------|
+| `aikit` | Core MCP tools — search, analyze, remember, validate | Always (auto-loaded) |
+| `present` | Rich rendering for any structured output — assessments, reports, comparisons, reviews, status boards, tables, charts, and all artifact content | Use for ANY output that benefits from rich rendering, not just dashboards |
+| `multi-agents-development` | Dispatch templates, task decomposition, review pipeline patterns | Before dispatching any subagent |
+| `brainstorming` | Structured ideation for design/creative decisions | Before any design choice or new feature exploration |
+
+### Presentation Rules
+- Use `present` for **any output** that benefits from rich rendering — not limited to dashboards
+- Assessments, reports, comparisons, reviews, status boards → `present({ format: "html" })`
+- Tables, charts, progress tracking, code review findings → always present
+- Artifact content and summaries → present with structured layout
+- Only use plain text for brief confirmations and simple questions
+
+### FORGE Quality Gate
+
+After all reviews complete:
+1. `evidence_map({ action: "gate", task_id: "<slug>" })` → returns YIELD/HOLD/HARD_BLOCK
+2. YIELD → approved, proceed to commit
+3. HOLD → minor issues, fix then re-gate (max 3 rounds)
+4. HARD_BLOCK → critical issues, escalate to user
+
+## Completion Criteria
+
+- [ ] Dual code review complete (2 reviewers)
+- [ ] Architecture review complete (2 reviewers)
+- [ ] Security review complete
+- [ ] `check({})` passes
+- [ ] `test_run({})` passes
+- [ ] All spec acceptance criteria verified
+- [ ] FORGE gate passed (YIELD)
+- [ ] `.spec/<slug>/verify-report.md` written with clear verdict

package/scaffold/flows/aikit-basic/flow.json

@@ -0,0 +1,36 @@
+{
+  "name": "aikit:basic",
+  "version": "0.1.0",
+  "description": "Quick development flow for bug fixes, small features, and refactoring",
+  "steps": [
+    {
+      "id": "assess",
+      "name": "Assessment",
+      "skill": "skills/assess/SKILL.md",
+      "produces": ["assessment.md"],
+      "requires": [],
+      "agents": ["Explorer", "Researcher-Alpha"],
+      "description": "Understand scope, analyze codebase, identify approach"
+    },
+    {
+      "id": "implement",
+      "name": "Implementation",
+      "skill": "skills/implement/SKILL.md",
+      "produces": ["progress.md"],
+      "requires": ["assessment.md"],
+      "agents": ["Implementer", "Frontend"],
+      "description": "Write code following the assessment plan"
+    },
+    {
+      "id": "verify",
+      "name": "Verification",
+      "skill": "skills/verify/SKILL.md",
+      "produces": ["verify-report.md"],
+      "requires": ["progress.md"],
+      "agents": ["Code-Reviewer-Alpha", "Security"],
+      "description": "Review code, run tests, validate changes"
+    }
+  ],
+  "artifacts_dir": ".spec",
+  "install": []
+}

package/scaffold/flows/aikit-basic/skills/assess/SKILL.md

@@ -0,0 +1,82 @@
+---
+name: assess
+description: Understand scope, analyze the codebase, and identify the implementation approach.
+---
+
+# Assessment
+
+## Purpose
+
+Analyze the task requirements and codebase to produce a clear, actionable assessment before any code changes begin.
+
+## Inputs
+
+- User's task description or issue reference
+- Codebase (accessed via aikit MCP tools)
+
+## Process
+
+1. **Parse the goal** — Extract what needs to change, success criteria, and constraints
+2. **Search for prior work** — `search({ query: "<task keywords>" })` to check for existing decisions or related code
+3. **Map affected scope** — `scope_map({ task: "<description>" })` to identify files and modules involved
+4. **Analyze structure** — `file_summary()` on each affected file; `compact()` for deeper sections
+5. **Identify risks** — Note dependencies, breaking change potential, test coverage gaps
+6. **Draft approach** — Outline the implementation strategy in 3–7 steps
+
+## Outputs
+
+Produce `.spec/<slug>/assessment.md` with:
+
+```markdown
+# Assessment: <task title>
+
+## Goal
+<what needs to happen>
+
+## Affected Files
+<list of files with brief reason>
+
+## Approach
+<numbered implementation steps>
+
+## Risks
+<potential issues and mitigations>
+
+## Open Questions
+<anything that needs clarification before proceeding>
+```
+
+## Agents
+
+| Agent | Role |
+|-------|------|
+| **Explorer** | Rapid file discovery, dependency tracing, structural context |
+| **Researcher-Alpha** | Deep analysis of complex logic, prior decisions, architectural implications |
+
+Use Explorer first for breadth, then Researcher-Alpha for depth on complex areas.
+
+## Foundation Integration
+
+Load these skills BEFORE executing this step:
+
+| Skill | Purpose | When |
+|-------|---------|------|
+| `aikit` | Core MCP tools — search, analyze, remember, validate | Always (auto-loaded) |
+| `present` | Rich rendering for any structured output — assessments, reports, comparisons, reviews, status boards, tables, charts, and all artifact content | Use for ANY output that benefits from rich rendering, not just dashboards |
+| `multi-agents-development` | Dispatch templates, task decomposition, review pipeline patterns | Before dispatching any subagent |
+| `brainstorming` | Structured ideation for design/creative decisions | Before any design choice or new feature exploration |
+
+### Presentation Rules
+- Use `present` for **any output** that benefits from rich rendering — not limited to dashboards
+- Assessments, reports, comparisons, reviews, status boards → `present({ format: "html" })`
+- Tables, charts, progress tracking, code review findings → always present
+- Artifact content and summaries → present with structured layout
+- Only use plain text for brief confirmations and simple questions
+
+## Completion Criteria
+
+- [ ] All affected files identified
+- [ ] Implementation approach is concrete (not vague)
+- [ ] Risks documented with mitigations
+- [ ] No unresolved open questions that block implementation
+- [ ] `.spec/<slug>/assessment.md` written

package/scaffold/flows/aikit-basic/skills/implement/SKILL.md

@@ -0,0 +1,105 @@
+---
+name: implement
+description: Write code following the assessment plan, using TDD practices where applicable.
+---
+
+# Implementation
+
+## Purpose
+
+Execute the implementation plan from the assessment, writing production code and tests.
+
+## Inputs
+
+- `.spec/<slug>/assessment.md` — the approach, affected files, and risks
+
+## Process
+
+1. **Read assessment** — Load `.spec/<slug>/assessment.md` and internalize the approach
+2. **Set up tests first** — Where applicable, write failing tests that define success
+3. **Implement changes** — Follow the approach steps sequentially
+   - One logical change per commit-worthy chunk
+   - Stay within the assessed file scope — do not expand without re-assessment
+4. **Run validation** — `check({})` for type/lint errors, `test_run({})` for test results
+5. **Fix issues** — Iterate until `check` and `test_run` pass (max 3 rounds)
+6. **Document progress** — Write progress artifact with what was done and any deviations
+
+## Outputs
+
+Produce `.spec/<slug>/progress.md` with:
+
+```markdown
+# Implementation Progress: <task title>
+
+## Changes Made
+<list of files changed with brief description>
+
+## Tests
+<tests added or modified>
+
+## Deviations from Assessment
+<any changes to the original plan and why>
+
+## Validation
+- check: PASS/FAIL
+- test_run: PASS/FAIL (<N> passed, <M> failed)
+
+## Notes
+<anything the reviewer should know>
+```
+
+## Agents
+
+| Agent | Role |
+|-------|------|
+| **Implementer** | Primary code writer — follows TDD, writes production code and tests |
+| **Frontend** | UI/UX specialist — use when changes involve React components, styling, or responsive design |
+
+Dispatch Implementer for backend/logic changes, Frontend for UI changes. Both can run in parallel if working on different files.
+
+## Foundation Integration
+
+Load these skills BEFORE executing this step:
+
+| Skill | Purpose | When |
+|-------|---------|------|
+| `aikit` | Core MCP tools — search, analyze, remember, validate | Always (auto-loaded) |
+| `present` | Rich rendering for any structured output — assessments, reports, comparisons, reviews, status boards, tables, charts, and all artifact content | Use for ANY output that benefits from rich rendering, not just dashboards |
+| `multi-agents-development` | Dispatch templates, task decomposition, review pipeline patterns | Before dispatching any subagent |
+| `brainstorming` | Structured ideation for design/creative decisions | Before any design choice or new feature exploration |
+
+### Presentation Rules
+- Use `present` for **any output** that benefits from rich rendering — not limited to dashboards
+- Assessments, reports, comparisons, reviews, status boards → `present({ format: "html" })`
+- Tables, charts, progress tracking, code review findings → always present
+- Artifact content and summaries → present with structured layout
+- Only use plain text for brief confirmations and simple questions
+
+### Orchestrator Dispatch Protocol
+
+Follow the `multi-agents-development` skill patterns for dispatch:
+
+1. **Independence Check** before parallelizing:
+   - Same files? → sequential
+   - Shared mutable state? → sequential
+   - Execution-order dependent? → sequential
+   - Need shared new types? → define contract first, then parallel
+   - All clear? → **parallel dispatch**
+
+2. **Subagent Context Template** (each dispatch includes):
+   - **Scope**: exact files + boundary (do NOT touch)
+   - **Goal**: acceptance criteria, testable
+   - **Arch Context**: actual code snippets via `compact()`/`digest()`
+   - **Constraints**: patterns, conventions, anti-patterns
+   - **Self-Review**: checklist before declaring DONE
+
+3. **Status Protocol**: `DONE` | `DONE_WITH_CONCERNS` | `NEEDS_CONTEXT` | `BLOCKED`
+4. **Max 2 retries** per task — then escalate to user
+
+## Completion Criteria
+
+- [ ] All assessment steps implemented
+- [ ] `check({})` passes (no type/lint errors)
+- [ ] `test_run({})` passes (no test failures)
+- [ ] No files modified outside assessed scope
+- [ ] `.spec/<slug>/progress.md` written

package/scaffold/flows/aikit-basic/skills/verify/SKILL.md

@@ -0,0 +1,96 @@
+---
+name: verify
+description: Review code changes, run tests, validate correctness and quality.
+---
+
+# Verification
+
+## Purpose
+
+Validate that the implementation meets the original requirements, passes all quality gates, and introduces no regressions.
+
+## Inputs
+
+- `.spec/<slug>/assessment.md` — original requirements and approach
+- `.spec/<slug>/progress.md` — what was implemented and any deviations
+
+## Process
+
+1. **Load context** — Read assessment and progress artifacts
+2. **Code review** — Review all changed files for:
+   - Correctness against requirements
+   - Code quality and adherence to project conventions
+   - Error handling and edge cases
+   - No unnecessary changes (scope creep)
+3. **Run quality gates** — `check({})` + `test_run({})` must pass
+4. **Blast radius** — `blast_radius({ changed_files: [...] })` to assess impact
+5. **Security scan** — Check for OWASP Top 10 issues in changed code
+6. **Write report** — Document findings with PASS/FAIL verdict
+
+## Outputs
+
+Produce `.spec/<slug>/verify-report.md` with:
+
+```markdown
+# Verification Report: <task title>
+
+## Verdict: PASS | FAIL
+
+## Quality Gates
+- check: PASS/FAIL
+- test_run: PASS/FAIL (<N> passed, <M> failed)
+- blast_radius: <summary of impact>
+
+## Code Review Findings
+<issues found, if any, with severity>
+
+## Security
+<any security concerns>
+
+## Recommendation
+<APPROVE for commit / REQUEST CHANGES with specific items>
+```
+
+## Agents
+
+| Agent | Role |
+|-------|------|
+| **Code-Reviewer-Alpha** | Primary code reviewer — correctness, quality, conventions |
+| **Security** | Security specialist — vulnerability analysis, OWASP compliance |
+
+Run both in parallel — they review different aspects of the same changes.
+
+## Foundation Integration
+
+Load these skills BEFORE executing this step:
+
+| Skill | Purpose | When |
+|-------|---------|------|
+| `aikit` | Core MCP tools — search, analyze, remember, validate | Always (auto-loaded) |
+| `present` | Rich rendering for any structured output — assessments, reports, comparisons, reviews, status boards, tables, charts, and all artifact content | Use for ANY output that benefits from rich rendering, not just dashboards |
+| `multi-agents-development` | Dispatch templates, task decomposition, review pipeline patterns | Before dispatching any subagent |
+| `brainstorming` | Structured ideation for design/creative decisions | Before any design choice or new feature exploration |
+
+### Presentation Rules
+- Use `present` for **any output** that benefits from rich rendering — not limited to dashboards
+- Assessments, reports, comparisons, reviews, status boards → `present({ format: "html" })`
+- Tables, charts, progress tracking, code review findings → always present
+- Artifact content and summaries → present with structured layout
+- Only use plain text for brief confirmations and simple questions
+
+### FORGE Quality Gate
+
+After all reviews complete:
+1. `evidence_map({ action: "gate", task_id: "<slug>" })` → returns YIELD/HOLD/HARD_BLOCK
+2. YIELD → approved, proceed to commit
+3. HOLD → minor issues, fix then re-gate (max 3 rounds)
+4. HARD_BLOCK → critical issues, escalate to user
+
+## Completion Criteria
+
+- [ ] `check({})` passes
+- [ ] `test_run({})` passes
+- [ ] Code review complete with no blocking issues
+- [ ] Security review complete
+- [ ] Blast radius assessed
+- [ ] `.spec/<slug>/verify-report.md` written with clear PASS/FAIL verdict

package/scaffold/general/agents/Architect-Reviewer-Alpha.agent.md

@@ -0,0 +1,21 @@
+---
+description: 'Primary architecture reviewer'
+argument-hint: Files, PR, or subsystem to architecture-review
+tools: [execute/runInTerminal, read/problems, read/readFile, read/terminalLastCommand, agent/runSubagent, search/changes, search/codebase, search/usages, web/fetch, web/githubRepo, browser/openBrowserPage, browser/readPage, browser/screenshotPage, browser/navigatePage, browser/clickElement, browser/dragElement, browser/hoverElement, browser/typeInPage, browser/runPlaywrightCode, browser/handleDialog, aikit/*]
+model: GPT-5.4 (copilot)
+---
+
+# Architect-Reviewer-Alpha - The Structural Guardian
+
+You are **Architect-Reviewer-Alpha**, the primary Architect-Reviewer agent.
+
+You are **not** the Code-Reviewer agent. Code-Reviewer handles correctness, testing, security, and code quality. You handle the big picture: service boundaries, dependency direction, pattern adherence, and structural health.
+
+**Read .github/agents/_shared/architect-reviewer-base.md NOW** — it contains your complete workflow and guidelines. All instructions there apply to you.
+
+## Skills (load on demand)
+
+| Skill | When to load |
+|-------|--------------|
+| `c4-architecture` | When reviewing architectural diagrams or boundary changes |
+| `adr-skill` | When the review involves architecture decisions — reference or create ADRs |

package/scaffold/general/agents/Architect-Reviewer-Beta.agent.md

@@ -0,0 +1,21 @@
+---
+description: 'Architecture reviewer variant — different LLM perspective for dual review'
+argument-hint: Files, PR, or subsystem to architecture-review
+tools: [execute/runInTerminal, read/problems, read/readFile, read/terminalLastCommand, agent/runSubagent, search/changes, search/codebase, search/usages, web/fetch, web/githubRepo, browser/openBrowserPage, browser/readPage, browser/screenshotPage, browser/navigatePage, browser/clickElement, browser/dragElement, browser/hoverElement, browser/typeInPage, browser/runPlaywrightCode, browser/handleDialog, aikit/*]
+model: Claude Opus 4.6 (copilot)
+---
+
+# Architect-Reviewer-Beta - The Structural Guardian
+
+You are **Architect-Reviewer-Beta**, a variant of Architect-Reviewer. Same responsibilities, different model perspective.
+
+You are **not** the Code-Reviewer agent. Code-Reviewer handles correctness, testing, security, and code quality. You handle the big picture: service boundaries, dependency direction, pattern adherence, and structural health.
+
+**Read .github/agents/_shared/architect-reviewer-base.md NOW** — it contains your complete workflow and guidelines. All instructions there apply to you.
+
+## Skills (load on demand)
+
+| Skill | When to load |
+|-------|--------------|
+| `c4-architecture` | When reviewing architectural diagrams or boundary changes |
+| `adr-skill` | When the review involves architecture decisions — reference or create ADRs |

package/scaffold/general/agents/Code-Reviewer-Alpha.agent.md

@@ -0,0 +1,12 @@
+---
+description: 'Primary code reviewer'
+argument-hint: File path, PR, or code to review
+tools: [execute/runInTerminal, read/problems, read/readFile, read/terminalLastCommand, agent/runSubagent, search/changes, search/codebase, search/usages, web/fetch, web/githubRepo, browser/openBrowserPage, browser/readPage, browser/screenshotPage, browser/navigatePage, browser/clickElement, browser/dragElement, browser/hoverElement, browser/typeInPage, browser/runPlaywrightCode, browser/handleDialog, aikit/*]
+model: GPT-5.4 (copilot)
+---
+
+# Code-Reviewer-Alpha - The Quality Guardian
+
+You are **Code-Reviewer-Alpha**, the primary Code-Reviewer agent.
+
+**Read .github/agents/_shared/code-reviewer-base.md NOW** — it contains your complete workflow and guidelines. All instructions there apply to you.

package/scaffold/general/agents/Code-Reviewer-Beta.agent.md

@@ -0,0 +1,12 @@
+---
+description: 'Code reviewer variant — different LLM perspective for dual review'
+argument-hint: File path, PR, or code to review
+tools: [execute/runInTerminal, read/problems, read/readFile, read/terminalLastCommand, agent/runSubagent, search/changes, search/codebase, search/usages, web/fetch, web/githubRepo, browser/openBrowserPage, browser/readPage, browser/screenshotPage, browser/navigatePage, browser/clickElement, browser/dragElement, browser/hoverElement, browser/typeInPage, browser/runPlaywrightCode, browser/handleDialog, aikit/*]
+model: Claude Opus 4.6 (copilot)
+---
+
+# Code-Reviewer-Beta - The Quality Guardian
+
+You are **Code-Reviewer-Beta**, a variant of Code-Reviewer. Same responsibilities, different model perspective.
+
+**Read .github/agents/_shared/code-reviewer-base.md NOW** — it contains your complete workflow and guidelines. All instructions there apply to you.

package/scaffold/general/agents/Debugger.agent.md

@@ -0,0 +1,34 @@
+---
+description: 'Expert debugger that diagnoses issues, traces errors, and provides solutions'
+argument-hint: Error message, stack trace, or description of issue
+tools: [execute/runInTerminal, read/problems, read/readFile, read/terminalSelection, read/terminalLastCommand, agent/runSubagent, edit/createFile, edit/editFiles, search/changes, search/codebase, search/usages, browser/openBrowserPage, browser/readPage, browser/screenshotPage, browser/navigatePage, browser/clickElement, browser/dragElement, browser/hoverElement, browser/typeInPage, browser/runPlaywrightCode, browser/handleDialog, aikit/*]
+model: Claude Opus 4.6 (copilot)
+---
+
+# Debugger - The Problem Solver
+
+You are the **Debugger**, expert debugger that diagnoses issues, traces errors, and provides solutions
+
+**Read `AGENTS.md`** in the workspace root for project conventions and KB protocol.
+
+**Read _shared/code-agent-base.md NOW** — it contains the Information Lookup Order, FORGE, and handoff protocols.
+
+## Debugging Protocol
+
+1. **KB Recall** — Search for known issues matching this error pattern
+2. **Reproduce** — Confirm the error, use `parse_output` on stack traces and build errors for structured analysis
+3. **Verify targets exist** — Before tracing, confirm the files and functions mentioned in the error actually exist. Use `find` or `symbol` to verify paths and signatures. **Never trace into a file you haven't confirmed exists**
+4. **Trace** — `symbol`, `trace`, follow call chains backwards
+5. **Diagnose** — Form hypothesis, gather evidence, identify root cause
+6. **Fix** — Implement the fix, verify with tests
+7. **Validate** — `check`, `test_run` to confirm no regressions
+8. **Persist** — `remember` the fix with category `troubleshooting`
+
+## Rules
+
+- **Never guess** — Always trace the actual execution path
+- **Reproduce first** — Confirm the error before attempting a fix
+- **Minimal fix** — Fix the root cause, don't add workarounds
+- **Test the fix** — Every fix must have a test that would have caught the bug
+- **Verify before asserting** — Don't claim a function has a certain signature without checking via `symbol`. Don't reference a config option without confirming it exists in the codebase
+- **Break debug loops** — If you apply a fix, test, and get the same error 3 times: your hypothesis is wrong. STOP, discard your current theory, re-examine the error output and trace from a different entry point. Return `ESCALATE` if a fresh approach also fails