[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M786DM3XP5XF4YNNSBCDFHPD":3,"skill-same:01M786DM3XP5XF4YNNSBCDFHPD":83},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":19,"linkOnly":20,"markdownContent":21,"markdownBody":22,"frontMatter":23,"refName":30,"commitSha":31,"skillDirectory":32,"forksCount":14,"repositoryHtmlUrl":33,"repositoryHomepageUrl":6,"ownerHtmlUrl":34,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":35,"install":36,"resources":48},"01M786DM3XP5XF4YNNSBCDFHPD","sp-specify",null,"Use when a new or changed feature request needs guided requirement discovery and a planning-ready specification package.","chenziyang110\u002Flaunchdeck","chenziyang110","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F43693913?v=4","01M7863EBWK1D0P6A29YGEMAS4","Robin11","01M7863ECM1VB6RXDMHTW90D2T",0,"MIT","https:\u002F\u002Fgithub.com\u002Fchenziyang110\u002Flaunchdeck\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fsp-specify\u002FSKILL.md",[],[],"2026-11-15 14:19:17",false,"---\nname: \"sp-specify\"\ndescription: \"Use when a new or changed feature request needs guided requirement discovery and a planning-ready specification package.\"\nargument-hint: \"Describe the feature you want to specify\"\ncompatibility: \"Requires spec-kit project structure with .specify\u002F directory\"\nmetadata:\n  author: \"github-spec-kit\"\n  source: \"templates\u002Fcommands\u002Fspecify.md\"\nuser-invocable: true\n---\n## Invocation Syntax\n\n- In this integration, invoke workflow skills with `\u002Fsp-plan`-style syntax.\n- References such as `\u002Fsp.plan`, `\u002Fsp.tasks`, or `next_command: \u002Fsp.plan` are canonical workflow-state identifiers and handoff values.\n- Preserve those canonical state tokens exactly in artifacts and workflow state; do not rewrite them to this integration's invocation syntax.\n\n\n\n## Workflow Contract Summary\n\n- **When to use**: A new or changed feature request needs a planning-ready specification package instead of immediate implementation.\n- **Primary objective**: Produce a planning-ready specification contract through discovery for raw requests or semantic-delta compilation for a confirmed discussion contract, followed by deterministic completeness and traceability review.\n- **Primary outputs**: Canonical agent-only `FEATURE_DIR\u002Fspec-contract.json` plus human\u002Fproject `FEATURE_DIR\u002Fspec.md`; `alignment.md`, `context.md`, `references.md`, and a requirements report only when their triggered content has independent value; `workflow-state.md` remains resume state rather than a handoff.\n- **Default handoff**: After user review, recommend exactly one next command: `\u002Fsp.plan`, `\u002Fsp.clarify`, or `\u002Fsp.deep-research`.\n- **Execution note**: This summary is routing metadata only. Follow the full contract below end-to-end rather than inferring behavior from the description alone.\n\n## Blocked Exit Contract\n\nIf blocked after safe recovery, read and follow\n`.specify\u002Ftemplates\u002Fworkflow-blocker-template.md` and its JSON schema. Never\nreturn only an error or “ask a human”; preserve state and keep agent-capable\nrepair agent-owned. Set `human_action_required: true` only for authority,\ncredentials, protected systems, human decisions\u002Freviews, or physical access.\nTailor steps, expected results, failure paths, evidence, and resume action to\nCI, visual review, or product decisions. Never claim completion.\n\n## User Input\n\n```text\n$ARGUMENTS\n```\n\nYou **MUST** consider the user input before proceeding (if not empty).\n\n## Objective\n\nTurn a new or changed feature request into a reviewed, planning-ready specification package through a concise collaborative flow: understand context, clarify one high-impact question at a time, compare approaches, confirm the spec shape, write artifacts, self-review, and ask the user to review before planning.\n\n## Context\n\n- Primary inputs: the user's request for discovery mode, or canonical agent-only `handoff-to-specify.json` for compile mode; current repository context, passive memory, and project cognition are loaded only when the contract lacks fresh evidence for a planning-relevant claim.\n- Authoritative output: agent-only `spec-contract.json`. `spec.md` is the project-facing rendering; `alignment.md`, `context.md`, `references.md`, and requirements diagnostics are conditional views with independent value. `workflow-state.md` is resume state, not phase handoff truth.\n- This command is specification-only. It is not permission to implement code.\n\n## Process\n\n- Create or resume the feature workspace and `workflow-state.md`.\n- Before creating a feature workspace, classify arguments as either a normal feature description or a discussion handoff path\u002FJSON path\u002Fslug. If no arguments are supplied, use exactly one unconsumed `status: handoff-ready` discussion whose `next_command` is `\u002Fsp.specify` or `sp-specify`; if there are zero or multiple candidates, stop and ask for a feature description or specific handoff.\n- For a discussion handoff, require canonical JSON `status: handoff-ready`, `planning_gate_status: ready`, `quality_gate.status: user_confirmed`, matching `quality_gate.confirmed_digest` and `review_digest`, zero hard unknowns, zero open conflicts, and complete protected `MP-*`, `CA-###`, evidence, and settled-decision coverage.\n- If a discussion workspace contains `specification-input.md` or looks specification-ready but lacks the ready JSON contract, stop with `blocked_by_handoff_integrity` and route back to `sp-discussion` to write or repair `handoff-to-specify.json`; do not reconstruct it from supporting files.\n- Derive the feature description from `handoff_goal` plus the implementation target summary. Do not pass the raw handoff path, JSON path, or slug to the create-feature script as the feature description.\n- Explore project context only enough to understand ownership, constraints, adjacent surfaces, and source evidence.\n- If invoked from `sp-discussion`, read the canonical contract once, reuse its context capsule and decision digest, and inspect supporting discussion files only when a named evidence reference is stale, missing, or contradictory.\n- If invoked from `sp-discussion`, keep the source discussion slug from the contract; after `spec-contract.json` is written and self-reviewed, run `specify discussion mark-consumed \u003Cslug> --feature-dir \"$FEATURE_DIR\"` or update the equivalent consumption state.\n- Extract every upstream capability-like signal from those sources and assign exactly one disposition: `preserved`, `in_scope`, `deferred`, `dropped`, or `clarification_blocker`.\n- Ask one high-impact question at a time when the answer can change scope, acceptance, architecture, compatibility, security, data shape, external integration, or downstream planning.\n- Decompose ambiguous terms such as capability, real, usable, works, end-to-end, fetch, probe, health, model, endpoint, integration, auth, `new` command, `\u003Ctool> new`, create, scaffold, authoring, template creation, authoring workflow, CLI path, TUI path, `能力`, `真实`, and `可用` before compiling the spec.\n- Treat create\u002Fscaffold\u002F`new` command\u002Fauthoring workflow wording as an operation-shaped capability signal. If surface minimization changes the entry point, preserve the capability operation through an explicit TUI route, core API, public CLI command, or user-confirmed deferral; do not downgrade it to manual copy docs or static template-only support without confirmation.\n\n## UI Reference Input\n\n- First classify UI applicability independently of whether the user supplied a\n  screenshot. New or changed user-visible screens, components, layouts,\n  navigation, interaction flows, responsive behavior, visual states, TUI\n  layouts, or CLI presentation are UI-bearing work.\n- For substantive UI-bearing work, require `ui-brief.md` even when there is no\n  external reference. The leader may compile that brief from approved\n  `DESIGN.md`, existing product surfaces, and confirmed experience requirements.\n  A narrow copy-only or existing-pattern state fix may record why a separate\n  brief adds no decision value and use a precise `spec.md#...` design-contract\n  reference as `design_contract.ui_brief_ref`; the UI contract is never omitted.\n- Treat `DESIGN.md` with `design_system.status: bootstrap` as not ready for a\n  new direction. Route product-wide or high-visibility design decisions to\n  `sp-design`; do not inherit its generic starter tokens as product intent.\n- Detect screenshots, HTML\u002FCSS mockups, Tailwind\u002Fshadcn\u002FReact\u002FVue\u002FSvelte snippets, Figma exports, reference URLs, existing product pages, or matching-language such as \"make it like this\", \"basically the same\", \"copy this layout\", or \"use this as the design\".\n- When UI reference input exists, ask for the fidelity mode unless the user already stated it:\n  - `approximate` by default: preserve layout, density, hierarchy, visual rhythm, component structure, and primary interactions.\n  - `high`: require visual comparison and deviation notes.\n  - `inspiration`: extract principles only and avoid similar-looking output.\n- Use `choose_ui_reference_lane_dispatch(command_name=\"specify\", snapshot, workload_shape)` before dispatching UI reference work.\n- Record `lane_mode: ui-reference-artifact`, `dispatch_shape`, `execution_surface`, `workflow_status`, `blocked_reason`, and whether inline fallback was user approved.\n- The `sp-specify` leader must not directly parse UI references and write the UI contract when UI reference input is present. The leader dispatches and validates the lane.\n- The writable UI reference lane may write only `ui-reference-notes.md`, `ui-brief.md`, and optional `ui-target.html` inside the active `FEATURE_DIR`.\n- Do not treat this as a read-only evidence lane; source code, tests, app styling, component implementation, package managers, builds, and app servers remain forbidden.\n- In discovery mode, present materially different approaches when they change behavior, boundary, compatibility, or acceptance proof. In compile mode, inherit the confirmed approach and emit only its semantic delta.\n- Do not repeat user review for an unchanged confirmed discussion contract. Ask again only when specification compilation changes scope, behavior, risk acceptance, target boundary, or another user-owned decision.\n- When entered through `sp-auto` with `auto_default_recommendation: true`, automatically accept a single safe recommended approach or section-shape option instead of stopping only for a `1`\u002F`2`\u002F`3` reply; do not use this to confirm scope reduction, dropped upstream signals, out-of-scope conflicts, or unresolved planning-critical ambiguity.\n- Write `spec-contract.json` first, render project-facing artifacts from it, then self-review for placeholders, contradictions, ambiguous requirements, silent scope narrowing, dropped upstream signals, out-of-scope conflicts, missing acceptance proof, and unconfirmed product minimization.\n- Ask the user only about a non-empty `semantic_delta` or unresolved user-owned decision before recommending exactly one next command: `\u002Fsp.plan`, `\u002Fsp.clarify`, or `\u002Fsp.deep-research`.\n\n## Output Contract\n\n- Write or update canonical `spec-contract.json` using `.specify\u002Ftemplates\u002Fspec-contract-template.json`, then render `spec.md`. Write `alignment.md`, `context.md`, `references.md`, and requirements diagnostics only when their triggered content cannot be represented by a stable reference in the contract.\n- When compatibility requires `brainstorming\u002Fhandoff-to-specify.json`, generate it as a pointer-only agent transition with `source_contract`, `review_digest`, `semantic_delta`, `required_refs`, blockers, and next action; do not copy the requirement contract.\n- When UI reference input exists, require `ui-reference-notes.md`; for every\n  substantive concrete UI surface, require `ui-brief.md` whether or not a\n  reference was supplied; create `ui-target.html` only when a disposable visual target materially reduces ambiguity.\n- For `approximate` and `high` UI reference fidelity, activate `Reference-Implementation`, populate `Fidelity Requirements`, persist canonical Reference-Implementation `required_evidence`, and record UI-specific labels only as aliases\u002Fmapping notes.\n- `alignment.md` must record `Semantic Term Decisions`, `Upstream Intent Disposition`, and `Out-Of-Scope Conflicts` when relevant.\n- Do not recommend `\u002Fsp.plan` while a capability-like upstream signal lacks disposition, an ambiguous high-impact term lacks confirmation, or an out-of-scope conflict lacks user confirmation.\n- Report what was confirmed, what remains open, what was deferred or dropped, and the single valid next command.\n\n## Guardrails\n\n- Do not edit source code, tests, or implementation files from `sp-specify`.\n- Do not treat the discussion handoff summary as complete when discussion source files exist.\n- Do not silently narrow user scope, redefine broad capability terms, or convert the request into a smaller delivery without user confirmation.\n- Do not require legacy brainstorming journals, stage manifests, lock JSON files, or replay artifacts for normal `sp-specify` completion.\n- Do not treat this summary block as the workflow itself; the detailed contract below remains authoritative.\n\n## Senior Consequence Analysis Gate\n\nRun this gate whenever the request, artifact set, defect, or planned change can affect lifecycle operations, running objects, concurrent work, destructive behavior, shared state, downstream consumers, compatibility, security-sensitive behavior, or multiple plausible product behaviors.\n\nProject cognition first. Use the project cognition runtime to identify ownership, consumers, state surfaces, change-propagation facts, verification routes, conflicts, known unknowns, and coverage gaps. Senior consequence analysis second. Turn those facts into explicit product and implementation obligations instead of treating the graph as the decision-maker.\n\nProject cognition readiness provides routing advice. If readiness is `query_ready`, read top-level `minimal_live_reads` first, then use lane-level `first_pass_paths` reasons. If readiness is `review`, inspect the returned `minimal_live_reads` before continuing and treat `coverage_diagnostics` as confidence and closeout signals. If readiness is `needs_rebuild`, continue with live repository evidence and recommend `\u002Fsp-map-scan -> \u002Fsp-map-build` only for brownfield first\u002Fmissing\u002Funusable baseline, schema failure, schema v1 or old broad-schema rebuild-required readiness, zero active-generation `path_index` rows outside `greenfield_empty`, missing or invalid `alias_index`, `explicit_rebuild_requested`, or `baseline_identity_invalid`. If readiness is `blocked`, report the blocked state and continue with live repository evidence unless the user's actual request is to fix cognition runtime state. If readiness is `unsupported_runtime`, continue with live evidence and record that compass intake was unavailable. If `baseline_kind=greenfield_empty`, continue with workflow artifacts and live requirements; do not recommend map-scan -> map-build solely because the graph has no paths. Carry relevant project cognition facts, returned `minimal_live_reads`, inference notes, and coverage gaps into the workflow's artifacts or durable state, but back consequence claims with live code, tests, scripts, configuration, or authoritative docs. Mutation closeout is separate from entry routing: entry stale may continue, but that does not allow source\u002Fruntime mutation workflows to defer closeout. Workflow-owned mutation closeout is not an external map-maintenance handoff; after changing project-related files or behavior, the workflow must run inline project cognition update from its changed paths, affected surfaces, and verification evidence, with `project-cognition mark-dirty` only as fallback when inline update cannot complete. `sp-map-update` is for manual\u002Fexternal maintenance and follow-up repair; it is external map maintenance, not routine closeout for this workflow's own changes. In shared routing summaries, sp-map-update is for manual\u002Fexternal maintenance and ordinary existing-baseline gaps.\n\nRequired output when the gate triggers:\n\n- **Affected Object Map**: name each object, record, worker, queue, artifact, command, API, file surface, user-visible state, or downstream consumer that can be affected.\n- **State-Behavior Matrix**: describe behavior for each important lifecycle state, including created, queued, running, paused, failed, cancelled, completed, resumed, archived, missing, stale, or partially refreshed states when relevant.\n- **Dependency Impact Table**: map direct dependencies, indirect consumers, shared state, compatibility surfaces, validation routes, and adjacent workflows that can break if semantics change.\n- **Recovery And Validation Contract**: state rollback, retry, idempotency, cleanup, migration, observability, and validation evidence required before handoff or completion.\n- **Coverage Gaps**: list what project cognition or live evidence cannot prove, who must resolve each gap, the latest safe resolve phase, the stop-and-reopen condition, and the routing decision: current workflow may continue with an assumption, must ask the user, must route to clarification or deep research, or must request map maintenance.\n- **Consequence Obligations**: assign stable `CA-###` IDs to every obligation that must survive downstream handoff, task generation, worker packets, verification, or debug closeout. Each `CA-###` must include claim, affected objects, owner workflow, latest resolve phase, status, and stop-and-reopen condition.\n\nStand down only for docs-only wording changes, trivial isolated fixes, or local refactors that cannot affect lifecycle operations, running state, destructive operations, shared state, downstream consumers, compatibility, security, or multiple behavior choices. Record the no-trigger reason or stand-down reason in the workflow's durable artifact or closeout before skipping the required outputs.\n\nIf the gate triggers and the current workflow cannot preserve the required outputs, stop and route to the workflow that can. Do not mark ready, resolved, handoff-ready, planning-ready, or complete while triggered consequence obligations remain unresolved, unmapped, or unsupported by validation evidence.\n\n## Agent Phase Handoff\n\nPhase handoff is an agent-only control surface. Human-facing explanation belongs in the visible reply or in project documents that have independent review value; it must not be duplicated into a handoff.\n\n- The previous phase's canonical JSON contract is the next phase's primary input.\n- Use the compact transition shape from `.specify\u002Ftemplates\u002Fagent-phase-transition-schema.json`: `status`, `source_ref`, `semantic_delta`, `required_refs`, `blockers`, `next_action`, and recovery only when blocked.\n- Carry the minimum sufficient context: include a fact only when omitting it could change the next action, lose a requirement or obligation, force rediscovery, weaken verification, or prevent safe recovery.\n- Preserve decisions, acceptance criteria, evidence provenance, `MP-*`, `CA-###`, and stop\u002Freopen conditions by stable reference. Do not copy their full bodies into every downstream artifact.\n- Protected `MP-*` and `CA-###` obligations must not drop between phases. A downstream phase may resolve or reopen them, but may not silently omit them.\n- Carry the locked implementation-target reference. A cross-project transition must not silently point to the current repository when the confirmed target differs.\n- Consume project rules and Learning through `learning start --command \u003Cclassic-command-name> -> list -> show`; run selected `show_argv` only. Constitution remains at `.specify\u002Fmemory\u002Fconstitution.md`; never parse Learning storage.\n- Capture at owning closeout only when the lesson would change a future action; prefer `learning capture-auto`.\n- A rendered Markdown view is never an agent handoff authority. Do not require Markdown\u002FJSON companion agreement.\n- Revalidate upstream truth only when its revision changed, evidence became stale, live repository facts contradict it, or the current phase discovers a scope, boundary, feasibility, or risk change.\n- If `semantic_delta` is empty, do not repeat upstream questions, approach selection, or user confirmation.\n\n## Deterministic Workflow Runtime\n\nFor a feature-bearing `specify -> plan -> tasks -> implement -> accept` stage,\nthe CLI owns phase order and `workflow-state.md`. Do not author or advance\n`workflow-state.md` by hand.\n\n- After `FEATURE_DIR` is known, run `uvx --from git+https:\u002F\u002Fgithub.com\u002Fchenziyang110\u002Fspec-kit-plus.git@4a631657f75460886dbd12ebe48b14fc11cfe0bf specify workflow show --feature-dir \u003Cfeature-dir> --format json`. If state is missing at the first feature stage, run `uvx --from git+https:\u002F\u002Fgithub.com\u002Fchenziyang110\u002Fspec-kit-plus.git@4a631657f75460886dbd12ebe48b14fc11cfe0bf specify workflow enter --command specify --feature-dir \u003Cfeature-dir> --format json`.\n- On entry to `plan`, `tasks`, `implement`, or `accept`, use the current revision with `uvx --from git+https:\u002F\u002Fgithub.com\u002Fchenziyang110\u002Fspec-kit-plus.git@4a631657f75460886dbd12ebe48b14fc11cfe0bf specify workflow transition --to \u003Cthis-stage> --feature-dir \u003Cfeature-dir> --expected-revision \u003Crevision> --format json` before writing that stage's artifacts. The command validates the completed source-stage artifacts and refuses skips, stale revisions, or incomplete handoffs with exit `10`.\n- The destination command owns the transition. A completed stage recommends the next command but must not execute `workflow transition` to that next stage in the same invocation.\n- Use `uvx --from git+https:\u002F\u002Fgithub.com\u002Fchenziyang110\u002Fspec-kit-plus.git@4a631657f75460886dbd12ebe48b14fc11cfe0bf specify workflow next --feature-dir \u003Cfeature-dir> --format json` for the compact next action. Execute only its structured `next_argv`; do not reconstruct flags from prose.\n- After safe agent recovery is exhausted, persist the blocker through `uvx --from git+https:\u002F\u002Fgithub.com\u002Fchenziyang110\u002Fspec-kit-plus.git@4a631657f75460886dbd12ebe48b14fc11cfe0bf specify workflow block --input \u003Cblocker-json-or-> --format json`. Obtain its exact input shape with `uvx --from git+https:\u002F\u002Fgithub.com\u002Fchenziyang110\u002Fspec-kit-plus.git@4a631657f75460886dbd12ebe48b14fc11cfe0bf specify api schema workflow-block-input --format json`; preserve the returned resume argv and human tutorial.\n- After explicit human acceptance and the acceptance-owned closeout both succeed, run `uvx --from git+https:\u002F\u002Fgithub.com\u002Fchenziyang110\u002Fspec-kit-plus.git@4a631657f75460886dbd12ebe48b14fc11cfe0bf specify workflow closeout --feature-dir \u003Cfeature-dir> --expected-revision \u003Crevision> --format json`. It validates acceptance artifacts before marking the feature workflow complete.\n\nFor every blocked exit, including a pre-feature discussion that cannot use the\nfeature runtime yet, follow\n`.specify\u002Ftemplates\u002Fworkflow-blocker-template.md` and its schema. Report the\nexact cause, sanitized evidence, attempted recovery and result, affected scope,\nsmallest next action, observable unblock criteria, and exact resume point. Keep\nagent-capable repair agent-owned. When authority, credentials, a protected\nsystem, physical access, or human judgment is genuinely required, add the full\nHuman Action Guide: goal, prerequisites, safety notes, numbered exact actions,\nexpected result and safe failure branch for every action, independent\nverification, sanitized evidence to return, and the exact resume command.\n\n## Planning Cognition Policy\n\nUse project cognition as advisory navigation, never as sole proof. For an unchanged phase pass, run at most one `project-cognition compass --intent plan` intake when the canonical context capsule lacks a required facet.\n\nRun or emulate:\n\n```text\nC:\\Users\\11034\\.specify\\bin\\project-cognition.exe compass --intent plan --query=\\\"$ARGUMENTS\\\" --format json\n```\n\n- Read and carry `epistemic_contract` in the phase context capsule. Require `graph_role=route_candidate_only`, `fact_source_of_truth=live_repository`, `live_verification_required=true`, `graph_only_claims_allowed=false`, and `unverified_claim_action=withhold`. The contract cannot authorize source changes and cannot prove current behavior.\n- Graph claims are indexed assertions. Even `verified_in_graph_generation` is only an active graph-generation state, not current repository truth; graph claims cannot authorize source changes and cannot set workflow `claim_ready=true`. Use related graph claims to narrow live reads, then prove or reject them from bounded repository evidence.\n- Reuse the returned `compass_state`, `minimal_live_reads`, `first_pass_paths`, lane `claim_refs`, `coverage_diagnostics`, and `expansion_ref` as the phase context capsule. Treat `route_confidence` only within `confidence_scope=route_candidate`; use top-level advanced-query `claim_signals` or `project-cognition expand --section claim_evidence` for bounded `source_path`\u002F`span` evidence. These signals require live verification and cannot prove current repository truth. Read only the minimum live evidence needed for the active claim and let contradictory live evidence override the route candidate.\n- Interpret `claim_ranking` only as a bounded rerank of candidates already eligible through `match_score`; claims cannot create candidates and cannot replace live verification. Fresh supported or graph-generation-verified claims add at most `+1`, while stale and contradicted claims subtract `-1` and `-2`. On `stale_claim_signal` or `contradicted_claim_signal`, preserve `usable_with_review`, follow `reconcile_claims_with_minimal_live_reads`, and complete the lane action against live repository evidence.\n- When claim-specific bounded reads settle a stale or contradicted route, provide only reconciliation intent: workflow, stable `claim_id`, reason, repository-relative `source_path`, bounded line `span`, `supporting` or `contradicting` role, and optional claim-specific verification. Run `project-cognition claim-reconcile prepare --input \u003Cintent.json> --format json`; the runtime owns all integrity fields and the prepared packet path. Execute the returned `apply_argv` exactly (`project-cognition claim-reconcile apply --input \u003Cprepared_packet_path> --format json`). Generic verification cannot re-promote a graph claim. If reconciliation is ready, rerun Compass once for the planning route; otherwise withhold the claim.\n- `fresh`, `stale`, `possibly_stale`, `needs_update`, and `partial_refresh` are planning advisories. Follow returned `minimal_live_reads` and prove the active claim from live evidence; do not stop solely because the index is stale.\n- Rebuild only for an unusable\u002Fmissing baseline or explicit rebuild condition. Do not turn ordinary planning into map maintenance.\n- Artifact-only specification, planning, and task generation do not mark project cognition dirty. A cognition follow-up is required only after actual source\u002Fruntime truth changes.\n- For UI-bearing work, use the same intake to locate likely real entry points,\n  token\u002Ftheme\u002Fcomponent owners, reusable patterns, required states, responsive\n  behavior, visual\u002Faccessibility tests, and design assets. Verify selected paths\n  live, then carry only the compact routes needed by downstream task packets.\n\n[AGENT] For project-cognition-backed semantic intake, routing, audit, resume, or final-claim gates, read `references\u002Fsemantic-work-contract.md`.\n\n## Read-Only Evidence Lane Dispatch\n\nUse this shared dispatch contract when a workflow needs independent evidence gathering but the delegated lane must not mutate project state.\n\nCall `choose_evidence_lane_dispatch(command_name=\"\u003Cworkflow>\", snapshot, workload_shape)` before dispatching read-only evidence lanes.\n\nPerform native subagent capability discovery before recording a delegated lane. Do not record `subagent-blocked` until the active tool surface has been checked and the blocker is specific: no safe lane, no lane contract, no native subagent surface, or unsafe packetization.\n\nRecord the selected fields when a lane is used or blocked:\n\n- `lane_mode: read-only-evidence`\n- `dispatch_shape: leader-inline | one-subagent | parallel-subagents | subagent-blocked`\n- `execution_surface: leader-inline | native-subagents | none`\n- `structured_result: evidence_packet`\n- `blocked_reason` when `dispatch_shape: subagent-blocked`\n\nDispatch rules:\n\n- Stay `leader-inline` for simple questions or one narrow evidence check.\n- Dispatch `one-subagent` when exactly one safe read-only evidence lane is useful and the runtime exposes native subagents.\n- Dispatch `parallel-subagents` when two or more independent read-only evidence lanes can run without overlapping conclusions or state ownership.\n- Record `subagent-blocked` only when a read-only evidence lane is required but no safe lane, no lane contract, or no native subagent surface is available.\n\nEvery read-only evidence lane must have a compact lane contract:\n\n- objective\n- user question or discussion decision it supports\n- authoritative inputs\n- allowed read scope\n- forbidden operations\n- acceptance checks\n- evidence packet format\n- join condition\n\nAllowed delegated operations are file reads, `rg`, project cognition navigation\u002Fquery output, project memory reads, generated-state reads, docs reads, and template reads.\n\nForbidden delegated operations are file writes, state writes, handoff writes, tests, builds, package managers, project CLI commands, app\u002Fserver launch, branch creation, and workflow invocation.\n\nThe parent workflow owns judgment. Subagents return evidence packets only; they do not decide product direction, readiness, handoff status, final answers, or next workflow.\n\n## Main Flow\n\n1. Resolve discussion handoff intake before feature creation; require canonical agent-only `handoff-to-specify.json`, verify `handoff-ready`, `quality_gate.status: user_confirmed`, and `planning_gate_status: ready`, derive the feature description, and do not pass the raw contract path as the feature description. Do not use `specification-input.md`, `discussion-state.md`, or other discussion source files as a substitute.\n2. Verify the installed command surface with `specify --help`, then run `.specify\u002Fscripts\u002Fpowershell\u002Fcreate-new-feature.ps1 \"$ARGUMENTS\"` from the repo root as the generated create-feature script; generated projects resolve this to `.specify\u002Fscripts\u002Fbash\u002Fcreate-new-feature.sh \"$ARGUMENTS\"` or `.specify\u002Fscripts\u002Fpowershell\u002Fcreate-new-feature.ps1 \"$ARGUMENTS\"`. If the feature-creation script exits non-zero, stop with its evidence; do not call `specify lane register` or invent a feature-creation CLI command. After it returns `FEATURE_DIR`, enter or resume `specify` through the deterministic workflow runtime before writing any feature artifact.\n3. Explore project context with project cognition as advisory navigation, then prove current facts from live files and record source evidence.\n4. Select discovery mode for a raw request or compile mode for a confirmed discussion contract. In compile mode, compute `semantic_delta`, ask only about a planning-critical delta, and do not repeat user review when `semantic_delta` is empty.\n5. Decompose semantic terms into explicit decisions and capability operations in `spec-contract.json`; present two or three approaches only when behavior, boundary, compatibility, or acceptance proof changes.\n6. Preserve the discussion contract by reference. Read discussion source files only when a named evidence reference is stale, missing, or contradictory; carry its existing decision digest instead of rebuilding it.\n7. For UI-facing work—with or without supplied screenshots—read selected\n   `DESIGN.md` and live UI evidence; compile `Experience Requirements`,\n   design-system readiness (`design_system_status`, `design_risk_level`), and a\n   feature `ui-brief.md` plus the complete current `design_contract` for\n   substantive UI changes. Separately record work type, surface type, platform,\n   subject, audience, single job, visual\u002Fcontent\u002Finteraction theses, signature,\n   approved visual ref, reference intents, real content\u002Fimage plans, and the\n   structure\u002Fvisual\u002Fruntime evidence triad. Treat a bootstrap or\n   missing required system as a strong blocker and a non-blocking adoption gap\n   as a soft risk. When raw UI references exist, additionally use\n   `choose_ui_reference_lane_dispatch`, `ui-reference-artifact`, and\n   `Reference-Implementation` fidelity evidence.\n8. Write `spec-contract.json`, render or update specification-owned project-facing artifacts, and run deterministic completeness, traceability, and contradiction checks. Run `uvx --from git+https:\u002F\u002Fgithub.com\u002Fchenziyang110\u002Fspec-kit-plus.git@4a631657f75460886dbd12ebe48b14fc11cfe0bf specify hook validate-artifacts --command specify --feature-dir \u003Cfeature-dir> --format json` and fail closed if the specification package is incomplete. Request user review only for non-empty semantic delta or a real unresolved decision, then recommend exactly one next command: `\u002Fsp.plan`, `\u002Fsp.clarify`, or `\u002Fsp.deep-research`.\n\nCreate only specification-stage outputs. Do not create `plan-contract.json`, `plan.md`, research\u002Fdesign-plan artifacts, `tasks.md`, or `task-index.json`; the separately invoked planning and task workflows own them. Do not edit production source, tests, migrations, or runtime configuration.\n\n## Detailed References\n\nRead [Reference index](references\u002FINDEX.md) before applying detailed contracts.\n\n- [discussion handoff validation](references\u002Fdiscussion-handoff-validation.md)\n- [semantic traceability](references\u002Fsemantic-traceability.md)\n- [ui reference lane](references\u002Fui-reference-lane.md)\n- [artifact package](references\u002Fartifact-package.md)\n- [question cadence and review](references\u002Fquestion-cadence-and-review.md)\n- [self review and quality gates](references\u002Fself-review-and-quality-gates.md)\n\n## Claude Code Subagent Capability Discovery\n\n- Execution model: preserve the workflow's existing `subagent-mandatory`, `subagents-first`, `adaptive`, or `subagent-assisted` policy.\n- Dispatch shape: preserve the workflow's existing dispatch shape; use `subagent-blocked` only after the discovery step below fails or is unsafe.\n- Execution surface: prefer `native-subagents` when the current runtime supports it; use `none` only after recording the unavailable or unsafe surface.\n- Native subagent capability discovery: Before recording `subagent-blocked`, check the active tool surface for the integration-native subagent or task-dispatch entrypoint and record the exact missing surface if unavailable.\n- Do not record `subagent-blocked` until this capability discovery step is complete and the exact unavailable or unsafe surface is recorded.\n- Native subagent dispatch: Dispatch subagents through the integration's native subagent support using the shared prompt contract.\n- Join behavior: Use the integration-native join point, then integrate results back on the leader path.\n- Preserve this workflow's existing packet, handoff, artifact, and result schema; this section only governs capability discovery before dispatch or blocked-state recording.\n\n## Claude Code Structured Question Preference\n\n- If this command was routed by `sp-auto` with `auto_default_recommendation: true`, evaluate the automatic recommended\u002Fdefault continuation gate before any question path.\n- When that gate has one safe recommended\u002Fdefault answer, you must auto-resolve the question or confirmation, record the accepted recommendation in the workflow state or summary, continue the workflow, and do not invoke the native structured question tool only to ask for that approval.\n- If the automatic gate is not safe, write the blocker and self-unblock recommendation before using the normal question path.\n- If the runtime's native structured question tool is available for the current turn and the `sp-auto` automatic gate did not resolve the question, you must use it.\n- Do not render the textual fallback block when the native tool is available.\n- Do not self-authorize textual fallback because the question seems simple, short, or easy to phrase manually.\n- Treat the template's textual question format as fallback-only guidance; use it to shape the question content, but do not render the textual block unless the native tool is unavailable in the current runtime or the tool call fails.\n- Keep native-tool availability, runtime mode, and fallback mechanics backstage. Do not tell the user that a structured question tool is unavailable, that the current runtime\u002Fmode lacks a tool, or that a fallback is being used; ask the user-facing question directly when a question is genuinely required.\n- Ask only the minimum number of questions required by this workflow's existing contract.\n- Keep the user-visible question text in the user's current language and keep option labels short.\n- Do not emit both a native tool question and the textual fallback block in the same turn. The user should see the active question exactly once.\n- If the native tool is unavailable in the current runtime or the tool call fails, fall back to the shared open question block structure already defined in this template.\n- In `specify`, use this preference for:\n  - planning-critical clarification\n  - capability split confirmation\n  - user-owned semantic delta before planning readiness\n- Native tool target: `AskUserQuestion`\n- When this native tool target is listed for the integration and the runtime does not signal otherwise, assume it is available by default in normal interactive sessions.\n- Question count: 1-4 questions per call\n- Option count: 2-4 options per question\n- Required question fields: `question`, `header`, `options`, `multiSelect`\n- Option fields: `label`, `description`, `preview (optional)`\n- Use `multiSelect: false` unless the workflow explicitly needs multiple selections.\n- Use `metadata` only when tracking or analytics context adds value; otherwise keep the call minimal.\n\n## Pre-Analysis Protocol\n\n- Before drafting or asking clarification questions, identify the target need, scope boundary, key constraints, acceptance proof, known unknowns, and safest next step.\n- Keep guided requirement discovery concise and avoid reviving the deprecated fixed heavy discovery lifecycle.\n- Treat `final-handoff-decision` as a compatibility readiness check name only; do not restore the legacy staged handoff flow.\n- In compile mode, reuse the confirmed discussion contract's context capsule and decision digest. Run one bounded `project-cognition compass --intent plan --query=\"$ARGUMENTS\" --format json` intake only when a planning facet is absent or outdated; preserve `project-cognition query --intent plan --query-plan` as a precision escalation for an explicit unresolved concept.\n- Read top-level `minimal_live_reads` first and open live files only for the named gap. Do not build a second broad repository summary or infer final scope from first-pass paths.\n- After `FEATURE_DIR` is known, use `specify workflow show --feature-dir \u003Cfeature-dir> --format json`; when state is missing, run `specify workflow enter --command specify --feature-dir \u003Cfeature-dir> --format json`. The deterministic runtime owns `workflow-state.md`; do not reconstruct it in the prompt. Do not implement code, edit source files, edit tests, or run implementation-oriented fix loops from `sp-specify`.\n- Write canonical `spec-contract.json` first. Render `spec.md`; write `alignment.md`, `context.md`, `references.md`, or diagnostics only when the triggered content has independent project-review value and cannot be represented by a stable ref.\n- Clarify only planning-critical ambiguity. Recommend `\u002Fsp.clarify` or `\u002Fsp.deep-research` only when the unresolved item belongs there.\n- Preserve this as an internal understand-before-acting pass; do not replace the one-question-at-a-time requirement discovery flow with a broad analysis report.\n\n## Semantic Traceability Guidance\n\n- Preserve the concise `sp-specify` flow: explore project context, ask one high-impact question at a time, compare two or three approaches, write artifacts, self-review, and ask for user review.\n- When `sp-specify` comes from `sp-discussion`, compile canonical `spec-contract.json` from the confirmed requirement contract and preserve its decision digest by reference.\n- Read supporting discussion files only when a named evidence reference is stale, missing, or contradictory; record only the refs actually needed in the compact context capsule.\n- Compute `semantic_delta`; when it is empty and deterministic review passes, do not repeat upstream questions or user confirmation.\n- Decompose semantic terms before narrowing scope and keep unconfirmed narrowing out of planning-ready state.\n- Downstream stages must reopen upstream intent explicitly instead of silently reinterpreting it.\n\n## Project Cognition Freshness Closeout\n\n- This workflow is artifact-only unless the user explicitly requested source\u002Fruntime\u002Ftemplate\u002Fconfig\u002Ftest\u002Fgenerated-asset changes; do not call `project-cognition mark-dirty`, `project-cognition complete-refresh`, or `project-cognition validate-build --format json` just because `sp-specify`, `sp-plan`, or `sp-tasks` wrote planning artifacts.\n- If this planning workflow makes actual source\u002Fruntime\u002Ftemplate\u002Fconfig\u002Ftest\u002Fgenerated-asset changes in the current run, it stops being artifact-only for closeout: run inline project cognition update from the workflow-owned changed paths and affected surfaces.\n- Git-baseline freshness only changes after source\u002Fruntime\u002Ftemplate\u002Fconfig\u002Ftest\u002Fgenerated-asset changes are recorded; planning-only artifact edits do not require `project-cognition complete-refresh`, and manual override\u002Ffallback belongs only to an explicit map-maintenance recovery path.\n- Inline project cognition update uses `project-cognition delta append` followed by `project-cognition update --delta-session \"$DELTA_SESSION_ID\" --reason workflow-finalize --format json` when a delta session exists, or `project-cognition update --payload-file \".specify\u002Fproject-cognition\u002Fupdates\u002F\u003Cupdate-id>.json\" --reason workflow-finalize --format json` when no delta session exists.\n- The payload-file path must include changed_paths, behavior_surfaces, generated_surfaces, state_contracts, verification, known_unknowns, and confidence_notes so the update is equivalent to `sp-map-update`, not just a path stamp; `verification_evidence` and `generated_surface_notes` are accepted compatibility aliases.\n- Use `known_unknowns` only for blockers that make the cognition update unsafe to trust. If unrelated dirty or untracked working-tree paths were excluded by explicit workflow-owned paths, record that as `confidence_notes` or `boundary.initial_dirty_paths`, not as blocking `known_unknowns`.\n- clean closeout keys on `result_state`, not `update_id`, `last_update_id`, or freshness alone. Treat `ready` and `no_op` as clean, `partial_refresh` as recorded but not fully clean, `needs_rebuild` as a map-scan\u002Fmap-build route, `blocked` as blocked, and `recorded` as legacy recorded-only output that is never clean completion.\n- Use `project-cognition mark-dirty --reason \"\u003Creason>\" --format json` only when inline update cannot complete.\n- `sp-map-update` is for manual\u002Fexternal maintenance and follow-up repair, not routine cleanup for changes this workflow just made; run `\u002Fsp-map-scan` followed by `\u002Fsp-map-build` only for brownfield first\u002Fmissing\u002Funusable baseline, schema failure, schema v1 or old broad-schema rebuild-required readiness, zero active-generation `path_index` rows outside `greenfield_empty`, missing or invalid `alias_index`, `explicit_rebuild_requested`, or `baseline_identity_invalid`.\n","## Invocation Syntax\n\n- In this integration, invoke workflow skills with `\u002Fsp-plan`-style syntax.\n- References such as `\u002Fsp.plan`, `\u002Fsp.tasks`, or `next_command: \u002Fsp.plan` are canonical workflow-state identifiers and handoff values.\n- Preserve those canonical state tokens exactly in artifacts and workflow state; do not rewrite them to this integration's invocation syntax.\n\n\n\n## Workflow Contract Summary\n\n- **When to use**: A new or changed feature request needs a planning-ready specification package instead of immediate implementation.\n- **Primary objective**: Produce a planning-ready specification contract through discovery for raw requests or semantic-delta compilation for a confirmed discussion contract, followed by deterministic completeness and traceability review.\n- **Primary outputs**: Canonical agent-only `FEATURE_DIR\u002Fspec-contract.json` plus human\u002Fproject `FEATURE_DIR\u002Fspec.md`; `alignment.md`, `context.md`, `references.md`, and a requirements report only when their triggered content has independent value; `workflow-state.md` remains resume state rather than a handoff.\n- **Default handoff**: After user review, recommend exactly one next command: `\u002Fsp.plan`, `\u002Fsp.clarify`, or `\u002Fsp.deep-research`.\n- **Execution note**: This summary is routing metadata only. Follow the full contract below end-to-end rather than inferring behavior from the description alone.\n\n## Blocked Exit Contract\n\nIf blocked after safe recovery, read and follow\n`.specify\u002Ftemplates\u002Fworkflow-blocker-template.md` and its JSON schema. Never\nreturn only an error or “ask a human”; preserve state and keep agent-capable\nrepair agent-owned. Set `human_action_required: true` only for authority,\ncredentials, protected systems, human decisions\u002Freviews, or physical access.\nTailor steps, expected results, failure paths, evidence, and resume action to\nCI, visual review, or product decisions. Never claim completion.\n\n## User Input\n\n```text\n$ARGUMENTS\n```\n\nYou **MUST** consider the user input before proceeding (if not empty).\n\n## Objective\n\nTurn a new or changed feature request into a reviewed, planning-ready specification package through a concise collaborative flow: understand context, clarify one high-impact question at a time, compare approaches, confirm the spec shape, write artifacts, self-review, and ask the user to review before planning.\n\n## Context\n\n- Primary inputs: the user's request for discovery mode, or canonical agent-only `handoff-to-specify.json` for compile mode; current repository context, passive memory, and project cognition are loaded only when the contract lacks fresh evidence for a planning-relevant claim.\n- Authoritative output: agent-only `spec-contract.json`. `spec.md` is the project-facing rendering; `alignment.md`, `context.md`, `references.md`, and requirements diagnostics are conditional views with independent value. `workflow-state.md` is resume state, not phase handoff truth.\n- This command is specification-only. It is not permission to implement code.\n\n## Process\n\n- Create or resume the feature workspace and `workflow-state.md`.\n- Before creating a feature workspace, classify arguments as either a normal feature description or a discussion handoff path\u002FJSON path\u002Fslug. If no arguments are supplied, use exactly one unconsumed `status: handoff-ready` discussion whose `next_command` is `\u002Fsp.specify` or `sp-specify`; if there are zero or multiple candidates, stop and ask for a feature description or specific handoff.\n- For a discussion handoff, require canonical JSON `status: handoff-ready`, `planning_gate_status: ready`, `quality_gate.status: user_confirmed`, matching `quality_gate.confirmed_digest` and `review_digest`, zero hard unknowns, zero open conflicts, and complete protected `MP-*`, `CA-###`, evidence, and settled-decision coverage.\n- If a discussion workspace contains `specification-input.md` or looks specification-ready but lacks the ready JSON contract, stop with `blocked_by_handoff_integrity` and route back to `sp-discussion` to write or repair `handoff-to-specify.json`; do not reconstruct it from supporting files.\n- Derive the feature description from `handoff_goal` plus the implementation target summary. Do not pass the raw handoff path, JSON path, or slug to the create-feature script as the feature description.\n- Explore project context only enough to understand ownership, constraints, adjacent surfaces, and source evidence.\n- If invoked from `sp-discussion`, read the canonical contract once, reuse its context capsule and decision digest, and inspect supporting discussion files only when a named evidence reference is stale, missing, or contradictory.\n- If invoked from `sp-discussion`, keep the source discussion slug from the contract; after `spec-contract.json` is written and self-reviewed, run `specify discussion mark-consumed \u003Cslug> --feature-dir \"$FEATURE_DIR\"` or update the equivalent consumption state.\n- Extract every upstream capability-like signal from those sources and assign exactly one disposition: `preserved`, `in_scope`, `deferred`, `dropped`, or `clarification_blocker`.\n- Ask one high-impact question at a time when the answer can change scope, acceptance, architecture, compatibility, security, data shape, external integration, or downstream planning.\n- Decompose ambiguous terms such as capability, real, usable, works, end-to-end, fetch, probe, health, model, endpoint, integration, auth, `new` command, `\u003Ctool> new`, create, scaffold, authoring, template creation, authoring workflow, CLI path, TUI path, `能力`, `真实`, and `可用` before compiling the spec.\n- Treat create\u002Fscaffold\u002F`new` command\u002Fauthoring workflow wording as an operation-shaped capability signal. If surface minimization changes the entry point, preserve the capability operation through an explicit TUI route, core API, public CLI command, or user-confirmed deferral; do not downgrade it to manual copy docs or static template-only support without confirmation.\n\n## UI Reference Input\n\n- First classify UI applicability independently of whether the user supplied a\n  screenshot. New or changed user-visible screens, components, layouts,\n  navigation, interaction flows, responsive behavior, visual states, TUI\n  layouts, or CLI presentation are UI-bearing work.\n- For substantive UI-bearing work, require `ui-brief.md` even when there is no\n  external reference. The leader may compile that brief from approved\n  `DESIGN.md`, existing product surfaces, and confirmed experience requirements.\n  A narrow copy-only or existing-pattern state fix may record why a separate\n  brief adds no decision value and use a precise `spec.md#...` design-contract\n  reference as `design_contract.ui_brief_ref`; the UI contract is never omitted.\n- Treat `DESIGN.md` with `design_system.status: bootstrap` as not ready for a\n  new direction. Route product-wide or high-visibility design decisions to\n  `sp-design`; do not inherit its generic starter tokens as product intent.\n- Detect screenshots, HTML\u002FCSS mockups, Tailwind\u002Fshadcn\u002FReact\u002FVue\u002FSvelte snippets, Figma exports, reference URLs, existing product pages, or matching-language such as \"make it like this\", \"basically the same\", \"copy this layout\", or \"use this as the design\".\n- When UI reference input exists, ask for the fidelity mode unless the user already stated it:\n  - `approximate` by default: preserve layout, density, hierarchy, visual rhythm, component structure, and primary interactions.\n  - `high`: require visual comparison and deviation notes.\n  - `inspiration`: extract principles only and avoid similar-looking output.\n- Use `choose_ui_reference_lane_dispatch(command_name=\"specify\", snapshot, workload_shape)` before dispatching UI reference work.\n- Record `lane_mode: ui-reference-artifact`, `dispatch_shape`, `execution_surface`, `workflow_status`, `blocked_reason`, and whether inline fallback was user approved.\n- The `sp-specify` leader must not directly parse UI references and write the UI contract when UI reference input is present. The leader dispatches and validates the lane.\n- The writable UI reference lane may write only `ui-reference-notes.md`, `ui-brief.md`, and optional `ui-target.html` inside the active `FEATURE_DIR`.\n- Do not treat this as a read-only evidence lane; source code, tests, app styling, component implementation, package managers, builds, and app servers remain forbidden.\n- In discovery mode, present materially different approaches when they change behavior, boundary, compatibility, or acceptance proof. In compile mode, inherit the confirmed approach and emit only its semantic delta.\n- Do not repeat user review for an unchanged confirmed discussion contract. Ask again only when specification compilation changes scope, behavior, risk acceptance, target boundary, or another user-owned decision.\n- When entered through `sp-auto` with `auto_default_recommendation: true`, automatically accept a single safe recommended approach or section-shape option instead of stopping only for a `1`\u002F`2`\u002F`3` reply; do not use this to confirm scope reduction, dropped upstream signals, out-of-scope conflicts, or unresolved planning-critical ambiguity.\n- Write `spec-contract.json` first, render project-facing artifacts from it, then self-review for placeholders, contradictions, ambiguous requirements, silent scope narrowing, dropped upstream signals, out-of-scope conflicts, missing acceptance proof, and unconfirmed product minimization.\n- Ask the user only about a non-empty `semantic_delta` or unresolved user-owned decision before recommending exactly one next command: `\u002Fsp.plan`, `\u002Fsp.clarify`, or `\u002Fsp.deep-research`.\n\n## Output Contract\n\n- Write or update canonical `spec-contract.json` using `.specify\u002Ftemplates\u002Fspec-contract-template.json`, then render `spec.md`. Write `alignment.md`, `context.md`, `references.md`, and requirements diagnostics only when their triggered content cannot be represented by a stable reference in the contract.\n- When compatibility requires `brainstorming\u002Fhandoff-to-specify.json`, generate it as a pointer-only agent transition with `source_contract`, `review_digest`, `semantic_delta`, `required_refs`, blockers, and next action; do not copy the requirement contract.\n- When UI reference input exists, require `ui-reference-notes.md`; for every\n  substantive concrete UI surface, require `ui-brief.md` whether or not a\n  reference was supplied; create `ui-target.html` only when a disposable visual target materially reduces ambiguity.\n- For `approximate` and `high` UI reference fidelity, activate `Reference-Implementation`, populate `Fidelity Requirements`, persist canonical Reference-Implementation `required_evidence`, and record UI-specific labels only as aliases\u002Fmapping notes.\n- `alignment.md` must record `Semantic Term Decisions`, `Upstream Intent Disposition`, and `Out-Of-Scope Conflicts` when relevant.\n- Do not recommend `\u002Fsp.plan` while a capability-like upstream signal lacks disposition, an ambiguous high-impact term lacks confirmation, or an out-of-scope conflict lacks user confirmation.\n- Report what was confirmed, what remains open, what was deferred or dropped, and the single valid next command.\n\n## Guardrails\n\n- Do not edit source code, tests, or implementation files from `sp-specify`.\n- Do not treat the discussion handoff summary as complete when discussion source files exist.\n- Do not silently narrow user scope, redefine broad capability terms, or convert the request into a smaller delivery without user confirmation.\n- Do not require legacy brainstorming journals, stage manifests, lock JSON files, or replay artifacts for normal `sp-specify` completion.\n- Do not treat this summary block as the workflow itself; the detailed contract below remains authoritative.\n\n## Senior Consequence Analysis Gate\n\nRun this gate whenever the request, artifact set, defect, or planned change can affect lifecycle operations, running objects, concurrent work, destructive behavior, shared state, downstream consumers, compatibility, security-sensitive behavior, or multiple plausible product behaviors.\n\nProject cognition first. Use the project cognition runtime to identify ownership, consumers, state surfaces, change-propagation facts, verification routes, conflicts, known unknowns, and coverage gaps. Senior consequence analysis second. Turn those facts into explicit product and implementation obligations instead of treating the graph as the decision-maker.\n\nProject cognition readiness provides routing advice. If readiness is `query_ready`, read top-level `minimal_live_reads` first, then use lane-level `first_pass_paths` reasons. If readiness is `review`, inspect the returned `minimal_live_reads` before continuing and treat `coverage_diagnostics` as confidence and closeout signals. If readiness is `needs_rebuild`, continue with live repository evidence and recommend `\u002Fsp-map-scan -> \u002Fsp-map-build` only for brownfield first\u002Fmissing\u002Funusable baseline, schema failure, schema v1 or old broad-schema rebuild-required readiness, zero active-generation `path_index` rows outside `greenfield_empty`, missing or invalid `alias_index`, `explicit_rebuild_requested`, or `baseline_identity_invalid`. If readiness is `blocked`, report the blocked state and continue with live repository evidence unless the user's actual request is to fix cognition runtime state. If readiness is `unsupported_runtime`, continue with live evidence and record that compass intake was unavailable. If `baseline_kind=greenfield_empty`, continue with workflow artifacts and live requirements; do not recommend map-scan -> map-build solely because the graph has no paths. Carry relevant project cognition facts, returned `minimal_live_reads`, inference notes, and coverage gaps into the workflow's artifacts or durable state, but back consequence claims with live code, tests, scripts, configuration, or authoritative docs. Mutation closeout is separate from entry routing: entry stale may continue, but that does not allow source\u002Fruntime mutation workflows to defer closeout. Workflow-owned mutation closeout is not an external map-maintenance handoff; after changing project-related files or behavior, the workflow must run inline project cognition update from its changed paths, affected surfaces, and verification evidence, with `project-cognition mark-dirty` only as fallback when inline update cannot complete. `sp-map-update` is for manual\u002Fexternal maintenance and follow-up repair; it is external map maintenance, not routine closeout for this workflow's own changes. In shared routing summaries, sp-map-update is for manual\u002Fexternal maintenance and ordinary existing-baseline gaps.\n\nRequired output when the gate triggers:\n\n- **Affected Object Map**: name each object, record, worker, queue, artifact, command, API, file surface, user-visible state, or downstream consumer that can be affected.\n- **State-Behavior Matrix**: describe behavior for each important lifecycle state, including created, queued, running, paused, failed, cancelled, completed, resumed, archived, missing, stale, or partially refreshed states when relevant.\n- **Dependency Impact Table**: map direct dependencies, indirect consumers, shared state, compatibility surfaces, validation routes, and adjacent workflows that can break if semantics change.\n- **Recovery And Validation Contract**: state rollback, retry, idempotency, cleanup, migration, observability, and validation evidence required before handoff or completion.\n- **Coverage Gaps**: list what project cognition or live evidence cannot prove, who must resolve each gap, the latest safe resolve phase, the stop-and-reopen condition, and the routing decision: current workflow may continue with an assumption, must ask the user, must route to clarification or deep research, or must request map maintenance.\n- **Consequence Obligations**: assign stable `CA-###` IDs to every obligation that must survive downstream handoff, task generation, worker packets, verification, or debug closeout. Each `CA-###` must include claim, affected objects, owner workflow, latest resolve phase, status, and stop-and-reopen condition.\n\nStand down only for docs-only wording changes, trivial isolated fixes, or local refactors that cannot affect lifecycle operations, running state, destructive operations, shared state, downstream consumers, compatibility, security, or multiple behavior choices. Record the no-trigger reason or stand-down reason in the workflow's durable artifact or closeout before skipping the required outputs.\n\nIf the gate triggers and the current workflow cannot preserve the required outputs, stop and route to the workflow that can. Do not mark ready, resolved, handoff-ready, planning-ready, or complete while triggered consequence obligations remain unresolved, unmapped, or unsupported by validation evidence.\n\n## Agent Phase Handoff\n\nPhase handoff is an agent-only control surface. Human-facing explanation belongs in the visible reply or in project documents that have independent review value; it must not be duplicated into a handoff.\n\n- The previous phase's canonical JSON contract is the next phase's primary input.\n- Use the compact transition shape from `.specify\u002Ftemplates\u002Fagent-phase-transition-schema.json`: `status`, `source_ref`, `semantic_delta`, `required_refs`, `blockers`, `next_action`, and recovery only when blocked.\n- Carry the minimum sufficient context: include a fact only when omitting it could change the next action, lose a requirement or obligation, force rediscovery, weaken verification, or prevent safe recovery.\n- Preserve decisions, acceptance criteria, evidence provenance, `MP-*`, `CA-###`, and stop\u002Freopen conditions by stable reference. Do not copy their full bodies into every downstream artifact.\n- Protected `MP-*` and `CA-###` obligations must not drop between phases. A downstream phase may resolve or reopen them, but may not silently omit them.\n- Carry the locked implementation-target reference. A cross-project transition must not silently point to the current repository when the confirmed target differs.\n- Consume project rules and Learning through `learning start --command \u003Cclassic-command-name> -> list -> show`; run selected `show_argv` only. Constitution remains at `.specify\u002Fmemory\u002Fconstitution.md`; never parse Learning storage.\n- Capture at owning closeout only when the lesson would change a future action; prefer `learning capture-auto`.\n- A rendered Markdown view is never an agent handoff authority. Do not require Markdown\u002FJSON companion agreement.\n- Revalidate upstream truth only when its revision changed, evidence became stale, live repository facts contradict it, or the current phase discovers a scope, boundary, feasibility, or risk change.\n- If `semantic_delta` is empty, do not repeat upstream questions, approach selection, or user confirmation.\n\n## Deterministic Workflow Runtime\n\nFor a feature-bearing `specify -> plan -> tasks -> implement -> accept` stage,\nthe CLI owns phase order and `workflow-state.md`. Do not author or advance\n`workflow-state.md` by hand.\n\n- After `FEATURE_DIR` is known, run `uvx --from git+https:\u002F\u002Fgithub.com\u002Fchenziyang110\u002Fspec-kit-plus.git@4a631657f75460886dbd12ebe48b14fc11cfe0bf specify workflow show --feature-dir \u003Cfeature-dir> --format json`. If state is missing at the first feature stage, run `uvx --from git+https:\u002F\u002Fgithub.com\u002Fchenziyang110\u002Fspec-kit-plus.git@4a631657f75460886dbd12ebe48b14fc11cfe0bf specify workflow enter --command specify --feature-dir \u003Cfeature-dir> --format json`.\n- On entry to `plan`, `tasks`, `implement`, or `accept`, use the current revision with `uvx --from git+https:\u002F\u002Fgithub.com\u002Fchenziyang110\u002Fspec-kit-plus.git@4a631657f75460886dbd12ebe48b14fc11cfe0bf specify workflow transition --to \u003Cthis-stage> --feature-dir \u003Cfeature-dir> --expected-revision \u003Crevision> --format json` before writing that stage's artifacts. The command validates the completed source-stage artifacts and refuses skips, stale revisions, or incomplete handoffs with exit `10`.\n- The destination command owns the transition. A completed stage recommends the next command but must not execute `workflow transition` to that next stage in the same invocation.\n- Use `uvx --from git+https:\u002F\u002Fgithub.com\u002Fchenziyang110\u002Fspec-kit-plus.git@4a631657f75460886dbd12ebe48b14fc11cfe0bf specify workflow next --feature-dir \u003Cfeature-dir> --format json` for the compact next action. Execute only its structured `next_argv`; do not reconstruct flags from prose.\n- After safe agent recovery is exhausted, persist the blocker through `uvx --from git+https:\u002F\u002Fgithub.com\u002Fchenziyang110\u002Fspec-kit-plus.git@4a631657f75460886dbd12ebe48b14fc11cfe0bf specify workflow block --input \u003Cblocker-json-or-> --format json`. Obtain its exact input shape with `uvx --from git+https:\u002F\u002Fgithub.com\u002Fchenziyang110\u002Fspec-kit-plus.git@4a631657f75460886dbd12ebe48b14fc11cfe0bf specify api schema workflow-block-input --format json`; preserve the returned resume argv and human tutorial.\n- After explicit human acceptance and the acceptance-owned closeout both succeed, run `uvx --from git+https:\u002F\u002Fgithub.com\u002Fchenziyang110\u002Fspec-kit-plus.git@4a631657f75460886dbd12ebe48b14fc11cfe0bf specify workflow closeout --feature-dir \u003Cfeature-dir> --expected-revision \u003Crevision> --format json`. It validates acceptance artifacts before marking the feature workflow complete.\n\nFor every blocked exit, including a pre-feature discussion that cannot use the\nfeature runtime yet, follow\n`.specify\u002Ftemplates\u002Fworkflow-blocker-template.md` and its schema. Report the\nexact cause, sanitized evidence, attempted recovery and result, affected scope,\nsmallest next action, observable unblock criteria, and exact resume point. Keep\nagent-capable repair agent-owned. When authority, credentials, a protected\nsystem, physical access, or human judgment is genuinely required, add the full\nHuman Action Guide: goal, prerequisites, safety notes, numbered exact actions,\nexpected result and safe failure branch for every action, independent\nverification, sanitized evidence to return, and the exact resume command.\n\n## Planning Cognition Policy\n\nUse project cognition as advisory navigation, never as sole proof. For an unchanged phase pass, run at most one `project-cognition compass --intent plan` intake when the canonical context capsule lacks a required facet.\n\nRun or emulate:\n\n```text\nC:\\Users\\11034\\.specify\\bin\\project-cognition.exe compass --intent plan --query=\\\"$ARGUMENTS\\\" --format json\n```\n\n- Read and carry `epistemic_contract` in the phase context capsule. Require `graph_role=route_candidate_only`, `fact_source_of_truth=live_repository`, `live_verification_required=true`, `graph_only_claims_allowed=false`, and `unverified_claim_action=withhold`. The contract cannot authorize source changes and cannot prove current behavior.\n- Graph claims are indexed assertions. Even `verified_in_graph_generation` is only an active graph-generation state, not current repository truth; graph claims cannot authorize source changes and cannot set workflow `claim_ready=true`. Use related graph claims to narrow live reads, then prove or reject them from bounded repository evidence.\n- Reuse the returned `compass_state`, `minimal_live_reads`, `first_pass_paths`, lane `claim_refs`, `coverage_diagnostics`, and `expansion_ref` as the phase context capsule. Treat `route_confidence` only within `confidence_scope=route_candidate`; use top-level advanced-query `claim_signals` or `project-cognition expand --section claim_evidence` for bounded `source_path`\u002F`span` evidence. These signals require live verification and cannot prove current repository truth. Read only the minimum live evidence needed for the active claim and let contradictory live evidence override the route candidate.\n- Interpret `claim_ranking` only as a bounded rerank of candidates already eligible through `match_score`; claims cannot create candidates and cannot replace live verification. Fresh supported or graph-generation-verified claims add at most `+1`, while stale and contradicted claims subtract `-1` and `-2`. On `stale_claim_signal` or `contradicted_claim_signal`, preserve `usable_with_review`, follow `reconcile_claims_with_minimal_live_reads`, and complete the lane action against live repository evidence.\n- When claim-specific bounded reads settle a stale or contradicted route, provide only reconciliation intent: workflow, stable `claim_id`, reason, repository-relative `source_path`, bounded line `span`, `supporting` or `contradicting` role, and optional claim-specific verification. Run `project-cognition claim-reconcile prepare --input \u003Cintent.json> --format json`; the runtime owns all integrity fields and the prepared packet path. Execute the returned `apply_argv` exactly (`project-cognition claim-reconcile apply --input \u003Cprepared_packet_path> --format json`). Generic verification cannot re-promote a graph claim. If reconciliation is ready, rerun Compass once for the planning route; otherwise withhold the claim.\n- `fresh`, `stale`, `possibly_stale`, `needs_update`, and `partial_refresh` are planning advisories. Follow returned `minimal_live_reads` and prove the active claim from live evidence; do not stop solely because the index is stale.\n- Rebuild only for an unusable\u002Fmissing baseline or explicit rebuild condition. Do not turn ordinary planning into map maintenance.\n- Artifact-only specification, planning, and task generation do not mark project cognition dirty. A cognition follow-up is required only after actual source\u002Fruntime truth changes.\n- For UI-bearing work, use the same intake to locate likely real entry points,\n  token\u002Ftheme\u002Fcomponent owners, reusable patterns, required states, responsive\n  behavior, visual\u002Faccessibility tests, and design assets. Verify selected paths\n  live, then carry only the compact routes needed by downstream task packets.\n\n[AGENT] For project-cognition-backed semantic intake, routing, audit, resume, or final-claim gates, read `references\u002Fsemantic-work-contract.md`.\n\n## Read-Only Evidence Lane Dispatch\n\nUse this shared dispatch contract when a workflow needs independent evidence gathering but the delegated lane must not mutate project state.\n\nCall `choose_evidence_lane_dispatch(command_name=\"\u003Cworkflow>\", snapshot, workload_shape)` before dispatching read-only evidence lanes.\n\nPerform native subagent capability discovery before recording a delegated lane. Do not record `subagent-blocked` until the active tool surface has been checked and the blocker is specific: no safe lane, no lane contract, no native subagent surface, or unsafe packetization.\n\nRecord the selected fields when a lane is used or blocked:\n\n- `lane_mode: read-only-evidence`\n- `dispatch_shape: leader-inline | one-subagent | parallel-subagents | subagent-blocked`\n- `execution_surface: leader-inline | native-subagents | none`\n- `structured_result: evidence_packet`\n- `blocked_reason` when `dispatch_shape: subagent-blocked`\n\nDispatch rules:\n\n- Stay `leader-inline` for simple questions or one narrow evidence check.\n- Dispatch `one-subagent` when exactly one safe read-only evidence lane is useful and the runtime exposes native subagents.\n- Dispatch `parallel-subagents` when two or more independent read-only evidence lanes can run without overlapping conclusions or state ownership.\n- Record `subagent-blocked` only when a read-only evidence lane is required but no safe lane, no lane contract, or no native subagent surface is available.\n\nEvery read-only evidence lane must have a compact lane contract:\n\n- objective\n- user question or discussion decision it supports\n- authoritative inputs\n- allowed read scope\n- forbidden operations\n- acceptance checks\n- evidence packet format\n- join condition\n\nAllowed delegated operations are file reads, `rg`, project cognition navigation\u002Fquery output, project memory reads, generated-state reads, docs reads, and template reads.\n\nForbidden delegated operations are file writes, state writes, handoff writes, tests, builds, package managers, project CLI commands, app\u002Fserver launch, branch creation, and workflow invocation.\n\nThe parent workflow owns judgment. Subagents return evidence packets only; they do not decide product direction, readiness, handoff status, final answers, or next workflow.\n\n## Main Flow\n\n1. Resolve discussion handoff intake before feature creation; require canonical agent-only `handoff-to-specify.json`, verify `handoff-ready`, `quality_gate.status: user_confirmed`, and `planning_gate_status: ready`, derive the feature description, and do not pass the raw contract path as the feature description. Do not use `specification-input.md`, `discussion-state.md`, or other discussion source files as a substitute.\n2. Verify the installed command surface with `specify --help`, then run `.specify\u002Fscripts\u002Fpowershell\u002Fcreate-new-feature.ps1 \"$ARGUMENTS\"` from the repo root as the generated create-feature script; generated projects resolve this to `.specify\u002Fscripts\u002Fbash\u002Fcreate-new-feature.sh \"$ARGUMENTS\"` or `.specify\u002Fscripts\u002Fpowershell\u002Fcreate-new-feature.ps1 \"$ARGUMENTS\"`. If the feature-creation script exits non-zero, stop with its evidence; do not call `specify lane register` or invent a feature-creation CLI command. After it returns `FEATURE_DIR`, enter or resume `specify` through the deterministic workflow runtime before writing any feature artifact.\n3. Explore project context with project cognition as advisory navigation, then prove current facts from live files and record source evidence.\n4. Select discovery mode for a raw request or compile mode for a confirmed discussion contract. In compile mode, compute `semantic_delta`, ask only about a planning-critical delta, and do not repeat user review when `semantic_delta` is empty.\n5. Decompose semantic terms into explicit decisions and capability operations in `spec-contract.json`; present two or three approaches only when behavior, boundary, compatibility, or acceptance proof changes.\n6. Preserve the discussion contract by reference. Read discussion source files only when a named evidence reference is stale, missing, or contradictory; carry its existing decision digest instead of rebuilding it.\n7. For UI-facing work—with or without supplied screenshots—read selected\n   `DESIGN.md` and live UI evidence; compile `Experience Requirements`,\n   design-system readiness (`design_system_status`, `design_risk_level`), and a\n   feature `ui-brief.md` plus the complete current `design_contract` for\n   substantive UI changes. Separately record work type, surface type, platform,\n   subject, audience, single job, visual\u002Fcontent\u002Finteraction theses, signature,\n   approved visual ref, reference intents, real content\u002Fimage plans, and the\n   structure\u002Fvisual\u002Fruntime evidence triad. Treat a bootstrap or\n   missing required system as a strong blocker and a non-blocking adoption gap\n   as a soft risk. When raw UI references exist, additionally use\n   `choose_ui_reference_lane_dispatch`, `ui-reference-artifact`, and\n   `Reference-Implementation` fidelity evidence.\n8. Write `spec-contract.json`, render or update specification-owned project-facing artifacts, and run deterministic completeness, traceability, and contradiction checks. Run `uvx --from git+https:\u002F\u002Fgithub.com\u002Fchenziyang110\u002Fspec-kit-plus.git@4a631657f75460886dbd12ebe48b14fc11cfe0bf specify hook validate-artifacts --command specify --feature-dir \u003Cfeature-dir> --format json` and fail closed if the specification package is incomplete. Request user review only for non-empty semantic delta or a real unresolved decision, then recommend exactly one next command: `\u002Fsp.plan`, `\u002Fsp.clarify`, or `\u002Fsp.deep-research`.\n\nCreate only specification-stage outputs. Do not create `plan-contract.json`, `plan.md`, research\u002Fdesign-plan artifacts, `tasks.md`, or `task-index.json`; the separately invoked planning and task workflows own them. Do not edit production source, tests, migrations, or runtime configuration.\n\n## Detailed References\n\nRead [Reference index](references\u002FINDEX.md) before applying detailed contracts.\n\n- [discussion handoff validation](references\u002Fdiscussion-handoff-validation.md)\n- [semantic traceability](references\u002Fsemantic-traceability.md)\n- [ui reference lane](references\u002Fui-reference-lane.md)\n- [artifact package](references\u002Fartifact-package.md)\n- [question cadence and review](references\u002Fquestion-cadence-and-review.md)\n- [self review and quality gates](references\u002Fself-review-and-quality-gates.md)\n\n## Claude Code Subagent Capability Discovery\n\n- Execution model: preserve the workflow's existing `subagent-mandatory`, `subagents-first`, `adaptive`, or `subagent-assisted` policy.\n- Dispatch shape: preserve the workflow's existing dispatch shape; use `subagent-blocked` only after the discovery step below fails or is unsafe.\n- Execution surface: prefer `native-subagents` when the current runtime supports it; use `none` only after recording the unavailable or unsafe surface.\n- Native subagent capability discovery: Before recording `subagent-blocked`, check the active tool surface for the integration-native subagent or task-dispatch entrypoint and record the exact missing surface if unavailable.\n- Do not record `subagent-blocked` until this capability discovery step is complete and the exact unavailable or unsafe surface is recorded.\n- Native subagent dispatch: Dispatch subagents through the integration's native subagent support using the shared prompt contract.\n- Join behavior: Use the integration-native join point, then integrate results back on the leader path.\n- Preserve this workflow's existing packet, handoff, artifact, and result schema; this section only governs capability discovery before dispatch or blocked-state recording.\n\n## Claude Code Structured Question Preference\n\n- If this command was routed by `sp-auto` with `auto_default_recommendation: true`, evaluate the automatic recommended\u002Fdefault continuation gate before any question path.\n- When that gate has one safe recommended\u002Fdefault answer, you must auto-resolve the question or confirmation, record the accepted recommendation in the workflow state or summary, continue the workflow, and do not invoke the native structured question tool only to ask for that approval.\n- If the automatic gate is not safe, write the blocker and self-unblock recommendation before using the normal question path.\n- If the runtime's native structured question tool is available for the current turn and the `sp-auto` automatic gate did not resolve the question, you must use it.\n- Do not render the textual fallback block when the native tool is available.\n- Do not self-authorize textual fallback because the question seems simple, short, or easy to phrase manually.\n- Treat the template's textual question format as fallback-only guidance; use it to shape the question content, but do not render the textual block unless the native tool is unavailable in the current runtime or the tool call fails.\n- Keep native-tool availability, runtime mode, and fallback mechanics backstage. Do not tell the user that a structured question tool is unavailable, that the current runtime\u002Fmode lacks a tool, or that a fallback is being used; ask the user-facing question directly when a question is genuinely required.\n- Ask only the minimum number of questions required by this workflow's existing contract.\n- Keep the user-visible question text in the user's current language and keep option labels short.\n- Do not emit both a native tool question and the textual fallback block in the same turn. The user should see the active question exactly once.\n- If the native tool is unavailable in the current runtime or the tool call fails, fall back to the shared open question block structure already defined in this template.\n- In `specify`, use this preference for:\n  - planning-critical clarification\n  - capability split confirmation\n  - user-owned semantic delta before planning readiness\n- Native tool target: `AskUserQuestion`\n- When this native tool target is listed for the integration and the runtime does not signal otherwise, assume it is available by default in normal interactive sessions.\n- Question count: 1-4 questions per call\n- Option count: 2-4 options per question\n- Required question fields: `question`, `header`, `options`, `multiSelect`\n- Option fields: `label`, `description`, `preview (optional)`\n- Use `multiSelect: false` unless the workflow explicitly needs multiple selections.\n- Use `metadata` only when tracking or analytics context adds value; otherwise keep the call minimal.\n\n## Pre-Analysis Protocol\n\n- Before drafting or asking clarification questions, identify the target need, scope boundary, key constraints, acceptance proof, known unknowns, and safest next step.\n- Keep guided requirement discovery concise and avoid reviving the deprecated fixed heavy discovery lifecycle.\n- Treat `final-handoff-decision` as a compatibility readiness check name only; do not restore the legacy staged handoff flow.\n- In compile mode, reuse the confirmed discussion contract's context capsule and decision digest. Run one bounded `project-cognition compass --intent plan --query=\"$ARGUMENTS\" --format json` intake only when a planning facet is absent or outdated; preserve `project-cognition query --intent plan --query-plan` as a precision escalation for an explicit unresolved concept.\n- Read top-level `minimal_live_reads` first and open live files only for the named gap. Do not build a second broad repository summary or infer final scope from first-pass paths.\n- After `FEATURE_DIR` is known, use `specify workflow show --feature-dir \u003Cfeature-dir> --format json`; when state is missing, run `specify workflow enter --command specify --feature-dir \u003Cfeature-dir> --format json`. The deterministic runtime owns `workflow-state.md`; do not reconstruct it in the prompt. Do not implement code, edit source files, edit tests, or run implementation-oriented fix loops from `sp-specify`.\n- Write canonical `spec-contract.json` first. Render `spec.md`; write `alignment.md`, `context.md`, `references.md`, or diagnostics only when the triggered content has independent project-review value and cannot be represented by a stable ref.\n- Clarify only planning-critical ambiguity. Recommend `\u002Fsp.clarify` or `\u002Fsp.deep-research` only when the unresolved item belongs there.\n- Preserve this as an internal understand-before-acting pass; do not replace the one-question-at-a-time requirement discovery flow with a broad analysis report.\n\n## Semantic Traceability Guidance\n\n- Preserve the concise `sp-specify` flow: explore project context, ask one high-impact question at a time, compare two or three approaches, write artifacts, self-review, and ask for user review.\n- When `sp-specify` comes from `sp-discussion`, compile canonical `spec-contract.json` from the confirmed requirement contract and preserve its decision digest by reference.\n- Read supporting discussion files only when a named evidence reference is stale, missing, or contradictory; record only the refs actually needed in the compact context capsule.\n- Compute `semantic_delta`; when it is empty and deterministic review passes, do not repeat upstream questions or user confirmation.\n- Decompose semantic terms before narrowing scope and keep unconfirmed narrowing out of planning-ready state.\n- Downstream stages must reopen upstream intent explicitly instead of silently reinterpreting it.\n\n## Project Cognition Freshness Closeout\n\n- This workflow is artifact-only unless the user explicitly requested source\u002Fruntime\u002Ftemplate\u002Fconfig\u002Ftest\u002Fgenerated-asset changes; do not call `project-cognition mark-dirty`, `project-cognition complete-refresh`, or `project-cognition validate-build --format json` just because `sp-specify`, `sp-plan`, or `sp-tasks` wrote planning artifacts.\n- If this planning workflow makes actual source\u002Fruntime\u002Ftemplate\u002Fconfig\u002Ftest\u002Fgenerated-asset changes in the current run, it stops being artifact-only for closeout: run inline project cognition update from the workflow-owned changed paths and affected surfaces.\n- Git-baseline freshness only changes after source\u002Fruntime\u002Ftemplate\u002Fconfig\u002Ftest\u002Fgenerated-asset changes are recorded; planning-only artifact edits do not require `project-cognition complete-refresh`, and manual override\u002Ffallback belongs only to an explicit map-maintenance recovery path.\n- Inline project cognition update uses `project-cognition delta append` followed by `project-cognition update --delta-session \"$DELTA_SESSION_ID\" --reason workflow-finalize --format json` when a delta session exists, or `project-cognition update --payload-file \".specify\u002Fproject-cognition\u002Fupdates\u002F\u003Cupdate-id>.json\" --reason workflow-finalize --format json` when no delta session exists.\n- The payload-file path must include changed_paths, behavior_surfaces, generated_surfaces, state_contracts, verification, known_unknowns, and confidence_notes so the update is equivalent to `sp-map-update`, not just a path stamp; `verification_evidence` and `generated_surface_notes` are accepted compatibility aliases.\n- Use `known_unknowns` only for blockers that make the cognition update unsafe to trust. If unrelated dirty or untracked working-tree paths were excluded by explicit workflow-owned paths, record that as `confidence_notes` or `boundary.initial_dirty_paths`, not as blocking `known_unknowns`.\n- clean closeout keys on `result_state`, not `update_id`, `last_update_id`, or freshness alone. Treat `ready` and `no_op` as clean, `partial_refresh` as recorded but not fully clean, `needs_rebuild` as a map-scan\u002Fmap-build route, `blocked` as blocked, and `recorded` as legacy recorded-only output that is never clean completion.\n- Use `project-cognition mark-dirty --reason \"\u003Creason>\" --format json` only when inline update cannot complete.\n- `sp-map-update` is for manual\u002Fexternal maintenance and follow-up repair, not routine cleanup for changes this workflow just made; run `\u002Fsp-map-scan` followed by `\u002Fsp-map-build` only for brownfield first\u002Fmissing\u002Funusable baseline, schema failure, schema v1 or old broad-schema rebuild-required readiness, zero active-generation `path_index` rows outside `greenfield_empty`, missing or invalid `alias_index`, `explicit_rebuild_requested`, or `baseline_identity_invalid`.\n",{"name":5,"metadata":24,"description":7,"argument-hint":27,"compatibility":28,"user-invocable":29},{"author":25,"source":26},"github-spec-kit","templates\u002Fcommands\u002Fspecify.md","Describe the feature you want to specify","Requires spec-kit project structure with .specify\u002F directory",true,"main","021f5cbe02157229460a577e9a585f2da6d78cb0",".claude\u002Fskills\u002Fsp-specify","https:\u002F\u002Fgithub.com\u002Fchenziyang110\u002Flaunchdeck","https:\u002F\u002Fgithub.com\u002Fchenziyang110","2026-08-07 18:10:54",{"source":8,"skillName":5,"commands":37,"prompt":47,"zipAvailable":29},[38,41,44],{"tool":39,"command":40},"npx","npx skills add chenziyang110\u002Flaunchdeck --skill sp-specify",{"tool":42,"command":43},"bunx","bunx skills add chenziyang110\u002Flaunchdeck --skill sp-specify",{"tool":45,"command":46},"pnpm","pnpm dlx skills add chenziyang110\u002Flaunchdeck --skill sp-specify","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fchenziyang110\u002Flaunchdeck\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fsp-specify\u002FSKILL.md",[49,55,59,63,67,71,75,79],{"path":50,"resourceType":51,"resourceTypeDesc":52,"sizeBytes":53,"sourceHtmlUrl":54},"references\u002Fartifact-package.md","REFERENCE","参考文档",3801,"https:\u002F\u002Fgithub.com\u002Fchenziyang110\u002Flaunchdeck\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fsp-specify\u002Freferences\u002Fartifact-package.md",{"path":56,"resourceType":51,"resourceTypeDesc":52,"sizeBytes":57,"sourceHtmlUrl":58},"references\u002Fdiscussion-handoff-validation.md",4978,"https:\u002F\u002Fgithub.com\u002Fchenziyang110\u002Flaunchdeck\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fsp-specify\u002Freferences\u002Fdiscussion-handoff-validation.md",{"path":60,"resourceType":51,"resourceTypeDesc":52,"sizeBytes":61,"sourceHtmlUrl":62},"references\u002FINDEX.md",1575,"https:\u002F\u002Fgithub.com\u002Fchenziyang110\u002Flaunchdeck\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fsp-specify\u002Freferences\u002FINDEX.md",{"path":64,"resourceType":51,"resourceTypeDesc":52,"sizeBytes":65,"sourceHtmlUrl":66},"references\u002Fquestion-cadence-and-review.md",2222,"https:\u002F\u002Fgithub.com\u002Fchenziyang110\u002Flaunchdeck\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fsp-specify\u002Freferences\u002Fquestion-cadence-and-review.md",{"path":68,"resourceType":51,"resourceTypeDesc":52,"sizeBytes":69,"sourceHtmlUrl":70},"references\u002Fself-review-and-quality-gates.md",3977,"https:\u002F\u002Fgithub.com\u002Fchenziyang110\u002Flaunchdeck\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fsp-specify\u002Freferences\u002Fself-review-and-quality-gates.md",{"path":72,"resourceType":51,"resourceTypeDesc":52,"sizeBytes":73,"sourceHtmlUrl":74},"references\u002Fsemantic-traceability.md",14841,"https:\u002F\u002Fgithub.com\u002Fchenziyang110\u002Flaunchdeck\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fsp-specify\u002Freferences\u002Fsemantic-traceability.md",{"path":76,"resourceType":51,"resourceTypeDesc":52,"sizeBytes":77,"sourceHtmlUrl":78},"references\u002Fsemantic-work-contract.md",32225,"https:\u002F\u002Fgithub.com\u002Fchenziyang110\u002Flaunchdeck\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fsp-specify\u002Freferences\u002Fsemantic-work-contract.md",{"path":80,"resourceType":51,"resourceTypeDesc":52,"sizeBytes":81,"sourceHtmlUrl":82},"references\u002Fui-reference-lane.md",3141,"https:\u002F\u002Fgithub.com\u002Fchenziyang110\u002Flaunchdeck\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fsp-specify\u002Freferences\u002Fui-reference-lane.md",[84,91,97,103,110,119],{"skillNo":85,"name":86,"nameZh":6,"description":87,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":88,"categories":89,"keywords":90,"publishedAt":19},"01M7875F3HQ1GF5F6BR36KY3JE","launchdeck-agent","Codex host adapter contract fixture for Launchdeck.","https:\u002F\u002Fgithub.com\u002Fchenziyang110\u002Flaunchdeck\u002Fblob\u002Fmain\u002Ftest\u002Ffixtures\u002Fagent-hosts\u002Fcodex\u002Fskill\u002FSKILL.md",[],[],{"skillNo":92,"name":86,"nameZh":6,"description":93,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":94,"categories":95,"keywords":96,"publishedAt":19},"01M7875DV2DQR33K1NFJHKAMZP","Claude host adapter contract fixture for Launchdeck.","https:\u002F\u002Fgithub.com\u002Fchenziyang110\u002Flaunchdeck\u002Fblob\u002Fmain\u002Ftest\u002Ffixtures\u002Fagent-hosts\u002Fclaude\u002Fskill\u002FSKILL.md",[],[],{"skillNo":98,"name":86,"nameZh":6,"description":99,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":100,"categories":101,"keywords":102,"publishedAt":19},"01M78759JQ7A6FQ8KDQTNYS3X9","Use this skill aggressively for local project lifecycle operations even when the user does not mention Launchdeck: start this project, run the dev server, dev, build, test, restart service, stop service, show logs, inspect ports, port is occupied, clean cache; and when the user explicitly asks to configure this local project for Launchdeck or create or generate a project-adapted `.launchdeck.yml`, including 为这个项目生成 Launchdeck 配置. Do not use for ordinary code edits, docs-only work, general explanations, API design discussion, or production deployment unless the user also asks to operate or configure a local project or service.","https:\u002F\u002Fgithub.com\u002Fchenziyang110\u002Flaunchdeck\u002Fblob\u002Fmain\u002Fagent\u002Finstaller-payload\u002Fskill\u002Flaunchdeck-agent\u002FSKILL.md",[],[],{"skillNo":104,"name":105,"nameZh":6,"description":106,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":107,"categories":108,"keywords":109,"publishedAt":19},"01M78753ZJQ7G2CZT1W1G8WRJV","zig-testing","Use ONLY when user explicitly requests Zig test code, built-in test runner configuration,\ntest failure diagnosis, or coverage for Zig projects.\n\nTriggers: \"write test zig\", \"zig test\", \"testing.allocator\", \"zig coverage\",\n\"comptime test\", \"zig expectError\", \"zig snapshot test\", \"zig fuzz\".\n\nDo NOT activate for: general Zig coding without test context, build.zig configuration\nfor non-test targets, Zig compiler errors, or Zig build system setup.","https:\u002F\u002Fgithub.com\u002Fchenziyang110\u002Flaunchdeck\u002Fblob\u002Fmain\u002F.specify\u002Ftemplates\u002Fpassive-skills\u002Fzig-testing\u002FSKILL.md",[],[],{"skillNo":111,"name":112,"nameZh":6,"description":113,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":114,"licenseFileUrl":115,"sourceHtmlUrl":116,"categories":117,"keywords":118,"publishedAt":19},"01M78750JXY4Z5D5W1EX3PQ31Z","webapp-testing","Toolkit for interacting with and testing local web applications using Playwright. Supports verifying frontend functionality, debugging UI behavior, capturing browser screenshots, and viewing browser logs.","Apache-2.0","https:\u002F\u002Fgithub.com\u002Fchenziyang110\u002Flaunchdeck\u002Fblob\u002Fmain\u002F.specify\u002Ftemplates\u002Fpassive-skills\u002Fwebapp-testing\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fchenziyang110\u002Flaunchdeck\u002Fblob\u002Fmain\u002F.specify\u002Ftemplates\u002Fpassive-skills\u002Fwebapp-testing\u002FSKILL.md",[],[],{"skillNo":120,"name":121,"nameZh":6,"description":122,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":123,"categories":124,"keywords":125,"publishedAt":19},"01M7874X2T83EQQFRCEY5SJJVC","verification-before-completion","Use when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidence before assertions always","https:\u002F\u002Fgithub.com\u002Fchenziyang110\u002Flaunchdeck\u002Fblob\u002Fmain\u002F.specify\u002Ftemplates\u002Fpassive-skills\u002Fverification-before-completion\u002FSKILL.md",[],[]]