[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6DT18NF43V0F4DBX6C3T4VB":3,"skill-same:01M6DT18NF43V0F4DBX6C3T4VB":79},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":17,"publishedAt":35,"linkOnly":36,"markdownContent":37,"markdownBody":38,"frontMatter":39,"refName":40,"commitSha":41,"skillDirectory":42,"forksCount":43,"repositoryHtmlUrl":44,"repositoryHomepageUrl":6,"ownerHtmlUrl":45,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":46,"install":47,"resources":60},"01M6DT18NF43V0F4DBX6C3T4VB","Qgenerate-spec",null,"Use when a routed goal or plan handoff needs TASK_REQUEST and VERIFY_CHECKLIST documents — router-owned internal PSE unit. Use Qgoal to enter; use Qplan for roadmap work.","inho-team\u002Fqe-framework","inho-team","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F264128745?v=4","01M6DSZK6GTAMMXSV3VJJSKN6Y","01M6DSZKA95G3ADR7SCQ7ANTJH",6,"MIT","https:\u002F\u002Fgithub.com\u002Finho-team\u002Fqe-framework\u002Fblob\u002Fmain\u002Fskills\u002FQgenerate-spec\u002FSKILL.md",[],[18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34],"spec","Qgenerate spec","documents","core","verify","plan","haiku","work","use","router","roadmap","goal","checklist","qplan","task","false","handoff","2026-11-10 10:12:30",false,"---\nname: Qgenerate-spec\ndescription: \"Use when a routed goal or plan handoff needs TASK_REQUEST and VERIFY_CHECKLIST documents — router-owned internal PSE unit. Use Qgoal to enter; use Qplan for roadmap work.\"\nuser_invocable: false\nrecommendedModel: haiku\ntier: core\n---\n\n> **`.qe` reads → DB:** `.qe\u002F` content is stored in the SQLite store (`qe_files`), so a path may have **no file on disk**. Read `.qe\u002F` content with `node scripts\u002Fqe-cat.mjs \u003Cpath>` (or `--ls`\u002F`--exists`) and structured state with `node scripts\u002Fqe-query.mjs …` — do not assume the raw file exists. See `QE_CONVENTIONS.md`.\n\n# Project Spec Document Generation (Qplan Component)\n\n> Internal PSE unit. Users start work with `{adapter.commandPrefix}Qgoal {목표}`; `user_invocable` is catalog\u002Fdocumentation metadata only. Runtime enforcement is the G010 PreToolUse gate.\n\n## Role\nYou are a specialist document writer acting as a **sub-component of the `Qplan` ecosystem**. Your primary goal is to transform a high-level roadmap Phase into **Haiku-Ready Atomic Tasks**.\n\nBefore generating a spec internally, ensure the shared `QE.md` and active-client instruction pointer exist.\nThe supported public intake is `Qgoal` or `Qplan`; this stage is not directly invocable.\n\n## Role Constraints (Absolute Rules)\n- When this skill is invoked, focus exclusively on writing the 3 spec documents.\n- Do not perform any actions outside of document writing, such as writing code, fixing bugs, or answering general questions.\n- **User confirmation MUST go through the interaction adapter.** Claude MUST use `AskUserQuestion` and MUST NOT print options as plain text. Codex interactive may print concise plain-text choices because `AskUserQuestion` is not a Codex primitive. Codex non-interactive MUST select the deterministic recommended default and report it.\n\n## Client Adapter Compatibility\n\nInteraction rules:\n- **Claude**: use `AskUserQuestion` for Step 3 and any other structured choice.\n- **Codex interactive**: ask concise plain-text choices with the same option labels.\n- **Codex non-interactive**: choose **Generate Only** unless the task is already chained or the user explicitly requested execution.\n\nCommand rendering rules:\n- Render handoff commands through `adapter.commandPrefix`.\n- Claude examples use `\u002FQ...`, for example `\u002FQexecute {UUID}`.\n- Codex examples use `$Q...`, for example `$Qexecute {UUID}`.\n\n## Documents to Generate\n\n| # | Filename | Path | Description |\n|---|----------|------|-------------|\n| 1 | Project instruction artifact | Project root | Shared QE context is `QE.md`; the Claude adapter points from `CLAUDE.md` and Codex from `AGENTS.md`. Must reference `QE_CONVENTIONS.md` for QE rules. Task history is in `.qe\u002FTASK_LOG.md`. |\n| 2 | `TASK_REQUEST_{UUID}.md` | `.qe\u002Ftasks\u002Fpending\u002F` | Task request — what, how, checklist, notes |\n| 3 | `VERIFY_CHECKLIST_{UUID}.md` | `.qe\u002Fchecklists\u002Fpending\u002F` | Verification checklist — validation criteria, additional notes |\n\n- A single task shares the same UUID across both documents.\n- Multiple tasks get separate TASK_REQUEST \u002F VERIFY_CHECKLIST pairs.\n- Newly generated documents always go in `pending\u002F`.\n\n## SIVS Single-AI Role Contract\n\nThe active client owns every SIVS stage; do not delegate Spec to another AI\nclient or bridge. The **main thread** creates TASK_REQUEST and\nVERIFY_CHECKLIST, then runs the mandatory spec critical gate with isolated\nsubagent roles. If native subagents are unavailable, use role-separated inline\npasses and record `mode=degraded-inline`.\n\n`.qe\u002Fsivs-config.json` may set an active-client model or effort, but it cannot\nroute this stage to Claude or Codex. See `core\u002FSIVS_SINGLE_AI_MODEL.md`.\n\n## Workflow\n\n### Step 1: Context Acquisition (Mandatory)\nBefore collecting user info, identify the strategic context:\n1. **Resolve active plan** (slug-based Named Plan layout):\n   - If the first CLI token matches `{slug}:` (where slug is `[a-z0-9][a-z0-9-]{0,63}`), use that as the plan slug and strip it from the argument string.\n   - Else read `.qe\u002Fstate\u002Fcurrent-session.json` → extract `session_id` → read `.qe\u002Fplanning\u002F.sessions\u002F{session_id}.json` → extract `activePlanSlug`.\n   - Else read `.qe\u002Fplanning\u002FACTIVE_PLAN` (single-line slug pointer).\n   - Else (no slug resolvable): fall back to legacy flat `.qe\u002Fplanning\u002FROADMAP.md` + `STATE.md` and proceed as before.\n2. **Check Roadmap**: When a slug is resolved, read `.qe\u002Fplanning\u002Fplans\u002F{slug}\u002FROADMAP.md` and `plans\u002F{slug}\u002FSTATE.md`. When falling back, read the flat files.\n3. **Identify Phase**: If an active Phase exists in the resolved STATE.md, use its **Success Criteria** and **Requirement IDs** as the primary source of truth for the spec.\n4. **Missing Roadmap**: If no plan is resolvable and no flat roadmap exists either, **STOP** and suggest running `{adapter.commandPrefix}Qplan` first to maintain the PSE Chain integrity.\n\n### Steps 1.4–1.5: Context dump and clarification\n\nAccept long or unstructured context without asking the user to reformat it. For\nSmall-or-larger ambiguous work, ask only the highest-impact missing questions;\nMicro tasks and exact file\u002Freproduction requests skip clarification. Record every\nAI-chosen default under `## 가정 (AI 결정)` as `[ASSUMED]`. Full thresholds,\nsignals, and question dimensions:\n[.\u002Freference\u002Fspec-workflow.md](.\u002Freference\u002Fspec-workflow.md).\n\n### Step 2: Information Gathering\n... (omitted) ...\n\nRequired information:\n- **Project name**, **description** (one-paragraph summary)\n- **Goals** (1-5 items), **Constraints** (tech stack, performance, security, etc.), **Decisions** (finalized)\n- **Task list** — for each task: what, how, steps (checklist), expected output files (optional), notes, type (`code`|`analysis`|`docs`|`other`), validation criteria (checks), verification notes, and optional decision rationale (chosen approach, alternatives, consequences)\n- **Code Risk Register** — for every `type: code` task, include a mandatory risk section that names worst-case failure, data loss\u002Fcorruption risk, security\u002Fpermission risk, concurrency\u002Frace risk, rollback strategy, and unverified assumptions. If a category is not applicable, write `N\u002FA` with the reason; do not omit it.\n\n### Step 2: Draft Documents\nWrite drafts using templates from `templates\u002F` directory (`TASK_REQUEST_TEMPLATE.md`, `VERIFY_CHECKLIST_TEMPLATE.md`). For any generated project instruction artifact, reference `QE_CONVENTIONS.md` (project root) for QE rules (file naming, task status, completion criteria) and include a reference line pointing to it. Replace `{{placeholder}}` with actual content.\n- **Frontmatter substitution (per `core\u002FDOC_CONVENTIONS.md`)**: the title-following `qe-doc-frontmatter` block placeholders are filled deterministically — `{{kind}}` = the generator mapping value (`TASK_REQUEST` → `spec`, `VERIFY_CHECKLIST` → `verify`), `{{plan}}` = the active plan slug, `{{phase}}` = the requested\u002Fcurrent phase name, `{{created}}` = today's date (`YYYY-MM-DD`), `{{status}}` = `pending` at creation. Keep the H1 title on line 1 so the completion hook still extracts it; the frontmatter block goes on the line immediately after.\n- **Model Preference**: Use **Haiku** for drafting standardized templates to reduce latency.\n\n### Steps 2.4–2.6: Premise and spec gates\n\nVerify external CLI, manifest, hook, API, and npm claims before drafting. Mark\nunresolved claims `[UNVERIFIED]` and remove disproved premises. Check structural\nand executability criteria, then always run `Qcritical-review --stage spec` with\nisolated roles. FAIL remains execution-blocking after at most two revisions;\nWARN\u002FPASS may proceed with notes. Full workflow:\n[.\u002Freference\u002Fspec-workflow.md](.\u002Freference\u002Fspec-workflow.md).\n\nThis gate ALWAYS runs. Unlike Step 2.5, it has no skip conditions.\n\n### Step 3: Review, Create, and Execute\n\nUse the interaction adapter to choose Generate Only or Generate & Execute. A\ngate-blocked spec may only be saved or revised. Recommend a wave for four or\nmore independent items. Non-interactive Codex defaults to Generate Only unless\nexecution was explicitly requested or chained. Create artifacts in pending\u002F and\nchain execution internally; never ask the user to orchestrate internal PSE stages.\nDetailed choices and output reporting:\n[.\u002Freference\u002Fspec-workflow.md](.\u002Freference\u002Fspec-workflow.md).\n\n## Autonomous Mode Support\n\nWhen called from Qexecute -utopia (autonomous mode), Qgenerate-spec:\n- Skips all interaction prompts — auto-selects the documented default\n- Auto-proceeds through Steps 1-3 without user confirmation\n- Sets `\u003C!-- chained-from: Qgenerate-spec -->` on generated TASK_REQUEST files\n\nSee `Qexecute -utopia` for autonomous execution modes (`-utopia`, `-utopia -verify`).\n\n## Document Writing Rules\n\n### Language Matching (Required)\nTASK_REQUEST and VERIFY_CHECKLIST must match the user's language.\n- Korean user → Korean documents; English user → English documents; mixed\u002Funclear → English\n- **Scope:** TASK_REQUEST and VERIFY_CHECKLIST only. Internal framework files stay English. CLAUDE.md follows user language when specified.\n\n### Project Instruction Artifact\n- Single Source of Truth for client-specific project context; Claude adapter uses `CLAUDE.md`, Codex-capable projects may use `AGENTS.md` or an equivalent QE-managed instruction file.\n- **Do NOT write task lists in the instruction artifact.** Task history lives in `.qe\u002FTASK_LOG.md`. The instruction artifact only contains a reference pointer: `## Task Log` → see `.qe\u002FTASK_LOG.md`\n\n### TASK_REQUEST\n- **What vs How**: Clearly separate the business goal from the technical implementation logic (from QE planning patterns).\n- **Atomic Items**: Every checklist item must be **independent** and **verifiable**.\n- **Dependency Mapping**: If an item depends on another, mark it: `- [ ] {desc} \u003C!-- depends_on: [UUID\u002FItem#] -->`.\n- **Haiku-Ready**: Ensure items are small enough to be implemented without Sonnet-level reasoning.\n- **Output files**: Always append `→ output: {file-path}` for direct accountability.\n- **Assumed defaults**: Any decision the user delegated (\"나머지는 알아서\") and the AI resolved goes in an optional `## 가정 (AI 결정)` section, one `[ASSUMED]` line per decision with a one-phrase rationale. This keeps delegated choices reviewable instead of buried in the draft.\n- **Role ownership**: In role-separated or tiered orchestration, identify the expected implementer-owned files or modules so the reviewer can later judge boundary violations.\n- **Code Risk Register (mandatory for `type: code`)**: Add this section before the checklist and fill every field:\n  ```markdown\n  ## Risk Register\n  - Worst-case failure:\n  - Data loss \u002F corruption risk:\n  - Security \u002F permission risk:\n  - Concurrency \u002F race risk:\n  - Rollback strategy:\n  - Unverified assumptions:\n  ```\n  The register is a hard SIVS contract. Empty fields, placeholder text, or omitted categories block execution until fixed.\n\n### VERIFY_CHECKLIST\n- Each criterion answerable as yes\u002Fno\n- Task complete when all items checked\n- Include note to update `.qe\u002FTASK_LOG.md` task list to ✅\n- **Auto-include by type:**\n  - `type: code` → add: \"No security vulnerabilities (OWASP Top 10) in changed code\", \"All existing tests pass\", \"Worst-case failure path is identified\", \"Data loss\u002Fcorruption, security\u002Fpermission, and concurrency\u002Frace risks are explicitly evaluated or marked N\u002FA with reason\", \"Unverified assumptions and residual risks are reported in the final handoff\", \"High-risk findings are mitigated by tests, defensive code, or an explicit defer rationale\"\n  - `type: code` + auth\u002Fcrypto\u002Fpayment → add: \"Authentication\u002Fencryption implementation is secure (Esecurity-officer or manual review)\"\n  - `type: docs` → add: \"All links in documentation are valid\", \"Terminology and formatting are consistent\"\n\n## UUID Generation Rules\n- 8-character hex (e.g., `a1b2c3d4`), generated randomly\n- Same UUID shared between TASK_REQUEST and VERIFY_CHECKLIST for same task\n- **Collision check**: Before using a UUID, verify no file matching `TASK_REQUEST_{UUID}.md` already exists in `.qe\u002Ftasks\u002Fpending\u002F` or `.qe\u002Ftasks\u002Fcompleted\u002F`. If it exists, generate a new random UUID and check again.\n- Generate UUIDs via bash: `openssl rand -hex 4` (produces 8-char hex)\n\n## Self-Evolving\n- After completing tasks, if recurring patterns found, suggest template improvements\n- On user approval, reflect patterns in future generation\n\n## Contract Candidate Extraction (Optional)\n\nOnly `\u003C!-- contract-candidates: auto -->` enables extraction. Write generated\ncontracts to `.qe\u002Fcontracts\u002Fpending\u002F`, preserve existing drafts, and require\nexplicit human approval before promotion. Full rules:\n[.\u002Freference\u002Fdocument-contracts.md](.\u002Freference\u002Fdocument-contracts.md).\n\n## Handoff\nAfter generating spec files (on \"Generate Only\"), display using the standard handoff format from `QE_CONVENTIONS.md`:\n\n```\nPhase {X}: {PhaseName} — Spec complete\n\nPSE: [x] Plan [x] Spec [>] Execute [ ] Verify\n\n{TaskDescription — 다음 작업 내용 한 줄 요약}\nNext: {adapter.commandPrefix}Qexecute {UUID}\n```\n\nNote: \"Generate & Execute\" auto-chains, so the handoff is only needed for \"Generate Only\".\n\n**Fresh-context hint**: If the spec conversation was long (context dump + multi-round clarification), append one line recommending execution from a fresh session: \"이 세션의 컨텍스트가 무겁습니다 — 새 세션에서 `{adapter.commandPrefix}Qexecute {UUID}` 실행을 권장합니다.\" The spec file already carries everything Qexecute needs; LLMs perform best with a lean context, so don't drag the spec-drafting conversation into execution.\n\n## Output Format\n- Wrap document content in markdown code blocks when displaying\n- Pure markdown only, no JSON\n","> **`.qe` reads → DB:** `.qe\u002F` content is stored in the SQLite store (`qe_files`), so a path may have **no file on disk**. Read `.qe\u002F` content with `node scripts\u002Fqe-cat.mjs \u003Cpath>` (or `--ls`\u002F`--exists`) and structured state with `node scripts\u002Fqe-query.mjs …` — do not assume the raw file exists. See `QE_CONVENTIONS.md`.\n\n# Project Spec Document Generation (Qplan Component)\n\n> Internal PSE unit. Users start work with `{adapter.commandPrefix}Qgoal {목표}`; `user_invocable` is catalog\u002Fdocumentation metadata only. Runtime enforcement is the G010 PreToolUse gate.\n\n## Role\nYou are a specialist document writer acting as a **sub-component of the `Qplan` ecosystem**. Your primary goal is to transform a high-level roadmap Phase into **Haiku-Ready Atomic Tasks**.\n\nBefore generating a spec internally, ensure the shared `QE.md` and active-client instruction pointer exist.\nThe supported public intake is `Qgoal` or `Qplan`; this stage is not directly invocable.\n\n## Role Constraints (Absolute Rules)\n- When this skill is invoked, focus exclusively on writing the 3 spec documents.\n- Do not perform any actions outside of document writing, such as writing code, fixing bugs, or answering general questions.\n- **User confirmation MUST go through the interaction adapter.** Claude MUST use `AskUserQuestion` and MUST NOT print options as plain text. Codex interactive may print concise plain-text choices because `AskUserQuestion` is not a Codex primitive. Codex non-interactive MUST select the deterministic recommended default and report it.\n\n## Client Adapter Compatibility\n\nInteraction rules:\n- **Claude**: use `AskUserQuestion` for Step 3 and any other structured choice.\n- **Codex interactive**: ask concise plain-text choices with the same option labels.\n- **Codex non-interactive**: choose **Generate Only** unless the task is already chained or the user explicitly requested execution.\n\nCommand rendering rules:\n- Render handoff commands through `adapter.commandPrefix`.\n- Claude examples use `\u002FQ...`, for example `\u002FQexecute {UUID}`.\n- Codex examples use `$Q...`, for example `$Qexecute {UUID}`.\n\n## Documents to Generate\n\n| # | Filename | Path | Description |\n|---|----------|------|-------------|\n| 1 | Project instruction artifact | Project root | Shared QE context is `QE.md`; the Claude adapter points from `CLAUDE.md` and Codex from `AGENTS.md`. Must reference `QE_CONVENTIONS.md` for QE rules. Task history is in `.qe\u002FTASK_LOG.md`. |\n| 2 | `TASK_REQUEST_{UUID}.md` | `.qe\u002Ftasks\u002Fpending\u002F` | Task request — what, how, checklist, notes |\n| 3 | `VERIFY_CHECKLIST_{UUID}.md` | `.qe\u002Fchecklists\u002Fpending\u002F` | Verification checklist — validation criteria, additional notes |\n\n- A single task shares the same UUID across both documents.\n- Multiple tasks get separate TASK_REQUEST \u002F VERIFY_CHECKLIST pairs.\n- Newly generated documents always go in `pending\u002F`.\n\n## SIVS Single-AI Role Contract\n\nThe active client owns every SIVS stage; do not delegate Spec to another AI\nclient or bridge. The **main thread** creates TASK_REQUEST and\nVERIFY_CHECKLIST, then runs the mandatory spec critical gate with isolated\nsubagent roles. If native subagents are unavailable, use role-separated inline\npasses and record `mode=degraded-inline`.\n\n`.qe\u002Fsivs-config.json` may set an active-client model or effort, but it cannot\nroute this stage to Claude or Codex. See `core\u002FSIVS_SINGLE_AI_MODEL.md`.\n\n## Workflow\n\n### Step 1: Context Acquisition (Mandatory)\nBefore collecting user info, identify the strategic context:\n1. **Resolve active plan** (slug-based Named Plan layout):\n   - If the first CLI token matches `{slug}:` (where slug is `[a-z0-9][a-z0-9-]{0,63}`), use that as the plan slug and strip it from the argument string.\n   - Else read `.qe\u002Fstate\u002Fcurrent-session.json` → extract `session_id` → read `.qe\u002Fplanning\u002F.sessions\u002F{session_id}.json` → extract `activePlanSlug`.\n   - Else read `.qe\u002Fplanning\u002FACTIVE_PLAN` (single-line slug pointer).\n   - Else (no slug resolvable): fall back to legacy flat `.qe\u002Fplanning\u002FROADMAP.md` + `STATE.md` and proceed as before.\n2. **Check Roadmap**: When a slug is resolved, read `.qe\u002Fplanning\u002Fplans\u002F{slug}\u002FROADMAP.md` and `plans\u002F{slug}\u002FSTATE.md`. When falling back, read the flat files.\n3. **Identify Phase**: If an active Phase exists in the resolved STATE.md, use its **Success Criteria** and **Requirement IDs** as the primary source of truth for the spec.\n4. **Missing Roadmap**: If no plan is resolvable and no flat roadmap exists either, **STOP** and suggest running `{adapter.commandPrefix}Qplan` first to maintain the PSE Chain integrity.\n\n### Steps 1.4–1.5: Context dump and clarification\n\nAccept long or unstructured context without asking the user to reformat it. For\nSmall-or-larger ambiguous work, ask only the highest-impact missing questions;\nMicro tasks and exact file\u002Freproduction requests skip clarification. Record every\nAI-chosen default under `## 가정 (AI 결정)` as `[ASSUMED]`. Full thresholds,\nsignals, and question dimensions:\n[.\u002Freference\u002Fspec-workflow.md](.\u002Freference\u002Fspec-workflow.md).\n\n### Step 2: Information Gathering\n... (omitted) ...\n\nRequired information:\n- **Project name**, **description** (one-paragraph summary)\n- **Goals** (1-5 items), **Constraints** (tech stack, performance, security, etc.), **Decisions** (finalized)\n- **Task list** — for each task: what, how, steps (checklist), expected output files (optional), notes, type (`code`|`analysis`|`docs`|`other`), validation criteria (checks), verification notes, and optional decision rationale (chosen approach, alternatives, consequences)\n- **Code Risk Register** — for every `type: code` task, include a mandatory risk section that names worst-case failure, data loss\u002Fcorruption risk, security\u002Fpermission risk, concurrency\u002Frace risk, rollback strategy, and unverified assumptions. If a category is not applicable, write `N\u002FA` with the reason; do not omit it.\n\n### Step 2: Draft Documents\nWrite drafts using templates from `templates\u002F` directory (`TASK_REQUEST_TEMPLATE.md`, `VERIFY_CHECKLIST_TEMPLATE.md`). For any generated project instruction artifact, reference `QE_CONVENTIONS.md` (project root) for QE rules (file naming, task status, completion criteria) and include a reference line pointing to it. Replace `{{placeholder}}` with actual content.\n- **Frontmatter substitution (per `core\u002FDOC_CONVENTIONS.md`)**: the title-following `qe-doc-frontmatter` block placeholders are filled deterministically — `{{kind}}` = the generator mapping value (`TASK_REQUEST` → `spec`, `VERIFY_CHECKLIST` → `verify`), `{{plan}}` = the active plan slug, `{{phase}}` = the requested\u002Fcurrent phase name, `{{created}}` = today's date (`YYYY-MM-DD`), `{{status}}` = `pending` at creation. Keep the H1 title on line 1 so the completion hook still extracts it; the frontmatter block goes on the line immediately after.\n- **Model Preference**: Use **Haiku** for drafting standardized templates to reduce latency.\n\n### Steps 2.4–2.6: Premise and spec gates\n\nVerify external CLI, manifest, hook, API, and npm claims before drafting. Mark\nunresolved claims `[UNVERIFIED]` and remove disproved premises. Check structural\nand executability criteria, then always run `Qcritical-review --stage spec` with\nisolated roles. FAIL remains execution-blocking after at most two revisions;\nWARN\u002FPASS may proceed with notes. Full workflow:\n[.\u002Freference\u002Fspec-workflow.md](.\u002Freference\u002Fspec-workflow.md).\n\nThis gate ALWAYS runs. Unlike Step 2.5, it has no skip conditions.\n\n### Step 3: Review, Create, and Execute\n\nUse the interaction adapter to choose Generate Only or Generate & Execute. A\ngate-blocked spec may only be saved or revised. Recommend a wave for four or\nmore independent items. Non-interactive Codex defaults to Generate Only unless\nexecution was explicitly requested or chained. Create artifacts in pending\u002F and\nchain execution internally; never ask the user to orchestrate internal PSE stages.\nDetailed choices and output reporting:\n[.\u002Freference\u002Fspec-workflow.md](.\u002Freference\u002Fspec-workflow.md).\n\n## Autonomous Mode Support\n\nWhen called from Qexecute -utopia (autonomous mode), Qgenerate-spec:\n- Skips all interaction prompts — auto-selects the documented default\n- Auto-proceeds through Steps 1-3 without user confirmation\n- Sets `\u003C!-- chained-from: Qgenerate-spec -->` on generated TASK_REQUEST files\n\nSee `Qexecute -utopia` for autonomous execution modes (`-utopia`, `-utopia -verify`).\n\n## Document Writing Rules\n\n### Language Matching (Required)\nTASK_REQUEST and VERIFY_CHECKLIST must match the user's language.\n- Korean user → Korean documents; English user → English documents; mixed\u002Funclear → English\n- **Scope:** TASK_REQUEST and VERIFY_CHECKLIST only. Internal framework files stay English. CLAUDE.md follows user language when specified.\n\n### Project Instruction Artifact\n- Single Source of Truth for client-specific project context; Claude adapter uses `CLAUDE.md`, Codex-capable projects may use `AGENTS.md` or an equivalent QE-managed instruction file.\n- **Do NOT write task lists in the instruction artifact.** Task history lives in `.qe\u002FTASK_LOG.md`. The instruction artifact only contains a reference pointer: `## Task Log` → see `.qe\u002FTASK_LOG.md`\n\n### TASK_REQUEST\n- **What vs How**: Clearly separate the business goal from the technical implementation logic (from QE planning patterns).\n- **Atomic Items**: Every checklist item must be **independent** and **verifiable**.\n- **Dependency Mapping**: If an item depends on another, mark it: `- [ ] {desc} \u003C!-- depends_on: [UUID\u002FItem#] -->`.\n- **Haiku-Ready**: Ensure items are small enough to be implemented without Sonnet-level reasoning.\n- **Output files**: Always append `→ output: {file-path}` for direct accountability.\n- **Assumed defaults**: Any decision the user delegated (\"나머지는 알아서\") and the AI resolved goes in an optional `## 가정 (AI 결정)` section, one `[ASSUMED]` line per decision with a one-phrase rationale. This keeps delegated choices reviewable instead of buried in the draft.\n- **Role ownership**: In role-separated or tiered orchestration, identify the expected implementer-owned files or modules so the reviewer can later judge boundary violations.\n- **Code Risk Register (mandatory for `type: code`)**: Add this section before the checklist and fill every field:\n  ```markdown\n  ## Risk Register\n  - Worst-case failure:\n  - Data loss \u002F corruption risk:\n  - Security \u002F permission risk:\n  - Concurrency \u002F race risk:\n  - Rollback strategy:\n  - Unverified assumptions:\n  ```\n  The register is a hard SIVS contract. Empty fields, placeholder text, or omitted categories block execution until fixed.\n\n### VERIFY_CHECKLIST\n- Each criterion answerable as yes\u002Fno\n- Task complete when all items checked\n- Include note to update `.qe\u002FTASK_LOG.md` task list to ✅\n- **Auto-include by type:**\n  - `type: code` → add: \"No security vulnerabilities (OWASP Top 10) in changed code\", \"All existing tests pass\", \"Worst-case failure path is identified\", \"Data loss\u002Fcorruption, security\u002Fpermission, and concurrency\u002Frace risks are explicitly evaluated or marked N\u002FA with reason\", \"Unverified assumptions and residual risks are reported in the final handoff\", \"High-risk findings are mitigated by tests, defensive code, or an explicit defer rationale\"\n  - `type: code` + auth\u002Fcrypto\u002Fpayment → add: \"Authentication\u002Fencryption implementation is secure (Esecurity-officer or manual review)\"\n  - `type: docs` → add: \"All links in documentation are valid\", \"Terminology and formatting are consistent\"\n\n## UUID Generation Rules\n- 8-character hex (e.g., `a1b2c3d4`), generated randomly\n- Same UUID shared between TASK_REQUEST and VERIFY_CHECKLIST for same task\n- **Collision check**: Before using a UUID, verify no file matching `TASK_REQUEST_{UUID}.md` already exists in `.qe\u002Ftasks\u002Fpending\u002F` or `.qe\u002Ftasks\u002Fcompleted\u002F`. If it exists, generate a new random UUID and check again.\n- Generate UUIDs via bash: `openssl rand -hex 4` (produces 8-char hex)\n\n## Self-Evolving\n- After completing tasks, if recurring patterns found, suggest template improvements\n- On user approval, reflect patterns in future generation\n\n## Contract Candidate Extraction (Optional)\n\nOnly `\u003C!-- contract-candidates: auto -->` enables extraction. Write generated\ncontracts to `.qe\u002Fcontracts\u002Fpending\u002F`, preserve existing drafts, and require\nexplicit human approval before promotion. Full rules:\n[.\u002Freference\u002Fdocument-contracts.md](.\u002Freference\u002Fdocument-contracts.md).\n\n## Handoff\nAfter generating spec files (on \"Generate Only\"), display using the standard handoff format from `QE_CONVENTIONS.md`:\n\n```\nPhase {X}: {PhaseName} — Spec complete\n\nPSE: [x] Plan [x] Spec [>] Execute [ ] Verify\n\n{TaskDescription — 다음 작업 내용 한 줄 요약}\nNext: {adapter.commandPrefix}Qexecute {UUID}\n```\n\nNote: \"Generate & Execute\" auto-chains, so the handoff is only needed for \"Generate Only\".\n\n**Fresh-context hint**: If the spec conversation was long (context dump + multi-round clarification), append one line recommending execution from a fresh session: \"이 세션의 컨텍스트가 무겁습니다 — 새 세션에서 `{adapter.commandPrefix}Qexecute {UUID}` 실행을 권장합니다.\" The spec file already carries everything Qexecute needs; LLMs perform best with a lean context, so don't drag the spec-drafting conversation into execution.\n\n## Output Format\n- Wrap document content in markdown code blocks when displaying\n- Pure markdown only, no JSON\n",{"name":5,"tier":21,"description":7,"user_invocable":36,"recommendedModel":24},"main","098bee25999f0ad7b3bba659cc28b79555ffe77f","skills\u002FQgenerate-spec",0,"https:\u002F\u002Fgithub.com\u002Finho-team\u002Fqe-framework","https:\u002F\u002Fgithub.com\u002Finho-team","2026-10-12 20:59:00",{"source":8,"skillName":5,"commands":48,"prompt":58,"zipAvailable":59},[49,52,55],{"tool":50,"command":51},"npx","npx skills add inho-team\u002Fqe-framework --skill Qgenerate-spec",{"tool":53,"command":54},"bunx","bunx skills add inho-team\u002Fqe-framework --skill Qgenerate-spec",{"tool":56,"command":57},"pnpm","pnpm dlx skills add inho-team\u002Fqe-framework --skill Qgenerate-spec","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Finho-team\u002Fqe-framework\u002Fblob\u002Fmain\u002Fskills\u002FQgenerate-spec\u002FSKILL.md",true,[61,67,71,75],{"path":62,"resourceType":63,"resourceTypeDesc":64,"sizeBytes":65,"sourceHtmlUrl":66},"reference\u002Fdocument-contracts.md","REFERENCE","参考文档",1628,"https:\u002F\u002Fgithub.com\u002Finho-team\u002Fqe-framework\u002Fblob\u002Fmain\u002Fskills\u002FQgenerate-spec\u002Freference\u002Fdocument-contracts.md",{"path":68,"resourceType":63,"resourceTypeDesc":64,"sizeBytes":69,"sourceHtmlUrl":70},"reference\u002Fspec-workflow.md",1909,"https:\u002F\u002Fgithub.com\u002Finho-team\u002Fqe-framework\u002Fblob\u002Fmain\u002Fskills\u002FQgenerate-spec\u002Freference\u002Fspec-workflow.md",{"path":72,"resourceType":63,"resourceTypeDesc":64,"sizeBytes":73,"sourceHtmlUrl":74},"templates\u002FTASK_REQUEST_TEMPLATE.md",1805,"https:\u002F\u002Fgithub.com\u002Finho-team\u002Fqe-framework\u002Fblob\u002Fmain\u002Fskills\u002FQgenerate-spec\u002Ftemplates\u002FTASK_REQUEST_TEMPLATE.md",{"path":76,"resourceType":63,"resourceTypeDesc":64,"sizeBytes":77,"sourceHtmlUrl":78},"templates\u002FVERIFY_CHECKLIST_TEMPLATE.md",880,"https:\u002F\u002Fgithub.com\u002Finho-team\u002Fqe-framework\u002Fblob\u002Fmain\u002Fskills\u002FQgenerate-spec\u002Ftemplates\u002FVERIFY_CHECKLIST_TEMPLATE.md",[80,92,115,124,138,145],{"skillNo":81,"name":82,"nameZh":6,"description":83,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":84,"categories":85,"keywords":86,"publishedAt":35},"01M6DT1S8NH342N5C7G66JCW4B","Qversion","Shows the current QE Framework version. Use when asked 'what version', 'qe version', 'show version', or 'check version'.","https:\u002F\u002Fgithub.com\u002Finho-team\u002Fqe-framework\u002Fblob\u002Fmain\u002Fskills\u002FQversion\u002FSKILL.md",[],[82,87,88,26,89,90,24,91],"show","version","user","check","framework",{"skillNo":93,"name":94,"nameZh":6,"description":95,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":96,"categories":97,"keywords":98,"publishedAt":35},"01M6DT1PACV7KP1TH48T39Z7TS","Qupdate","Use for \"update plugin\", \"upgrade\", \"update qe\", \"update codex\", or \"codex plugin\". Updates marketplace metadata\u002Fcache, framework files, installed Codex assets, and the bridge for the current install.","https:\u002F\u002Fgithub.com\u002Finho-team\u002Fqe-framework\u002Fblob\u002Fmain\u002Fskills\u002FQupdate\u002FSKILL.md",[],[94,99,100,101,102,103,104,105,106,107,108,109,110,87,111,26,112,113,114,24],"codex","codex plugin","plugin","update","pull","cache","marketplace","Bash","update plugin","update codex","assets","upgrade","files","bridge","fetch","node",{"skillNo":116,"name":117,"nameZh":6,"description":118,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":119,"categories":120,"keywords":121,"publishedAt":35},"01M6DT1K90BZKR4YDMCQ75HQSH","Qresume","Use when resuming work, restoring context, continuing from where you left off, or loading a previous session after compaction or a session break.","https:\u002F\u002Fgithub.com\u002Finho-team\u002Fqe-framework\u002Fblob\u002Fmain\u002Fskills\u002FQresume\u002FSKILL.md",[],[117,122,123,26,25,24],"context","session",{"skillNo":125,"name":126,"nameZh":6,"description":127,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":128,"categories":129,"keywords":130,"publishedAt":35},"01M6DT1GF6V84ACS15200PMC8H","Qplan","Use when starting or resuming a Plan. Runs bounded tacit-knowledge intake when needed, creates or updates a roadmap, then advances one verified Goal at a time. Use Qgoal only as a goal-intake alias.","https:\u002F\u002Fgithub.com\u002Finho-team\u002Fqe-framework\u002Fblob\u002Fmain\u002Fskills\u002FQplan\u002FSKILL.md",[],[31,131,132,133,134,29,28,135,26,23,136,137,21],"alias","Qgoal","intake","time","only","knowledge","as",{"skillNo":139,"name":132,"nameZh":6,"description":140,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":141,"categories":142,"keywords":143,"publishedAt":35},"01M6DT1CGVT3D9E38GD8GRZS7Z","Explicit single-Goal alias for Qplan. Use when the user enters Qgoal with the active client prefix.","https:\u002F\u002Fgithub.com\u002Finho-team\u002Fqe-framework\u002Fblob\u002Fmain\u002Fskills\u002FQgoal\u002FSKILL.md",[],[132,24,131,144,31,29,26,89],"active",{"skillNo":146,"name":147,"nameZh":6,"description":148,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":149,"categories":150,"keywords":151,"publishedAt":35},"01M6DT15P0Z7BPGB403106ZG5B","Qexecute","Use when a routed pipeline or an active task artifact (TASK_REQUEST UUID) needs execution or the -verify quality loop — router-owned internal PSE unit. Use Qgoal to enter.","https:\u002F\u002Fgithub.com\u002Finho-team\u002Fqe-framework\u002Fblob\u002Fmain\u002Fskills\u002FQexecute\u002FSKILL.md",[],[147,152,33,144,153,32,27,26,154,155,156,24,157,158,106,22,159,160,21],"read","artifact","edit","write","grep","quality","loop","execution","pipeline"]