@ncoderz/awa 1.0.0 → 1.2.0

package/templates/awa/.awa/.agent/schemas/PLAN.schema.yaml

@@ -0,0 +1,151 @@
+# Structural rules for PLAN-{nnn}-{plan-name}.md files
+target-files: ".awa/plans/PLAN-*.md"
+description: >
+  Ad-hoc plan for features, improvements, refactors, or other work.
+  Succinct language. Break down work into actionable steps (checkbox items).
+  Status and direction metadata required. Structure is flexible —
+  organize sections as the plan demands. Plans should not contain significant
+  code (short snippets for explanation are fine).
+  Traceability links to REQ/DESIGN/code/tests are optional but encouraged.
+line-limit: 500
+
+sections:
+  # H1 title with status/direction metadata
+  - heading: ".*"
+    level: 1
+    required: true
+    description: >
+      Plan title. Descriptive but concise (e.g., "Refactor Config Loader",
+      "Add Diff Preview Feature"). Followed immediately by STATUS and
+      DIRECTION metadata lines, and optional TRACEABILITY links.
+    contains:
+      - pattern: "^STATUS:"
+        label: "STATUS declaration"
+        description: >
+          Current plan status. One of: in-progress, completed, blocked.
+          Format: STATUS: in-progress
+      - pattern: "^DIRECTION:"
+        label: "DIRECTION declaration"
+        description: >
+          Workflow direction for this plan. One of: top-down (architecture
+          first), bottom-up (implementation first), lateral (cross-cutting).
+          Format: DIRECTION: top-down
+
+  # Context section (optional)
+  - heading: "Context"
+    level: 2
+    description: >
+      Why this plan exists. What problem or goal it addresses.
+      Brief — one or two paragraphs. Reference FEAT/REQ docs if they exist
+      rather than restating.
+
+  # Steps section (optional — steps may also appear in domain-specific H2s)
+  - heading: "Steps"
+    level: 2
+    description: >
+      Actionable steps as checkbox items. The core of the plan.
+      Format: - [ ] Step description
+      Mark completed steps with [x]. Group with H3 subsections if needed.
+      Each step should be concrete and verifiable.
+
+  # Risks section (optional)
+  - heading: "Risks"
+    level: 2
+    description: >
+      Known risks, unknowns, or potential blockers. Bullet list.
+      Include mitigation strategies where possible.
+
+  # Dependencies section (optional)
+  - heading: "Dependencies"
+    level: 2
+    description: >
+      Prerequisites or upstream work that must complete first.
+      Reference other plans, tasks, or external factors.
+
+  # Completion Criteria section (optional)
+  - heading: "Completion Criteria"
+    level: 2
+    description: >
+      How to know when this plan is done. Concrete, verifiable conditions.
+      Format: - [ ] Criterion description
+
+  # Open Questions section (optional)
+  - heading: "Open Questions"
+    level: 2
+    description: >
+      Unresolved questions needing clarification from the user or team.
+      Format: - [ ] Question (resolved questions marked [x] with answer).
+
+  # References section (optional)
+  - heading: "References"
+    level: 2
+    description: >
+      Links to related artifacts: REQ, DESIGN, TASK, FEAT, code files,
+      external docs. Format: - {artifact}: {path or description}
+
+  # Change Log section (optional)
+  - heading: "Change Log"
+    level: 2
+    description: "Version history. Format: - {version} ({date}): {changes}"
+
+sections-prohibited:
+  - "**"
+
+example: |
+  # Refactor Config Loader
+
+  STATUS: in-progress
+  DIRECTION: bottom-up
+  TRACEABILITY: REQ-CFG-config.md, DESIGN-CFG-config.md
+
+  ## Context
+
+  The config loader has grown organically and now mixes parsing, validation,
+  and merging in a single function. This makes it hard to test and extend.
+  Split into discrete pipeline stages.
+
+  ## Steps
+
+  - [x] Extract TOML parsing into standalone function
+  - [x] Extract validation into ConfigValidator
+  - [ ] Extract merge logic into ConfigMerger
+  - [ ] Update all call sites to use new pipeline
+  - [ ] Remove old monolithic load function
+
+  ### Testing
+
+  - [ ] Add property tests for ConfigMerger (CLI overrides file)
+  - [ ] Add unit tests for ConfigValidator edge cases
+  - [ ] Verify integration test still passes end-to-end
+
+  ## Risks
+
+  - Merge logic has implicit ordering assumptions that may break when extracted
+  - Call sites in CLI layer may depend on intermediate state
+
+  ## Dependencies
+
+  - TASK-CFG-config-001.md Phase 3 must be complete (defines the types)
+
+  ## Completion Criteria
+
+  - [ ] All existing tests pass
+  - [ ] New property tests cover merge invariants
+  - [ ] No function exceeds 40 lines
+  - [ ] Config pipeline is documented in DESIGN
+
+  ## Open Questions
+
+  - [x] Should validation happen before or after merge? — After merge (validate final state)
+  - [ ] Do we need a separate error type for merge failures?
+
+  ## References
+
+  - REQ: .awa/specs/REQ-CFG-config.md
+  - DESIGN: .awa/specs/DESIGN-CFG-config.md
+  - Code: src/core/config.ts
+
+  ## Change Log
+
+  - 001 (2025-06-15): Initial plan
+  - 002 (2025-06-18): Completed parsing extraction

package/templates/awa/.awa/.agent/schemas/README.schema.yaml

@@ -0,0 +1,137 @@
+# Structural rules for README.md
+target-files: "README.md"
+description: >
+  Project README. Succinct, user-facing language. Link to detailed docs in
+  /docs folder rather than including lengthy content inline. Required sections:
+  title, description, installation, and usage. Keep it concise — the README
+  is the front door, not the whole house.
+line-limit: 500
+
+sections:
+  # Project title (H1)
+  - heading: ".*"
+    level: 1
+    required: true
+    description: >
+      Project name as H1. Optionally followed by badge images and a one-paragraph
+      description of what the project does and why it exists.
+
+  # Features section (optional)
+  - heading: "Features"
+    level: 2
+    description: "Bullet list of key features. Keep to 5-10 items."
+
+  # Installation section
+  - heading: "Installation"
+    level: 2
+    required: true
+    description: >
+      How to install the project. May contain Prerequisites and Install
+      subsections. Include code blocks with shell commands.
+    contains:
+      - code-block: true
+        label: "install command"
+        description: "Shell command(s) to install the project."
+
+  # Usage section
+  - heading: "Usage"
+    level: 2
+    required: true
+    description: >
+      Quick start example showing minimal usage. Include at least one code block.
+      Additional examples can be H3 subsections.
+    contains:
+      - code-block: true
+        label: "usage example"
+        description: "Code block demonstrating basic usage."
+
+  # Documentation section (optional)
+  - heading: "Documentation"
+    level: 2
+    description: >
+      Links to detailed documentation in /docs folder.
+      Format: - [Title](docs/file.md) - Description
+
+  # Contributing section (optional)
+  - heading: "Contributing"
+    level: 2
+    description: "Brief instructions or link to CONTRIBUTING.md."
+
+  # License section (optional)
+  - heading: "License"
+    level: 2
+    description: "License name and link to LICENSE file."
+
+  # Acknowledgments section (optional)
+  - heading: "Acknowledgments"
+    level: 2
+    description: "Credits to libraries, tools, or contributors."
+
+example: |
+  # awa CLI
+
+  [![npm version](https://img.shields.io/npm/v/awa-cli.svg)](https://www.npmjs.com/package/awa-cli)
+  [![License: MIT](https://img.shields.io/badge/License-MIT-blue.svg)](LICENSE)
+
+  awa CLI generates AI coding agent configuration files from templates, enabling developers to quickly scaffold consistent agent setups across projects.
+
+  ## Features
+
+  - Template-based configuration generation
+  - Feature flag support for conditional content
+  - Multiple output formats (Markdown, YAML, JSON)
+  - Diff mode to preview changes before applying
+  - Local and remote template sources
+
+  ## Installation
+
+  ### Prerequisites
+
+  - Node.js 20 or higher
+  - npm or pnpm
+
+  ### Install
+
+  ```bash
+  npm install -g awa-cli
+  ```
+
+  ## Usage
+
+  ```bash
+  # Generate configuration from default template
+  awa generate
+
+  # Generate with specific features enabled
+  awa generate --features typescript,testing
+
+  # Preview changes without writing files
+  awa diff
+  ```
+
+  ### Examples
+
+  #### Custom Template
+
+  ```bash
+  awa generate --template ./my-templates --output ./.ai
+  ```
+
+  ## Documentation
+
+  - [Configuration Guide](docs/configuration.md) — Configure templates and options
+  - [Template Authoring](docs/templates.md) — Create custom templates
+  - [CLI Reference](docs/cli-reference.md) — Complete command documentation
+
+  ## Contributing
+
+  See [CONTRIBUTING.md](CONTRIBUTING.md) for guidelines.
+
+  ## License
+
+  [MIT](LICENSE)
+
+  ## Acknowledgments
+
+  - Eta templating engine
+  - Citty CLI framework

package/templates/awa/.awa/.agent/schemas/REQ.schema.yaml

@@ -0,0 +1,169 @@
+# Structural rules for REQ-{CODE}-{feature-name}.md files
+target-files: ".awa/specs/REQ-*.md"
+description: >
+  Requirements specification using EARS (Easy Approach to Requirements Syntax).
+  Succinct language. Do not overspecify. Omit irrelevant information.
+  Each requirement has an ID ({CODE}-{n}), a user story (AS A/I WANT/SO THAT),
+  and acceptance criteria with INCOSE-compliant types.
+  Subrequirements use dotted IDs ({CODE}-{n}.{p}).
+line-limit: 500
+
+sections:
+  # Top-level heading: "Requirements Specification"
+  - heading: "Requirements Specification"
+    level: 1
+    required: true
+    description: "Document title. No metadata in this section."
+
+  # Introduction section
+  - heading: "Introduction"
+    level: 2
+    required: true
+    description: "Brief context for the requirements. One or two paragraphs."
+
+  # Glossary section (optional)
+  - heading: "Glossary"
+    level: 2
+    description: >
+      Domain terms in TERM: definition format. Use CAPITALS for term names.
+      Format: - TERM: Definition
+
+  # Stakeholders section (optional)
+  - heading: "Stakeholders"
+    level: 2
+    description: >
+      Roles that interact with or are affected by this feature.
+      Format: - ROLE: Description
+
+  # Requirements section with repeatable requirement headings
+  - heading: "Requirements"
+    level: 2
+    required: true
+    description: >
+      Container for all requirements. Each child heading is a requirement
+      with ID, title, optional priority, user story, and acceptance criteria.
+    children:
+      - heading: "[A-Z]+-\\d+.*"
+        level: 3
+        required: true
+        repeatable: true
+        description: >
+          Individual requirement heading. Format: ### {CODE}-{n}: Title [{PRIORITY}]
+          where PRIORITY is MUST, SHOULD, COULD, or WONT (optional).
+          Contains a user story, optional rationale blockquote, ACCEPTANCE CRITERIA
+          heading, AC items, and optional DEPENDS ON line.
+        contains:
+          # User story format
+          - pattern: "AS A .*, I WANT .*, SO THAT"
+            label: "user story"
+            description: >
+              User story in AS A {role}, I WANT {want}, SO THAT {benefit} format.
+              One sentence. Role, want, and benefit are all required.
+          # Acceptance criteria heading
+          - pattern: "ACCEPTANCE CRITERIA"
+            label: "AC heading"
+            description: "Literal text ACCEPTANCE CRITERIA (no markdown heading, just text)."
+          # At least one AC item
+          - list:
+              pattern: "_AC-\\d+\\s*\\[(ubiquitous|event|state|conditional|optional|complex)\\]"
+              min: 1
+              label: "acceptance criteria items"
+            description: >
+              Acceptance criteria items. Format:
+              - {CODE}-{n}_AC-{m} [{type}]: {statement} - {notes}
+              Types (EARS/INCOSE):
+              - ubiquitous: always true, no trigger ("The system SHALL ...")
+              - event: triggered by a stimulus ("WHEN x THEN system SHALL ...")
+              - state: true while a condition holds ("WHILE x THE system SHALL ...")
+              - conditional: depends on a boolean condition ("IF x THEN system SHALL ...")
+              - optional: feature activated by trigger ("WHERE x IS ENABLED THE system SHALL ...")
+              - complex: combines multiple EARS patterns
+
+  # Assumptions section (optional)
+  - heading: "Assumptions"
+    level: 2
+    description: "Bullet list of assumptions underlying the requirements."
+
+  # Constraints section (optional)
+  - heading: "Constraints"
+    level: 2
+    description: "Bullet list of constraints on the implementation."
+
+  # Out of Scope section (optional)
+  - heading: "Out of Scope"
+    level: 2
+    description: "Bullet list of explicitly excluded functionality."
+
+  # Change Log section (optional)
+  - heading: "Change Log"
+    level: 2
+    description: "Version history. Format: - {version} ({date}): {changes}"
+
+sections-prohibited:
+  - "**"
+
+example: |
+  # Requirements Specification
+
+  ## Introduction
+
+  Core engine requirements for game framework.
+
+  ## Glossary
+
+  - GAME LOOP: Core cycle of update-render that drives the engine
+  - CONTEXT: Runtime state container for engine subsystems
+
+  ## Stakeholders
+
+  - GAME DEVELOPER: Builds games using the engine API
+  - ENGINE MAINTAINER: Maintains and extends engine internals
+
+  ## Requirements
+
+  ### ENG-1: Core Engine Framework [MUST]
+
+  AS A game developer, I WANT a game loop, SO THAT predictable execution.
+
+  > Foundation for all games.
+
+  ACCEPTANCE CRITERIA
+
+  - ENG-1_AC-1 [event]: WHEN engine initializes THEN system SHALL create context
+  - ENG-1_AC-2 [event]: WHEN `--verbose` flag is provided THEN system SHALL enable debug logging
+  - ENG-1_AC-3 [ubiquitous]: The system SHALL maintain 60fps minimum frame rate
+
+  ### ENG-1.1: Subsystem Registration [SHOULD]
+
+  AS A engine maintainer, I WANT subsystems to self-register, SO THAT modular architecture.
+
+  ACCEPTANCE CRITERIA
+
+  - ENG-1.1_AC-1 [event]: WHEN subsystem loads THEN it SHALL register with context
+
+  ### ENG-2: Resource Management [MUST]
+
+  AS A game developer, I WANT automatic resource loading, SO THAT simplified asset management.
+
+  ACCEPTANCE CRITERIA
+
+  - ENG-2_AC-1 [event]: WHEN resource requested THEN system SHALL load asynchronously
+  - ENG-2_AC-2 [ubiquitous]: The system SHALL cache loaded resources
+
+  DEPENDS ON: ENG-1
+
+  ## Assumptions
+
+  - Target platform supports OpenGL 3.3 or higher
+
+  ## Constraints
+
+  - Must run on Windows, macOS, and Linux
+
+  ## Out of Scope
+
+  - Mobile platform support
+
+  ## Change Log
+
+  - 1.0.0 (2025-01-10): Initial requirements

package/templates/awa/.awa/.agent/schemas/TASK.schema.yaml

@@ -0,0 +1,200 @@
+# Structural rules for TASK-{CODE}-{feature-name}-{nnn}.md files
+target-files: ".awa/tasks/TASK-*.md"
+description: >
+  Implementation tasks only. Dependency-ordered. Traceable to REQ and DESIGN.
+  Each task has an ID (T-{CODE}-{nnn}), a description, and a target file path.
+  Phases group tasks by execution order; requirement phases carry [MUST]/[SHOULD]/[COULD]
+  priority markers and include GOAL, TEST CRITERIA, IMPLEMENTS, and TESTS lines.
+  Setup/foundation/polish phases must NOT include IMPLEMENTS or TESTS.
+line-limit: 500
+
+sections:
+  # Top-level heading: "Implementation Tasks"
+  - heading: "Implementation Tasks"
+    level: 1
+    required: true
+    description: >
+      Document title. Followed by FEATURE (name from REQ) and SOURCE
+      (comma-separated paths to REQ and DESIGN files).
+    contains:
+      - pattern: "^FEATURE:"
+        label: "FEATURE declaration"
+        description: "Feature name this task list implements (from REQ)."
+      - pattern: "^SOURCE:"
+        label: "SOURCE declaration"
+        description: "Comma-separated paths to the REQ and DESIGN source files."
+
+  # Phase headings: "## Phase N: Name [PRIORITY]"
+  - heading: "Phase \\d+:.*"
+    level: 2
+    required: true
+    repeatable: true
+    description: >
+      Numbered phases in execution order. Requirement phases append a priority
+      marker: [MUST], [SHOULD], or [COULD]. Setup/foundation/polish phases
+      have no priority marker. Each phase contains checkbox task items.
+    contains:
+      # Tasks as checkbox items: "- [ ] T-{CODE}-{nnn} ... → path"
+      - list:
+          pattern: "\\[ \\] T-[A-Z][A-Z0-9]*-\\d+"
+          min: 1
+          label: "task checkbox items"
+        description: >
+          Task items as unchecked checkboxes. Format:
+          - [ ] T-{CODE}-{nnn} [P]? [{CODE}-{n}]? Description → target/path.
+          [P] marks parallelizable tasks. [{CODE}-{n}] is the requirement ID
+          (only on requirement phases). Always unchecked in generated output.
+      # Tasks must have file path targets (→)
+      - pattern: "→"
+        label: "file path targets"
+        description: "Every task line must include → followed by the target file path."
+      # GOAL required on requirement phases (those with [MUST], [SHOULD], [COULD])
+      - pattern: "^GOAL:"
+        label: "GOAL statement"
+        description: "One-line goal for the phase, derived from the requirement's user story."
+        when:
+          heading-matches: "\\[(MUST|SHOULD|COULD)\\]"
+      # TEST CRITERIA required on requirement phases
+      - pattern: "^TEST CRITERIA:"
+        label: "TEST CRITERIA statement"
+        description: "How to verify the phase is complete."
+        when:
+          heading-matches: "\\[(MUST|SHOULD|COULD)\\]"
+      # IMPLEMENTS forbidden on setup/foundation/polish phases (no priority marker)
+      - pattern: "IMPLEMENTS:"
+        prohibited: true
+        label: "IMPLEMENTS trace line (not allowed in setup/polish phases)"
+        description: >
+          IMPLEMENTS: {CODE}-{n}[.{p}]_AC-{m} — traces a task to the AC it implements.
+          Only allowed on requirement phases (those with a priority marker).
+        when:
+          heading-not-matches: "\\[(MUST|SHOULD|COULD)\\]"
+      # TESTS forbidden on setup/foundation/polish phases
+      - pattern: "TESTS:"
+        prohibited: true
+        label: "TESTS trace line (not allowed in setup/polish phases)"
+        description: >
+          TESTS: {CODE}_P-{n} or {CODE}-{n}[.{p}]_AC-{m} — traces a task to the
+          property or AC it tests. Only allowed on requirement phases.
+        when:
+          heading-not-matches: "\\[(MUST|SHOULD|COULD)\\]"
+      # Requirement labels forbidden on setup/foundation/polish phases
+      - pattern: "\\[[A-Z]+-\\d+\\]"
+        prohibited: true
+        label: "requirement label (not allowed in setup/polish phases)"
+        description: >
+          [{CODE}-{n}] requirement labels are only allowed on requirement phases
+          (those with a priority marker like [MUST], [SHOULD], [COULD]).
+        when:
+          heading-not-matches: "\\[(MUST|SHOULD|COULD)\\]"
+
+  # Dependencies section
+  - heading: "Dependencies"
+    level: 2
+    required: true
+    description: >
+      Lists inter-requirement dependencies. Format:
+      {CODE}-{n} → {CODE}-{n} (reason) or {CODE}-{n} → (none).
+
+  # Parallel Opportunities section
+  - heading: "Parallel Opportunities"
+    level: 2
+    required: true
+    description: >
+      Identifies tasks within each phase that can execute concurrently.
+      Format: Phase N: T-{CODE}-{nnn}, T-{CODE}-{nnn} can run parallel after T-{CODE}-{nnn}.
+
+  # Requirements Traceability section
+  - heading: "Requirements Traceability"
+    level: 2
+    required: true
+    description: >
+      Trace matrix grouped by source REQ file. Each H3 is a REQ file path,
+      containing bullet entries mapping ACs to tasks and tests, followed by
+      properties to tests. Ends with UNCOVERED listing any ACs or properties
+      without task/test coverage.
+    children:
+      - heading: ".*"
+        level: 3
+        repeatable: true
+        required: true
+        description: >
+          Source REQ file heading. Format: ### REQ-{CODE}-{feature}.md
+          Followed by bullet list of AC and property trace entries.
+          AC format: - {AC-ID} → {Task} ({Test})
+          Property format: - {Property-ID} → {Test}
+    contains:
+      - pattern: "^UNCOVERED:"
+        label: "UNCOVERED declaration"
+        description: "Lists AC or property IDs that lack task/test coverage, or (none)."
+
+sections-prohibited:
+  - "**"
+
+example: |
+  # Implementation Tasks
+
+  FEATURE: Configuration System
+  SOURCE: REQ-CFG-config.md, DESIGN-CFG-config.md
+
+  ## Phase 1: Setup
+
+  - [ ] T-CFG-001 Initialize module structure → src/config/
+  - [ ] T-CFG-002 [P] Add dependencies (smol-toml) → package.json
+
+  ## Phase 2: Foundation
+
+  - [ ] T-CFG-003 Define Config and RawConfig types → src/config/types.ts
+  - [ ] T-CFG-004 Define ConfigError variants → src/config/errors.ts
+
+  ## Phase 3: Config Loading [MUST]
+
+  GOAL: Load and merge configuration from file with defaults
+  TEST CRITERIA: Can load valid TOML, missing keys get defaults
+
+  - [ ] T-CFG-010 [CFG-1] Implement load function → src/config/loader.ts
+    IMPLEMENTS: CFG-1_AC-1
+  - [ ] T-CFG-011 [CFG-1] Implement merge function → src/config/loader.ts
+    IMPLEMENTS: CFG-1_AC-2
+  - [ ] T-CFG-012 [P] [CFG-1] Property test for default preservation → tests/config/loader.test.ts
+    TESTS: CFG_P-1
+  - [ ] T-CFG-013 [P] [CFG-1] Test load from valid path → tests/config/loader.test.ts
+    TESTS: CFG-1_AC-1
+
+  ## Phase 4: Config Validation [SHOULD]
+
+  GOAL: Validate loaded config against schema
+  TEST CRITERIA: Invalid config rejected with clear error
+
+  - [ ] T-CFG-020 [CFG-2] Implement validate function → src/config/validator.ts
+    IMPLEMENTS: CFG-2_AC-1
+  - [ ] T-CFG-021 [P] [CFG-2] Test schema validation → tests/config/validator.test.ts
+    TESTS: CFG-2_AC-1
+
+  ## Phase 5: Polish
+
+  - [ ] T-CFG-030 Integration test: load → validate → use → tests/config/integration.test.ts
+    TESTS: CFG-1_AC-1, CFG-2_AC-1
+
+  ---
+
+  ## Dependencies
+
+  CFG-1 → (none)
+  CFG-2 → CFG-1 (validates loaded config)
+
+  ## Parallel Opportunities
+
+  Phase 3: T-CFG-012, T-CFG-013 can run parallel after T-CFG-011
+  Phase 4: T-CFG-021 can run parallel with T-CFG-020
+
+  ## Requirements Traceability
+
+  ### REQ-CFG-config.md
+
+  - CFG-1_AC-1 → T-CFG-010 (T-CFG-013)
+  - CFG-1_AC-2 → T-CFG-011 (T-CFG-012)
+  - CFG-2_AC-1 → T-CFG-020 (T-CFG-021)
+  - CFG_P-1 → T-CFG-012
+
+  UNCOVERED: (none)

package/templates/awa/.claude/agents/awa.md

@@ -1,7 +1,7 @@
 <% if (it.features.includes('claude')) { %>
 ---
 name: awa
-description: "awa 0.2.0"
+description: "awa <%= it.version %>"
 ---
 
 <%~ include('_partials/awa.core.md', it) %>
@@ -9,6 +9,6 @@ description: "awa 0.2.0"
 <tool name="read_file">
  <read path=".awa/rules/*.md" required="true" />
  <read path=".awa/specs/ARCHITECTURE.md" required="true" />
- <read path=".awa/.agent/schemas/*.schema.md" required="before writing corresponding file type" />
+ <read path=".awa/.agent/schemas/*.schema.yaml" required="before writing corresponding file type" />
 </tool>
 <% } %>

package/templates/awa/.claude/skills/awa-align/SKILL.md

@@ -0,0 +1,3 @@
+<% if (it.features.includes('claude')) { %>
+<%~ include('_partials/_skill.awa-align.md', it) %>
+<% } %>

package/templates/awa/.claude/skills/awa-check/SKILL.md

@@ -0,0 +1,4 @@
+<% if (it.features.includes('claude')) { %>
+<%~ include('_partials/_skill.awa-check.md', it) %>
+<% } %>
+

package/templates/awa/.claude/skills/awa-usage/SKILL.md

@@ -0,0 +1,3 @@
+<% if (it.features.includes('claude')) { %>
+<%~ include('_partials/_skill.awa-usage.md', it) %>
+<% } %>

package/templates/awa/.codex/prompts/awa-align.md

@@ -0,0 +1,3 @@
+<% if (it.features.includes('codex')) { %>
+<%~ include('_partials/_cmd.awa-align.md', it) %>
+<% } %>