@vpxa/aikit 0.1.74 → 0.1.76

package/scaffold/_preview/flows/aikit-advanced/steps/plan/README.md

@@ -1,122 +0,0 @@
----
-name: plan
-description: Analyze the codebase, design the architecture, and create a detailed implementation plan.
----
-
-# Planning
-
-## Prerequisites Check
-
-Before starting this step, verify:
-- [ ] Specification approved with clarity score ≥90
-- [ ] `{{artifacts_path}}/spec.md` exists and is complete
-
-If prerequisites are NOT met → **backtrack to spec step** (`flow_step({ action: 'redo' })` on previous step)
-
-## Purpose
-
-Translate the specification into a concrete, phased implementation plan with architecture decisions, file-level scope, and dependency ordering.
-
-## Inputs
-
-- `{{artifacts_path}}/spec.md` — the validated specification
-
-## Process
-
-1. **Load spec** — Read and internalize all requirements and acceptance criteria
-2. **Codebase analysis** — `scope_map({ task: "<feature>" })` to identify affected subsystems
-3. **Deep dive** — `file_summary()` + `compact()` on each affected module
-4. **Architecture design** — Decide on:
-   - Where new code lives (new files vs extensions)
-   - API surface changes
-   - Data model changes
-   - Integration patterns
-5. **ADR for non-trivial decisions** — Use `adr-skill` for decisions that affect future development
-6. **Phase decomposition** — Break work into 3–10 ordered phases, each independently testable
-7. **Dependency graph** — Map which phases depend on others and which can parallelize
-8. **Risk assessment** — Identify implementation risks per phase
-
-## Outputs
-
-Write `{{artifacts_path}}/plan.md` to disk. **You MUST create this file** using `create_file` or equivalent — do not just present content in chat.
-
-Template:
-
-```markdown
-# Implementation Plan: <feature title>
-
-## Architecture Overview
-<high-level design with rationale>
-
-## Affected Modules
-| Module | Changes | Risk |
-|--------|---------|------|
-| <module> | <what changes> | low/medium/high |
-
-## Phases
-### Phase 1: <name>
-- **Files**: <list>
-- **Changes**: <description>
-- **Tests**: <what to test>
-- **Depends on**: none
-- **Parallelizable with**: Phase 2
-
-### Phase 2: <name>
-...
-
-## Architecture Decisions
-- ADR-<N>: <title> — <chosen option and rationale>
-
-## Risks
-| Risk | Likelihood | Impact | Mitigation |
-|------|-----------|--------|------------|
-| <risk> | low/medium/high | <impact> | <mitigation> |
-```
-
-## Agents
-
-| Agent | Role |
-|-------|------|
-| **Planner** | Creates comprehensive TDD implementation plans with phase decomposition |
-| **Explorer** | Rapid codebase exploration for discovery of affected files and dependencies |
-
-Use Explorer for initial breadth (file discovery, dependency tracing), then Planner for depth (phase design, ordering).
-
-## 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 |
-| `adr-skill` | Architecture Decision Records for non-trivial technical decisions | When plan involves architecture choices that need documentation |
-| `c4-architecture` | C4 model diagrams showing system structure changes | When plan modifies system architecture |
-
-### 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 spec requirements have corresponding plan phases
-- [ ] Each phase has explicit file scope and test strategy
-- [ ] Architecture decisions documented with rationale
-- [ ] Dependency graph has no circular dependencies
-- [ ] Risks identified with mitigations
-- [ ] `{{artifacts_path}}/plan.md` written
-
-## Knowledge Capture
-
-Before completing this step, persist important findings using `remember()`:
-
-- **Task dependencies**: Critical ordering constraints and parallel opportunities
-- **Risk assessment**: Identified risks and mitigation strategies
-- **Resource decisions**: File ownership, module boundaries, and integration points
-
-**Every step produces knowledge worth preserving.** If you discovered something that would help a future session, call `remember()` now.

package/scaffold/_preview/flows/aikit-advanced/steps/spec/README.md

@@ -1,121 +0,0 @@
----
-name: spec
-description: Elicit requirements, clarify scope, and define acceptance criteria through structured dialogue.
----
-
-# Specification
-
-## Prerequisites Check
-
-Before starting this step, verify:
-- [ ] Design decisions approved (design-decisions.md exists with user approval)
-- [ ] FORGE tier assigned and documented
-
-If prerequisites are NOT met -> **backtrack to design step** (`flow_step({ action: 'redo' })` on previous step)
-
-## Purpose
-
-Transform a vague or broad feature request into a precise, testable specification through requirements elicitation and stakeholder dialogue.
-
-## Inputs
-
-- User's feature request, issue, or idea
-- Codebase context (accessed via aikit MCP tools)
-
-## Process
-
-1. **Understand intent** — Parse what the user wants and why
-2. **Search for context** — `search()` for related prior decisions, existing patterns, and similar features
-3. **Elicit requirements** — Ask structured questions to clarify:
-   - **Functional**: What must the system do?
-   - **Non-functional**: Performance, security, accessibility constraints
-   - **Scope boundaries**: What is explicitly out of scope?
-   - **Acceptance criteria**: How do we know it's done?
-4. **Score clarity** — Use the `requirements-clarity` skill to score 0–100. Iterate questions until ≥ 90.
-5. **Draft specification** — Write formal spec with all requirements resolved
-
-## Outputs
-
-Write `{{artifacts_path}}/spec.md` to disk. **You MUST create this file** using `create_file` or equivalent — do not just present content in chat.
-
-Template:
-
-```markdown
-# Specification: <feature title>
-
-## Summary
-<1-2 sentence description>
-
-## Motivation
-<why this feature is needed>
-
-## Functional Requirements
-1. <requirement with acceptance criterion>
-2. ...
-
-## Non-Functional Requirements
-- Performance: <constraints>
-- Security: <constraints>
-- Accessibility: <constraints>
-
-## Scope
-### In Scope
-- <item>
-
-### Out of Scope
-- <item>
-
-## Acceptance Criteria
-- [ ] <testable criterion>
-- [ ] ...
-
-## Open Questions
-<none — all resolved during elicitation>
-
-## Clarity Score: <N>/100
-```
-
-## Agents
-
-| Agent | Role |
-|-------|------|
-| **Researcher-Alpha** | Deep analysis of existing codebase patterns, prior decisions, and technical constraints |
-
-Use the `brainstorming` skill for creative/design exploration before formalizing requirements. Use `requirements-clarity` skill to score and iterate until the spec is unambiguous.
-
-## 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 |
-| `requirements-clarity` | Score requirements 0-100, iterate until ≥90 before proceeding | Before writing spec — ensures requirements are clear enough |
-
-### 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 functional requirements have acceptance criteria
-- [ ] Scope boundaries are explicit
-- [ ] Requirements clarity score ≥ 90
-- [ ] No open questions remain
-- [ ] `{{artifacts_path}}/spec.md` written
-
-## Knowledge Capture
-
-Before completing this step, persist important findings using `remember()`:
-
-- **Requirements clarified**: Ambiguities resolved and assumptions validated
-- **Scope boundaries**: What the spec covers and explicit exclusions
-- **Acceptance criteria**: Key testable conditions that define "done"
-
-**Every step produces knowledge worth preserving.** If you discovered something that would help a future session, call `remember()` now.

package/scaffold/_preview/flows/aikit-advanced/steps/task/README.md

@@ -1,119 +0,0 @@
----
-name: task
-description: Break the implementation plan into ordered, atomic tasks with dependencies and agent assignments.
----
-
-# Task Breakdown
-
-## Prerequisites Check
-
-Before starting this step, verify:
-- [ ] Implementation plan approved
-- [ ] `{{artifacts_path}}/plan.md` exists with defined phases
-
-If prerequisites are NOT met → **backtrack to plan step** (`flow_step({ action: 'redo' })` on previous step)
-
-## Purpose
-
-Decompose the implementation plan into small, atomic tasks that agents can execute independently, with clear dependency ordering and acceptance criteria per task.
-
-## Inputs
-
-- `{{artifacts_path}}/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
-
-Write `{{artifacts_path}}/tasks.md` to disk. **You MUST create this file** using `create_file` or equivalent — do not just present content in chat.
-
-Template:
-
-```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
-- [ ] `{{artifacts_path}}/tasks.md` written
-
-## Knowledge Capture
-
-Before completing this step, persist important findings using `remember()`:
-
-- **Task decomposition rationale**: Why tasks were split this way and what each accomplishes
-- **Interface contracts**: APIs, types, or data shapes that tasks depend on
-- **Coordination points**: Where tasks interact and handoff requirements
-
-**Every step produces knowledge worth preserving.** If you discovered something that would help a future session, call `remember()` now.

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

@@ -1,145 +0,0 @@
----
-name: verify
-description: Dual code review, architecture review, security review, and comprehensive test validation.
----
-
-# Verification (Advanced)
-
-## Prerequisites Check
-
-Before starting this step, verify:
-- [ ] All tasks marked complete in progress tracker
-- [ ] `check({})` and `test_run({})` pass
-- [ ] `{{artifacts_path}}/progress.md` exists with execution results
-
-If prerequisites are NOT met → **backtrack to execute step** (`flow_step({ action: 'redo' })` on previous step)
-
-## Purpose
-
-Perform thorough multi-perspective validation of all changes through parallel dual code review, architecture review, and security analysis.
-
-## Inputs
-
-- `{{artifacts_path}}/spec.md` — original requirements and acceptance criteria
-- `{{artifacts_path}}/plan.md` — architecture decisions and phase design
-- `{{artifacts_path}}/tasks.md` — task breakdown with per-task acceptance criteria
-- `{{artifacts_path}}/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
-
-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: <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 |
-| `lesson-learned` | Extract engineering principles from completed work | After verification — capture lessons from the implementation |
-| `session-handoff` | Context preservation for session continuity | When verification spans sessions or for final handoff documentation |
-
-### 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)
-- [ ] `{{artifacts_path}}/verify-report.md` written with clear 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/flows/aikit-basic/README.md

@@ -1,51 +0,0 @@
-# aikit:basic — Quick Development Flow
-
-Quick development flow for **bug fixes, small features, and refactoring**.
-
-## Steps
-
-| # | Step | Skill | Produces | Requires | Agents |
-|---|------|-------|----------|----------|--------|
-| 1 | **Design Gate** | `steps/design/README.md` | `design-decisions.md` | — | Researcher-Alpha/Beta/Gamma/Delta |
-| 2 | **Assessment** | `steps/assess/README.md` | `assessment.md` | `design-decisions.md` | Explorer, Researcher-Alpha |
-| 3 | **Implementation** | `steps/implement/README.md` | `progress.md` | `assessment.md` | Implementer, Frontend |
-| 4 | **Verification** | `steps/verify/README.md` | `verify-report.md` | `progress.md` | Code-Reviewer-Alpha, Security |
-
-## How It Works
-
-Each step has a **README.md** file that contains the detailed instructions for the agent(s) executing that step. The Orchestrator reads the README.md via `flow_read_instruction` and delegates work accordingly.
-
-### Step 1: Design Gate
-- **Auto-skips** for bug fixes and refactors (produces a minimal `design-decisions.md` noting it was skipped)
-- For small features: runs quick brainstorming, FORGE classification, and optional decision protocol
-- Read `steps/design/README.md` for the full decision tree
-
-### Step 2: Assessment
-- Explore the codebase to understand scope and impact
-- Use `search`, `scope_map`, `file_summary`, `compact` to gather context
-- Identify the approach and produce `assessment.md`
-
-### Step 3: Implementation
-- Write code following the assessment plan
-- The Orchestrator dispatches Implementer/Frontend agents with specific file scopes
-- Follow TDD practices where applicable
-
-### Step 4: Verification
-- Code review, test execution, security check
-- Run `check({})` + `test_run({})` + `blast_radius({})`
-- Produce `verify-report.md` with findings
-
-## Using Skills Inside Steps
-
-When the Orchestrator activates a step:
-
-1. **Read the instruction first** — `flow_read_instruction` returns the README.md for the current step
-2. **Follow step instructions** — the README.md is the primary guide for what to do
-3. **Delegate to listed agents** — each step lists which agents are appropriate
-4. **Produce the required artifact** — the step's `produces` field specifies what file to create in the artifacts directory
-5. **Check dependencies** — the step's `requires` field lists artifacts from previous steps that must exist
-6. **Report status** — agents report `DONE` | `DONE_WITH_CONCERNS` | `NEEDS_CONTEXT` | `BLOCKED` to the Orchestrator
-
-## Artifacts
-
-All artifacts are stored in the run directory under .flows/{topic}/. The template variable `{{artifacts_path}}` resolves to the actual path at runtime.

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

@@ -1,109 +0,0 @@
----
-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)
-
-## Prerequisites Check
-
-Before executing this step, verify:
-
-- [ ] Design decisions documented (from the design step)
-- [ ] FORGE classification determined (tier assigned)
-- [ ] If brainstorming was done, session outcomes are recorded
-
-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 **design** step
-3. Do NOT proceed with partial inputs — quality degrades downstream
-
-## 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
-
-Write `{{artifacts_path}}/assessment.md` to disk. **You MUST create this file** using `create_file` or equivalent — do not just present content in chat.
-
-Template:
-
-```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 |
-| `c4-architecture` | C4 model architecture diagrams — system context, container, component, deployment views | When visualizing system structure during assessment |
-| `adr-skill` | Architecture Decision Records — create, review, maintain ADRs | When assessment reveals non-trivial design 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
-
-- [ ] All affected files identified
-- [ ] Implementation approach is concrete (not vague)
-- [ ] Risks documented with mitigations
-- [ ] No unresolved open questions that block implementation
-- [ ] `{{artifacts_path}}/assessment.md` written
-
-## Knowledge Capture
-
-Before completing this step, persist important findings using `remember()`:
-
-- **Codebase discoveries**: File locations, architecture patterns, or dependency relationships found during assessment
-- **Problem diagnosis**: Root cause analysis, contributing factors, and affected components
-- **Scope decisions**: What's in scope, what's explicitly excluded, and why
-
-**Every step produces knowledge worth preserving.** If you discovered something that would help a future session, call `remember()` now.