@ncoderz/awa 1.7.2 → 1.8.0

package/templates/awa/_tests/copilot/.github/prompts/awa.spec-merge.prompt.md

@@ -0,0 +1,102 @@
+---
+description: Merge two feature codes into one using awa spec merge
+argument-hint: "<source-code> <target-code>"
+---
+
+# Merge Two Feature Codes
+
+## Bootstrap
+
+<tool name="read_file">
+ <read path=".awa/.agent/awa.core.md" required="true" error="on not found" />
+ <read path=".awa/rules/*.md" required="true" />
+ <read path=".awa/specs/ARCHITECTURE.md" required="true" error="on not found" />
+</tool>
+
+## User Input
+
+```text
+${input}
+```
+
+You **MUST** consider the user input before proceeding (if not empty).
+
+## Inputs
+
+<file type="architecture" path=".awa/specs/ARCHITECTURE.md" />
+<file type="feat" path=".awa/specs/FEAT-{SOURCE_CODE}-*.md" required="true" />
+<file type="feat" path=".awa/specs/FEAT-{TARGET_CODE}-*.md" required="if exists" />
+<file type="requirements" path=".awa/specs/REQ-{SOURCE_CODE}-*.md" required="if exists" />
+<file type="requirements" path=".awa/specs/REQ-{TARGET_CODE}-*.md" required="if exists" />
+<file type="design" path=".awa/specs/DESIGN-{SOURCE_CODE}-*.md" required="if exists" />
+<file type="design" path=".awa/specs/DESIGN-{TARGET_CODE}-*.md" required="if exists" />
+<file type="api" path=".awa/specs/API-{SOURCE_CODE}-*.tsp" required="if exists" />
+<file type="api" path=".awa/specs/API-{TARGET_CODE}-*.tsp" required="if exists" />
+<file type="examples" path=".awa/specs/EXAMPLE-{SOURCE_CODE}-*.md" required="if exists" />
+<file type="examples" path=".awa/specs/EXAMPLE-{TARGET_CODE}-*.md" required="if exists" />
+<file type="tasks" path=".awa/tasks/TASK-{SOURCE_CODE}-*.md" required="if exists" />
+<file type="tasks" path=".awa/tasks/TASK-{TARGET_CODE}-*.md" required="if exists" />
+
+## Action
+
+Merge the source feature code into the target feature code using `awa spec merge`, following awa conventions.
+
+This combines all spec files, traceability IDs, code markers, and tests from the source code into the target code's namespace, then removes the source.
+
+## Merge Process
+
+0. PRE-VALIDATE
+   - Run `awa check` to record existing errors before proceeding
+
+1. IDENTIFY CODES
+   - Determine the source code (to be absorbed) and target code (to receive content)
+   - Verify both codes exist by checking for spec files: `awa spec codes`
+   - Confirm the merge direction with the user if ambiguous
+
+2. PREVIEW CHANGES
+   - Run `awa spec merge <source> <target> --dry-run` to see planned operations
+   - Review the output: ID remap table, file moves, renames
+   - If output looks wrong, abort and investigate
+
+3. EXECUTE MERGE
+   - Run `awa spec merge <source> <target>` to apply the merge
+
+4. CONSOLIDATE TARGET FILES
+   - List all spec files now under the target code namespace
+   - For each file type (FEAT, REQ, DESIGN, API, EXAMPLE), check if multiple files exist that should be combined
+   - Where two files of the same type cover closely related or overlapping content, merge them into one:
+     - Append the smaller file's content to the larger one
+     - Remove duplicate sections, but do not alter the wording of requirements or design components
+     - Ensure the merged file stays within schema line limits; split if needed
+   - Files that cover distinct topics should remain separate
+
+5. FIX MERGED FILES
+   - Open every merged spec file and verify content coherence
+   - Reorder content into logical order
+   - Check that REQ files have consistent requirement structure
+   - Check that DESIGN files have non-overlapping component names
+   - Ensure all files respect schema line limits; split if needed
+
+6. VALIDATE
+   - Run `awa check` to verify new status
+   - Fix any newly reported errors
+   - If no errors reported, process is complete
+
+## Outputs
+
+- Renamed spec files under the target code namespace, with recoded traceability markers
+- Optionally consolidated target files where content overlaps
+
+## Rules
+
+You SHALL always preview with `--dry-run` before executing a merge.
+You SHALL confirm the merge direction (source → target) with the user.
+You SHALL run `awa check --spec-only` after merge to verify structural integrity.
+You SHALL run `awa check` after merge if code markers were rewritten.
+You SHALL review merged file content for coherence and size limits.
+You SHALL use `--renumber` when clean sequential IDs are requested.
+You SHALL NOT merge a code into itself.
+You SHALL NOT proceed if `--dry-run` reveals unexpected stale references.
+You SHALL update user-facing documentation when the merge changes public features, CLI, or configuration.
+You SHALL clarify open points with user.
+You MAY use todos and tools as needed.

package/templates/awa/_tests/copilot/.github/prompts/awa.spec-tidy.prompt.md

@@ -0,0 +1,96 @@
+---
+description: Tidy and reorganise the specifications logically
+---
+
+# Tidy and Reorganise Specifications
+
+## Bootstrap
+
+<tool name="read_file">
+ <read path=".awa/.agent/awa.core.md" required="true" error="on not found" />
+ <read path=".awa/rules/*.md" required="true" />
+ <read path=".awa/specs/ARCHITECTURE.md" required="true" error="on not found" />
+</tool>
+
+## User Input
+
+```text
+${input}
+```
+
+You **MUST** consider the user input before proceeding (if not empty).
+
+## Inputs
+
+<file type="architecture" path=".awa/specs/ARCHITECTURE.md" />
+<file type="feat" path=".awa/specs/FEAT-{SOURCE_CODE}-*.md" required="true" />
+<file type="requirements" path=".awa/specs/REQ-{SOURCE_CODE}-*.md" required="if exists" />
+<file type="design" path=".awa/specs/DESIGN-{SOURCE_CODE}-*.md" required="if exists" />
+<file type="api" path=".awa/specs/API-{SOURCE_CODE}-*.tsp" required="if exists" />
+<file type="examples" path=".awa/specs/EXAMPLE-{SOURCE_CODE}-*.md" required="if exists" />
+<file type="tasks" path=".awa/tasks/TASK-{SOURCE_CODE}-*.md" required="if exists" />
+
+## Action
+
+Tidy and reorganise the specifications logically, following awa conventions. Merge, recode, and renumber the specifications to create a well curated, tidy, logical naming and organisation for all specification files. Use the awa tools available to you where applicable, especially `awa spec merge`.
+
+## Merge Process
+
+0. PRE-VALIDATE
+   - Run `awa check` to record existing errors before proceeding
+
+1. IDENTIFY CHANGES
+   - Find existing codes for spec files: `awa spec codes`
+   - Read through all spec files to understand their content and relationships
+   - Identify files that should be merged, recoded, or renumbered to improve logical organisation
+   - For merges, determine the source and target codes
+
+2. PREVIEW CHANGES
+   - For each planned merge, run `awa spec merge <source> <target> --dry-run` to see planned operations
+   - Review the output: ID remap table, file moves, renames
+   - For each planned recode, run `awa spec recode <code> <new-code> --dry-run` to see planned operations
+   - Review the output: ID remap table, file renames
+   - For each planned renumber, run `awa spec renumber <code> --dry-run` to see planned ID changes
+   - Review the output: ID remap table
+   - If output looks wrong, abort and investigate
+
+3. EXECUTE MERGE / RECODE / RENUMBER
+   - Run the commands without dry run to apply the changes
+
+4. CONSOLIDATE FILES
+   - Re-list all spec files
+   - For each file type (FEAT, REQ, DESIGN, API, EXAMPLE), check if multiple files exist that should be combined
+   - Where two files of the same type cover closely related or overlapping content, merge them into one:
+     - Append the smaller file's content to the larger one
+     - Remove duplicate sections, but do not alter the wording of requirements or design components
+     - Ensure the merged file stays within schema line limits; split if needed
+   - Files that cover distinct topics should remain separate
+
+5. FIX MERGED FILES
+   - Open every merged spec file and verify content coherence
+   - Reorder content into logical order
+   - Check that REQ files have consistent requirement structure
+   - Check that DESIGN files have non-overlapping component names
+   - Ensure all files respect schema line limits; split if needed
+
+6. VALIDATE
+   - Run `awa check` to verify new status
+   - Fix any newly reported errors
+   - If no errors reported, process is complete
+
+## Outputs
+
+- Well named and structured spec files with consistent codes and logical organisation
+
+## Rules
+
+You SHALL always preview with `--dry-run` before executing an awa operation.
+You SHALL run `awa check --spec-only` after reorganisation to verify structural integrity.
+You SHALL run `awa check` after reorganisation if code markers were rewritten.
+You SHALL review reorganised file content for coherence and size limits.
+You SHALL use `--renumber` when clean sequential IDs are requested.
+You SHALL NOT merge a code into itself.
+You SHALL NOT proceed if `--dry-run` reveals unexpected stale references.
+You SHALL update user-facing documentation when the reorganisation changes public features, CLI, or configuration.
+You SHALL clarify open points with user.
+You MAY use todos and tools as needed.

package/templates/awa/_tests/copilot/.github/prompts/awa.tasks.prompt.md

@@ -0,0 +1,158 @@
+---
+description: Create or update task list document
+argument-hint: "<design> [<instructions>]"
+---
+
+# Create or Update Task List(s)
+
+## Bootstrap
+
+<tool name="read_file">
+ <read path=".awa/.agent/awa.core.md" required="true" error="on not found" />
+ <read path=".awa/rules/*.md" required="true" />
+ <read path=".awa/specs/ARCHITECTURE.md" required="true" error="on not found" />
+ <read path=".awa/.agent/schemas/DESIGN.schema.yaml" optional="true" />
+ <read path=".awa/.agent/schemas/REQ.schema.yaml" optional="true" />
+ <read path=".awa/.agent/schemas/TASK.schema.yaml" required="true" error="on not found" />
+</tool>
+
+## User Input
+
+```text
+${input}
+```
+
+You **MUST** consider the user input before proceeding (if not empty).
+
+## Inputs
+
+<file type="architecture" path=".awa/specs/ARCHITECTURE.md" />
+<file type="feat" path=".awa/specs/FEAT-{CODE}-{feature-name}.md" required="if relevant" />
+<file type="examples" path=".awa/specs/EXAMPLE-{CODE}-{feature-name}-{nnn}.md" required="if relevant" />
+<file type="requirements" path=".awa/specs/REQ-{CODE}-{feature-name}.md" required="if relevant" />
+<file type="design" path=".awa/specs/DESIGN-{CODE}-{feature-name}.md" required="if relevant" />
+<file type="api" path=".awa/specs/API-{CODE}-{feature-name}.md" required="if relevant" />
+
+## Action
+
+Update or create the task list document(s) as specified in the instruction above, following awa conventions.
+
+## Process
+
+1. PARSE REQ
+   - Extract requirements ({CODE}-{n}) with priorities (must/should/could)
+   - Extract acceptance criteria ({CODE}-{n}[.{p}]_AC-{m}) with types
+   - Note dependencies between requirements
+   - Identify testable criteria
+
+2. PARSE DESIGN
+   - Extract components ({CODE}-{ComponentName}) and interfaces
+   - Map IMPLEMENTS references (component → ACs)
+   - Extract properties ({CODE}_P-{n}) and VALIDATES references
+   - Note architectural decisions and constraints
+   - Extract error types for error handling tasks
+
+3. IF ARCH PROVIDED
+   - Extract project structure for file paths
+   - Extract technology stack for setup tasks
+   - Note architectural rules as constraints
+
+4. GENERATE TASKS
+   - Phase 1: Setup (project initialization, dependencies)
+   - Phase 2: Foundation (shared types, core interfaces, error types)
+   - Phase 3+: One phase per requirement (priority order: must → should → could)
+   - Final Phase: Integration and polish
+   - Include test tasks based on properties and ACs
+
+5. VALIDATE
+   - Every AC has at least one implementing task
+   - Every P has a test task
+   - No orphan tasks (all trace to AC or P)
+   - Dependencies respect component order from DESIGN
+
+## Task Organization
+
+### From Requirements
+
+- Each requirement ({CODE}-{n}) becomes a phase (priority order)
+- All ACs for that requirement → tasks within its phase
+- Subrequirements ({CODE}-{n}.{p}) nest under parent phase
+
+### From Design Components
+
+- Each component → one or more implementation tasks
+- Component's IMPLEMENTS list → task's IMPLEMENTS line
+- Component interface → task description specifics
+
+### From Properties
+
+- Each property ({CODE}_P-{n}) → test task
+- Property's VALIDATES list → determines test assertions
+- Property type determines test approach:
+  - Invariants → property-based tests
+  - Specific behaviors → example-based tests
+
+### From Error Types
+
+- Each error type → error handling task in Foundation phase
+- Error variants → validation tasks in relevant requirement phases
+
+## Phase Structure
+
+### Phase 1: Setup
+
+- Project initialization
+- Dependency installation
+- Configuration scaffolding
+- No requirement labels, no IMPLEMENTS lines
+
+### Phase 2: Foundation
+
+- Core types from DESIGN dataModels
+- Error types from DESIGN errorHandling
+- Shared interfaces
+- No requirement labels, IMPLEMENTS only if AC covers foundation
+
+### Phase 3+: Requirements (priority order)
+
+Within each requirement phase:
+1. Types/models specific to this requirement
+2. Implementation tasks (component by component)
+3. Test tasks (properties first, then direct AC tests)
+
+Each phase should be independently testable after completion.
+
+### Final Phase: Polish
+
+- Integration tests across requirements
+- Cross-cutting concerns
+- No requirement labels
+
+### Documentation Phase
+
+- Documentation update tasks for any changed user-facing behavior, CLI, API, or configuration
+- If no user-facing changes, include a single task: "No doc changes — internal only"
+- No requirement labels, no IMPLEMENTS lines
+
+## Validation Checklist
+
+Before output, verify:
+
+- [ ] Every task has correct format (checkbox, ID, description, path)
+- [ ] Every AC appears in at least one IMPLEMENTS line
+- [ ] Every P appears in at least one TESTS line
+- [ ] Requirement labels only on requirement phase tasks
+- [ ] [P] markers only where truly parallelizable
+- [ ] Dependencies match DESIGN component order
+- [ ] Each requirement phase has clear test criteria
+- [ ] Trace summary accounts for all ACs and Ps
+- [ ] Documentation phase present with doc update tasks or explicit "no changes" task
+
+## Outputs
+
+<file path=".awa/tasks/TASK-{CODE}-{feature-name}-{nnn}.md" />
+
+## Rules
+
+You SHALL clarify open points with user.
+You MAY use todos and tools as needed.

package/templates/awa/_tests/copilot/.github/prompts/awa.upgrade.prompt.md

@@ -0,0 +1,68 @@
+---
+description: Upgrade specs to match current schemas
+argument-hint: "[<upgrade-instructions>]"
+---
+
+# Upgrade Specs to Current Schemas
+
+## Bootstrap
+
+<tool name="read_file">
+ <read path=".awa/.agent/awa.core.md" required="true" error="on not found" />
+ <read path=".awa/rules/*.md" required="true" />
+ <read path=".awa/specs/ARCHITECTURE.md" required="true" error="on not found" />
+ <read path=".awa/.agent/schemas/ARCHITECTURE.schema.yaml" required="true" error="on not found" />
+ <read path=".awa/.agent/schemas/FEAT.schema.yaml" required="true" error="on not found" />
+ <read path=".awa/.agent/schemas/EXAMPLE.schema.yaml" required="true" error="on not found" />
+ <read path=".awa/.agent/schemas/REQ.schema.yaml" required="true" error="on not found" />
+ <read path=".awa/.agent/schemas/DESIGN.schema.yaml" required="true" error="on not found" />
+ <read path=".awa/.agent/schemas/TASK.schema.yaml" required="true" error="on not found" />
+ <read path=".awa/.agent/schemas/PLAN.schema.yaml" required="true" error="on not found" />
+ <read path=".awa/.agent/schemas/ALIGN_REPORT.schema.yaml" required="true" error="on not found" />
+</tool>
+
+## User Input
+
+```text
+${input}
+```
+
+You **MUST** consider the user input before proceeding (if not empty).
+
+## Inputs
+
+<file type="architecture" path=".awa/specs/ARCHITECTURE.md" />
+<file type="feat" path=".awa/specs/FEAT-{CODE}-{feature-name}.md" required="if exists" />
+<file type="examples" path=".awa/specs/EXAMPLE-{CODE}-{feature-name}-{nnn}.md" required="if exists" />
+<file type="requirements" path=".awa/specs/REQ-{CODE}-{feature-name}.md" required="if exists" />
+<file type="design" path=".awa/specs/DESIGN-{CODE}-{feature-name}.md" required="if exists" />
+<file type="api" path=".awa/specs/API-{CODE}-{feature-name}.md" required="if exists" />
+<file type="tasks" path=".awa/tasks/TASK-{CODE}-{feature-name}-{nnn}.md" required="if exists" />
+<file type="plan" path=".awa/plans/PLAN-{nnn}-{plan-name}.md" required="if exists" />
+<file type="align_report" path=".awa/alignment/ALIGN-{x}-WITH-{y}-{nnn}.md" required="if exists" />
+<file type="code" required="if relevant" />
+
+
+## Action
+
+Upgrade the specified specs to conform to their schemas and traceability rules.
+
+1) ORIENT: Confirm which artifacts to upgrade; clarify missing targets.
+2) CHECK: Run `awa check` in the terminal to identify schema violations and traceability errors across all target files. Parse the output to build a list of findings to fix.
+3) FIX: For each reported error, edit the file to resolve the violation — fix section structure, heading levels, missing required content, prohibited patterns, and broken trace IDs.
+4) RECHECK: Run `awa check` again to verify all errors are resolved. Repeat FIX → RECHECK until the check passes cleanly (warnings and info findings are acceptable).
+5) REPORT: Summarize changes and remaining questions before finalizing.
+
+## Outputs
+
+- Updated spec(s) and supporting templates (as applicable)
+
+## Rules
+
+You SHALL avoid destructive edits; propose clarifications when unsure.
+You SHALL follow schema structure strictly (section order, nesting).
+You SHALL obey schema render expectations (omit optional empty sections, avoid prohibited patterns).
+You SHALL upgrade existing trace IDs if necessary.
+You SHALL upgrade existing filenames if necessary.
+You SHALL respect the file line-limits; split logically if needed.
+You MAY use todos and tools as needed.

package/templates/awa/_tests/copilot/.github/prompts/awa.vibe.prompt.md

@@ -0,0 +1,72 @@
+---
+description: Implement an idea from start to finish using the full awa workflow
+argument-hint: "<idea> [<constraints>]"
+---
+
+# Vibe: Idea to Implementation
+
+## Bootstrap
+
+<tool name="read_file">
+ <read path=".awa/.agent/awa.core.md" required="true" error="on not found" />
+ <read path=".awa/rules/*.md" required="true" />
+ <read path=".awa/specs/ARCHITECTURE.md" required="if exists" />
+</tool>
+
+## User Input
+
+```text
+${input}
+```
+
+You **MUST** consider the user input before proceeding (if not empty).
+
+## Inputs
+
+<file type="architecture" path=".awa/specs/ARCHITECTURE.md" />
+<file type="feat" path=".awa/specs/FEAT-{CODE}-{feature-name}.md" required="if relevant" />
+<file type="examples" path=".awa/specs/EXAMPLE-{CODE}-{feature-name}-{nnn}.md" required="if relevant" />
+<file type="requirements" path=".awa/specs/REQ-{CODE}-{feature-name}.md" required="if relevant" />
+<file type="design" path=".awa/specs/DESIGN-{CODE}-{feature-name}.md" required="if relevant" />
+<file type="api" path=".awa/specs/API-{CODE}-{feature-name}.md" required="if relevant" />
+<file type="tasks" path=".awa/tasks/TASK-{CODE}-{feature-name}-{nnn}.md" required="if relevant" />
+<file type="code" required="if relevant" />
+
+## Action
+
+Take an idea from concept to working implementation, flowing through the awa workflow in the standard direction.
+
+## Process
+
+1. UNDERSTAND: Clarify idea, scope, constraints. Determine starting point.
+2. Flow through stages, creating/updating specs as needed
+3. Checkpoint at each transition: confirm direction with user
+4. Implement code with traceability, write tests
+5. Verify all acceptance criteria satisfied
+
+## Checkpoints
+
+Pause at each stage transition unless user requests autonomous mode:
+- "Architecture defined. Proceed to feature context?"
+- "Feature context captured. Proceed to requirements?"
+- "Requirements captured. Proceed to design?"
+- "Design complete. Proceed to implementation?"
+- "Implementation complete. Update documentation?"
+
+## Outputs
+
+- Specs as needed (ARCHITECTURE, FEAT, REQ, DESIGN, TASK)
+- Implemented code with traceability markers
+- Tests covering acceptance criteria
+- Updated documentation if user-facing behavior changed
+
+## Rules
+
+You SHALL flow through stages in order, skipping only what exists or isn't needed.
+You SHALL pause at checkpoints unless user requests autonomous mode.
+You SHALL maintain traceability throughout.
+You SHOULD keep each stage minimal; avoid overengineering.
+You SHOULD ask clarifying questions early, not mid-implementation.
+You MAY collapse stages for trivial changes.
+You SHALL update user-facing documentation when implementation changes user-facing behavior, CLI, API, or configuration.
+You MAY use todos and tools as needed.

package/templates/awa/_tests/copilot/.github/skills/awa-align/SKILL.md

@@ -0,0 +1,67 @@
+---
+name: awa-align
+description: Align of source with target. Use this when asked to validate, check, or verify alignment between artifacts.
+---
+
+# Validate Alignment of Source(x) with Target(y)
+
+## Bootstrap
+
+<tool name="read_file">
+ <read path=".awa/.agent/awa.core.md" required="true" error="on not found" />
+ <read path=".awa/rules/*.md" required="true" />
+ <read path=".awa/specs/ARCHITECTURE.md" required="true" error="on not found" />
+ <read path=".awa/.agent/schemas/ALIGN_REPORT.schema.yaml" required="true" error="on not found" />
+</tool>
+
+## User Input
+
+```text
+${input}
+```
+
+Format: `<source> [<target>]` where:
+- **Source (x)**: The artifact being validated. If not specified, use the last completed work.
+- **Target (y)**: The artifact to validate against. If not specified, it is implied according to these rules:
+
+1. x is plan → ask for clarification
+2. previous work against a plan → use that plan
+3. else → walk UP workflow toward architecture
+
+You **MUST** consider the user input before proceeding (if not empty).
+
+## Definitions
+
+x = source artifact (what is being validated) = design(s).
+y = target artifact (what x is validated against) = requirement(s).
+
+## Inputs
+
+<file type="architecture" path=".awa/specs/ARCHITECTURE.md" />
+<file type="feat" path=".awa/specs/FEAT-{CODE}-{feature-name}.md" required="if relevant" />
+<file type="examples" path=".awa/specs/EXAMPLE-{CODE}-{feature-name}-{nnn}.md" required="if relevant" />
+<file type="requirements" path=".awa/specs/REQ-{CODE}-{feature-name}.md" required="if relevant" />
+<file type="design" path=".awa/specs/DESIGN-{CODE}-{feature-name}.md" required="if relevant" />
+<file type="api" path=".awa/specs/API-{CODE}-{feature-name}.md" required="if relevant" />
+<file type="tasks" path=".awa/tasks/TASK-{CODE}-{feature-name}-{nnn}.md" required="if relevant" />
+<file type="plan" path=".awa/plans/PLAN-{nnn}-{plan-name}.md" required="if relevant" />
+<file type="code_and_tests" path="various" required="if relevant" />
+
+## Action
+
+Validate that the specified source:x aligns with the target:y, and if not, report all differences.
+Follow awa conventions.
+
+## Outputs
+
+<file path=".awa/align/ALIGN-{x}-WITH-{y}-{nnn}.md" />
+<cli>STATUS: {PASSED ✅ | FAILED ❌}</cli>
+
+## Rules
+
+You SHALL validate alignment of source:y with target:y.
+You SHALL report all differences.
+You SHALL consider traceability.
+You SHALL report missing trace IDs.
+You MAY use todos and tools as needed.
+

package/templates/awa/_tests/copilot/.github/skills/awa-architecture/SKILL.md

@@ -0,0 +1,50 @@
+---
+name: awa-architecture
+description: Create or update ARCHITECTURE.md. Use this when asked to create, update or modify the project architecture.
+---
+
+# Create or Update Architecture
+
+## Bootstrap
+
+<tool name="read_file">
+ <read path=".awa/.agent/awa.core.md" required="true" error="on not found" />
+ <read path=".awa/rules/*.md" required="true" />
+ <read path=".awa/specs/ARCHITECTURE.md" required="if exists" />
+ <read path=".awa/.agent/schemas/ARCHITECTURE.schema.yaml" required="true" error="on not found" />
+</tool>
+
+## User Input
+
+```text
+${input}
+```
+
+You **MUST** consider the user input before proceeding (if not empty).
+
+## Inputs
+
+<file type="architecture" path=".awa/specs/ARCHITECTURE.md" if="exists" />
+<file type="code" required="if reverse workflow" />
+
+## Action
+
+Update or create the architecture document as specified in the instruction above, following awa conventions.
+
+If deriving from existing code (reverse workflow), analyze the codebase to extract architectural patterns, technology stack, and component structure.
+
+## Outputs
+
+<file path=".awa/specs/ARCHITECTURE.md" />
+
+## Rules
+
+You SHALL solidify architecture changes with respect to existing architecture if any.
+You SHALL ensure high-level system structure, technology stack, and component relationships.
+You SHALL ensure each section of the architecture is addressed.
+You SHALL establish architectural rules and constraints.
+You SHALL focus on top-level architecture, not design.
+You SHOULD keep architecture at a manageable level of detail.
+You SHALL support reverse workflow: deriving architecture from existing code when requested.
+You SHALL clarify open points with user.
+You MAY use todos and tools as needed.

package/templates/awa/_tests/copilot/.github/skills/awa-brainstorm/SKILL.md

@@ -0,0 +1,57 @@
+---
+name: awa-brainstorm
+description: Brainstorm ideas, explore solutions, and evaluate options. Use this when asked to brainstorm, explore ideas, or analyze trade-offs.
+---
+
+# Brainstorm Ideas
+
+## Bootstrap
+
+<tool name="read_file">
+ <read path=".awa/.agent/awa.core.md" required="true" error="on not found" />
+ <read path=".awa/rules/*.md" required="true" />
+ <read path=".awa/specs/ARCHITECTURE.md" required="if exists" />
+</tool>
+
+## User Input
+
+```text
+${input}
+```
+
+You **MUST** consider the user input before proceeding (if not empty).
+
+## Inputs
+
+<file type="architecture" path=".awa/specs/ARCHITECTURE.md" />
+<file type="feat" path=".awa/specs/FEAT-{CODE}-{feature-name}.md" required="if relevant" />
+<file type="examples" path=".awa/specs/EXAMPLE-{CODE}-{feature-name}-{nnn}.md" required="if relevant" />
+<file type="requirements" path=".awa/specs/REQ-{CODE}-{feature-name}.md" required="if relevant" />
+<file type="design" path=".awa/specs/DESIGN-{CODE}-{feature-name}.md" required="if relevant" />
+<file type="api" path=".awa/specs/API-{CODE}-{feature-name}.md" required="if relevant" />
+<file type="tasks" path=".awa/tasks/TASK-{CODE}-{feature-name}-{nnn}.md" required="if relevant" />
+<file type="code" required="if relevant" />
+
+## Action
+
+Brainstorm ideas and explore solutions for the specified topic.
+
+1. DIVERGE: Generate multiple distinct approaches without filtering
+2. ANALYZE: Evaluate options against constraints and trade-offs
+3. CONVERGE: Recommend top candidates with rationale
+
+## Outputs
+
+<cli>Brainstorm summary in conversation</cli>
+<file path=".awa/plans/PLAN-{nnn}-{brainstorm-topic}.md" if="user requests formalization" />
+
+## Rules
+
+You SHALL explore multiple distinct approaches before converging.
+You SHALL identify trade-offs honestly, not just pros.
+You SHALL distinguish between facts and assumptions.
+You SHOULD challenge assumptions and explore alternatives.
+You SHALL NOT dismiss ideas prematurely during divergence.
+You SHALL engage in dialogue; ask clarifying questions.
+You MAY use web search for research and validation.
+You MAY use todos and tools as needed.