aw-spec-cli 0.1.25 → 0.1.27

package/assets/.agents/skills/appweaver-demo/SKILL.md

@@ -1,59 +0,0 @@
----
-name: "appweaver-demo"
-description: "Prototype launcher (Antigravity): run the aw-orchestrator using the specified strategy (spawn, agent, sdk, sdk-apply)."
-argument-hint: "Optional strategy ('agent', 'spawn', 'sdk', 'sdk-apply') and/or k=value vars (e.g. 'agent out_dir=...')"
-compatibility: "Requires .appweaver/orchestrator/ and the gemini CLI on PATH"
-user-invocable: true
-disable-model-invocation: false
----
-
-# Orchestrator Launcher
-
-All orchestration lives in the workflow YAML and is executed by `.appweaver/orchestrator/orchestrator.py` (the general, agent-agnostic engine). The interpreter assembles the COMPLETE payload (system + user) for every request; you never author generation context yourself.
-
-- **Engine + workflow (general):** `.appweaver/orchestrator/orchestrator.py`, `*.orch.yaml`
-- **This agent's transport profile:** `.agents/agent.json`
-
-  > Antigravity spawns via the `agy` CLI (Gemini-based; no `--system-prompt`, so
-  > `system` is folded into the prompt). Its `sdk` block declares the SDK the
-  > `sdk`/`sdk-apply` strategies import (`google-antigravity`) and the adapter
-  > (`.appweaver/orchestrator/adapters/google_antigravity.py`, shared per-SDK)
-  > that owns its calling convention.
-
-## Execution Steps
-
-1. **Parse Arguments**:
-   - Identify the requested strategy (one of: `agent`, `spawn`, `sdk`, `sdk-apply`). If the user specifies a strategy as the first argument, use it. Otherwise, default to `spawn`.
-   - Always pass the strategy explicitly: `--strategy <strategy>`.
-   - `--agent-profile .agents/agent.json` is required for `spawn`, `sdk`, and `sdk-apply`:
-     `spawn` reads the CLI to launch (`agy`) from it; `sdk`/`sdk-apply` read the SDK
-     package/module (and its `adapter` file) to import from its `sdk` block.
-     If the SDK package isn't installed, add `--sdk-install` so the engine
-     pip-installs the declared package first. (`agent` needs no profile.)
-   - `--checkpoint .appweaver/orchestrator/.demo-out/demo.state.json` is required for
-     `sdk-apply` and `agent` (suspend/resume — follow the loop in step 3).
-   - `spawn` accepts `--model <name>` (e.g. `gemini-2.5-pro`); isolation is
-     best-effort for Antigravity (no `--bare` equivalent). `sdk`/`sdk-apply`
-     accept `--model <name>`; isolation is intrinsic (fresh SDK session).
-
-2. **Run the Interpreter**:
-   Run the command (include only the bracketed flags that apply to the chosen strategy):
-   ```bash
-   python3 .appweaver/orchestrator/orchestrator.py \
-     .appweaver/orchestrator/workflows/aw-spec-demo.orch.yaml \
-     --strategy <strategy> \
-     [--agent-profile .agents/agent.json]   # spawn, sdk, sdk-apply \
-     [--checkpoint .appweaver/orchestrator/.demo-out/demo.state.json]  # sdk-apply, agent \
-     --json
-   ```
-
-3. **Handle Suspend/Resume Loop (for `agent` or `sdk-apply` strategies)**:
-   - If the command exits with code `2` (suspend):
-     - Read the prompt from the sidecar file `<checkpoint-path>.user.md` (and system instructions from `<checkpoint-path>.system.md`).
-     - Fulfill the request directly using your own tools (e.g., implementing the handler or reviewing files in the workspace).
-     - Write the final generation or review output to `<checkpoint-path>.response.md`.
-     - Re-run the exact same command.
-     - Repeat until the orchestrator exits with code `0`.
-
-4. **Report**:
-   Report the final JSON outputs (`status`, `outputs`, `review_pass`, generated file paths, etc.) to the user.

package/assets/.appweaver/orchestrator/.smoke-out/smoke.md

@@ -1,6 +0,0 @@
-<!-- authored by aw-orchestrator MOCK transport -->
-<!-- target: .appweaver/orchestrator/.smoke-out/smoke.md -->
-<!-- envelope: system=[] context=['.appweaver/orchestrator/.smoke-out/smoke.md'] -->
-<!-- task chars: 48 -->
-
-# (mock content)

package/assets/.appweaver/orchestrator/workflows/aw-spec-demo.orch.yaml

@@ -1,100 +0,0 @@
-# =============================================================================
-# aw-spec-demo.orch.yaml — a runnable demo workflow for the aw-orchestrator.
-# Launch via the parametric skill:  /appweaver demo [strategy]
-#
-# It walks the exact loop from the diagram:
-#   build_context → agent_generate (fresh) → agent_review (fresh) → repeat
-#
-# Run it (safe, no model calls — prints the assembled payloads):
-#   python3 .appweaver/orchestrator/orchestrator.py .appweaver/orchestrator/workflows/aw-spec-demo.orch.yaml
-#
-# Run it for real (spawns fresh `claude -p --bare` per generation):
-#   python3 .appweaver/orchestrator/orchestrator.py .appweaver/orchestrator/workflows/aw-spec-demo.orch.yaml \
-#       --transport claude --model opus --budget 0.50
-# =============================================================================
-
-dialect: aw-spec.orchestrator/v1
-name: demo-fresh-generation
-
-vars:
-  out_dir: .appweaver/orchestrator/.demo-out
-  review_pass: "false"          # loop guard, flipped by agent_review
-
-workflow:
-
-  # 1. Builds Complete Context — the interpreter reads standards (→ system) and
-  #    any prior artifacts (→ user context). Every standard it loads is kit-resident,
-  #    so the demo runs in a bare checkout with no guardrails/ tree at all.
-  - id: ctx_generate
-    action: build_context
-    system:
-      - { path: .appweaver/ai-rules.md }   # kit-resident, so the demo needs no project tree
-    context:
-      - { path: "{{out_dir}}/spec.md", optional: true }
-
-  # 2. Invoke Claude Code (FRESH generation) — it decides the file path(s) itself
-  #    (per the loaded folder-structure/architecture standards), writes them with
-  #    its tools, and REPORTS the paths back. The interpreter binds that list.
-  - id: gen_handler
-    action: agent_generate
-    tools: "Read,Write,Edit,Bash"
-    permission_mode: acceptEdits
-    task: |
-      Implement a CQRS command handler `CreateOrderHandler` for a "Create Order"
-      feature, following the loaded Clean Architecture + CQRS standards. Keep it
-      compilable C#; no TODOs.
-    outputs:
-      - { name: gen_status,  from: "$.status" }
-      - { name: gen_summary, from: "$.summary" }
-      - { name: gen_files,   from: "$.files" }    # the paths the agent chose
-
-  # 3. Review the current output — a SECOND fresh generation, read-only, that
-  #    judges the files the generation reported and returns pass/issues.
-  - id: review_handler
-    action: agent_review
-    review_of_var: gen_files
-    task: |
-      Review the handler for compliance with the loaded standards (naming, layer
-      boundaries, CQRS separation). Decide pass/fail.
-    outputs:
-      - { name: review_pass,   from: "$.pass" }
-      - { name: review_issues, from: "$.issues" }
-
-  # 4. If review failed, rebuild context (now including the issues) and
-  #    regenerate — up to 3 times. This is the "…continues" cycle.
-  - id: revise
-    action: loop
-    while: "{{review_pass}} != true"
-    max_iterations: 3
-    steps:
-      - id: ctx_revise
-        action: build_context
-        vars:
-          issues: "{{review_issues}}"
-        system:
-          - { path: .appweaver/ai-rules.md }
-        context_from: gen_files            # the files the agent chose last round
-      - id: regen
-        action: agent_generate
-        tools: "Read,Write,Edit"
-        task: |
-          Fix these review issues in the file(s) provided in context, preserving
-          everything already correct: {{issues}}
-        outputs:
-          - { name: gen_files, from: "$.files" }
-      - id: rereview
-        action: agent_review
-        review_of_var: gen_files
-        task: Re-review after the fix. Decide pass/fail.
-        outputs:
-          - { name: review_pass,   from: "$.pass" }
-          - { name: review_issues, from: "$.issues" }
-      - id: stop_when_pass
-        action: break
-        condition: "{{review_pass}} == true"
-
-outputs:
-  generated: "{{gen_summary}}"
-  review_pass: "{{review_pass}}"
-  files: "{{gen_files}}"          # decided by the fresh agent, not the interpreter
-  next: "interpreter continues to the next workflow step"

package/assets/.claude/skills/appweaver-demo/SKILL.md

@@ -1,59 +0,0 @@
----
-name: "appweaver-demo"
-description: "Prototype launcher (Claude Code): run the aw-orchestrator using the specified strategy (spawn, agent, sdk, sdk-apply)."
-argument-hint: "Optional strategy ('agent', 'spawn', 'sdk', 'sdk-apply') and/or k=value vars (e.g. 'agent out_dir=...')"
-compatibility: "Requires .appweaver/orchestrator/ and the claude CLI on PATH"
-user-invocable: true
-disable-model-invocation: false
----
-
-# Orchestrator Launcher
-
-All orchestration lives in the workflow YAML and is executed by `.appweaver/orchestrator/orchestrator.py` (the general, agent-agnostic engine). The interpreter assembles the COMPLETE payload (system + user) for every request; you never author generation context yourself.
-
-- **Engine + workflow (general):** `.appweaver/orchestrator/orchestrator.py`, `*.orch.yaml`
-- **This agent's transport profile:** `.claude/agent.json`
-
-  > Claude Code spawns via the `claude -p` CLI (native `--system-prompt`,
-  > `--tools`, and `--bare` isolation). Its `sdk` block declares the SDK the
-  > `sdk`/`sdk-apply` strategies import (`claude-agent-sdk`) and the adapter
-  > (`.appweaver/orchestrator/adapters/claude_agent_sdk.py`, shared per-SDK)
-  > that owns its calling convention.
-
-## Execution Steps
-
-1. **Parse Arguments**:
-   - Identify the requested strategy (one of: `agent`, `spawn`, `sdk`, `sdk-apply`). If the user specifies a strategy as the first argument, use it. Otherwise, default to `spawn`.
-   - Always pass the strategy explicitly: `--strategy <strategy>`.
-   - `--agent-profile .claude/agent.json` is required for `spawn`, `sdk`, and `sdk-apply`:
-     `spawn` reads the CLI to launch from it; `sdk`/`sdk-apply` read the SDK
-     package/module (and its `adapter` file) to import from its `sdk` block.
-     If the SDK package isn't installed, add `--sdk-install` so the engine
-     pip-installs the declared package first. (`agent` needs no profile.)
-   - `--checkpoint .appweaver/orchestrator/.demo-out/demo.state.json` is required for
-     `sdk-apply` and `agent` (suspend/resume — follow the loop in step 3).
-   - `spawn` may also add `--isolation bare|fresh` and `--model <name>` (bare is
-     strongest; use it when `ANTHROPIC_API_KEY` is set). `sdk`/`sdk-apply` accept
-     `--model <name>`; isolation is intrinsic (fresh SDK session, no settings).
-
-2. **Run the Interpreter**:
-   Run the command (include only the bracketed flags that apply to the chosen strategy):
-   ```bash
-   python3 .appweaver/orchestrator/orchestrator.py \
-     .appweaver/orchestrator/workflows/aw-spec-demo.orch.yaml \
-     --strategy <strategy> \
-     [--agent-profile .claude/agent.json]   # spawn, sdk, sdk-apply \
-     [--checkpoint .appweaver/orchestrator/.demo-out/demo.state.json]  # sdk-apply, agent \
-     --json
-   ```
-
-3. **Handle Suspend/Resume Loop (for `agent` or `sdk-apply` strategies)**:
-   - If the command exits with code `2` (suspend):
-     - Read the prompt from the sidecar file `<checkpoint-path>.user.md` (and system instructions from `<checkpoint-path>.system.md`).
-     - Fulfill the request directly using your own tools (e.g., implementing the handler or reviewing files in the workspace).
-     - Write the final generation or review output to `<checkpoint-path>.response.md`.
-     - Re-run the exact same command.
-     - Repeat until the orchestrator exits with code `0`.
-
-4. **Report**:
-   Report the final JSON outputs (`status`, `outputs`, `review_pass`, generated file paths, etc.) to the user.

package/assets/.kilocode/agent.json

@@ -1,28 +0,0 @@
-{
-  "name": "kilocode",
-  "sdk": {
-    "type": "claude-agent-sdk",
-    "package": "claude-agent-sdk",
-    "module": "claude_agent_sdk",
-    "adapter": "../.appweaver/orchestrator/adapters/claude_agent_sdk.py"
-  },
-  "runtime": "Kilo Code launches the interpreter; generation delegates to the Claude Code CLI",
-  "note": "Kilo Code is a VS Code extension with no standalone headless generation CLI, so this profile reuses `claude -p` for the fresh generation. To generate via Gemini instead, replace bin/args/system/user/tools_flag/approval with the .agents (antigravity) profile's values.",
-  "bin": "claude",
-  "args": ["-p", "--output-format", "json", "--no-session-persistence"],
-  "model_flag": "--model",
-  "system": { "flag": "--system-prompt" },
-  "user": { "mode": "stdin" },
-  "tools_flag": "--tools",
-  "approval": {
-    "acceptEdits": ["--permission-mode", "acceptEdits"],
-    "bypassPermissions": ["--permission-mode", "bypassPermissions"],
-    "default": ["--permission-mode", "default"]
-  },
-  "isolation": {
-    "bare": ["--bare"],
-    "fresh": ["--setting-sources", ""]
-  },
-  "budget_flag": "--max-budget-usd",
-  "result_keys": ["result"]
-}

package/assets/.kilocode/workflows/appweaver-demo.md

@@ -1,59 +0,0 @@
----
-name: "appweaver-demo"
-description: "Prototype launcher (Kilo Code): run the aw-orchestrator using the specified strategy (spawn, agent, sdk, sdk-apply)."
-argument-hint: "Optional strategy ('agent', 'spawn', 'sdk', 'sdk-apply') and/or k=value vars (e.g. 'agent out_dir=...')"
-compatibility: "Requires .appweaver/orchestrator/ and the claude CLI on PATH"
-user-invocable: true
-disable-model-invocation: false
----
-
-# Orchestrator Launcher
-
-All orchestration lives in the workflow YAML and is executed by `.appweaver/orchestrator/orchestrator.py` (the general, agent-agnostic engine). The interpreter assembles the COMPLETE payload (system + user) for every request; you never author generation context yourself.
-
-- **Engine + workflow (general):** `.appweaver/orchestrator/orchestrator.py`, `*.orch.yaml`
-- **This agent's transport profile:** `.kilocode/agent.json`
-
-  > Kilo Code has no native headless CLI, so it reuses `claude -p` for `spawn`
-  > (native `--system-prompt`, `--tools`, `--bare` isolation). Its `sdk` block
-  > declares the SDK the `sdk`/`sdk-apply` strategies import (`claude-agent-sdk`)
-  > and the adapter (`.appweaver/orchestrator/adapters/claude_agent_sdk.py`,
-  > shared per-SDK) that owns its calling convention.
-
-## Execution Steps
-
-1. **Parse Arguments**:
-   - Identify the requested strategy (one of: `agent`, `spawn`, `sdk`, `sdk-apply`). If the user specifies a strategy as the first argument, use it. Otherwise, default to `spawn`.
-   - Always pass the strategy explicitly: `--strategy <strategy>`.
-   - `--agent-profile .kilocode/agent.json` is required for `spawn`, `sdk`, and `sdk-apply`:
-     `spawn` reads the CLI to launch from it; `sdk`/`sdk-apply` read the SDK
-     package/module (and its `adapter` file) to import from its `sdk` block.
-     If the SDK package isn't installed, add `--sdk-install` so the engine
-     pip-installs the declared package first. (`agent` needs no profile.)
-   - `--checkpoint .appweaver/orchestrator/.demo-out/demo.state.json` is required for
-     `sdk-apply` and `agent` (suspend/resume — follow the loop in step 3).
-   - `spawn` may also add `--isolation bare|fresh` and `--model <name>` (bare is
-     strongest; use it when `ANTHROPIC_API_KEY` is set). `sdk`/`sdk-apply` accept
-     `--model <name>`; isolation is intrinsic (fresh SDK session, no settings).
-
-2. **Run the Interpreter**:
-   Run the command (include only the bracketed flags that apply to the chosen strategy):
-   ```bash
-   python3 .appweaver/orchestrator/orchestrator.py \
-     .appweaver/orchestrator/workflows/aw-spec-demo.orch.yaml \
-     --strategy <strategy> \
-     [--agent-profile .kilocode/agent.json]   # spawn, sdk, sdk-apply \
-     [--checkpoint .appweaver/orchestrator/.demo-out/demo.state.json]  # sdk-apply, agent \
-     --json
-   ```
-
-3. **Handle Suspend/Resume Loop (for `agent` or `sdk-apply` strategies)**:
-   - If the command exits with code `2` (suspend):
-     - Read the prompt from the sidecar file `<checkpoint-path>.user.md` (and system instructions from `<checkpoint-path>.system.md`).
-     - Fulfill the request directly using your own tools (e.g., implementing the handler or reviewing files in the workspace).
-     - Write the final generation or review output to `<checkpoint-path>.response.md`.
-     - Re-run the exact same command.
-     - Repeat until the orchestrator exits with code `0`.
-
-4. **Report**:
-   Report the final JSON outputs (`status`, `outputs`, `review_pass`, generated file paths, etc.) to the user.

package/assets/.kilocode/workflows/appweaver.md

@@ -1,55 +0,0 @@
----
-name: "appweaver"
-description: "Parametric launcher (Kilo Code): run ANY converted aw-spec skill on the aw-orchestrator under one of the 4 strategies (agent [default], spawn, sdk, sdk-apply)."
-argument-hint: "<skill> [strategy] [input…] — e.g. 'select-domain', 'specify spawn Build an order API', 'analyze-slice'"
-compatibility: "Requires .appweaver/orchestrator/ and the claude CLI on PATH"
-user-invocable: true
-disable-model-invocation: false
----
-
-# Orchestrator Skill Launcher
-
-Runs one converted `aw-spec-*` workflow on the shared, agent-agnostic engine. All orchestration and **all context management live in the workflow YAML + engine** (`.appweaver/orchestrator/orchestrator.py`): the interpreter assembles the COMPLETE payload (system + user) for every request; you never author generation context yourself. Execution follows the chosen strategy; the checkpoint channel carries every human-facing interaction regardless of strategy.
-
-- **Engine + workflows (common, shared by all agents):** `.appweaver/orchestrator/orchestrator.py`, `.appweaver/orchestrator/workflows/aw-spec-<skill>.orch.yaml`, shared modules in `.appweaver/orchestrator/modules/`, shared scripts in `.appweaver/scripts/`
-- **This agent's transport profile:** `.kilocode/agent.json`
-
-  > Kilo Code has no native headless CLI, so it reuses `claude -p` for `spawn`
-  > (native `--system-prompt`, `--tools`, `--bare` isolation). Its `sdk` block
-  > declares the SDK the `sdk`/`sdk-apply` strategies import (`claude-agent-sdk`)
-  > and the adapter (`.appweaver/orchestrator/adapters/claude_agent_sdk.py`,
-  > shared per-SDK) that owns its calling convention.
-
-## Execution Steps
-
-1. **Parse Arguments** (`<skill> [strategy] [input…]`):
-   - `skill` (required): the aw-spec skill name, e.g. `demo`, `select-domain`, `foundation`, `specify`, `design`, `implement`, `build`. Resolve the workflow file `.appweaver/orchestrator/workflows/aw-spec-<skill>.orch.yaml`. If it does not exist, list the available `aw-spec-*.orch.yaml` files in that folder and stop.
-   - `strategy` (optional, one of `agent`, `spawn`, `sdk`, `sdk-apply`; default `agent` — YOU fulfill each generation through the checkpoint channel, no profile needed): who executes each generation. Always pass `--strategy <strategy>`.
-   - Everything after the strategy is the user input: pass it as `--input "<text>"` (omit when empty).
-   - `--agent-profile .kilocode/agent.json` is required for `spawn`, `sdk`, and `sdk-apply` (`agent` needs no profile). If the SDK package isn't installed, add `--sdk-install`.
-   - **Always** pass `--checkpoint .appweaver/orchestrator/.state/<skill>.state.json` — for EVERY strategy. Converted skills contain interactive steps (questions, selections, hooks); the checkpoint is how they reach you and the user. Strategies only govern who generates.
-   - `spawn` may also add `--isolation bare|fresh` and `--model <name>`; `sdk`/`sdk-apply` accept `--model <name>`.
-
-2. **Run the Interpreter**:
-   ```bash
-   python3 .appweaver/orchestrator/orchestrator.py \
-     .appweaver/orchestrator/workflows/aw-spec-<skill>.orch.yaml \
-     --strategy <strategy> \
-     --checkpoint .appweaver/orchestrator/.state/<skill>.state.json \
-     [--agent-profile .kilocode/agent.json]   # spawn, sdk, sdk-apply \
-     [--input "<user input>"] \
-     --json
-   ```
-
-3. **Handle the Suspend/Resume Loop** — whenever the command exits with code `2`, read the printed `pending` JSON and dispatch on `pending.kind`; fulfill it, write the response to `pending.response_path`, then re-run the SAME command. Repeat until exit `0` (done) or `1` (stopped by a gate).
-   - **`ask`** — ask the USER the `prompt` with the listed `options` (use your question tool). Write the chosen answer as PLAIN TEXT to `response_path` (comma-separated values when `multi` is true).
-   - **`select`** — ask the USER to pick ONE of `options`; write the chosen value as plain text to `response_path`.
-   - **`hook`** — run each MANDATORY hook in `hooks` (each is a slash command of THIS agent) in this conversation; optional hooks at your discretion. Then write `done` to `response_path`.
-   - **`author`** — read `system_path` + `user_path` and treat them as your ONLY standards and context. Author the COMPLETE content of the file named in `target` and write it — content ONLY, no commentary, no code fence — to `response_path`. Do NOT write the target file yourself; the interpreter does that.
-   - **`agent_generate`** — read `system_path` + `user_path`; perform the task YOURSELF with the listed `tools` within `permission_mode`; write your full final reply — ending with the required ```json fence — to `response_path`.
-   - **`agent_query` / `agent_review`** — same as above but READ-ONLY (do not modify files); the reply must end with the required ```json fence.
-   - **`apply`** — an isolated generation already decided the changes: read `artifact_path` and write its file contents EXACTLY to the paths it names, then write the confirmation ```json fence to `response_path`.
-   - If `pending.note` is present, your previous response was rejected — follow the note and rewrite `response_path`.
-
-4. **Report**:
-   Report the final JSON (`status`, `outputs`, and any `reason`) to the user. On `stopped`, relay the gate message verbatim — it tells the user what to fix or run first.