@vpxa/aikit 0.1.1 → 0.1.3

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

@@ -1,100 +1,100 @@
----
-name: plan
-description: Analyze the codebase, design the architecture, and create a detailed implementation plan.
----
-
-# Planning
-
-## Purpose
-
-Translate the specification into a concrete, phased implementation plan with architecture decisions, file-level scope, and dependency ordering.
-
-## Inputs
-
-- `.spec/<slug>/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
-
-Produce `.spec/<slug>/plan.md` with:
-
-```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 |
-
-### 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
-- [ ] `.spec/<slug>/plan.md` written
+---
+name: plan
+description: Analyze the codebase, design the architecture, and create a detailed implementation plan.
+---
+
+# Planning
+
+## Purpose
+
+Translate the specification into a concrete, phased implementation plan with architecture decisions, file-level scope, and dependency ordering.
+
+## Inputs
+
+- `.spec/<slug>/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
+
+Produce `.spec/<slug>/plan.md` with:
+
+```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 |
+
+### 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
+- [ ] `.spec/<slug>/plan.md` written

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

@@ -1,100 +1,100 @@
----
-name: spec
-description: Elicit requirements, clarify scope, and define acceptance criteria through structured dialogue.
----
-
-# Specification
-
-## 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
-
-Produce `.spec/<slug>/spec.md` with:
-
-```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 |
-
-### 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
-- [ ] `.spec/<slug>/spec.md` written
+---
+name: spec
+description: Elicit requirements, clarify scope, and define acceptance criteria through structured dialogue.
+---
+
+# Specification
+
+## 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
+
+Produce `.spec/<slug>/spec.md` with:
+
+```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 |
+
+### 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
+- [ ] `.spec/<slug>/spec.md` written

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

@@ -1,99 +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
+---
+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