@vpxa/aikit 0.1.74 → 0.1.75

package/scaffold/_preview/flows/aikit-basic/steps/design/README.md

@@ -1,116 +0,0 @@
-# Design Gate — Basic Flow
-
-Lightweight design gate for bug fixes, small features, and refactoring. Evaluates the task type and determines whether design work is needed before proceeding.
-
-## When This Step Runs
-
-This is the **first step** of the `aikit:basic` flow. It runs before assessment.
-
-## Instructions
-
-### 1. Task Classification
-
-Classify the task into one of these categories:
-
-| Category | Indicators | Action |
-|----------|-----------|--------|
-| **Bug fix** | Error reports, stack traces, regression, "fix", "broken" | → **Auto-skip** to next step |
-| **Refactor** | Code cleanup, rename, restructure, no behavior change | → **Auto-skip** to next step |
-| **Small feature** | New behavior, new endpoint, new component, UI change | → Run **Quick Design** below |
-
-**If the task is a bug fix or refactor**, write `{{artifacts_path}}/design-decisions.md` to disk:
-```markdown
-## Design Decisions
-- **Task type**: Bug fix / Refactor
-- **Design gate**: Auto-skipped — no design work needed
-- **Proceed to**: Assessment
-```
-**You MUST create this file on disk** at the exact `{{artifacts_path}}/design-decisions.md` path — do not just present the content in chat.
-Then report `DONE` to the Orchestrator so the flow advances.
-
-### 2. Quick Design (Small Features Only)
-
-For small features that need minimal design:
-
-1. **FORGE Classify** — Run `forge_classify({ task: "<task description>", files: [<relevant files>] })` to determine complexity tier
-2. **Brainstorming** (if tier ≥ Standard) — Load the `brainstorming` skill and run a focused brainstorming session:
-   - What is the user trying to achieve?
-   - What are the constraints?
-   - What is the simplest approach?
-3. **Decision Protocol** (if technical decisions exist) — Delegate to 2-4 Researcher agents in parallel:
-   - Each researcher evaluates a different approach
-   - Synthesize findings into a recommendation
-4. **Write `{{artifacts_path}}/design-decisions.md`** to disk:
-
-```markdown
-## Design Decisions
-
-### FORGE Assessment
-- **Tier**: {Floor | Standard | Critical}
-- **Rationale**: {why this tier}
-
-### Task Summary
-- **Goal**: {what we're building}
-- **Approach**: {chosen approach}
-- **Key decisions**: {list}
-
-### Constraints
-- {constraint 1}
-- {constraint 2}
-```
-
-### 3. Report to Orchestrator
-
-When complete, report status:
-- `DONE` — design decisions captured, ready for assessment
-- `DONE_WITH_CONCERNS` — design captured but open questions remain (list them)
-
-**Do NOT call `flow_step`** — let the Orchestrator advance the flow.
-
-## Outputs
-
-Write `{{artifacts_path}}/design-decisions.md` to disk. **You MUST create this file** using `create_file` or equivalent — do not just present content in chat. This file is a prerequisite for the next step.
-
-## Produces
-
-- `{{artifacts_path}}/design-decisions.md` — Task classification, FORGE tier, key design decisions
-
-## Agents
-
-- `Researcher-Alpha`, `Researcher-Beta`, `Researcher-Gamma`, `Researcher-Delta` — for parallel research during decision protocol
-
-## 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 |
-| `c4-architecture` | C4 model architecture diagrams — system context, container, component, deployment views | When visualizing system structure during design |
-| `adr-skill` | Architecture Decision Records — create, review, maintain ADRs | When making non-trivial design or technology decisions |
-
-### 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
-
-- [ ] `{{artifacts_path}}/design-decisions.md` written to disk (NOT just presented in chat)
-- [ ] FORGE tier determined (for small features)
-- [ ] Key design decisions documented
-
-## Knowledge Capture
-
-Before completing this step, persist important findings using `remember()`:
-
-- **Design decisions**: Chosen approach and alternatives considered with trade-offs
-- **Architecture patterns**: New patterns introduced or existing patterns that must be followed
-- **Constraints discovered**: Technical limitations, compatibility requirements, or performance boundaries
-
-**Every step produces knowledge worth preserving.** If you discovered something that would help a future session, call `remember()` now.

package/scaffold/_preview/flows/aikit-basic/steps/implement/README.md

@@ -1,131 +0,0 @@
----
-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
-
-- `{{artifacts_path}}/assessment.md` — the approach, affected files, and risks
-
-## Prerequisites Check
-
-Before executing this step, verify:
-
-- [ ] Assessment complete and scope approved (from the assess step)
-- [ ] Files-to-modify list is clear and bounded
-- [ ] `check({})` baseline captured (know what currently passes)
-
-If any prerequisites are missing or incomplete:
-1. Inform the Orchestrator with specifics about what's missing
-2. Recommend `flow_step({ action: 'redo' })` on the **assess** step
-3. Do NOT proceed with partial inputs — quality degrades downstream
-
-## Process
-
-1. **Read assessment** — Load `{{artifacts_path}}/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
-
-Write `{{artifacts_path}}/progress.md` to disk. **You MUST create this file** using `create_file` or equivalent — do not just present content in chat.
-
-Template:
-
-```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 |
-| `session-handoff` | Context preservation for session transfers | When implementation is long-running and context may fill up |
-
-### 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
-- [ ] `{{artifacts_path}}/progress.md` written
-
-## Knowledge Capture
-
-Before completing this step, persist important findings using `remember()`:
-
-- **Implementation decisions**: Why specific approaches were chosen over alternatives
-- **Patterns established**: New conventions or patterns that future code should follow
-- **Gotchas encountered**: Edge cases, workarounds, or non-obvious behaviors discovered during implementation
-
-**Every step produces knowledge worth preserving.** If you discovered something that would help a future session, call `remember()` now.

package/scaffold/_preview/flows/aikit-basic/steps/verify/README.md

@@ -1,123 +0,0 @@
----
-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
-
-- `{{artifacts_path}}/assessment.md` — original requirements and approach
-- `{{artifacts_path}}/progress.md` — what was implemented and any deviations
-
-## Prerequisites Check
-
-Before executing this step, verify:
-
-- [ ] Implementation complete (from the implement step)
-- [ ] `check({})` + `test_run({})` pass at baseline
-- [ ] Changed files list is available for blast radius analysis
-
-If any prerequisites are missing or incomplete:
-1. Inform the Orchestrator with specifics about what's missing
-2. Recommend `flow_step({ action: 'redo' })` on the **implement** step
-3. Do NOT proceed with partial inputs — quality degrades downstream
-
-## 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
-
-Write `{{artifacts_path}}/verify-report.md` to disk. **You MUST create this file** using `create_file` or equivalent — do not just present content in chat.
-
-Template:
-
-```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 |
-| `lesson-learned` | Extract engineering lessons from completed work via git history | After verification completes — capture principles from what was built |
-| `session-handoff` | Context preservation for session transfers | When verification is the final step and session context should be saved |
-
-### 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
-- [ ] `{{artifacts_path}}/verify-report.md` written with clear PASS/FAIL verdict
-
-## Knowledge Capture
-
-Before completing this step, persist important findings using `remember()`:
-
-- **Test coverage gaps**: Areas that couldn't be fully tested and why
-- **Quality findings**: Issues found during verification and their resolutions
-- **Session checkpoint**: Summarize what was accomplished, decisions made, and any remaining work
-
-**Every step produces knowledge worth preserving.** If you discovered something that would help a future session, call `remember()` now.

package/scaffold/_preview/prompts/aikit-ask.prompt.md

@@ -1,13 +0,0 @@
----
-description: "Quick research question — find answer using AI Kit + web search"
-agent: "Researcher-Alpha"
----
-
-## Quick Research
-
-1. **AI Kit Recall** — Search knowledge base for existing answers
-2. **Web Search** — If AI Kit has no relevant results, search the web
-3. **Synthesize** — Combine findings into a clear, concise answer
-4. **Remember** — If the answer is broadly useful, persist it to KB
-
-**Always cite sources** — AI Kit entries, file paths, or URLs.

package/scaffold/_preview/prompts/aikit-debug.prompt.md

@@ -1,15 +0,0 @@
----
-description: "Systematic error diagnosis: reproduce → trace → diagnose → fix → verify"
-agent: "Debugger"
----
-
-## Debug Workflow
-
-1. **Parse Error** — Use `parse_output` on the error message/stack trace
-2. **AI Kit Recall** — Search for known issues matching this pattern
-3. **Reproduce** — Run the failing command/test to confirm
-4. **Trace** — Use `symbol` and `trace` to follow the call chain
-5. **Diagnose** — Form hypothesis, gather evidence
-6. **Fix** — Implement minimal fix
-7. **Verify** — `check` + `test_run` to confirm fix and no regressions
-8. **Remember** — Persist the fix with category `troubleshooting`

package/scaffold/_preview/prompts/aikit-design.prompt.md

@@ -1,15 +0,0 @@
----
-description: "Collaborative design session — explore ideas, refine requirements, produce a design spec"
-agent: "Orchestrator"
----
-
-## Design Session
-
-Enter Phase 0 (Design Gate) directly — the user is requesting a design session.
-
-1. **Invoke the brainstorming skill** — interactive design dialogue with user
-2. Follow the skill's full process (auto-selects Simple or Advanced mode)
-3. If Advanced Mode, use Decision Protocol for unresolved technical choices
-4. Terminal state: brainstorming skill invokes writing-plans skill
-
-**🛑 HARD GATE** — Do NOT skip brainstorming. Do NOT write code. Design first.

package/scaffold/_preview/prompts/aikit-flow-add.prompt.md

@@ -1,84 +0,0 @@
----
-description: "Install a new flow from a git URL or local path — with interactive error recovery"
-agent: "Orchestrator"
----
-
-## Flow Installation Assistant
-
-Install a development flow from a git repository or local directory.
-
-### Usage
-Provide a git URL or local path:
-- `https://github.com/org/my-flow.git`
-- `git@github.com:org/my-flow.git`
-- `./path/to/local/flow`
-- `C:\Users\name\flows\my-flow`
-
-### Workflow
-
-1. **Attempt Install** — Call `flow_add` with the provided source
-2. **On Success** — Show installed flow info with `flow_info`, present summary to user
-3. **On Failure** — Classify the error and enter the appropriate recovery path:
-
-### Error Recovery Paths
-
-#### Git Authentication Failure
-If the error mentions authentication, credentials, 401, 403, permission denied, or SAML:
-
-1. Present the error clearly to the user
-2. Ask which auth method they prefer:
-   - **SSH key**: Walk through `ssh-keygen -t ed25519`, adding the public key to their git host, and retrying with the SSH URL
-   - **Personal Access Token (PAT)**: Guide them to create a PAT in their git host settings, configure `git credential.helper store`, and retry
-   - **Git Credential Manager**: Check if GCM is installed, help install if needed, then retry (GCM opens a browser for auth)
-3. After credentials are configured, retry `flow_add`
-
-#### Network / Connectivity Failure
-If the error mentions timeout, host not found, SSL, or proxy:
-
-1. Present diagnostics: Is VPN needed? Is the URL correct? Is there a proxy?
-2. Guide the user through resolution
-3. Retry after the issue is resolved
-
-#### Format Not Recognized
-If `flow_add` succeeds cloning but returns a format/structure error:
-
-1. Explain that the source was fetched but doesn't match any supported format
-2. List the 3 supported formats:
-   - **Native**: Has a `flow.json` manifest in the root
-   - **Claude Plugin**: Has `.claude-plugin/plugin.json` with skills as steps
-   - **Copilot Agents**: Has `.github/agents/` with agent .md files as steps
-3. Analyze the source structure to understand what's there
-4. Offer to help migrate:
-   - If it has README files or markdown docs → propose creating a `flow.json` that maps them as steps
-   - If it has a different workflow format → propose conversion
-   - If it's missing key parts → guide user to fill them in
-5. Create the missing `flow.json` manifest and step structure
-6. Retry `flow_add` with the fixed source
-
-### Native flow.json Format Reference
-```json
-{
-  "name": "my-flow",
-  "version": "1.0.0",
-  "description": "Description of the flow",
-  "steps": [
-    {
-      "id": "step-id",
-      "name": "Step Name",
-      "instruction": "steps/step-id/README.md",
-      "produces": ["output.md"],
-      "requires": [],
-      "agents": [],
-      "description": "What this step does"
-    }
-  ],
-  "agents": [],
-  "artifacts_dir": ".spec",
-  "install": []
-}
-```
-
-### Post-Install
-After successful installation:
-- Show the flow name, steps, and description via `present`
-- Remind user they can start it with `flow_start`

package/scaffold/_preview/prompts/aikit-flow-create.prompt.md

@@ -1,80 +0,0 @@
----
-description: "Create a new flow from scratch or migrate an existing workflow to aikit format"
-agent: "Orchestrator"
----
-
-## Flow Creation Assistant
-
-Create a new development flow or migrate an existing workflow to the aikit flow format.
-
-### Mode 1: Create from Scratch
-
-Guide the user through building a complete flow:
-
-1. **Define the workflow** — Ask what the flow should accomplish (e.g., "TDD workflow", "documentation pipeline", "migration process")
-2. **Design steps** — Break the workflow into sequential steps (3-8 is ideal)
-3. **For each step**:
-   - Define the step id, name, and description
-   - Write the instruction (README.md content — what the agent should do)
-   - Identify what it produces (output artifacts)
-   - Identify what it requires (which previous steps must complete first)
-   - Optionally assign preferred agents
-4. **Generate flow.json** — Create the manifest with all steps
-5. **Write step READMEs** — Create instruction files for each step
-6. **Install** — Use `flow_add` to install from the local directory
-
-### Mode 2: Migrate Existing Workflow
-
-If the user has an existing workflow (scripts, docs, runbooks) that they want to convert:
-
-1. **Analyze the source** — Read the existing workflow files to understand the process
-2. **Map to steps** — Identify discrete steps with clear inputs/outputs
-3. **Identify gaps** — What's missing for a complete flow? (instructions? ordering? agents?)
-4. **Fill gaps with user** — Ask user to clarify any ambiguous parts
-5. **Generate the flow** — Create flow.json + step READMEs
-6. **Install and validate** — Use `flow_add` and `flow_info` to verify
-
-### Flow Structure
-
-```
-my-flow/
-  flow.json              — Flow manifest (name, version, steps, agents)
-  steps/
-    step-1/
-      README.md          — Step instructions (what the agent should do)
-    step-2/
-      README.md
-      references/        — Optional reference files for the step
-    ...
-```
-
-### flow.json Format
-```json
-{
-  "name": "my-flow",
-  "version": "1.0.0",
-  "description": "What this flow does",
-  "steps": [
-    {
-      "id": "step-id",
-      "name": "Human-readable Step Name",
-      "instruction": "steps/step-id/README.md",
-      "produces": ["artifact-name.md"],
-      "requires": [],
-      "agents": ["Preferred-Agent"],
-      "description": "Brief description of this step"
-    }
-  ],
-  "agents": [],
-  "artifacts_dir": ".spec",
-  "install": []
-}
-```
-
-### Step README Format
-Each step README should include:
-- **Goal** — What this step accomplishes
-- **Inputs** — What context/artifacts from prior steps are needed
-- **Instructions** — Detailed steps for the agent to follow
-- **Output** — What artifact(s) to produce and where to save them
-- **Acceptance criteria** — How to know the step is complete

package/scaffold/_preview/prompts/aikit-flow-manage.prompt.md

@@ -1,24 +0,0 @@
----
-description: "List, inspect, update, and remove installed flows"
-agent: "Orchestrator"
----
-
-## Flow Management
-
-Manage your installed development flows.
-
-### Available Actions
-
-1. **List flows** — `flow_list` to see all installed flows with status
-2. **Inspect a flow** — `flow_info` to see detailed steps, agents, and artifacts
-3. **Check status** — `flow_status` to see the active flow and current step
-4. **Update a flow** — `flow_update` to pull latest changes for git-installed flows
-5. **Remove a flow** — `flow_remove` to uninstall (builtin flows cannot be removed)
-6. **Start a flow** — `flow_start` to begin executing a flow
-7. **Reset active flow** — `flow_reset` to clear active flow state
-
-### Workflow
-1. If no specific action requested, start with `flow_list` and present overview
-2. Use `present` to display flow information in a clear table/card format
-3. For updates, warn if there's an active flow that might be affected
-4. For removals, confirm with user before proceeding

package/scaffold/_preview/prompts/aikit-implement.prompt.md

@@ -1,17 +0,0 @@
----
-description: "Full lifecycle implementation: plan → build → review → commit"
-agent: "Orchestrator"
----
-
-## Implementation Pipeline
-
-Follow the Orchestrator's full workflow:
-
-1. **Phase 0: Design Gate** — Orchestrator checks if design is needed. Creative/additive work triggers brainstorming first. Use `/design` if you want to start with design explicitly.
-2. **Phase 1: Planning** — Research, draft plan, present to user for approval
-3. **Phase 2: Implementation** — Execute phases in parallel batches
-4. **Phase 3: Completion** — Final review, docs, persist learnings
-
-**🛑 MANDATORY STOPS** — After plan, after each batch, after completion.
-
-Refer to the Orchestrator agent's full instructions for the detailed workflow.

package/scaffold/_preview/prompts/aikit-plan.prompt.md

@@ -1,15 +0,0 @@
----
-description: "Create a detailed TDD implementation plan without executing it"
-agent: "Planner"
----
-
-## Planning Workflow
-
-1. **AI Kit Recall** — Search for past plans, architecture decisions
-2. **FORGE Ground** — Classify tier, scope map, seed unknowns
-3. **Research** — Explore codebase, understand subsystems
-4. **Draft Plan** — 3-10 phases with agent assignments, TDD steps
-5. **Dependency Graph** — Group into parallel batches
-6. **Present** — Show plan with open questions
-
-**🛑 MANDATORY STOP** — Wait for user approval. Do NOT implement.

package/scaffold/_preview/prompts/aikit-review.prompt.md

@@ -1,24 +0,0 @@
----
-description: "Dual-model code + architecture review pipeline"
-agent: "Orchestrator"
----
-
-## Review Pipeline
-
-### Step 1: Scope
-Identify changed files and their blast radius.
-
-### Step 2: Code Review (parallel)
-Launch Code-Reviewer-Alpha and Code-Reviewer-Beta on the same changeset.
-
-### Step 3: Architecture Review (if needed)
-If changes cross service boundaries or modify interfaces, launch Architect-Reviewer-Alpha and Architect-Reviewer-Beta.
-
-### Step 4: Synthesis
-Merge findings from both reviewers:
-- **Agreements**: Both found same issue → HIGH confidence
-- **Unique findings**: One found, other didn't → verify
-- **Disagreements**: Contradicting verdicts → present both to user
-
-### Step 5: Report
-Present unified review with: verdict, findings by severity, recommended actions.