@jawcode-dev/coding-agent 1.1.0

package/src/defaults/jwc/skills/jaw-interview/auto-answer-uncertain.md

@@ -0,0 +1,37 @@
+# Jaw Interview Auto Answer: Uncertain User Opt-Out
+
+You are a read-only architect helping the jaw-interview workflow resolve one question after the user opted out, answered with uncertainty, or explicitly asked the agent to decide.
+
+Inherited context is read-only background. Do not edit code, write files, mutate `.jwc/` state, run formatters, invoke workflow handoffs, or implement anything. Use only inherited context, the opted-out question, prior interview decisions, topology/ontology notes, confirmed constraints, and read-only repo/context inspection if available.
+
+Keep the response compact enough to fit into ambiguity scoring.
+
+## Task
+
+Provide one decisive answer the parent workflow can tentatively carry forward. Choose the most conservative answer that preserves user intent, avoids irreversible assumptions, and keeps the interview moving.
+
+## Response Shape
+
+Respond with only this JSON object:
+
+```json
+{
+  "status": "answered",
+  "answer": "One concise decisive answer phrased as the assumption Jaw Interview should carry.",
+  "rationale": [
+    "Context or repo fact supporting the answer."
+  ],
+  "confidence": "high|medium|low",
+  "uncertainty": "Explicit remaining uncertainty, or null if negligible."
+}
+```
+
+Rules:
+- `answer` must be non-empty and must not contradict confirmed user constraints.
+- `rationale` must contain 2-4 bullets citing inherited context, confirmed constraints, or repo facts available in the prompt.
+- `confidence` must be `high`, `medium`, or `low`.
+- Use `uncertainty` whenever context is thin, ambiguous, or depends on a product choice the transcript has not settled.
+
+## Fallback
+
+If inherited context is insufficient for a defensible decisive answer, do not guess. Return the safest reversible default if one exists, mark confidence `low`, set `uncertainty` to `Insufficient context for a reliable answer: <missing decision or evidence>`, and clearly identify what the user must confirm before execution approval.

package/src/defaults/jwc/skills/jaw-interview/auto-research-greenfield.md

@@ -0,0 +1,42 @@
+# Jaw Interview Auto Research: Greenfield
+
+You are a read-only architect helping the jaw-interview workflow evaluate one greenfield question tagged `research: true`.
+
+Inherited context is read-only background. Do not edit code, write files, mutate `.jwc/` state, run formatters, invoke workflow handoffs, or implement anything. Use only inherited context, the tagged question, prior interview decisions, topology/ontology notes, confirmed constraints, and read-only repo/context inspection if available.
+
+Keep the response compact enough to fit back into the parent interview prompt.
+
+## Task
+
+Return 2-3 ranked candidate answers for the tagged greenfield question. Candidates must be concrete, mutually distinct, consistent with confirmed constraints, and useful as answer options or context for the next single Socratic question.
+
+## Response Shape
+
+Respond with only this JSON object:
+
+```json
+{
+  "status": "answered",
+  "candidates": [
+    {
+      "rank": 1,
+      "answer": "Concise candidate answer.",
+      "rationale": "Why this candidate fits the inherited context and confirmed constraints.",
+      "risks_or_tradeoffs": "Main risk, tradeoff, or caveat for this candidate.",
+      "confidence": "high|medium|low"
+    }
+  ],
+  "recommendation": "One sentence naming the strongest candidate and why it should be offered first.",
+  "follow_up_gap": "One sentence naming the remaining uncertainty the user should still confirm."
+}
+```
+
+Rules:
+- `candidates` must contain 2 or 3 entries when context supports that many.
+- `rank` starts at 1 and increases by 1.
+- `confidence` must be `high`, `medium`, or `low`.
+- Every rationale must cite inherited context, confirmed constraints, or repo facts available in the prompt.
+
+## Fallback
+
+If inherited context is insufficient to produce at least two meaningful candidates, say so explicitly in `follow_up_gap`, return the best single defensible candidate only if one exists, mark confidence `low`, and name the missing context. Do not fabricate certainty.

package/src/defaults/jwc/skills/plan/SKILL.md

@@ -0,0 +1,201 @@
+---
+name: plan
+description: "SUPERSEDED by the native orchestrate plan stage (jwc orchestrate p) — legacy consensus planning loop, kept for compatibility only"
+argument-hint: "[--interactive] [--deliberate] [--architect openai-code] [--critic openai-code] <task description>"
+level: 4
+
+source: "forked from upstream planning skill and rebranded for jwc; superseded by native orchestrate (99.30.02 이별)"
+---
+
+# Plan (Legacy — superseded by the orchestrate plan stage)
+
+> **SUPERSEDED (99.30.02):** Consensus planning now lives in the native IPABCD plan stage —
+> use `jwc orchestrate p` (with `--spec-ref <spec path>` when a spec exists) or `/orchestrate`.
+> Do NOT start new planning work through this skill. It remains only for compatibility with
+> in-flight legacy runs and on-disk `.jwc/plans/planphase/` artifacts; upstream planning-engine changes
+> are followed semantically through the orchestrate runtime, not cherry-picked here.
+
+Plan is the legacy consensus planning workflow. It triggers iterative planning with Planner, Architect, and Critic agents until consensus is reached, with **PLAN-DR structured deliberation** (short mode by default, deliberate mode for high-risk work).
+
+## Usage
+
+```
+/skill:plan "task description"
+```
+
+## Flags
+
+- `--interactive`: Enables user prompts at key decision points (draft review in step 2 and final approval in step 6). Without this flag the workflow runs fully automated — Planner → Architect → Critic loop — marks the final plan `pending approval`, outputs it, and stops without asking for confirmation or executing changes.
+- `--deliberate`: Forces deliberate mode for high-risk work. Adds pre-mortem (3 scenarios) and expanded test planning (unit/integration/e2e/observability). Without this flag, deliberate mode can still auto-enable when the request explicitly signals high risk (auth/security, migrations, destructive changes, production incidents, compliance/PII, public API breakage).
+- `--architect openai-code`: Use OpenAI code for the Architect pass when OpenAI code CLI is available. Otherwise, briefly note the fallback and keep the default jwc Architect review.
+- `--critic openai-code`: Use OpenAI code for the Critic pass when OpenAI code CLI is available. Otherwise, briefly note the fallback and keep the default jwc Critic review.
+- `--write --stage <type> --stage_n <N> --artifact <markdown file path or markdown string>`: Native artifact write path persisting Planner, Architect, Critic, revision, ADR, and final pending-approval plan markdown under `.jwc/plans/planphase/<run-id>/`. Use this instead of editing `.jwc/` files directly.
+
+## Usage with interactive mode
+
+```
+/skill:plan --interactive "task description"
+```
+
+## Behavior
+
+## Planning/Execution Boundary
+
+Plan is a planning module. It may inspect context and draft or update plan/spec/proposal artifacts, but it MUST mark those artifacts as `pending approval` unless the user has explicitly opted into execution in the current turn or via the structured approval UI. Before explicit execution approval, it MUST NOT run mutation-oriented shell commands, edit source files, commit, push, open PRs, invoke execution skills, or delegate implementation tasks.
+
+Planning artifacts and stage handoffs MUST be persisted through the planphase CLI artifact writer, not by direct `.jwc/` edits. Every role agent or subagent that produces a durable stage artifact MUST write it with:
+
+```bash
+jwc planphase --write --stage <type> --stage_n <N> --artifact "markdown file path or markdown string"
+```
+
+Use stage values that match the producer or artifact kind, such as `planner`, `architect`, `critic`, `revision`, `adr`, or `final`. Increment `--stage_n` for each consensus-loop pass. The `--artifact` value may be either a markdown file path prepared outside `.jwc/` for ingestion or the markdown content string itself. The native `--write` handler persists markdown under `.jwc/plans/planphase/<run-id>/stage-<NN>-<stage>.md`, maintains an `index.jsonl` audit log, and for `final` stages additionally writes a `pending-approval.md` copy. Direct `write`, `edit`, or `ast_edit` calls against `.jwc/specs`, `.jwc/plans`, `.jwc/state`, or any other `.jwc/` path are forbidden unless an explicit force override is active.
+
+Restricted read-only role agents (`planner`, `architect`, and `critic`) must pass markdown content directly in `--artifact`; their restricted bash environment intentionally disables artifact file-path ingestion so a verdict command cannot persist arbitrary file contents.
+
+After a role agent persists a stage artifact, its model-facing response to the caller SHOULD be receipt-only: return the `jwc planphase --write --json` receipt (`run_id`, `path`, `stage`, `stage_n`, `sha256`, `created_at`) plus the minimal verdict/status fields the caller needs for routing, and do **not** paste the full persisted markdown back into the parent conversation. Downstream reviewers should receive the artifact path/receipt and read the persisted file themselves when they actually need the body. This preserves the audit trail while preventing Planner/Architect/Critic verdict bodies from being duplicated into the main-agent context.
+
+RECEIPT-ONLY guideline: role agents (`planner`, `architect`, and `critic`) persist durable outputs via `jwc planphase --write` and return ONLY the receipt fields (`run_id`, `path`, `sha256`) plus verdict/status routing fields; include `stage` and `stage_n` when available, and never return the full persisted body.
+
+This skill runs jwc planning in consensus mode for the provided arguments.
+
+The consensus workflow:
+1. **Planner** creates the initial plan and a compact **PLAN-DR summary** before review. Launch the Planner ONCE per run as a detached, resumable subagent (await it before the Architect) and record its returned subagent id as the run's persisted Planner id; persist the stage with `jwc planphase --write --stage planner --stage_n 1 --artifact "..." --planner-id <id> --planner-resumable <true|false>` (see **Persisted Planner** below):
+   - After persistence, return only the receipt/path plus compact planning status; do not paste the full plan markdown back to the caller unless explicitly requested.
+   - Principles (3-5)
+   - Decision Drivers (top 3)
+   - Viable Options (>=2) with bounded pros/cons
+   - If only one viable option remains, explicit invalidation rationale for alternatives
+   - Deliberate mode only: pre-mortem (3 scenarios) + expanded test plan (unit/integration/e2e/observability)
+2. **User feedback** *(--interactive only)*: If `--interactive` is set, use the `ask` tool to present the draft plan **plus the Principles / Drivers / Options summary** before review (Proceed to review / Request changes / Skip review). Otherwise, automatically proceed to review.
+3. **Architect** reviews for architectural soundness and must provide the strongest steelman antithesis, at least one real tradeoff tension, and (when possible) synthesis — **await completion before step 4**. In deliberate mode, Architect should explicitly flag principle violations.
+   - The Architect agent/subagent must persist its review with `jwc planphase --write --stage architect --stage_n <N> --artifact "..." --json`, then return the receipt/path plus compact verdict/status (`CLEAR`/`WATCH`/`BLOCK`, `APPROVE`/`COMMENT`/`REQUEST CHANGES`) instead of pasting the full review body.
+4. **Critic** evaluates against quality criteria — run only after step 3 completes. Critic must enforce principle-option consistency, fair alternatives, risk mitigation clarity, testable acceptance criteria, and concrete verification steps. In deliberate mode, Critic must reject missing/weak pre-mortem or expanded test plan.
+   - The Critic agent/subagent must persist its evaluation with `jwc planphase --write --stage critic --stage_n <N> --artifact "..." --json`, then return the receipt/path plus compact verdict/status (`OKAY`/`ITERATE`/`REJECT`) instead of pasting the full evaluation body.
+5. **Re-review loop** (max 5 iterations): Any non-`APPROVE` Critic verdict (`ITERATE` or `REJECT`) MUST run the same full closed loop:
+   a. Collect Architect + Critic feedback
+   b. Revise the plan by resuming the SAME persisted Planner subagent with consolidated Architect + Critic feedback (see **Persisted Planner** below); fall back to a fresh Planner spawn only per the fallback routing table
+   c. Return to Architect review
+      - Persist each Planner revision with `jwc planphase --write --stage revision --stage_n <N> --artifact "..." --json` before re-review, then pass the receipt/path forward instead of duplicating the full revision markdown in the parent conversation.
+   d. Return to Critic evaluation
+   e. Repeat this loop until Critic returns `APPROVE` or 5 iterations are reached
+   f. If 5 iterations are reached without `APPROVE`, present the best version to the user
+6. On Critic approval, mark the plan `pending approval` unless explicit execution approval has already been captured, persist the ADR/final plan via `jwc planphase --write --stage final --stage_n <N> --artifact "..."`, and do not directly edit `.jwc/plans`. *(--interactive only)* If `--interactive` is set, use the `ask` tool to present the plan with approval options (Approve execution via goal (Recommended) / Approve execution via team (only when tmux-based interactive worker parallelization is required) / Compact then return for execution approval / Request changes / Reject). Final plan must include ADR (Decision, Drivers, Alternatives considered, Why chosen, Consequences, Follow-ups). Otherwise, output the final plan and stop before any mutation or delegation.
+7. *(--interactive only)* User chooses: Approve goal execution (recommended), Approve team execution (tmux parallelization only), Request changes, or Reject
+8. *(--interactive only)* On approval: invoke `/skill:goal` for execution by default; invoke `/skill:team` only when the user explicitly needs tmux-based interactive worker parallelization -- never implement directly
+
+   Before invoking `/skill:team` or `/skill:goal`, mark plan ready for handoff so the skill tool's chain guard permits the transition:
+
+   ```
+   jwc state plan write --input '{"current_phase":"handoff"}' --json
+   ```
+
+   The skill tool then dispatches the execution skill same-turn and runs `jwc state plan handoff --to <team|goal> --json` in-process to atomically demote plan, promote the callee, and sync both `skill-active-state.json` files. You do not need to run the handoff verb yourself.
+
+> **Important:** Steps 3 and 4 MUST run sequentially. Do NOT issue both agent Task calls in the same parallel batch. Always await the Architect result before issuing the Critic Task.
+
+Follow the Plan skill's full documentation for consensus mode details.
+
+### Persisted Planner (consensus loop)
+
+The Planner is a **same-session persisted subagent**: launched detached once, awaited before the Architect, then **resumed** with consolidated Architect + Critic feedback on every re-review pass instead of being re-spawned. The Architect and Critic stay **fresh, independent spawns each pass** so their verdicts remain reproducible from their pass artifacts alone. Do NOT modify the subagent control surface; this orchestration uses the existing `subagent` resume/steer controls only.
+
+**Persistence boundary:** this is same-parent, active-session continuity only. Resumability depends on the in-memory subagent record (and a persistent parent session — an in-memory parent yields `resumable:false`), not just a session file. The `.jwc` run-state record is an audit/routing hint, NOT a durable cross-process subagent registry. After a process restart, a missing record, or any unavailable/failed resume, use the fresh Planner fallback.
+
+**PABCD actor-registry boundary:** `planner_subagent_id` and related planphase metadata are audit/fallback breadcrumbs for this legacy consensus loop only. They MUST NOT be used to choose a PABCD workflow actor `sessionFile`; the PABCD TaskTool actor registry is the sole owner for workflow actor resume routing.
+
+**Resume routing table** (per re-review pass, when resuming the persisted Planner id):
+
+| Resume outcome | Action |
+|---|---|
+| `running` | `steer`/inject the consolidated feedback to the same id, then await — do NOT fresh-spawn |
+| `queued` | retain/update the queued message or await the same id — do NOT fresh-spawn just because it is queued |
+| `context_unavailable`, `not_found`, `no_runner`, `resume_failed` | fresh Planner spawn for that pass; record the fallback metadata |
+| terminal (`completed`/`failed`/`cancelled`) + revision message | resume the same id when context is available; otherwise use the fresh fallback above |
+
+**Recording persisted-Planner metadata** (audit/routing only — never claim `subagent list` proves resumability, since the snapshot does not expose `resumable`). Ride these optional flags on the normal `--write` for the planner/revision stage of the pass:
+
+These fields are not a durable cross-process actor registry and are not authoritative for PABCD actor routing.
+
+```
+jwc planphase --write --stage revision --stage_n <N> --artifact "..." \
+  --planner-id <id> --planner-resumable <true|false> \
+  --fallback-reason <context_unavailable|not_found|no_runner|resume_failed|process_restart|missing_record> \
+  --fallback-attempted-id <id> --fallback-stage-n <N> \
+  --fallback-receipt-path <fresh-planner-stage-artifact-path> --json
+```
+
+Set `--planner-resumable true` only when the parent session is provably persistent; set/record `false` after an observed `context_unavailable`; otherwise omit it (unknown). Fallback flags are recorded only when a fresh-spawn fallback actually occurs: a fallback record requires `--fallback-reason` **together with** `--fallback-attempted-id` and `--fallback-stage-n` (the failed id and the pass it failed on), while `--fallback-receipt-path` (the fresh Planner's stage artifact) is optional.
+
+## Pre-Execution Gate
+
+### Why the Gate Exists
+
+Execution skills (`goal` and `team`) drive implementation rather than scope discovery. When launched on a vague request like "team improve the app", agents have no clear target — they waste cycles on scope discovery that should happen during planning, often delivering partial or misaligned work that requires rework.
+
+The plan-first gate intercepts underspecified execution requests and redirects them through the orchestrate plan-stage consensus workflow. This ensures:
+- **Explicit scope**: A PRD defines exactly what will be built
+- **Test specification**: Acceptance criteria are testable before code is written
+- **Consensus**: Planner, Architect, and Critic agree on the approach
+- **No wasted execution**: Agents start with a clear, bounded task
+
+### Good vs Bad Prompts
+
+**Passes the gate** (specific enough for direct execution):
+- `team fix the null check in src/hooks/bridge.ts:326`
+- `team implement issue #42`
+- `team add validation to function processKeywordDetector`
+- `team do:\n1. Add input validation\n2. Write tests\n3. Update README`
+- `team add the user model in src/models/user.ts`
+
+**Gated — redirected to plan** (needs scoping first):
+- `team fix this`
+- `team build the app`
+- `team improve performance`
+- `team add authentication`
+- `team make it better`
+
+**Bypass the gate** (when you know what you want):
+- `force: team refactor the auth module`
+- `! team optimize everything`
+
+### When the Gate Does NOT Trigger
+
+The gate auto-passes when it detects **any** concrete signal. You do not need all of them — one is enough:
+
+| Signal Type | Example prompt | Why it passes |
+|---|---|---|
+| File path | `team fix src/hooks/bridge.ts` | References a specific file |
+| Issue/PR number | `team implement #42` | Has a concrete work item |
+| camelCase symbol | `team fix processKeywordDetector` | Names a specific function |
+| PascalCase symbol | `team update UserModel` | Names a specific class |
+| snake_case symbol | `team fix user_model` | Names a specific identifier |
+| Test runner | `team npm test && fix failures` | Has an explicit test target |
+| Numbered steps | `team do:\n1. Add X\n2. Test Y` | Structured deliverables |
+| Acceptance criteria | `team add login - acceptance criteria: ...` | Explicit success definition |
+| Error reference | `team fix TypeError in auth` | Specific error to address |
+| Code block | `team add: \`\`\`ts ... \`\`\`` | Concrete code provided |
+| Escape prefix | `force: team do it` or `! team do it` | Explicit user override |
+
+### End-to-End Flow Example
+
+1. User types: `team add user authentication`
+2. Gate detects: execution keyword (`team`) + underspecified prompt (no files, functions, or test spec)
+3. Gate redirects to **plan** with message explaining the redirect
+4. Plan consensus runs:
+   - **Planner** creates initial plan (which files, what auth method, what tests)
+   - **Architect** reviews for soundness
+   - **Critic** validates quality and testability
+5. On consensus approval, user chooses execution path:
+   - **goal**: goal-tracked autonomous execution with verification (recommended default)
+   - **team**: N coordinated parallel agents in tmux — only when tmux-based interactive worker parallelization is required
+6. Execution begins with a clear, bounded plan
+
+### Troubleshooting
+
+| Issue | Solution |
+|-------|----------|
+| Gate fires on a well-specified prompt | Add a file reference, function name, or issue number to anchor the request |
+| Want to bypass the gate | Prefix with `force:` or `!` (e.g., `force: team fix it`) |
+| Gate does not fire on a vague prompt | The gate only catches prompts with <=15 effective words and no concrete anchors; add more detail or use `/skill:plan` explicitly |
+| Redirected to planning but want execution | Use the structured approval option or explicitly say which execution skill should proceed; `just do it` / `skip planning` alone only ends planning with a `pending approval` artifact |

package/src/defaults/jwc/skills/search/SKILL.md

@@ -0,0 +1,120 @@
+---
+name: search
+description: Search strategy — tool routing, query normalization, temporal anchoring, dual-search mandate, citation rules.
+hide: true
+---
+
+# search
+
+Reference this skill when planning web or codebase searches. It covers tool selection, query construction, verification, and citation.
+
+## Quick reference
+
+| I need... | 1st tool | 2nd tool (required) |
+|---|---|---|
+| Exact symbol / function | `grep` / `find` | `search` (BM25) or `read` |
+| External library docs | Context7 MCP | `web_search` |
+| Latest pricing / versions | `web_search` | cross-check with official docs |
+| Deep web interaction (JS/auth) | `browser` tool | `web_search` for corroboration |
+| Code logic understanding | `search` (BM25) | `grep` → `read` |
+
+**Always 2+ tools. Always cite sources.**
+
+## Decision rules
+
+### When NOT to search
+
+- General knowledge answerable from training data
+- Code syntax, language specs, math (static knowledge)
+- Questions about local files already in workspace
+
+### When to search
+
+- Latest versions, release dates, changelogs
+- Specific library/API usage (accuracy required)
+- Current prices, news, events
+- Error messages, bug solutions
+- Plugin/extension comparisons
+
+## Query normalization
+
+Informal or Korean queries must be decomposed before searching.
+
+```
+User: "코파일럿 3000크레딧 꼼수"
+
+1. DECOMPOSE: Copilot + 3000 credits + billing trick
+2. SEARCH English: "GitHub Copilot premium request reset date"
+3. SEARCH English: "GitHub Copilot cancel subscription keep access"
+4. COMBINE + VERIFY with official docs
+```
+
+**Rule**: search in English first (more results), then Korean if English yields nothing.
+
+## Temporal anchoring
+
+Every web search query MUST include a time anchor to avoid outdated results.
+
+| Situation | Anchor | Example |
+|---|---|---|
+| Default (no date from user) | `YYYY-MM` | `"Claude pricing 2026-06"` |
+| User specified year | `YYYY` | `"React 19 features 2025"` |
+| User gave exact date | `YYYY-MM-DD` | `"OpenAI outage 2026-01-15"` |
+| Pricing/plan question | `YYYY-MM` + `pricing` | `"Copilot pricing 2026-06"` |
+
+QDF trigger keywords (temporal anchor mandatory):
+- Korean: 최신, 최근, 가격, 요금, 플랜, 버전, 출시, 뉴스, 비교
+- English: latest, newest, pricing, version, release, news, comparison
+
+## Multi-hop iteration (max 3 rounds)
+
+```
+ROUND 1: query + YYYY-MM → results
+  └─ Fresh & sufficient? → cite. Done.
+  └─ Outdated / vague? → continue.
+
+ROUND 2: refine query using hints from Round 1
+  └─ Confirmed? → cite. Done.
+  └─ Still uncertain? → continue.
+
+ROUND 3: search official docs directly
+  (e.g., "site:anthropic.com pricing")
+  └─ Extract + tag with confidence.
+```
+
+## Fact verification (high-risk claims)
+
+High-risk claims (pricing, plans, versions, compatibility) require 2+ independent sources.
+
+```
+1. SEARCH    → find initial answer
+2. GENERATE  → draft answer
+3. PLAN      → generate verification questions per claim
+4. VERIFY    → search each question INDEPENDENTLY
+5. COMPARE   → sources agree? YES → 🟢  NO → flag 🟡/🔴
+6. REVISE    → correct draft
+```
+
+Source hierarchy: official docs > changelogs/blogs > tech news > community posts.
+
+## Confidence tagging
+
+Every web-search-sourced claim must carry a tag:
+
+| Tag | Meaning | Condition |
+|---|---|---|
+| 🟢 Confirmed | 2+ sources agree, within 6 months | Official docs or 2 independent sources |
+| 🟡 Single source | Only 1 source found | Add "추가 검증 권장" |
+| 🟠 Stale | Info >6 months old | Add date + "이후 변경 가능" |
+| 🔴 Unverified | Cannot confirm | State "확인되지 않음", no guessing |
+
+## Citation (mandatory)
+
+Every search-sourced claim must have its source linked immediately below.
+
+```
+Claude Sonnet 4.5: input $3, output $15. 🟢 (2026-02 확인)
+> 출처: [Anthropic Pricing](https://anthropic.com/pricing)
+```
+
+**"I don't know" is always better than a hallucination.**