gaia-framework 1.57.0 → 1.57.2

package/_gaia/core/tasks/help.md

@@ -1,45 +0,0 @@
-# GAIA Help — Context-Sensitive Routing
-
-You are the GAIA help system. Analyze the user's query and current project state to suggest the most relevant workflows.
-
-## Instructions
-
-1. Load `{project-root}/_gaia/_config/gaia-help.csv`
-2. Parse the user's query or current context:
-   - If they said "help" with no context: show top-level categories
-   - If they described a task: match to the most relevant workflow(s)
-   - If they're mid-workflow: suggest next steps based on current artifacts
-3. Check what artifacts already exist in `docs/`:
-   - `planning-artifacts/` — PRD, UX, architecture present?
-   - `implementation-artifacts/` — Sprint plan, stories present?
-   - `test-artifacts/` — Test plans present?
-   - `creative-artifacts/` — Creative outputs present?
-4. Based on artifacts found, determine project phase:
-   - No artifacts → suggest Phase 1 (Analysis)
-   - PRD exists, no architecture → suggest Phase 3 (Solutioning)
-   - Architecture exists, no sprint plan → suggest Phase 4 (Implementation)
-   - Sprint plan exists → suggest specific story or review workflows
-5. Present top 3-5 suggestions with:
-   - Workflow name and slash command
-   - One-line description
-   - Why it's relevant to the current context
-6. Offer to activate the selected workflow
-
-## Phase Guide
-
-| Phase | Key Artifact | Slash Command |
-|-------|-------------|---------------|
-| 1-Analysis | Product brief | `/gaia-brainstorm-project` |
-| 2-Planning | PRD | `/gaia-create-prd` |
-| 3-Solutioning | Architecture doc | `/gaia-create-architecture` |
-| 4-Implementation | Sprint plan | `/gaia-sprint-planning` |
-| 5-Deployment | Release plan | `/gaia-release-plan` |
-
-## Quick Actions
-
-- "I want to start a new project" → `/gaia-brainstorm-project`
-- "I have an existing codebase" → `/gaia-brownfield-onboarding`
-- "I need to write code" → `/gaia-dev-story`
-- "Review my code" → `/gaia-code-review`
-- "Run tests" → `/gaia-test-design`
-- "I need to brainstorm" → `/gaia-brainstorming`

package/_gaia/core/tasks/index-docs.xml

@@ -1,46 +0,0 @@
-<task id="index-docs" name="Index Documents">
-<objective>Generate or update an index.md file that references all documents in a target folder</objective>
-
-<critical>
-  <mandate>Scan ALL files in the target folder — never skip any</mandate>
-  <mandate>Preserve existing manual entries in index.md if present</mandate>
-  <mandate>Use relative paths in all links</mandate>
-</critical>
-
-<flow>
-  <step n="1" title="Identify Target">
-    <action>Ask user which folder to index (or use current folder)</action>
-    <action>Verify the folder exists on disk</action>
-  </step>
-
-  <step n="2" title="Scan Files">
-    <action>List all .md, .xml, .yaml, .csv files in the target folder</action>
-    <action>For each file: read the first 5 lines to extract title or purpose</action>
-    <action>Sort files by logical order: README first, then alphabetical</action>
-  </step>
-
-  <step n="3" title="Check Existing Index">
-    <action>If index.md exists: read it and preserve any manual sections</action>
-    <action>If no index.md: create from scratch</action>
-  </step>
-
-  <step n="4" title="Generate Index">
-    <action>Write index.md with:
-      - Folder title (from folder name)
-      - File count summary
-      - Table of contents with links and descriptions
-      - Last updated timestamp
-    </action>
-  </step>
-
-  <step n="5" title="Report">
-    <action>Show the generated index to the user</action>
-    <action>Report: files indexed, any files without titles</action>
-  </step>
-</flow>
-
-<output>
-  <format>Markdown index file with linked table of contents</format>
-  <location>{target-folder}/index.md</location>
-</output>
-</task>

package/_gaia/core/tasks/merge-docs.xml

@@ -1,34 +0,0 @@
-<task id="merge-docs" name="Merge Documents">
-<objective>Merge multiple markdown files back into a single document (inverse of shard-doc)</objective>
-
-<critical>
-  <mandate>Preserve section numbering and cross-references</mandate>
-  <mandate>Maintain consistent heading hierarchy</mandate>
-  <mandate>Reassemble in correct order</mandate>
-</critical>
-
-<flow>
-  <step n="1" title="Identify Source Files">
-    <action>Ask user for directory containing sharded files or list of files to merge</action>
-    <action>Read all source files and determine correct ordering</action>
-  </step>
-  <step n="2" title="Validate Structure">
-    <action>Check heading levels are consistent across files</action>
-    <action>Identify cross-references between sections</action>
-    <action>Resolve any numbering conflicts</action>
-  </step>
-  <step n="3" title="Merge">
-    <action>Reassemble files in correct order</action>
-    <action>Add document header and table of contents if needed</action>
-    <action>Fix cross-references to use section anchors instead of file links</action>
-  </step>
-  <step n="4" title="Output">
-    <action>Write merged document to user-specified location</action>
-  </step>
-</flow>
-
-<output>
-  <format>Single merged markdown document</format>
-  <location>User-specified output path</location>
-</output>
-</task>

package/_gaia/core/tasks/review-accessibility.xml

@@ -1,47 +0,0 @@
-<task id="review-accessibility" name="Accessibility Review Task">
-<objective>Review code and UI for WCAG 2.1 compliance</objective>
-
-<critical>
-  <mandate>Check ARIA attributes and roles</mandate>
-  <mandate>Verify keyboard navigation support</mandate>
-  <mandate>Evaluate color contrast and screen reader support</mandate>
-</critical>
-
-<flow>
-  <step n="1" title="Scope">
-    <action>Ask user for code/component to review</action>
-    <action>Read the target files</action>
-  </step>
-  <step n="2" title="Semantic HTML and ARIA">
-    <action>Check for proper semantic HTML elements</action>
-    <action>Verify ARIA attributes, roles, and labels</action>
-    <action>Check for alt text on images, labels on form inputs</action>
-    <action>For each finding: cite the specific WCAG 2.1 success criterion (e.g., 1.1.1 Non-text Content, 1.3.1 Info and Relationships, 4.1.2 Name Role Value) and its conformance level (A/AA/AAA)</action>
-  </step>
-  <step n="3" title="Keyboard and Focus">
-    <action>Verify keyboard navigation support</action>
-    <action>Check focus management and tab order</action>
-    <action>Verify skip navigation links</action>
-    <action>For each finding: cite the specific WCAG 2.1 success criterion (e.g., 2.1.1 Keyboard, 2.4.3 Focus Order, 2.4.1 Bypass Blocks) and its conformance level (A/AA/AAA)</action>
-  </step>
-  <step n="4" title="Visual and Screen Reader">
-    <action>Evaluate color contrast ratios (4.5:1 for text, 3:1 for large text)</action>
-    <action>Check screen reader compatibility</action>
-    <action>Verify text scaling support</action>
-    <action>For each finding: cite the specific WCAG 2.1 success criterion (e.g., 1.4.3 Contrast Minimum, 1.3.3 Sensory Characteristics, 1.4.4 Resize Text) and its conformance level (A/AA/AAA)</action>
-  </step>
-  <step n="5" title="Report">
-    <template-output file="{test_artifacts}/accessibility-review-{date}.md">
-      Generate accessibility review report organized by category (semantic HTML, ARIA, keyboard, focus, visual, screen reader). Each finding MUST use this format: WCAG Criterion ID (e.g., 1.1.1) | Criterion Name | Conformance Level (A/AA/AAA) | Severity (Critical/High/Medium/Low) | Finding Description | Remediation Guidance.
-    </template-output>
-  </step>
-</flow>
-
-<output>
-  <format>Markdown accessibility findings with WCAG criteria</format>
-  <location>{test_artifacts}/accessibility-review-{date}.md</location>
-</output>
-<next-step source="lifecycle-sequence.yaml">
-  <primary command="/gaia-create-arch">Design system architecture (Phase 3 starts here)</primary>
-</next-step>
-</task>

package/_gaia/core/tasks/review-adversarial.xml

@@ -1,55 +0,0 @@
-<task id="review-adversarial" name="Adversarial Review">
-<objective>Perform a cynical, critical review to find flaws, gaps, and weaknesses in any document or design</objective>
-
-<critical>
-  <mandate>Be deliberately skeptical — assume nothing works as claimed</mandate>
-  <mandate>Attack from multiple angles: technical, business, user, security, scale</mandate>
-  <mandate>Produce a ranked findings report with severity and confidence levels</mandate>
-  <mandate>Do NOT suggest fixes — only identify problems. Fixing is a separate step.</mandate>
-</critical>
-
-<flow>
-  <step n="1" title="Load Target">
-    <action>Ask user for the document/design/code to review</action>
-    <action>Read the entire target</action>
-    <action>Identify what type of artifact it is (PRD, architecture, story, code, etc.)</action>
-    <action>Derive {target} label for the output filename: use the target label provided by the caller (e.g., "prd", "architecture", "epics", "readiness"). If no label was provided, derive from the target filename by stripping the extension (e.g., prd.md → prd, architecture.md → architecture, epics-and-stories.md → epics, readiness-report.md → readiness).</action>
-  </step>
-
-  <step n="2" title="Adversarial Analysis">
-    <action>Attack from these perspectives:
-      - Feasibility: can this actually be built as described?
-      - Completeness: what's missing that should be there?
-      - Contradictions: do any sections contradict each other?
-      - Assumptions: what unstated assumptions could be wrong?
-      - Scale: will this work at 10x/100x the expected load?
-      - Failure modes: what happens when things go wrong?
-      - Dependencies: what external factors could break this?
-      - Security: what attack surfaces are exposed?
-      - User impact: where will users get confused or frustrated?
-      - Business risk: what could make this commercially unviable?
-    </action>
-  </step>
-
-  <step n="3" title="Generate Report">
-    <template-output file="{planning_artifacts}/adversarial-review-{target}-{date}.md">
-      Generate adversarial review report with: threat summary (top 3 most critical issues), full findings table (severity, confidence, category, description), and overall risk assessment for proceeding as-is.
-    </template-output>
-  </step>
-
-  <step n="4" title="Incorporate Findings">
-    <action>Read the adversarial review report just generated at {planning_artifacts}/adversarial-review-{target}-{date}.md</action>
-    <action>Extract critical and high severity findings</action>
-    <action>For each critical/high finding: update the target document — add missing sections, revise decisions, strengthen weak areas, address gaps</action>
-    <action>Add a "## Review Findings Incorporated" section to the target document listing each finding, its severity, and how it was addressed (revised / added / acknowledged as risk)</action>
-    <template-output file="{target_file}">
-      Update the target document with adversarial review findings incorporated. Critical/high findings lead to document revisions. Add "Review Findings Incorporated" section.
-    </template-output>
-  </step>
-</flow>
-
-<output>
-  <format>Markdown adversarial review report</format>
-  <location>{planning_artifacts}/adversarial-review-{target}-{date}.md</location>
-</output>
-</task>

package/_gaia/core/tasks/review-api-design.xml

@@ -1,38 +0,0 @@
-<task id="review-api-design" name="API Design Review Task">
-<objective>Review REST API design against standards and best practices</objective>
-
-<critical>
-  <mandate>Check naming conventions, HTTP methods, status codes</mandate>
-  <mandate>Verify versioning strategy</mandate>
-  <mandate>Reference RFC 7807 for error responses</mandate>
-</critical>
-
-<flow>
-  <step n="1" title="Scope">
-    <action>Ask user for API specification or code to review</action>
-    <action>Read the target files</action>
-  </step>
-  <step n="2" title="Naming Conventions">
-    <action>Check resource naming: plural nouns, kebab-case, no verbs in URLs</action>
-    <action>Verify consistent naming across endpoints</action>
-  </step>
-  <step n="3" title="HTTP Methods and Status Codes">
-    <action>Verify correct HTTP method usage: GET, POST, PUT, PATCH, DELETE</action>
-    <action>Check status codes are appropriate: 2xx, 4xx, 5xx</action>
-  </step>
-  <step n="4" title="Error Format and Versioning">
-    <action>Check error response format follows RFC 7807 or consistent pattern</action>
-    <action>Verify API versioning strategy (URL, header, or query param)</action>
-  </step>
-  <step n="5" title="Report">
-    <template-output file="{planning_artifacts}/api-design-review-{date}.md">
-      Generate API design review report with findings by category (naming, HTTP methods, status codes, error format, versioning), severity levels, and recommendations.
-    </template-output>
-  </step>
-</flow>
-
-<output>
-  <format>Markdown API design findings report</format>
-  <location>{planning_artifacts}/api-design-review-{date}.md</location>
-</output>
-</task>

package/_gaia/core/tasks/review-dependency-audit.xml

@@ -1,38 +0,0 @@
-<task id="review-dependency-audit" name="Dependency Audit Task">
-<objective>Scan project dependencies for security vulnerabilities, outdated versions, and license conflicts</objective>
-
-<critical>
-  <mandate>Check for known CVEs in dependencies</mandate>
-  <mandate>Identify outdated or unmaintained packages</mandate>
-  <mandate>Flag license conflicts</mandate>
-</critical>
-
-<flow>
-  <step n="1" title="Identify Dependency Files">
-    <action>Look for: package.json, requirements.txt, pom.xml, pubspec.yaml, go.mod, Gemfile, Cargo.toml</action>
-    <action>Read all found dependency files</action>
-  </step>
-  <step n="2" title="Vulnerability Check">
-    <action>Identify dependencies with known CVEs or security advisories</action>
-    <action>Check for deprecated or abandoned packages</action>
-  </step>
-  <step n="3" title="Version Analysis">
-    <action>Flag significantly outdated dependencies (major versions behind)</action>
-    <action>Identify dependencies with no recent releases or maintenance</action>
-  </step>
-  <step n="4" title="License Check">
-    <action>Identify license types for all dependencies</action>
-    <action>Flag potential license conflicts or copyleft concerns</action>
-  </step>
-  <step n="5" title="Report">
-    <template-output file="{test_artifacts}/dependency-audit-{date}.md">
-      Generate dependency audit report with risk levels (critical, high, medium, low), prioritized by exploitability and impact. Include: vulnerability findings with CVE IDs, outdated package list, license conflict summary, and remediation recommendations.
-    </template-output>
-  </step>
-</flow>
-
-<output>
-  <format>Markdown dependency audit report with risk levels</format>
-  <location>{test_artifacts}/dependency-audit-{date}.md</location>
-</output>
-</task>

package/_gaia/core/tasks/review-edge-case-hunter.xml

@@ -1,52 +0,0 @@
-<task id="review-edge-case-hunter" name="Edge Case Hunter">
-<objective>Walk every branching path and boundary condition to find unhandled edge cases</objective>
-
-<critical>
-  <mandate>Method-driven, not attitude-driven — orthogonal to adversarial review</mandate>
-  <mandate>Exhaustively trace every decision point and boundary</mandate>
-  <mandate>Report ONLY unhandled cases — skip cases that are already covered</mandate>
-  <mandate>Include concrete examples for each edge case found</mandate>
-</critical>
-
-<flow>
-  <step n="1" title="Load Target">
-    <action>Ask user for the document/code/design to analyze</action>
-    <action>Read the entire target</action>
-    <action>Identify the type: requirements, code, API spec, user flow, etc.</action>
-  </step>
-
-  <step n="2" title="Map Decision Points">
-    <action>Identify every branching path:
-      - If/else conditions and their inverses
-      - Switch/case branches and missing default
-      - Input validation boundaries (min, max, zero, negative, null, empty)
-      - State transitions and invalid state combinations
-      - Concurrent access scenarios
-      - Error handling paths and cascading failures
-      - Timeout and retry boundaries
-      - Data type boundaries (overflow, underflow, precision)
-    </action>
-  </step>
-
-  <step n="3" title="Trace Boundaries">
-    <action>For each boundary found:
-      - Test the exact boundary value
-      - Test one above and one below
-      - Test with null/empty/missing input
-      - Test with maximum possible input
-      - Test with special characters or malformed data
-    </action>
-  </step>
-
-  <step n="4" title="Generate Report">
-    <template-output file="{planning_artifacts}/edge-case-report-{date}.md">
-      Generate edge case report with: summary (N edge cases found, M critical), findings table (location, boundary type, unhandled case, concrete example, severity), and specific trigger scenarios for each finding.
-    </template-output>
-  </step>
-</flow>
-
-<output>
-  <format>Markdown edge case report with concrete test scenarios</format>
-  <location>{planning_artifacts}/edge-case-report-{date}.md</location>
-</output>
-</task>

package/_gaia/core/tasks/review-performance.xml

@@ -1,49 +0,0 @@
-<task id="review-performance" name="Performance Review Task">
-<objective>Review code for performance issues and optimization opportunities</objective>
-
-<critical>
-  <mandate>Check for N+1 queries and inefficient database access</mandate>
-  <mandate>Identify blocking operations and memory leaks</mandate>
-  <mandate>Flag large payloads and unoptimized loops</mandate>
-</critical>
-
-<flow>
-  <step n="1" title="Scope">
-    <action>Ask user for code to review</action>
-    <action>Read the target files</action>
-  </step>
-  <step n="2" title="Baseline Metrics">
-    <action>Search for previous performance review reports in {test_artifacts}/performance-review-*.md</action>
-    <action>If a previous report exists: extract baseline metrics (response times, query counts, memory usage, payload sizes) to use as comparison benchmarks</action>
-    <action>If no previous report exists: establish initial baseline by documenting current observable performance characteristics (endpoint response times, database query counts per operation, memory footprint, payload sizes) — label these as "Initial Baseline"</action>
-    <action>Record baseline metrics for comparison in the final report</action>
-  </step>
-  <step n="3" title="Database Performance">
-    <action>Check for N+1 queries</action>
-    <action>Identify missing indexes and inefficient queries</action>
-    <action>Review database connection pooling</action>
-  </step>
-  <step n="4" title="Runtime Performance">
-    <action>Identify blocking operations and synchronous bottlenecks</action>
-    <action>Check for memory leaks, large allocations</action>
-    <action>Flag unoptimized loops and redundant computations</action>
-  </step>
-  <step n="5" title="Network and Payload">
-    <action>Check for large payloads, missing pagination</action>
-    <action>Review caching strategy</action>
-    <action>Identify unnecessary API calls or round trips</action>
-  </step>
-  <step n="6" title="Report">
-    <template-output file="{test_artifacts}/performance-review-{date}.md">
-      Generate performance review report with:
-      - Findings by category (database, runtime, network/payload), severity levels, impact estimates, and fix suggestions
-      - Baseline Comparison section: if previous report exists, show before/after metrics for each category; if first run, show "Initial Baseline Established" with current metrics recorded for future comparison
-    </template-output>
-  </step>
-</flow>
-
-<output>
-  <format>Markdown performance findings with severity and impact</format>
-  <location>{test_artifacts}/performance-review-{date}.md</location>
-</output>
-</task>

package/_gaia/core/tasks/review-security.xml

@@ -1,37 +0,0 @@
-<task id="review-security" name="Security Review Task">
-<objective>Perform OWASP-focused security review on provided code or document</objective>
-
-<critical>
-  <mandate>Check against all OWASP Top 10 categories</mandate>
-  <mandate>Flag hardcoded secrets, API keys, credentials</mandate>
-  <mandate>Check authentication and authorization patterns</mandate>
-</critical>
-
-<flow>
-  <step n="1" title="Scope">
-    <action>Ask user what code/doc to review</action>
-    <action>Read the target files</action>
-  </step>
-  <step n="2" title="OWASP Scan">
-    <action>Check each OWASP Top 10 category: Broken Access Control, Cryptographic Failures, Injection, Insecure Design, Security Misconfiguration, Vulnerable Components, Auth Failures, Data Integrity Failures, Logging Failures, SSRF</action>
-  </step>
-  <step n="3" title="Secrets Scan">
-    <action>Look for hardcoded secrets, API keys, credentials</action>
-    <action>Verify secrets management approach</action>
-  </step>
-  <step n="4" title="Auth Review">
-    <action>Verify authentication and authorization patterns</action>
-    <action>Check for privilege escalation paths</action>
-  </step>
-  <step n="5" title="Report">
-    <template-output file="{planning_artifacts}/security-review-{date}.md">
-      Generate security review report with OWASP findings table, secrets scan results, auth pattern review, severity levels (critical, high, medium, low), and remediation recommendations.
-    </template-output>
-  </step>
-</flow>
-
-<output>
-  <format>Markdown findings report with severity: critical/high/medium/low</format>
-  <location>{planning_artifacts}/security-review-{date}.md</location>
-</output>
-</task>

package/_gaia/core/tasks/shard-doc.xml

@@ -1,49 +0,0 @@
-<task id="shard-doc" name="Shard Document">
-<objective>Split a large markdown document into smaller files based on level-2 (H2) sections</objective>
-
-<critical>
-  <mandate>Default split level is H2 (##) — user can override to H1 or H3</mandate>
-  <mandate>Preserve ALL content — never drop text between sections</mandate>
-  <mandate>Generate an index.md linking to all shards</mandate>
-  <mandate>Ask user for confirmation before writing files</mandate>
-</critical>
-
-<flow>
-  <step n="1" title="Load Source">
-    <action>Ask user for the source file path</action>
-    <action>Read the entire source file</action>
-    <action>Count total lines and sections</action>
-  </step>
-
-  <step n="2" title="Parse Sections">
-    <action>Identify all sections at the split level (default: H2)</action>
-    <action>Any content before the first section becomes _preamble.md</action>
-    <action>Generate a filename for each section from its heading:
-      - Lowercase, hyphenate spaces, remove special characters
-      - Prefix with section number: 01-section-name.md
-    </action>
-  </step>
-
-  <step n="3" title="Preview Plan">
-    <action>Show user the planned file list with line counts</action>
-    <action>Ask for confirmation or adjustments</action>
-    <action>If user adjusts: update plan accordingly</action>
-  </step>
-
-  <step n="4" title="Write Shards">
-    <action>Create output directory (same name as source file, without extension)</action>
-    <action>Write each section to its file</action>
-    <action>Write index.md linking all shards with descriptions</action>
-  </step>
-
-  <step n="5" title="Report">
-    <action>Report: number of shards created, total lines distributed</action>
-    <action>Suggest running index-docs task to update parent folder index</action>
-  </step>
-</flow>
-
-<output>
-  <format>Multiple markdown files + index.md</format>
-  <location>{source-file-directory}/{source-file-name}/</location>
-</output>
-</task>

package/_gaia/core/tasks/summarize-doc.xml

@@ -1,33 +0,0 @@
-<task id="summarize-doc" name="Summarize Document">
-<objective>Generate executive summary of a long document</objective>
-
-<critical>
-  <mandate>Extract key decisions, action items, open questions</mandate>
-  <mandate>Keep summary to 1-2 pages maximum</mandate>
-  <mandate>Preserve critical nuances, don't oversimplify</mandate>
-</critical>
-
-<flow>
-  <step n="1" title="Load Document">
-    <action>Ask user for document to summarize</action>
-    <action>Read the entire document</action>
-    <action>Identify document type and purpose</action>
-  </step>
-  <step n="2" title="Extract Key Points">
-    <action>Identify main thesis or purpose</action>
-    <action>Extract key decisions made</action>
-    <action>List action items with owners if specified</action>
-    <action>Capture open questions or unresolved items</action>
-  </step>
-  <step n="3" title="Generate Summary">
-    <action>Write executive summary: purpose, key findings, decisions, next steps</action>
-    <action>Keep to 1-2 pages</action>
-    <action>Include section references for readers who want details</action>
-  </step>
-</flow>
-
-<output>
-  <format>Markdown executive summary</format>
-  <location>Displayed to user (not saved unless requested)</location>
-</output>
-</task>

package/_gaia/core/tasks/validate-framework.xml

@@ -1,66 +0,0 @@
-<task id="validate-framework" name="GAIA Framework Validation">
-<objective>Scan all GAIA framework files for consistency, broken references, and missing components</objective>
-
-<critical>
-  <mandate>Report ALL issues found — do not stop at first error</mandate>
-  <mandate>Check every path reference in every file</mandate>
-  <mandate>Verify config resolution chain works end-to-end</mandate>
-</critical>
-
-<flow>
-  <step n="1" title="File Inventory">
-    <action>Scan _gaia/ directory tree, count all files by type (.md, .xml, .yaml, .csv)</action>
-    <action>Compare against expected counts from GT-AI-PLAN.md</action>
-  </step>
-
-  <step n="2" title="Workflow Integrity">
-    <action>For each workflow.yaml: verify instructions and validation files exist</action>
-    <action>Verify config_source files exist</action>
-    <action>Check for unresolved {variable} references</action>
-  </step>
-
-  <step n="3" title="Agent Integrity">
-    <action>For each agent .md file: verify XML is well-formed</action>
-    <action>Verify each menu item path references a real file</action>
-    <action>Verify activation steps are numbered correctly</action>
-  </step>
-
-  <step n="4" title="Command Integrity">
-    <action>For each .claude/commands/gaia-*.md file: verify it references real framework files</action>
-    <action>Cross-reference gaia-help.csv — every help entry should have a matching command</action>
-  </step>
-
-  <step n="5" title="Manifest Integrity">
-    <action>Verify agent-manifest.csv has rows for all agent files found on disk</action>
-    <action>Verify workflow-manifest.csv has rows for all workflow.yaml files found</action>
-    <action>Verify task-manifest.csv has rows for all task files found</action>
-    <action>Verify skill-manifest.csv has rows for all skill files found</action>
-  </step>
-
-  <step n="6" title="Config Resolution">
-    <action>Load global.yaml and each module config.yaml — verify they parse correctly</action>
-    <action>Resolve one workflow.yaml end-to-end to verify the resolution chain</action>
-    <action>Verify .resolved/ configs match expected values</action>
-  </step>
-
-  <step n="7" title="Skill Index Integrity">
-    <action>For each entry in _skill-index.yaml: verify file exists and line ranges are valid</action>
-    <action>Verify section content at declared line ranges matches section headers</action>
-  </step>
-
-  <step n="8" title="Knowledge Index Integrity">
-    <action>For each entry in knowledge _index.csv files: verify fragment file exists</action>
-    <action>Verify each fragment is under 200 lines</action>
-  </step>
-
-  <step n="9" title="Report">
-    <action>Generate framework validation report</action>
-    <action>Format: PASS/FAIL overall + itemized findings</action>
-    <action>Group by: critical (broken references), warning (missing optional), info (suggestions)</action>
-  </step>
-</flow>
-
-<output>
-  <format>Markdown report with PASS/FAIL status and itemized findings</format>
-</output>
-</task>

package/_gaia/core/workflows/brainstorming/steps/step-01-session-setup.md

@@ -1,7 +0,0 @@
-# Step 1: Session Setup
-
-1. Ask the user what they want to brainstorm about
-2. Clarify the scope: is this a broad exploration or a focused problem?
-3. Ask about constraints: time, budget, technical, team size
-4. Determine the desired output format: list, ranked, categorized, action plan
-5. Set the session tone: wild ideas welcome vs. practical solutions only

package/_gaia/core/workflows/brainstorming/steps/step-02-technique-selection.md

@@ -1,20 +0,0 @@
-# Step 2: Technique Selection
-
-Based on the session goal, suggest 2-3 appropriate brainstorming techniques:
-
-## Available Techniques
-
-| Technique | Best For | Description |
-|-----------|----------|-------------|
-| Mind Mapping | Exploring a broad topic | Start with central concept, branch out |
-| SCAMPER | Improving existing ideas | Substitute, Combine, Adapt, Modify, Put to other use, Eliminate, Reverse |
-| Reverse Brainstorming | Finding hidden problems | "How could we make this fail?" then invert |
-| Six Thinking Hats | Balanced perspective | Examine from 6 angles: facts, emotions, caution, benefits, creativity, process |
-| Brainwriting | Rapid idea generation | Generate ideas silently, build on others |
-| Worst Possible Idea | Breaking creative blocks | Start with terrible ideas, find the good in them |
-| SWOT | Strategic analysis | Strengths, Weaknesses, Opportunities, Threats |
-| How Might We | Reframing problems | Convert problems into opportunity statements |
-
-1. Present the recommended techniques with rationale
-2. Let the user choose which technique(s) to use
-3. Explain how the selected technique works

package/_gaia/core/workflows/brainstorming/steps/step-03-technique-execution.md

@@ -1,11 +0,0 @@
-# Step 3: Technique Execution
-
-1. Run the selected technique step by step
-2. For each round:
-   - Generate 5-10 ideas based on the technique's methodology
-   - Present ideas to user for reaction
-   - Build on user feedback to generate more ideas
-   - Capture all ideas without filtering
-3. If using multiple techniques, run each sequentially
-4. Aim for 15-30 total ideas before moving to organization
-5. Encourage quantity over quality at this stage