=== Live setup-phase test: /create:sk-skill:auto ===
Started: 2026-05-11T14:30:56+0200
Command: .opencode/commands/create/sk-skill.md

Reading additional input from stdin...
OpenAI Codex v0.130.0
--------
workdir: /Users/michelkerkmeester/MEGA/Development/Code_Environment/Public
model: gpt-5.5
provider: openai
approval: never
sandbox: workspace-write [workdir, /tmp, $TMPDIR, /Users/michelkerkmeester/.codex/memories] (network access enabled)
reasoning effort: medium
reasoning summaries: none
session id: 019e1704-e40a-7541-82eb-1cf38d557a13
--------
user
You are testing the setup-phase contract of the migrated command /create:sk-skill.

# RUNTIME RULES
- Inline Codex execution. Do NOT call SpawnAgent / collab / Task / sub-agent.
- Gate 3 answer: D) Skip spec-folder creation. Stdin is closed.
- Do NOT load the paired YAML workflow. Stop at the end of section zero setup resolution.
- Do NOT write any files outside /tmp/. Read-only inspection of the command markdown is allowed.

# YOUR TASK

1. Read .opencode/commands/create/sk-skill.md section zero (UNIFIED SETUP PHASE or equivalent).
2. Verify this command's section zero cites .opencode/skills/system-spec-kit/references/workflows/auto_mode_contract.md (the shared three-tier auto contract).
3. SIMULATE a dispatch of /create:sk-skill:auto with the following PRE-BOUND SETUP ANSWERS in the prompt body:

```
PRE-BOUND SETUP ANSWERS:
  skill_name: sk-throwaway
  operation: create
  spec_folder: new
  execution_mode: AUTONOMOUS
```

4. Walk through Tier-1 logic step by step. Determine which Tier the resolution lands in.
5. Report:
   - Citation present: yes/no with line number
   - Section zero Tier reached: 1 / 2 / 3
   - Setup question emitted: yes / no (CRITICAL — yes under Tier 1 means migration failed)
   - Resolved field map: list each setup field with its final value
   - STATUS value: PASSED / BLOCKED / fail-fast error
   - Verdict: PASS or PARTIAL or FAIL
     - PASS = Tier 1 resolved without question
     - PARTIAL = Tier 2 reached logically
     - FAIL = legacy Q-block emitted or hang

# OUTPUT
One markdown message with the 6 report fields. Do not edit files. Do not call SpawnAgent.

hook: SessionStart
hook: SessionStart
hook: SessionStart Completed
hook: SessionStart Completed
hook: UserPromptSubmit
hook: UserPromptSubmit
hook: UserPromptSubmit Completed
hook: UserPromptSubmit Completed
codex
SKILL ROUTING: advisor points to `sk-code`; I’ll use it lightly for read-only inspection and stay inside the command markdown, with the spec-folder gate already answered as `D) Skip`.
exec
/bin/zsh -lc "sed -n '1,220p' .opencode/skills/sk-code/SKILL.md && nl -ba .opencode/commands/create/sk-skill.md | sed -n '1,220p'" in /Users/michelkerkmeester/MEGA/Development/Code_Environment/Public
 succeeded in 0ms:
---
name: sk-code
description: "Multi-stack coding standards and verification. Smart router auto-detects the active surface and loads matching code patterns."
allowed-tools: [Bash, Edit, Glob, Grep, Read, Task, Write]
version: 3.3.0.0
---

<!-- Keywords: sk-code, code workflows, smart-router, code-surface-detection, webflow, frontend, html, css, javascript, Motion.dev, motion-dev, motion_dev, cross-stack-animation, gsap, lenis, swiper, hls, filepond, opencode, system-code, mcp, typescript, python, shell, jsonc, code-quality, debugging-workflow, verification -->

# Code Workflows - Surface-Aware Smart Router

`sk-code` is the single code-work skill. It first decides which code surface is in front of it, then loads the right implementation, quality, debugging, and verification resources.

**Core principle**: `Code surface detection -> Intent classification -> Surface resources -> Verification evidence`.

---

## 1. WHEN TO USE

> **🎯 Template customization surface.** This is the **only** skill end users should edit when adopting this template repo for their own project. Replace the shipped `references/{webflow,opencode,motion_dev}/` and `assets/{webflow,opencode,motion_dev}/` trees with your stack's references and assets. Update `STACK_FOLDERS` (§2) + `RESOURCE_MAP` to match. Every other skill (`sk-doc`, `sk-git`, `sk-code-review`, `system-spec-kit`, `mcp-coco-index`, etc.) is codebase-agnostic and must stay that way to keep upstream pulls clean. See root [README §4 Customizing for Your Stack](../../../README.md#customizing-for-your-stack).

Use this skill when doing code work in either supported surface:

- **WEBFLOW**: Webflow / vanilla frontend work in HTML, CSS, and JavaScript, including Motion.dev runtime usage, GSAP, Lenis, HLS, Swiper, FilePond, CDN/minification, and browser verification.
- **OPENCODE**: OpenCode system work under `.opencode/`, including skills, agents, commands, MCP servers, hooks, scripts, tests, JSON/JSONC config, TypeScript, JavaScript, Python, and Shell.

Also use this skill for cross-stack Motion.dev reference work when the question is about Motion APIs, snippets, integration modes, performance pitfalls, or CSS/Motion/GSAP/WAAPI trade-offs that should live in `references/motion_dev/` or `assets/motion_dev/` rather than inside Webflow-only guidance.

Use it for implementation, code quality, debugging, verification, test failures, build failures, and before any completion claim.

Do **not** use this skill for documentation-only changes (`sk-doc`), git workflow (`sk-git`), pure browser inspection (`mcp-chrome-devtools`), or formal findings-first review output (`sk-code-review` baseline plus this skill's surface evidence).

Documentation-only edits to skill markdown route to `sk-doc`, even when the file lives under `.opencode/skills/`. Examples: updating a `SKILL.md` headline, clarifying a README paragraph, rewriting a description section, or adding a one-line summary at the top of a markdown file. Negative example: "Update the sk-code SKILL.md headline section to clarify the two-axis routing model and add a one-line summary" is `sk-doc`, not `sk-code`, because the requested change is prose-only and does not modify executable behavior or routing logic.

### Phase Overview

| Phase | Purpose | Requirement |
| --- | --- | --- |
| Phase 0: Research | Understand unfamiliar code or risky changes | Optional, but required for complex work |
| Phase 1: Implementation | Write or modify code using surface patterns | Read actual files first |
| Phase 1.5: Code Quality Gate | Apply P0/P1/P2 checks and surface standards | Required before claiming implementation done |
| Phase 2: Debugging | Trace symptom to root cause and fix one cause at a time | Required when tests/runtime fail |
| Phase 3: Verification | Run surface verification commands and record evidence | Required before any done/works claim |

**Iron Law**: no completion claim without fresh verification evidence from the detected surface.

### Review Baseline Contract

`sk-code-review` owns findings format, severity model, and baseline security/quality/test review. `sk-code` owns surface detection and surface-specific standards evidence.

### Cross-Skill Consumption

When called from `/spec_kit:complete` with an `.opencode/` implementation target (`step_10_development` activity), `sk-code` surfaces the matching authoring checklist plus the `spec_folder_write` recipe AT WRITE-TIME (before the orchestrator's first write), not just at review-time.

| Target Path | Authoring Checklist Surfaced | Recipe |
|---|---|---|
| `.opencode/skills/` | `assets/opencode/checklists/skill_authoring.md` | — |
| `.opencode/agents/` | `assets/opencode/checklists/agent_authoring.md` | — |
| `.opencode/commands/` | `assets/opencode/checklists/command_authoring.md` | — |
| `.opencode/specs/` | `assets/opencode/checklists/spec_folder_authoring.md` | `assets/opencode/recipes/spec_folder_write.md` |
| MCP server source | `assets/opencode/checklists/mcp_server_authoring.md` | — |

Authoring-time load is the contract documented in `system-spec-kit/SKILL.md §16-17 cross-skill routing` and the `cross_skill_authoring_load` block in `/spec_kit:complete` YAMLs. Review-time `sk-code-review` baseline + `sk-code` router-selected evidence overlay remains unchanged.

---

<!-- /ANCHOR:when-to-use -->
<!-- ANCHOR:smart-routing -->
## 2. SMART ROUTING

### Surface Detection (FIRST)

Detection is context-aware and uses CWD plus changed/target files. **Precedence**: OPENCODE target/CWD wins over WEBFLOW markers (because mixed-marker workspaces are common — `.opencode/` system tools sometimes ship frontend animation libraries internally). When neither matches, fall through to UNKNOWN.

Machine-readable stack folder contract:

```python
STACK_FOLDERS = {
    "WEBFLOW": ["src/2_javascript/", "*.webflow.js"],
    "OPENCODE": [".opencode/skills/", ".opencode/agents/", ".opencode/commands/", ".opencode/specs/"],
    "MOTION_DEV": ["references/motion_dev/", "assets/motion_dev/"],
}
```

```bash
# Use early-return precedence — never let later branches overwrite an earlier match.

# 1. OPENCODE - takes precedence: CWD or any changed/target file under .opencode/
if [[ "$PWD" == */.opencode/* ]] \
   || [[ "$TARGET_FILE" == */.opencode/* ]]; then
  SURFACE="OPENCODE"

# 2. Explicit non-Webflow guard - a prompt can ask for Motion.dev cross-stack
# guidance without making the implementation surface WEBFLOW.
elif printf '%s\n' "${PROMPT_TEXT:-}" | grep -Eiq \
     '(^|[^[:alnum:]])(not webflow|no webflow designer|without webflow|non-webflow|vanilla html/css/js only|vanilla html css js only|stack-agnostic)([^[:alnum:]]|$)'; then
  SURFACE="UNKNOWN"

# 3. WEBFLOW - frontend HTML/CSS/JS and Webflow-specific vanilla animation web
elif [[ -d "src/2_javascript" ]] \
     || ls *.webflow.js 2>/dev/null | head -1 \
     || grep -lq "Webflow\.push\|--vw-" src/**/*.{js,css,html} 2>/dev/null \
     || grep -lqE "window\.Motion|window\.gsap|gsap\.(to|from|set|timeline|registerPlugin)|new Lenis|new Hls|new Swiper|FilePond" \
        src/**/*.{js,mjs,ts,html} *.{js,mjs,ts,html} 2>/dev/null \
     || [[ -f "wrangler.toml" ]]; then
  SURFACE="WEBFLOW"

# 4. UNKNOWN - not owned by this skill; ask for runtime + verification commands
else
  SURFACE="UNKNOWN"
fi
```

**Why OPENCODE wins precedence**: `.opencode/skills/sk-doc/scripts/preview-server.js` is an OPENCODE system tool that may import vanilla animation libraries (Lenis, GSAP) for its preview UI. A first-match-WEBFLOW pseudocode would route this OPENCODE work to the wrong standards. The target/CWD path is the strongest unambiguous signal of which surface owns the work.

**Supported surfaces**:

- `WEBFLOW`: frontend HTML/CSS/JS, Webflow conventions, vanilla animation libraries, CDN/minification, and browser evidence.
- `OPENCODE`: `.opencode/` system code and config with language sub-detection.
- `UNKNOWN`: ask a short disambiguation question and do not pretend unsupported stacks are covered.

For details: `references/stack_detection.md`.

### Phase Detection

```text
TASK CONTEXT
    |
    +- STEP 0: Detect surface from CWD + target files (primary routing key)
    |    +- references/<surface>/  (webflow / opencode)
    |    +- assets/<surface>/      (webflow / opencode)
    |
    +- STEP 1: Detect language sub-key (OPENCODE only) for verification commands
    |
    +- STEP 2: Weighted intent scoring (top-2 when ambiguity delta is small)
    |
    +- Phase 1: Implementation -> per-language style + standards + implementation trio
    +- Phase 2: Debugging       -> debugging refs + universal error recovery
    +- Phase 3: Verification    -> surface-appropriate verification commands + checklist
```

**The Iron Law**: NO COMPLETION CLAIMS WITHOUT RUNNING SURFACE-APPROPRIATE VERIFICATION.

Phase contract details: [`references/phase_detection.md`](./references/phase_detection.md).

### OPENCODE Language Sub-Detection

When surface is `OPENCODE`, detect language from changed/target file extensions first, then weighted keywords:

| Language | Extensions / Signals | Resources |
| --- | --- | --- |
| JAVASCRIPT | `.js`, `.mjs`, `.cjs`, CommonJS, Node, MCP | `references/opencode/javascript/*` |
| TYPESCRIPT | `.ts`, `.tsx`, `.mts`, `.d.ts`, tsconfig, interfaces | `references/opencode/typescript/*` |
| PYTHON | `.py`, pytest, argparse, docstrings | `references/opencode/python/*` |
| SHELL | `.sh`, `.bash`, shebang, pipefail | `references/opencode/shell/*` |
| CONFIG | `.json`, `.jsonc`, schema, descriptor | `references/opencode/config/*` |

Ambiguous multi-language tasks load the top matching language references plus the universal OpenCode checklist.

### Resource Domains

- `references/universal/`: surface-agnostic error recovery, code quality, style, and research guidance.
- `references/`: detection, intent scoring, loading, and lifecycle internals.
- `references/webflow/`, `assets/webflow/`: live Webflow/frontend per-language references under `references/webflow/{javascript,css,html}/*` — JS and CSS each carry `style_guide.md`, `quality_standards.md`, `quick_reference.md`; CSS additionally carries `patterns.md` (Webflow tokens, state machines, focus/form patterns); HTML carries `style_guide.md` only (Webflow Designer manages most HTML). Cross-language rules + enforcement workflow + dev workflow live under `references/webflow/shared/*`. Categorical workflow patterns (implementation, debugging, verification, performance, deployment) and copy-paste templates (`assets/webflow/templates/component_template.{js,css}`) round out the surface. Mirrors the OPENCODE per-language layout so the smart router resolves both surfaces with identical key-derived patterns.
- `references/motion_dev/`, `assets/motion_dev/`: cross-stack Motion.dev API, timeline, scroll/gesture, performance, decision-matrix, integration, install, playbook hook, and snippet resources. Webflow docs link here for generic Motion details while keeping Webflow-CDN and Designer guidance in `references/webflow/`.
- `references/opencode/`, `assets/opencode/`: OpenCode system-code language standards, shared patterns, hooks, alignment automation, and quality checklists.
- `assets/webflow/scripts/`: Webflow build, minification, and runtime verification utilities.
- `assets/scripts/`: Cross-surface helper scripts, including the OpenCode alignment verifier.

### OpenCode Authoring Resources

| Resource | Path | When to load |
|---|---|---|
| skill_authoring | `assets/opencode/checklists/skill_authoring.md` | CONDITIONAL (intent: authoring new skill) |
| agent_authoring | `assets/opencode/checklists/agent_authoring.md` | CONDITIONAL (intent: authoring new agent) |
| command_authoring | `assets/opencode/checklists/command_authoring.md` | CONDITIONAL (intent: authoring new command) |
| mcp_server_authoring | `assets/opencode/checklists/mcp_server_authoring.md` | CONDITIONAL (intent: authoring MCP server) |
| spec_folder_authoring | `assets/opencode/checklists/spec_folder_authoring.md` | CONDITIONAL (intent: spec folder write) |
| spec_folder_write recipe | `assets/opencode/recipes/spec_folder_write.md` | CONDITIONAL (intent: spec folder write) |

### Intent Classification

After surface detection, score task text for intents: `IMPLEMENTATION`, `CODE_QUALITY`, `DEBUGGING`, `VERIFICATION`, `TESTING`, `DEPLOYMENT`, `PERFORMANCE`, `ANIMATION`, `MOTION_DEV`, `FORMS`, `VIDEO`, `API`, `HOOKS`, `CONFIG`, and `LANGUAGE_STANDARDS`.

Top intent always loads. A close second intent also loads when scores are within the ambiguity threshold.

`MOTION_DEV` is a resource intent, not a third code surface. It loads `references/motion_dev/` and `assets/motion_dev/` for cross-stack Motion questions after WEBFLOW/OPENCODE/UNKNOWN surface handling has established where implementation work is happening.

### Verification Commands

| Surface | Required verification evidence |
| --- | --- |
| WEBFLOW | `node .opencode/skills/sk-code/assets/webflow/scripts/minify-webflow.mjs`, `node .opencode/skills/sk-code/assets/webflow/scripts/verify-minification.mjs`, `node .opencode/skills/sk-code/assets/webflow/scripts/test-minified-runtime.mjs`, plus desktop/mobile browser console clean evidence when runtime behavior changes |
| OPENCODE | `python3 .opencode/skills/sk-code/assets/scripts/verify_alignment_drift.py --root <changed-scope>`, plus targeted language/project tests such as vitest, pytest, shellcheck, JSON validation, or spec validation for changed spec folders |
| UNKNOWN | User-selected verification command set before completion claim |

### Smart Router Pseudocode

Smart Router pseudocode (full implementation): see [`references/smart_routing.md`](./references/smart_routing.md) for the authoritative `INTENT_MODEL`, `RESOURCE_MAP`, load tiers, and surface→intent routing logic.

<!-- /ANCHOR:smart-routing -->

---

## 3. HOW IT WORKS

### WEBFLOW Workflow

1. Detect frontend/Webflow markers before generic package markers.
2. Load Webflow implementation, debugging, verification, performance, and vendor-specific resources by intent.
3. Verify with build/minification scripts and browser evidence when behavior changes.
4. Update CDN/versioning guidance after JavaScript bundle changes.
5. For Motion API or decision questions, load `references/motion_dev/` as the cross-stack peer reference and keep Webflow-specific CDN guidance in `references/webflow/`.

### OPENCODE Workflow

1. Detect `.opencode/` context from CWD or target files.
2. Detect language from file extension first, then keyword scores.
3. Load shared OpenCode patterns, language standards, quick references, and checklists.
4. Run the alignment verifier and targeted tests before completion claims.
     1	---
     2	description: Create or update OpenCode skills via one unified command with operation routing. :auto/:confirm.
     3	argument-hint: "<skill-name> [operation] [type] [--path <dir>] [--chained] [:auto|:confirm] (:auto supports PRE-BOUND SETUP ANSWERS: prompt-body block for non-interactive setup)"
     4	allowed-tools: Read, Write, Edit, Bash, Glob, Grep, TodoWrite, mcp__cocoindex_code__search
     5	---
     6	
     7	> ⚠️ **EXECUTION PROTOCOL - READ FIRST**
     8	>
     9	> This command is the canonical entrypoint for skill command workflows.
    10	> Do not split behavior across legacy command definitions.
    11	>
    12	> Mandatory execution order:
    13	> 1. Run Phase 0 verification (`@markdown` or valid chained handoff)
    14	> 2. Run unified setup (single consolidated prompt)
    15	> 3. Verify required phase outputs are present
    16	> 4. Route by mode (`:auto` or `:confirm`)
    17	> 5. Route by operation (`full-create`, `full-update`, `reference-only`, `asset-only`)
    18	> 6. Load and execute the selected unified YAML workflow
    19	
    20	---
    21	
    22	# 🚨 MANDATORY FIRST ACTION - DO NOT SKIP
    23	
    24	Before reading any other section, execute Phase 0 and setup validation.
    25	Do not infer missing command arguments from prior conversation context.
    26	
    27	---
    28	
    29	# 🚨 PHASE 0: @MARKDOWN AGENT VERIFICATION
    30	
    31	**STATUS: ☐ BLOCKED**
    32	
    33	```text
    34	EXECUTE THIS AUTOMATIC SELF-CHECK (NOT A USER QUESTION):
    35	
    36	SELF-CHECK: Are you operating as @markdown OR under a valid chained parent handoff?
    37	|
    38	|- CASE A: Valid chained handoff detected (--chained)
    39	|  |- Required parent fields present?
    40	|  |  - skill_name
    41	|  |  - operation
    42	|  |  - execution_mode
    43	|  |  - parent_create_agent_verified=true
    44	|  |  - type (required only for reference-only or asset-only)
    45	|  |- IF all present:
    46	|  |  - create_agent_verified = skipped-chained
    47	|  |  - chained_handoff_valid = true
    48	|  |  - phase_0_status = PASSED
    49	|  |- IF missing required parent fields:
    50	|     - chained_handoff_valid = false
    51	|     - fall through to CASE B
    52	|
    53	|- CASE B: Standalone invocation
    54	|  |- Verify @markdown indicators:
    55	|  |  - Invoked with @markdown
    56	|  |  - Template-first generation behavior available
    57	|  |  - sk-doc quality validation behavior available
    58	|  |- IF yes:
    59	|  |  - create_agent_verified = true
    60	|  |  - phase_0_status = PASSED
    61	|  |- IF no/uncertain:
    62	|     - HARD BLOCK and stop
    63	
    64	HARD BLOCK MESSAGE:
    65	"This command requires @markdown for template-first generation and sk-doc validation.
    66	Restart with: @markdown /create:sk-skill <skill-name> [operation] [type]"
    67	```
    68	
    69	Phase outputs:
    70	- `create_agent_verified`
    71	- `chained_handoff_valid`
    72	
    73	---
    74	
    75	# 🔒 UNIFIED SETUP PHASE
    76	
    77	**STATUS: ☐ BLOCKED**
    78	
    79	This command uses one consolidated setup prompt. Do not split setup questions.
    80	
    81	### `:auto` Setup Resolution
    82	
    83	Setup contract: see `.opencode/skills/system-spec-kit/references/workflows/auto_mode_contract.md`.
    84	
    85	Under `execution_mode = AUTONOMOUS` (from the `:auto` suffix), follow the three-tier flow:
    86	
    87	1. **Tier 1 — Resolve confidently** (contract §1): parse `$ARGUMENTS` flags + `PRE-BOUND SETUP ANSWERS:` block (§2) + the Default Resolution Table below (§3). When every required field is resolved, persist to `{spec_path}/create-sk-skill-config.json` when a spec is linked, otherwise `/tmp/create-sk-skill-config.json` (shape: `skillName`, `operation`, `type`, `skillPath`, `executionMode: "auto"`, `specChoice`, `specPath`, `memoryChoice`, `chainedHandoffValid`), bind runtime YAML placeholders, set `STATUS: PASSED`, load `.opencode/commands/create/assets/create_sk_skill_auto.yaml`. End §0.
    88	
    89	2. **Tier 2 — Targeted ask** (contract §1): when 1-2 required fields are genuinely ambiguous AND no default exists, emit ONE narrow question per ambiguous field. Command-specific Tier-2-eligible fields (per the Default Resolution Table below): `type`, `spec_choice`. **Ordering rule**: if `type` is required for `reference-only` or `asset-only`, ask only for `type` first — the answer may make the operation branch fully resolvable on the next Tier 1 pass.
    90	
    91	3. **Tier 3 — Fail fast** (contract §4): emit the named-missing-inputs error format with `/create:sk-skill:auto` as the command name. Exit non-zero. Do not load YAML.
    92	
    93	`:confirm` path stays unchanged — see the consolidated setup prompt section below.
    94	
    95	### PRE-BOUND SETUP ANSWERS Schema (for `:auto` non-interactive dispatch)
    96	
    97	The dispatched prompt body may contain one structured marker block. Parse it before applying defaults. Grammar: see `auto_mode_contract.md` §2.
    98	
    99	```yaml
   100	PRE-BOUND SETUP ANSWERS:
   101	  skill_name: my-skill  # hyphen-case string
   102	  operation: full-create  # full-create | full-update | reference-only | asset-only
   103	  type: workflow  # reference-only: workflow | patterns | debugging | tools | quick_ref; asset-only: template | lookup | example | guide
   104	  skill_path: .opencode/skills/  # directory path
   105	  execution_mode: AUTONOMOUS  # from :auto suffix
   106	  spec_choice: new  # existing | new | update-related | skip | phase-folder
   107	  spec_path: .opencode/specs/103-example/001-my-skill/  # explicit path when applicable
   108	  memory_choice: skip  # latest | recent3 | skip | n/a
   109	  chained_handoff_valid: false  # boolean
   110	```
   111	
   112	Rules: see `auto_mode_contract.md` §2 (unspecified fields fall back to default; marker fields take precedence over `$ARGUMENTS` flags; unknown fields warn; malformed lines parse-error).
   113	
   114	### Default Resolution Table
   115	
   116	| Field | Required | Resolves Via | Default | Tier-2 Candidate |
   117	|-------|----------|--------------|---------|------------------|
   118	| `skill_name` | Y | `$ARGUMENTS` first positional token, marker `skill_name`, or chained parent value | none | N |
   119	| `operation` | Y | `$ARGUMENTS` second positional token, marker `operation`, or chained parent value | none | N |
   120	| `type` | Conditional | `$ARGUMENTS` third positional token, marker `type`, or chained parent value when `operation` is `reference-only` / `asset-only` | none | Y, when operation requires type and type is ambiguous |
   121	| `skill_path` | Y | flag `--path`, marker `skill_path`, or default | `.opencode/skills/` | N |
   122	| `execution_mode` | Y | attached suffix `:auto` or marker `execution_mode` | `AUTONOMOUS` under `:auto` | N |
   123	| `spec_choice` | Conditional | marker `spec_choice`, chained parent value, or targeted choice for `full-create` / `full-update` | none | Y, when full operation is selected and folder choice is ambiguous |
   124	| `spec_path` | Conditional | marker `spec_path`, derived from `spec_choice`, or chained parent value | none | N |
   125	| `memory_choice` | N | marker `memory_choice`, prior-work detection, or default | `skip` when no prior continuity records exist | N |
   126	| `chained_handoff_valid` | N | flag `--chained` plus parent fields, marker `chained_handoff_valid`, or default | `false` | N |
   127	
   128	**🚨 SINGLE CONSOLIDATED PROMPT - ONE USER INTERACTION**
   129	```text
   130	SETUP EXECUTION LOGIC:
   131	
   132	1) Parse invocation shape
   133	   - /create:sk-skill <skill-name> [operation] [type] [--path <dir>] [--chained] [:auto|:confirm]
   134	
   135	2) Parse mode suffix
   136	   - :auto detected    -> execution_mode = AUTONOMOUS (omit mode question)
   137	   - :confirm detected -> execution_mode = INTERACTIVE (omit mode question)
   138	   - no suffix         -> execution_mode = ASK
   139	
   140	3) Parse positional tokens
   141	   - token 1: skill_name (if present)
   142	   - token 2: operation (if present)
   143	   - token 3: type (if present)
   144	
   145	4) Parse flags
   146	   - --path <dir>
   147	   - --chained
   148	
   149	5) Chained setup bypass logic
   150	   - If chained_handoff_valid=true and all required fields for selected operation exist:
   151	     - Skip setup prompt
   152	     - Use parent values
   153	   - If chained_handoff_valid=false or required chained fields missing:
   154	     - Fall back to normal setup prompt
   155	
   156	6) Determine which setup questions are required
   157	   - Ask operation only when missing
   158	   - Ask type only when operation requires it and type is missing/invalid
   159	   - Ask execution mode only when no suffix is present
   160	   - Ask spec folder choice only for full-create and full-update
   161	   - Ask memory loading only when existing spec is selected and memory files exist
   162	
   163	7) Ask ONE consolidated setup prompt with only missing items
   164	
   165	   Q0. Skill Name (if missing)
   166	       - Required format: hyphen-case (lowercase, digits, hyphens)
   167	
   168	   Q1. Operation (if missing)
   169	       A) full-create (new skill end-to-end)
   170	       B) full-update (update existing skill and resources)
   171	       C) reference-only (create/update one reference document)
   172	       D) asset-only (create/update one asset document)
   173	
   174	   Q2. Type (required only for reference-only or asset-only)
   175	       - For reference-only: workflow | patterns | debugging | tools | quick_ref
   176	       - For asset-only: template | lookup | example | guide
   177	
   178	   Q3. Spec Folder (required for full-create/full-update)
   179	       A) Existing
   180	       B) New (recommended)
   181	       C) Update related
   182	       D) Skip
   183	       E) Phase folder
   184	
   185	       Optional for reference-only/asset-only:
   186	       A) Attach existing spec path for continuity tracking
   187	       B) Skip spec linkage
   188	
   189	   Q4. Prior Work Context (when the existing spec has prior continuity records)
   190	       A) Load most recent spec-doc record
   191	       B) Load up to 3 most recent spec-doc records
   192	       C) Skip
   193	
   194	   Q5. Execution Mode (if no suffix)
   195	       A) Interactive (:confirm)
   196	       B) Autonomous (:auto)
   197	
   198	8) Wait for user response and parse fields
   199	
   200	9) Normalize setup outputs
   201	   - skill_name
   202	   - operation
   203	   - type
   204	   - skill_path (from --path or default .opencode/skills/)
   205	   - execution_mode
   206	   - spec_choice
   207	   - spec_path
   208	   - memory_choice
   209	
   210	HARD STOPS:
   211	- Do not infer missing operation or type from context
   212	- Do not split setup across multiple prompts
   213	- Do not continue with missing required fields for selected operation
   214	```
   215	
   216	Phase outputs:
   217	- `skill_name`
   218	- `operation`
   219	- `type`
   220	- `skill_path`

codex
Found the setup block and the contract citation. I’m checking only the remaining setup-output lines now so the resolved field map matches the command’s own vocabulary.
exec
/bin/zsh -lc "nl -ba .opencode/commands/create/sk-skill.md | sed -n '216,260p'" in /Users/michelkerkmeester/MEGA/Development/Code_Environment/Public
 succeeded in 0ms:
   216	Phase outputs:
   217	- `skill_name`
   218	- `operation`
   219	- `type`
   220	- `skill_path`
   221	- `execution_mode`
   222	- `spec_choice`
   223	- `spec_path`
   224	- `memory_choice`
   225	
   226	---
   227	
   228	# PHASE STATUS VERIFICATION (BLOCKING)
   229	
   230	Verify all required values are set before YAML execution:
   231	
   232	| Field | Required | Rule |
   233	| --- | --- | --- |
   234	| create_agent_verified | Yes | `true` or `skipped-chained` |
   235	| skill_name | Yes | explicit, hyphen-case |
   236	| operation | Yes | one of 4 operation values |
   237	| type | Conditional | required for reference-only and asset-only |
   238	| skill_path | Yes | default `.opencode/skills/` if omitted |
   239	| execution_mode | Yes | `:auto` or `:confirm` |
   240	| spec_choice | Conditional | required for full-create and full-update |
   241	| spec_path | Conditional | required for spec choices A/B/C/E |
   242	
   243	Proceed only when all required fields validate.
   244	
   245	---
   246	
   247	## 1. PURPOSE
   248	
   249	Provide one canonical command entrypoint for skill lifecycle operations,
   250	eliminating split logic across deprecated command definitions while preserving
   251	strict @markdown + sk-doc + system-spec-kit behavior contracts.
   252	
   253	## 2. CONTRACT
   254	
   255	**Inputs:** `$ARGUMENTS` using canonical argument shape.
   256	
   257	**Outputs:**
   258	- Command execution through unified mode workflow and operation branch.
   259	- Deterministic completion summary with status and path.
   260	

exec
/bin/zsh -lc "nl -ba .opencode/skills/system-spec-kit/references/workflows/auto_mode_contract.md | sed -n '1,180p'" in /Users/michelkerkmeester/MEGA/Development/Code_Environment/Public
 succeeded in 0ms:
     1	---
     2	title: Auto Mode Contract Reference
     3	description: Canonical three-tier `:auto` setup-resolution contract shared by every user-invokable `/command:*:auto` surface. Defines tier semantics (resolve → targeted ask → fail-fast), `PRE-BOUND SETUP ANSWERS:` marker grammar, default-resolution table format, fail-fast error template, `:confirm` invariance, and verification protocol.
     4	---
     5	
     6	# Auto Mode Contract Reference
     7	
     8	This reference module defines the single canonical `:auto` setup-resolution contract used by every user-invokable `/command:*:auto` surface in spec-kit (`/spec_kit:*`, `/create:*`, `/improve:*`). Each command's §0 cites this contract and supplies only its own per-field Default Resolution Table + `PRE-BOUND SETUP ANSWERS:` field list. The contract semantics, marker grammar, error format, and verification protocol live here.
     9	
    10	Origin: shipped in `.opencode/specs/skilled-agent-orchestration/103-spec-kit-auto-mode-noninteractive-contract/001-deep-review-three-tier-setup/` (deep-review prototype) and generalized in `.../002-auto-mode-contract-generalization-to-all-commands/` (12-command rollout).
    11	
    12	Related memory: `feedback_auto_mode_ask_only_when_ambiguous.md`, `feedback_codex_spawnagent_allowlist.md`, `feedback_gate3_no_tmp_exemption.md`.
    13	
    14	---
    15	
    16	## §1. Three-Tier Flow
    17	
    18	`:auto` mode does NOT mean "never ask" (too rigid) and does NOT mean "always ask the full setup block" (too soft). It means "ask only when uncertain or ambiguous." This is achieved via three tiers, evaluated in order:
    19	
    20	### Tier 1 — Resolve Confidently
    21	
    22	When `execution_mode = AUTONOMOUS` (from `:auto` suffix), the command's §0 MUST attempt to resolve every required input from these sources in order:
    23	
    24	1. **`$ARGUMENTS` flags** — explicit user-passed flags (e.g. `--max-iterations=10`, `--spec-folder=PATH`, command-specific flags)
    25	2. **`PRE-BOUND SETUP ANSWERS:` block in the prompt body** — see §2 for grammar. Caller's explicit prompt-body binding wins over `$ARGUMENTS` when both are present
    26	3. **Documented per-field defaults** — see the command's own Default Resolution Table (§3) for which fields carry sensible defaults
    27	
    28	After resolution: if every required field has a value, persist the resolved map to the command's working-config file (e.g. `deep-review-config.json`, `plan-config.json`), set `STATUS: PASSED`, load the paired YAML workflow. Do NOT emit any setup question. End §0.
    29	
    30	### Tier 2 — Targeted Ask
    31	
    32	Use Tier 2 ONLY when Tier 1 leaves one or two required inputs unresolved AND each unresolved field is genuinely ambiguous AND no sensible default exists.
    33	
    34	Constraints:
    35	- Emit ONE narrow question per ambiguous field, naming only the ambiguous field. NEVER the full consolidated Q-block from the legacy setup phase.
    36	- If two fields are ambiguous but one's resolution likely makes the other obvious (e.g. `review_target_type` may make `spec_folder` self-evident), ask the first one first; do not bundle multiple ambiguities into a single prompt.
    37	- Missing required input (e.g. empty `$ARGUMENTS` with no marker for a required positional) is NOT ambiguity. Absence is a Tier 3 case.
    38	- Wait briefly for user reply. If an answer arrives, merge it into the resolved map and re-run Tier 1 from the default-application step. If stdin is closed (`</dev/null`, redirected output, non-interactive dispatch) and no answer arrives, fall through to Tier 3. Never wait indefinitely.
    39	
    40	### Tier 3 — Fail Fast
    41	
    42	Use Tier 3 when `:auto` still has unresolved required inputs after Tier 1 and Tier 2, OR when Tier 2 produced no answer because stdin is closed.
    43	
    44	Emit the named-missing-inputs error format (§4), exit non-zero, do NOT load the YAML workflow, do NOT emit any further setup question.
    45	
    46	---
    47	
    48	## §2. PRE-BOUND SETUP ANSWERS Schema
    49	
    50	The `PRE-BOUND SETUP ANSWERS:` block is a structured marker the dispatched AI parses out of the prompt body. It allows callers to pre-bind setup field values without using individual `$ARGUMENTS` flags.
    51	
    52	Grammar (YAML-style key/value, one field per line):
    53	
    54	```
    55	PRE-BOUND SETUP ANSWERS:
    56	  <field_name>: <value>  # optional inline comment
    57	  <field_name>: <value>
    58	  ...
    59	```
    60	
    61	Rules:
    62	
    63	- The block opens with `PRE-BOUND SETUP ANSWERS:` (exact case-sensitive heading, followed by colon). Indentation MAY be inside a markdown fenced code block or inline in the prompt text.
    64	- Each field is `  <key>: <value>` indented two spaces, one per line.
    65	- Values are interpreted by the command's Default Resolution Table (§3). Field types and value enums are command-specific.
    66	- Comments after `#` on a value line are ignored.
    67	- Unknown fields produce a warning (do not abort), so callers may include forward-compatible fields.
    68	- Fields not specified fall back to: command-specific Default Resolution Table → command-specific default value → unresolved (triggers Tier 2 or Tier 3 per §1).
    69	- Malformed lines (e.g. missing `:`, malformed value type) emit a parse error naming the line. Known fields parsed before the error may still be used; remaining unresolved fields continue to Tier 2 or Tier 3.
    70	- A second `PRE-BOUND SETUP ANSWERS:` block in the same prompt body produces a duplicate-block error.
    71	
    72	The marker block applies ONLY under `:auto`. Under `:confirm`, the block is informational and does not skip the consolidated question prompt.
    73	
    74	---
    75	
    76	## §3. Default Resolution Table
    77	
    78	Every command MUST publish a Default Resolution Table in its §0 (after citing this contract). The table lists each setup field with the following columns:
    79	
    80	| Field | Required | Resolves Via | Default | Tier-2 Candidate |
    81	|-------|----------|--------------|---------|------------------|
    82	
    83	Column meanings:
    84	
    85	- **Field**: the field name (matches the schema in §2 and the question label in the legacy consolidated Q-block).
    86	- **Required**: `Y` (must be resolved before YAML load) or `N` (optional).
    87	- **Resolves Via**: ordered list of resolution sources, e.g. `flag → $ARGUMENTS` / `marker → PRE-BOUND` / `default → "<value>"` / `auto-detect from <other field>` / `requires-ask`.
    88	- **Default**: the documented default value when no flag, marker, or auto-detection applies. May be `none` (no default — Tier 2 or Tier 3 candidate).
    89	- **Tier-2 Candidate**: `Y` if a missing value can be resolved by ONE targeted question (per §1); `N` if absence triggers fail-fast (Tier 3).
    90	
    91	A field is a Tier-2 candidate only when ALL of:
    92	- No flag exists for it.
    93	- No marker is provided.
    94	- No sensible default exists.
    95	- The field is genuinely required (Required=`Y`).
    96	- A user choice is the only resolution path (ambiguity, not absence).
    97	
    98	---
    99	
   100	## §4. Tier 3 Fail-Fast Error Template
   101	
   102	When Tier 3 fires, the command emits this exact format and exits non-zero:
   103	
   104	```
   105	[ERROR] /<command>:auto — required inputs unresolved under autonomous mode:
   106	  - <field>: <why-unresolved>
   107	  - <field>: <why-unresolved>
   108	Resolution: provide via $ARGUMENTS flags, PRE-BOUND SETUP ANSWERS: block, or switch to :confirm mode for interactive setup.
   109	```
   110	
   111	Rules:
   112	
   113	- Replace `<command>` with the canonical command name (e.g. `spec_kit:deep-review`).
   114	- One bulleted line per unresolved required field.
   115	- `<why-unresolved>` is one short phrase: "missing — no flag, no marker, no default" or "ambiguous — Tier 2 received no answer (stdin closed)".
   116	- Final line cites the three resolution paths verbatim.
   117	- Do NOT load the YAML workflow.
   118	- Do NOT emit setup questions in Tier 3.
   119	- Exit code: non-zero (1 is the convention).
   120	
   121	---
   122	
   123	## §5. `:confirm` Invariance
   124	
   125	The `:confirm` mode (interactive, with full consolidated Q-block) is unaffected by this contract. Commands MUST preserve their existing `:confirm` behavior exactly. The contract applies ONLY when `execution_mode = AUTONOMOUS` (from `:auto` suffix or explicit `--mode=AUTONOMOUS` flag).
   126	
   127	Test invariant: a `:confirm` dispatch against any contract-adopting command MUST emit the original consolidated Q-block (Q0..Qn). Regression-check this per command after migration.
   128	
   129	---
   130	
   131	## §6. Verification Protocol
   132	
   133	Each contract-adopting command requires four verification traces (dry-run mental dispatch traces against the command's §0):
   134	
   135	### Trace A — Tier 1 pass
   136	Dispatch with all required inputs resolvable (flags + markers + defaults). Expected: STATUS PASSED, YAML loaded, no question emitted.
   137	
   138	### Trace B — Tier 2 targeted ask
   139	Dispatch with exactly one ambiguous required field. Expected: ONE narrow question naming only that field; NEVER the full consolidated block.
   140	
   141	### Trace C — Tier 3 fail fast
   142	Dispatch with one or more truly missing required inputs (and stdin closed in non-interactive runtimes). Expected: error format from §4, exit non-zero, no YAML load.
   143	
   144	### Trace D — `:confirm` regression
   145	Dispatch with `:confirm` suffix and any inputs. Expected: existing full consolidated Q-block emitted.
   146	
   147	Live verification (when feasible) extends the dry-run traces with actual non-interactive dispatches (codex `exec </dev/null`, opencode `run --pure ... </dev/null`, claude `--print`) capturing transcripts as evidence. Live verification confirms the contract works under real runtime stdin-closure conditions.
   148	
   149	Evidence schema (one file per dispatch):
   150	- Command invocation verbatim
   151	- Full transcript
   152	- Verdict footer: PASS / PARTIAL / FAIL / SKIP
   153	- Optional: timing, model, runtime gotchas observed
   154	
   155	Stored under `<packet>/evidence/<command-slug>-<trace>.txt`.
   156	
   157	---
   158	
   159	## §7. Adoption Checklist
   160	
   161	For each command adopting this contract, the §0 of the command markdown:
   162	
   163	- [ ] Adds a one-line citation: `Setup contract: see references/workflows/auto_mode_contract.md`
   164	- [ ] Provides its own per-field Default Resolution Table (§3) listing every Q-block field with the four columns
   165	- [ ] Provides its own `PRE-BOUND SETUP ANSWERS:` field list (one row per setup field, matching the Default Resolution Table)
   166	- [ ] Documents any command-specific Tier-2 ordering rule (e.g. "ask review_target_type before spec_folder")
   167	- [ ] Updates frontmatter `argument-hint` to reference the new bypass capability
   168	- [ ] Preserves the existing `:confirm` consolidated Q-block path untouched
   169	- [ ] Authors §0 dry-run traces (A/B/C/D) and stores them under the adopting packet's `evidence/`
   170	
   171	Commands that have adopted this contract:
   172	
   173	- `/spec_kit:deep-review` (prototype) — see `.../103/001-deep-review-three-tier-setup/`
   174	- (to be appended as `.../103/002-...` rolls out)
   175	
   176	---
   177	
   178	## §8. Out of Scope
   179	
   180	- Commands without paired YAML workflows (`/improve:prompt`, `agent_router`, etc.) — they have no setup-phase surface where the contract applies.

exec
/bin/zsh -lc "rg -n \"\\bcreate\\b|full-create|spec_folder|spec_choice|operation\" .opencode/commands/create/sk-skill.md" in /Users/michelkerkmeester/MEGA/Development/Code_Environment/Public
 succeeded in 0ms:
2:description: Create or update OpenCode skills via one unified command with operation routing. :auto/:confirm.
3:argument-hint: "<skill-name> [operation] [type] [--path <dir>] [--chained] [:auto|:confirm] (:auto supports PRE-BOUND SETUP ANSWERS: prompt-body block for non-interactive setup)"
17:> 5. Route by operation (`full-create`, `full-update`, `reference-only`, `asset-only`)
41:|  |  - operation
66:Restart with: @markdown /create:sk-skill <skill-name> [operation] [type]"
87:1. **Tier 1 — Resolve confidently** (contract §1): parse `$ARGUMENTS` flags + `PRE-BOUND SETUP ANSWERS:` block (§2) + the Default Resolution Table below (§3). When every required field is resolved, persist to `{spec_path}/create-sk-skill-config.json` when a spec is linked, otherwise `/tmp/create-sk-skill-config.json` (shape: `skillName`, `operation`, `type`, `skillPath`, `executionMode: "auto"`, `specChoice`, `specPath`, `memoryChoice`, `chainedHandoffValid`), bind runtime YAML placeholders, set `STATUS: PASSED`, load `.opencode/commands/create/assets/create_sk_skill_auto.yaml`. End §0.
89:2. **Tier 2 — Targeted ask** (contract §1): when 1-2 required fields are genuinely ambiguous AND no default exists, emit ONE narrow question per ambiguous field. Command-specific Tier-2-eligible fields (per the Default Resolution Table below): `type`, `spec_choice`. **Ordering rule**: if `type` is required for `reference-only` or `asset-only`, ask only for `type` first — the answer may make the operation branch fully resolvable on the next Tier 1 pass.
91:3. **Tier 3 — Fail fast** (contract §4): emit the named-missing-inputs error format with `/create:sk-skill:auto` as the command name. Exit non-zero. Do not load YAML.
102:  operation: full-create  # full-create | full-update | reference-only | asset-only
106:  spec_choice: new  # existing | new | update-related | skip | phase-folder
119:| `operation` | Y | `$ARGUMENTS` second positional token, marker `operation`, or chained parent value | none | N |
120:| `type` | Conditional | `$ARGUMENTS` third positional token, marker `type`, or chained parent value when `operation` is `reference-only` / `asset-only` | none | Y, when operation requires type and type is ambiguous |
123:| `spec_choice` | Conditional | marker `spec_choice`, chained parent value, or targeted choice for `full-create` / `full-update` | none | Y, when full operation is selected and folder choice is ambiguous |
124:| `spec_path` | Conditional | marker `spec_path`, derived from `spec_choice`, or chained parent value | none | N |
133:   - /create:sk-skill <skill-name> [operation] [type] [--path <dir>] [--chained] [:auto|:confirm]
142:   - token 2: operation (if present)
150:   - If chained_handoff_valid=true and all required fields for selected operation exist:
157:   - Ask operation only when missing
158:   - Ask type only when operation requires it and type is missing/invalid
160:   - Ask spec folder choice only for full-create and full-update
169:       A) full-create (new skill end-to-end)
171:       C) reference-only (create/update one reference document)
172:       D) asset-only (create/update one asset document)
178:   Q3. Spec Folder (required for full-create/full-update)
202:   - operation
206:   - spec_choice
211:- Do not infer missing operation or type from context
213:- Do not continue with missing required fields for selected operation
218:- `operation`
222:- `spec_choice`
236:| operation | Yes | one of 4 operation values |
240:| spec_choice | Conditional | required for full-create and full-update |
249:Provide one canonical command entrypoint for skill lifecycle operations,
258:- Command execution through unified mode workflow and operation branch.
272:Accepted operation values:
273:- `full-create`
294:| 5 | Operation Routing | Select operation branch | operation-specific execution |
308:- Validate required fields by operation.
316:- Route to one branch: full-create/full-update/reference-only/asset-only.
327:- `:auto` -> `.opencode/commands/create/assets/create_sk_skill_auto.yaml`
328:- `:confirm` -> `.opencode/commands/create/assets/create_sk_skill_confirm.yaml`
347:   |   - operation
354:   |- If operation missing -> setup prompt Q1
356:   |- If operation in {reference-only, asset-only} and type missing -> setup prompt Q2
358:   |- If operation in {full-create, full-update} -> enforce spec folder setup Q3
360:   '- Route execution to selected mode YAML and operation branch
369:| `full-create` | New skill end-to-end | No | No (hard block if exists) |
375:- `full-create`: initializes and populates skill structure.
385:- H0: create verification / valid chained handoff
387:- H2: operation/type compatibility
388:- H3: existence semantics (create vs update/doc-only)
392:- S1: similar skill discovery before full-create
398:  - full-create/full-update: 90
444:| Invalid `operation` | Re-prompt Q1 with valid options |
445:| Missing or invalid `type` for doc-only operations | Re-prompt Q2 with operation-specific values |
446:| `full-create` on existing skill | Offer reroute to `full-update` |
447:| Update/doc-only on missing skill | Offer reroute to `full-create` or corrected skill name |
462:Full create:
464:/create:sk-skill pdf-editor full-create :confirm
469:/create:sk-skill pdf-editor full-update :auto
474:/create:sk-skill sk-doc reference-only workflow :confirm
479:/create:sk-skill sk-doc asset-only template :auto
484:/create:sk-skill sk-doc reference-only debugging --chained :auto
494:- `/create:skill <skill-name> [:auto|:confirm]`
495:  -> `/create:sk-skill <skill-name> full-create [:auto|:confirm]`
497:- `/create:skill_reference <skill-name> <reference-type> [--chained] [:auto|:confirm]`
498:  -> `/create:sk-skill <skill-name> reference-only <reference-type> [--chained] [:auto|:confirm]`
500:- `/create:skill_asset <skill-name> <asset-type> [--chained] [:auto|:confirm]`
501:  -> `/create:sk-skill <skill-name> asset-only <asset-type> [--chained] [:auto|:confirm]`
504:- `.opencode/commands/create/assets/create_sk_skill_auto.yaml`
505:- `.opencode/commands/create/assets/create_sk_skill_confirm.yaml`
513:| `/create:prompt` | Builds prompt artifacts and may reference skill creation patterns |
524:Operation: [operation]
548:- proceed with missing required operation/type fields
549:- bypass create-vs-update existence checks

exec
/bin/zsh -lc "nl -ba .opencode/commands/create/sk-skill.md | sed -n '268,300p'; nl -ba .opencode/commands/create/sk-skill.md | sed -n '488,502p'" in /Users/michelkerkmeester/MEGA/Development/Code_Environment/Public
 succeeded in 0ms:
   268	```text
   269	$ARGUMENTS
   270	```
   271	
   272	Accepted operation values:
   273	- `full-create`
   274	- `full-update`
   275	- `reference-only`
   276	- `asset-only`
   277	
   278	Accepted mode suffix values:
   279	- `:auto`
   280	- `:confirm`
   281	
   282	Accepted type values:
   283	- reference-only: `workflow`, `patterns`, `debugging`, `tools`, `quick_ref`
   284	- asset-only: `template`, `lookup`, `example`, `guide`
   285	
   286	## 4. WORKFLOW OVERVIEW
   287	
   288	| Step | Name | Purpose | Output |
   289	| --- | --- | --- | --- |
   290	| 1 | Phase 0 Verification | Ensure @markdown or valid chained handoff | `create_agent_verified` |
   291	| 2 | Unified Setup | Capture all required parameters once | normalized setup fields |
   292	| 3 | Phase Validation | Enforce required-field contract | phase pass/fail |
   293	| 4 | Mode Routing | Route to auto or confirm unified YAML | target YAML path |
   294	| 5 | Operation Routing | Select operation branch | operation-specific execution |
   295	| 6 | Validation + Completion | Enforce quality gates and produce status | `STATUS=OK|FAIL|CANCELLED` |
   296	
   297	## 5. INSTRUCTIONS
   298	
   299	### Step 1: Run Phase 0
   300	- Execute @markdown/chained verification.
   488	
   489	## 14. MIGRATION MAP
   490	
   491	Canonical command strategy is active.
   492	
   493	Deprecated invocation mapping:
   494	- `/create:skill <skill-name> [:auto|:confirm]`
   495	  -> `/create:sk-skill <skill-name> full-create [:auto|:confirm]`
   496	
   497	- `/create:skill_reference <skill-name> <reference-type> [--chained] [:auto|:confirm]`
   498	  -> `/create:sk-skill <skill-name> reference-only <reference-type> [--chained] [:auto|:confirm]`
   499	
   500	- `/create:skill_asset <skill-name> <asset-type> [--chained] [:auto|:confirm]`
   501	  -> `/create:sk-skill <skill-name> asset-only <asset-type> [--chained] [:auto|:confirm]`
   502	

codex
- **Citation present:** yes, line 83: `.opencode/skills/system-spec-kit/references/workflows/auto_mode_contract.md`

- **Section zero Tier reached:** 3

- **Setup question emitted:** no

- **Resolved field map:**
  - `skill_name`: `sk-throwaway`
  - `operation`: unresolved, marker value `create` is invalid; accepted values are `full-create`, `full-update`, `reference-only`, `asset-only`
  - `type`: n/a, not resolvable because `operation` is invalid
  - `skill_path`: `.opencode/skills/`
  - `execution_mode`: `AUTONOMOUS`
  - `spec_choice`: unresolved; prompt supplied `spec_folder`, but section zero schema expects `spec_choice`
  - `spec_path`: unresolved
  - `memory_choice`: `skip`
  - `chained_handoff_valid`: `false`

- **STATUS value:** fail-fast error

- **Verdict:** FAIL  
  Tier 1 does not resolve because two pre-bound fields do not match the command’s section-zero contract: `operation: create` is not a valid operation value, and `spec_folder` is an unknown field rather than `spec_choice`. No legacy Q-block is emitted, but the intended Tier-1 non-interactive setup contract does not pass.
hook: Stop
hook: Stop Completed
tokens used
19,546
- **Citation present:** yes, line 83: `.opencode/skills/system-spec-kit/references/workflows/auto_mode_contract.md`

- **Section zero Tier reached:** 3

- **Setup question emitted:** no

- **Resolved field map:**
  - `skill_name`: `sk-throwaway`
  - `operation`: unresolved, marker value `create` is invalid; accepted values are `full-create`, `full-update`, `reference-only`, `asset-only`
  - `type`: n/a, not resolvable because `operation` is invalid
  - `skill_path`: `.opencode/skills/`
  - `execution_mode`: `AUTONOMOUS`
  - `spec_choice`: unresolved; prompt supplied `spec_folder`, but section zero schema expects `spec_choice`
  - `spec_path`: unresolved
  - `memory_choice`: `skip`
  - `chained_handoff_valid`: `false`

- **STATUS value:** fail-fast error

- **Verdict:** FAIL  
  Tier 1 does not resolve because two pre-bound fields do not match the command’s section-zero contract: `operation: create` is not a valid operation value, and `spec_folder` is an unknown field rather than `spec_choice`. No legacy Q-block is emitted, but the intended Tier-1 non-interactive setup contract does not pass.


=== EXIT 0; WALL 79s ===
