[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M786C2KHPD5607QFXRGXSSSW":3,"skill-same:01M786C2KHPD5607QFXRGXSSSW":59},{"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},"01M786C2KHPD5607QFXRGXSSSW","sp-map-build",null,"Use when `sp-map-scan` has produced a value-weighted evidence baseline and you need to reconstruct the project cognition SQLite runtime.","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-map-build\u002FSKILL.md",[],[],"2026-11-15 14:19:17",false,"---\nname: \"sp-map-build\"\ndescription: \"Use when `sp-map-scan` has produced a value-weighted evidence baseline and you need to reconstruct the project cognition SQLite runtime.\"\nargument-hint: \"Optional scan package or atlas area to emphasize while building the project map\"\ncompatibility: \"Requires spec-kit project structure with .specify\u002F directory\"\nmetadata:\n  author: \"github-spec-kit\"\n  source: \"templates\u002Fcommands\u002Fmap-build.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 scan baseline exists and the project cognition runtime must be built or rebuilt from that evidence.\n- **Primary objective**: Validate value-weighted scan evidence, reconstruct graph nodes, edges, observations, typed graph claims, path indexes, and alias indexes from high-value evidence into the schema v5 SQLite cognition database, derive revisioned claim lifecycle state, assign confidence, and publish queryable task-oriented cognition bundles.\n- **Primary outputs**: `.specify\u002Fproject-cognition\u002Fstatus.json`, `.specify\u002Fproject-cognition\u002Fproject-cognition.db`, and query\u002Fupdate helper readiness metadata.\n- **Default handoff**: Return to the blocked brownfield workflow once the query-backed cognition baseline is ready.\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\nReconstruct or refresh the query-backed project cognition runtime from a completed evidence baseline.\n\n## Context\n\n- Primary inputs: `.specify\u002Fproject-cognition\u002Fstatus.json`, `.specify\u002Fproject-cognition\u002Fevidence\u002F`, `.specify\u002Fproject-cognition\u002Fprovisional\u002Fnodes.json`, `.specify\u002Fproject-cognition\u002Fprovisional\u002Fedges.json`, `.specify\u002Fproject-cognition\u002Fprovisional\u002Fobservations.json`, and live repository evidence.\n- This command owns the query-backed cognition runtime outputs: `.specify\u002Fproject-cognition\u002Fstatus.json` and `.specify\u002Fproject-cognition\u002Fproject-cognition.db`.\n- Run `C:\\Users\\11034\\.specify\\bin\\project-cognition.exe build-from-scan --format json` after scan and package validation. It adapts the accepted canonical scan package into a versioned proposal and runs the deterministic cognition proposal compiler before any graph-store mutation; only a publishable result may continue to DB import, metadata, status publication, and DB\u002Fstatus agreement.\n- Treat `compilation.publication_allowed=false` as a hard pre-publication block and stop without creating, archiving, replacing, or publishing the graph store.\n- Successful compilation preserves advisory graph material as route candidates rather than repository facts; prove behavioral claims from live repository evidence.\n- [AGENT] Treat sparse path-index gates as build preflight; do not publish query-ready status when `validate-build` would fail `path_index_to_included_ratio`, critical path, or important path checks.\n- Do not construct `.specify\u002Fproject-cognition\u002Fproject-cognition.db` with manual SQL as the normal workflow path.\n- If the evidence baseline is incomplete or the accepted evidence cannot support graph reconstruction, produce a scan gap report and return to `sp-map-scan`.\n- If scan packet intake exposes contract-invalid, systemic packet-family failures, or `paths_read` values that are not concrete path arrays, preserve the scan gap report and route back to `sp-map-scan`; this is not only a local patch in build.\n- Record accepted and rejected reconstruction evidence as DB\u002Fruntime update records and queryable task-local bundle readiness metadata. Treat any raw graph or slice files as compatibility\u002Fexport artifacts, not runtime truth.\n- Apply project cognition ignore rules from root `.cognitionignore` and `.specify\u002Fproject-cognition\u002F.cognitionignore`; rejected paths remain outside graph evidence and DB route indexes even when scan artifacts mention them.\n- Validate `repository-universe.json` as the canonical scan boundary before graph reconstruction; excluded paths are boundary facts, not graph evidence.\n- If native subagent dispatch is unavailable or a substantive build lane cannot complete, persist `subagent_blocked` in machine-readable state and block baseline activation until recovery. `coverage-ledger.json.open_gaps[]` may use `low_risk_open_gap` only with owner, reason, evidence expectation, and revisit condition.\n\n[AGENT] For project-cognition-backed semantic intake, routing, audit, resume, or final-claim gates, read `references\u002Fsemantic-work-contract.md`.\n\n## Detailed References\n\nRead [Reference index](references\u002FINDEX.md) before applying shared semantic contracts.\n\n- [semantic work contract](references\u002Fsemantic-work-contract.md)\n\n## Mandatory Subagent Execution\n\nAll substantive tasks in ordinary `sp-*` workflows default to and must use subagents.\n\nThe leader orchestrates: route, split tasks, prepare task contracts, dispatch subagents, wait for structured handoffs, integrate results, verify, and update state.\n\nBefore dispatch, every subagent lane needs a task contract with objective, authoritative inputs, allowed read\u002Fwrite scope, forbidden paths, acceptance checks, verification evidence, and structured handoff format.\n\nUse `execution_model: subagent-mandatory`.\nUse `dispatch_shape: one-subagent | parallel-subagents`.\nUse `execution_surface: native-subagents`.\n\n## Objective\n\nReconstruct or refresh the query-backed project cognition runtime from a completed value-weighted evidence baseline.\n\n## Project Learning\n\nThe CLI is the only agent-facing Learning read surface:\n\n1. Run `uvx --from git+https:\u002F\u002Fgithub.com\u002Fchenziyang110\u002Fspec-kit-plus.git@4a631657f75460886dbd12ebe48b14fc11cfe0bf specify learning start --command \u003Cclassic-command-name> --format json` before deeper non-trivial work.\n2. Select summaries by applicability and triggers; use `uvx --from git+https:\u002F\u002Fgithub.com\u002Fchenziyang110\u002Fspec-kit-plus.git@4a631657f75460886dbd12ebe48b14fc11cfe0bf specify learning list --command \u003Cclassic-command-name> --format json` only to filter or page.\n3. Execute one matching card's `show_argv`. Do not parse Learning storage.\n\n`start`, `list`, and `show` are read-only. Current repository evidence,\n`.specify\u002Fmemory\u002Fconstitution.md`, and explicit user direction override stale or\ncandidate Learning.\n\nAt closeout, corrections, retries, route changes, recovery, false leads, hidden\ndependencies, validation\u002Ftooling\u002Fstate\u002Fcognition gaps, constraints, and near\nmisses are capture signals. Prefer `uvx --from git+https:\u002F\u002Fgithub.com\u002Fchenziyang110\u002Fspec-kit-plus.git@4a631657f75460886dbd12ebe48b14fc11cfe0bf specify learning capture-auto`\nfrom owning state; manual capture includes summary, problem, action, triggers,\nsuccess criteria, avoid items, exceptions, and evidence.\n\n- `fast`: skip unless the task escalates.\n- `accept`, `analyze`, `ask`, `auto`, `constitution`, `explain`,\n  `implement-teams`, `taskstoissues`, and `team`: consume-only; do not violate\n  their write boundaries to capture.\n- Other non-trivial workflows: consume before deeper work; capture reusable\n  signals at closeout or record a no-learning decision.\n\nThe `policy` returned by the CLI is authoritative when prompt wording drifts.\n\n## Process\n\n- Start with validation, not writing.\n- Update `map-state.md` before long-running reconstruction, join-point acceptance, compaction-risk transitions, or any stop where resume will depend on more than the visible conversation.\n- Validate scan inputs before execution and compile\u002Fvalidate `MapBuildPacket` inputs before dispatch.\n- Validate both `.specify\u002Fproject-cognition\u002Fworkbench\u002Frepository-universe.json` and `.specify\u002Fproject-cognition\u002Fworkbench\u002Fscan-targets.json` before graph import. `repository-universe.json` is full path accounting; `scan-targets.json` is the high-value execution target set.\n- Treat `P0`\u002F`P1` `scan_decision=scan` rows as graph-build candidates that must be backed by accepted packet evidence before they can publish queryable runtime truth.\n- Treat `P2` rows according to their recorded `scan_decision`: scanned or sampled rows can support graph truth when evidence-backed; inventory-only rows remain boundary accounting.\n- Treat `P3`, `inventory_only`, and `excluded` rows as boundary accounting only unless explicit accepted scan evidence and a high-value reason promote them. Do not derive graph, path_index, alias_index, route rows, or `minimal_live_reads` from raw inventory-only rows.\n- Dispatch only validated packetized build lanes as `one-subagent` or `parallel-subagents`.\n- If overlap, missing packet data, missing required references, or unsafe acceptance criteria prevent safe dispatch, record `subagent-blocked` and stop for escalation or recovery.\n- Run `C:\\Users\\11034\\.specify\\bin\\project-cognition.exe validate-scan --format json` before graph import.\n- Run `C:\\Users\\11034\\.specify\\bin\\project-cognition.exe build-from-scan --format json` after scan and package validation. It adapts the accepted canonical scan package into a versioned proposal and runs the deterministic cognition proposal compiler before any graph-store mutation, then rebuilds the graph store into schema v5 and owns DB import, metadata, status publication, and DB\u002Fstatus agreement.\n- Treat `compilation.publication_allowed=false` as a hard pre-publication block. Report the bounded compiler conflicts and stop without creating, archiving, replacing, or publishing a graph store.\n- A successful compile means the proposal is structurally safe and deterministic enough to publish as advisory graph material. Compiled nodes, edges, paths, aliases, and graph claims remain route candidates rather than repository facts; even `verified_in_graph_generation` requires bounded live repository evidence before behavioral or workflow final claims.\n- If `build-from-scan` returns `status=blocked`, report its `errors`, identity reconciliation details from `identity_reconciliation`, `rejections`, `merge_records`, and `recovery_action` and do not proceed to build validation.\n- Run `C:\\Users\\11034\\.specify\\bin\\project-cognition.exe validate-build --format json` after `build-from-scan`.\n\n## Machine-Readable Blocked State\n\nHuman workflow prose may say `subagent-blocked`, but persisted machine fields use\n`subagent_blocked`.\n\nIf a substantive scan\u002Fbuild lane cannot dispatch or complete, write:\n\n- `.specify\u002Fproject-cognition\u002Fstatus.json` with `baseline_state=blocked` and\n  `subagent_blocked` in `stale_reasons` or `dirty_reasons`\n- `.specify\u002Fproject-cognition\u002Fworkbench\u002Fmap-state.md` with\n  `readiness=blocked`, `blocking_reason=subagent_blocked`, blocked lane ids,\n  blocked scope, and recovery condition\n- `.specify\u002Fproject-cognition\u002Fworkbench\u002Fcoverage-ledger.json.open_gaps[]` with\n  `reason=\"subagent_blocked\"`, `lane_id`, `packet_id`, `blocked_scope`,\n  `criticality`, `owner`, `status=\"blocked\"`, and `recovery_condition`\n\n`unknown` blocks, `blocked`, `critical_open_gap`, and `subagent_blocked` block baseline\nactivation. `low_risk_open_gap` may pass only with owner, reason,\n`evidence_expectation`, and `revisit_condition`.\n\n## Hard Boundary\n\n- `sp-map-build` is the command that publishes query-backed cognition truth.\n- `sp-map-build` must not fall back to handbook-first runtime output.\n- `sp-map-build` owns schema v5 SQLite runtime publication, confidence assignment, revisioned typed graph-claim lifecycle derivation, route validation, reconciliation-basis support, and alias catalog readiness.\n- Existing narratives may inform continuity, but final runtime rows must be backed by scan evidence. Map points, code proves: the alias catalog is route vocabulary, not evidence by itself.\n\n## Required Inputs\n\nBefore writing query-backed truth, read:\n\n- `.specify\u002Fproject-cognition\u002Fstatus.json`\n- `.specify\u002Fproject-cognition\u002Fevidence\u002F`\n- `.specify\u002Fproject-cognition\u002Fprovisional\u002Fnodes.json`\n- `.specify\u002Fproject-cognition\u002Fprovisional\u002Fedges.json`\n- `.specify\u002Fproject-cognition\u002Fprovisional\u002Fobservations.json`\n- optional `.specify\u002Fproject-cognition\u002Fprovisional\u002Fclaims.json`\n- `.specify\u002Fproject-cognition\u002Fcoverage.json`\n- `.specify\u002Fproject-cognition\u002Fworkbench\u002Frepository-universe.json`\n- `.specify\u002Fproject-cognition\u002Fworkbench\u002Fscan-targets.json`\n- `.specify\u002Fproject-cognition\u002Fworkbench\u002Fcoverage-ledger.json`\n- `.specify\u002Fproject-cognition\u002Fworkbench\u002Fscan-queue.json`\n- `.specify\u002Fproject-cognition\u002Fworkbench\u002Fhandoff-ledger.json`\n- `.specify\u002Fproject-cognition\u002Fworkbench\u002Fscan-packets\u002F`\n\nIf those artifacts are missing, stop and route back to `\u002Fsp-map-scan`.\n\n## Boundary Acceptance\n\n`sp-map-build` must validate `.specify\u002Fproject-cognition\u002Fworkbench\u002Frepository-universe.json` and `.specify\u002Fproject-cognition\u002Fworkbench\u002Fscan-targets.json` before publishing runtime truth.\n\n- Every `included_paths` entry in `repository-universe.json` must have one explicit boundary disposition: `deep_read`, `sampled`, `inventory_only`, `excluded`, or `blocked`.\n- For graph-eligible selected paths, every included path is represented in scan coverage or an accepted gap.\n- Every `selected_paths` entry in `scan-targets.json` must appear in `coverage.json`, `coverage-ledger.json`, or an accepted non-blocking gap.\n- Every `P0` or `P1` row with `scan_decision=scan` must have accepted packet evidence before runtime publication, or the build must return a scan gap report and route back to `sp-map-scan`.\n- `P2` rows may be sampled or inventory-only only when `scan-targets.json` records the lower-depth decision and `coverage-ledger.json` preserves the evidence expectation and revisit condition.\n- `P3`, `inventory_only`, and `excluded` rows are not missing graph evidence. They are complete only as boundary accounting and must not inflate graph-readiness failure counts.\n- Every `excluded_paths` entry must stay only in the boundary artifact or grouped exclusion ledger.\n- Excluded paths are represented only by the boundary artifact or grouped accounting ledgers, not by graph-facing coverage rows. Inventory-only paths follow the same boundary-accounting rule unless explicitly promoted.\n- Excluded paths must not appear in graph-facing coverage rows, evidence rows, provisional graph rows, DB path indexes, route indexes, alias indexes, or `minimal_live_reads`. Inventory-only paths follow the same rule unless the scan target explicitly promoted them with accepted evidence.\n- If repository-universe, scan-targets, coverage, and packet handoffs cannot explain the same selected path universe, return a scan gap report and route back to `sp-map-scan`.\n- If scan packet acceptance reports `fail_contract` or `fail_systemic`, route back to `sp-map-scan` with a scan gap report because the repair is not only a local patch.\n- `path_index_to_included_ratio` must be computed from graph-eligible paths: selected `P0`\u002F`P1` paths plus evidence-backed selected `P2` paths, minus true exclusions and `accepted_nonblocking_gap_paths`.\n- Critical and important graph-eligible paths must remain in the sparse path-index denominator unless they are true repository-universe exclusions or explicitly accepted nonblocking gaps.\n- `build-from-scan` must not set `freshness=fresh`, must not set `readiness=query_ready`, and must not set `graph_ready=true` until sparse path-index gates pass.\n\n## Schema V5 Runtime Contract\n\nSchema v5 is current-only. `project-cognition build-from-scan --format json`\ncreates schema v5 only for a missing database or consumes a complete current\nschema v5 database. The current runtime does not migrate schema v4 or older\ndatabases and does not archive or replace them. Remove the incompatible project-cognition.db\nexplicitly, then run `sp-map-scan -> sp-map-build` with the current binary.\nSchema v5 keeps the\nimplemented runtime tables: `metadata`, `generations`, `evidence`, `nodes`,\n`node_evidence`, `edges`, `edge_evidence`, `observations`,\n`observation_evidence`, `path_index`, `alias_index`, `claims`, `claim_evidence`,\n`claim_verifications`, `claim_transitions`, `claim_reconciliations`, and `updates`.\n\nConflicts, symbols, entrypoints, tests, slices, query examples, FTS tables, and compatibility `query_examples` are not current readiness requirements.\n\nGraph claims use `graph_claim_type` and a compiler-derived lifecycle state:\n`candidate`, `supported`, `verified_in_graph_generation`, `contradicted`, or\n`stale`. `claim_evidence` records supporting and contradicting evidence,\n`claim_verifications` records bounded verification inputs, and\n`claim_transitions` makes lifecycle changes auditable. Schema v5 also records\n`claim_reconciliations`; `claim_evidence.basis_state` distinguishes the current\nevidence basis used for routing from superseded or historical evidence. An Agent-provided\n`requested_state` is never authoritative. `verified_in_graph_generation` means\nonly that the active graph generation contains supporting evidence and a current\npassed graph verification; it is not current repository truth and never grants\nworkflow authorization or final claim readiness.\n\nFor brownfield baselines, `alias_index` is required: every active node must have\nat least one active-generation alias row, no alias may point at a missing node,\nand no alias may reference a missing non-empty evidence id. The schema v5 alias\ncatalog helps agents normalize user input before query planning; it does not prove behavior\nwithout live repository evidence.\n\nIf validation reports schema v1 through schema v4, an old broad schema, or\nrebuild-required readiness, leave the old database untouched and route the user\nto remove it explicitly before `sp-map-scan -> sp-map-build`.\nWhen writing the recommendation in plain text, use: run sp-map-scan -> sp-map-build.\n\n## Path Index Source Contract\n\nbuild-from-scan creates DB path_index rows from nodes.json `paths`. It does not read `attrs_json.path`, raw node metadata, `repository-universe.json`, `scan-targets.json`, or `coverage.json` as path-index sources.\ncoverage.json rows without matching node paths are recorded as rejected coverage with reason `no_node_relation`. Inventory-only and excluded rows do not need path_index rows and must not be inserted into nodes solely to satisfy raw path-count coverage. If `validate-build` reports\n`active_generation_has_no_path_index_rows`, route back to `sp-map-scan` to repair\nnode `paths` in the scan package instead of inserting SQL manually.\n\n## Output Contract\n\nThe only canonical runtime outputs for this command are:\n\n- `.specify\u002Fproject-cognition\u002Fstatus.json`\n- `.specify\u002Fproject-cognition\u002Fproject-cognition.db`\n- query\u002Fupdate helper readiness metadata\n- join-point `worker-results` evidence for delegated build lanes until the leader accepts the final query-ready baseline\n- `.specify\u002Fproject-cognition\u002Fworkbench\u002Fworker-results\u002F\u003Cpacket-id>.json`\n\nDo not publish handbook-first runtime truth from this command. Do not publish raw graph JSON artifacts or slices as runtime truth.\n\n## Guardrails\n\n- Do not rebuild the scan from chat memory.\n- Do not guess and continue when required scan inputs are incomplete.\n- Do not treat raw scan prose or raw Markdown checklist items alone as accepted build evidence.\n- Do not accept packet results without inspected paths, evidence, and confidence.\n- Do not accept packet results whose `paths_read` is a boolean, summary flag, or anything other than a non-empty array of concrete paths.\n- Do not accept read\u002Fdeep_read packet results whose `evidence_ids` are missing from the scan evidence package or point only to a different `source_path`.\n- Do not accept orphan packet results that do not correspond to a `scan-packets\u002F\u003Clane-id>.md` input packet.\n- Do not perform a structural-only refresh and call it success.\n- Do not accept manual SQL, sqlite shell scripting, hand-picked node subsets, or leader-memory graph reconstruction as normal build paths.\n- Do not locally patch around contract-invalid or systemic scan packet failures.\n- If the build lane cannot be safely packetized or delegated, record `subagent-blocked` and stop for escalation or recovery.\n- If a delegated lane returns unresolved evidence gaps, preserve the scan gap report and stop for escalation or recovery instead of inventing closure.\n\n## Project Cognition Workbench State Protocol\n\n- Project Map State Protocol remains active during build acceptance.\n- Validate Scan Inputs Before Execution.\n- Compile And Validate MapBuildPacket Inputs.\n- Treat `coverage-ledger.json` as the machine-readable row source.\n- `MapBuildPacket` is required for delegated build lanes.\n- Raw scan prose or raw Markdown checklist items alone are insufficient.\n- raw scan prose or raw Markdown checklist items alone\n- Packet evidence intake must reject packet results without paths read.\n- Packet evidence intake must require `paths_read` to be a non-empty array of concrete paths, not `true` or another summary flag.\n- Packet evidence intake must reject packet results that only summarize without evidence.\n- Packet evidence intake must reject non-`pass` packet outcomes until the scan lane is repacked, repaired, or recorded as an explicit unresolved gap.\n- derived-only evidence is insufficient for final graph acceptance.\n- Structural-only refresh is a failed build.\n- The build phase is not a scaffold, migration, or file-moving command.\n- Treat scan artifacts as inputs, not evidence, until packet evidence is accepted.\n- `.specify\u002F**` inputs are workbench\u002Fcontrol artifacts, not graph evidence rows.\n- DB publication must not write `.specify\u002F**` into `evidence.source_path`, `path_index.path`, or `alias_index` target material.\n- Build intake must reject `.cognitionignore`-excluded paths from scan coverage, evidence rows, provisional nodes, provisional edges, observations, packet results, and `repository-universe.json` included paths.\n- DB publication must not write `.cognitionignore`-excluded paths into `evidence.source_path`, `path_index.path`, or `alias_index` target material.\n- DB publication must not write raw inventory-only paths into `evidence.source_path`, `nodes.paths`, `path_index.path`, `alias_index`, route rows, or `minimal_live_reads` unless the path was promoted by `scan-targets.json` and backed by accepted evidence.\n\n## Build Duties\n\n`sp-map-build` must:\n\n- begins with validation, not writing\n- validate scan completeness for graph reconstruction through the value-weighted target set\n- validate that `scan-targets.json` selects high-value graph evidence and keeps low-value inventory-only surfaces out of graph publication\n- deduplicate provisional nodes into graph nodes\n- convert candidate edges into validated graph edges\n- build schema v5 `alias_index` rows from alias-ready node titles, types, paths, and bounded attrs\n- compile optional graph claim candidates, validate all node\u002Fevidence references, derive lifecycle state, and persist claim evidence, verification, and transition rows atomically with the generation\n- assign node, edge, observation, path, and alias confidence\n- publish queryable task-oriented bundles for downstream agent work\n- produce workflow-operational reachability validation\n- produce reverse coverage validation\n- project graph truth into retrieval outputs by building evidence-backed route rows\n- preserve compatibility `query_examples` only as non-readiness route examples when present\n- synthesize `concept_candidates` from graph-backed aliases, ownership,\n  capabilities, symptoms, generated surfaces, and verification routes\n- publish `route_pack` entries that connect selected concepts to owners,\n  consumers, affected paths, verification routes, conflicts, and\n  `minimal_live_reads`\n- do not rebuild the scan from chat memory\n- must not guess and continue when required scan inputs are incomplete\n- must reject `.cognitionignore`-excluded paths before graph reconstruction; if scan artifacts contain them, return a scan gap report instead of publishing runtime truth\n- must reject raw inventory-only paths before graph reconstruction unless they were promoted by `scan-targets.json` and backed by accepted evidence\n- maintain a scan gap report when unresolved critical rows remain in the graph-eligible set\n\nThe build must keep graph truth projection explicit: every route row that feeds\n`concept_candidates`, `query_examples`, or `route_pack` must be evidence-backed,\ntraceable to accepted scan evidence, and rejectable when confidence, ownership,\nor route semantics are weak.\n\n## Consequence Substrate Synthesis\n\n`sp-map-build` must synthesize consequence-analysis substrate from scan evidence so downstream workflows can query dependency impact without rebuilding the map:\n\n- owner edges for files, modules, commands, APIs, templates, generated assets, state files, and verification entry points\n- consumer edges for direct callsites, generated-surface propagation, adjacent workflows, user-facing commands, and automation\u002Fruntime entry points\n- lifecycle\u002Fstate edges for active actors, running work, queues, sessions, locks, caches, persisted state, cleanup, retry, rollback, and idempotency behavior\n- shared-state and destructive-operation edges where close\u002Fdelete\u002Farchive\u002Frename\u002Fmigrate actions can affect members, consumers, or in-flight work\n- verification-route records for the checks that prove owners, consumers, state transitions, and recovery behavior\n- known-unknown, stale-route, confidence, and `minimal_live_reads` records that `sp-map-update` can preserve or narrow incrementally\n\nThe resulting query-backed runtime must be able to answer which owners, consumers, state surfaces, generated surfaces, and verification routes are implicated by a changed path or requested behavior.\n\n## Required Graph Semantics\n\nEvery accepted schema v5 graph build must make room for:\n\n- nodes\n- edges\n- observations\n- path_index\n- alias_index\n- updates\n- queryable task-local bundles\n\nThe alias catalog must be route vocabulary backed by `alias_index` rows. It helps\nnormalize user input into project vocabulary; it is not evidence by itself.\n\n## Dispatch Guidance\n\n- Use `choose_subagent_dispatch(command_name=\"map-build\", snapshot, workload_shape)` before lane execution.\n- Dispatch each build lane from a validated `MapBuildPacket`.\n- Recommended build lanes include DB normalization, alias readiness review, route validation, and queryable task-local bundle generation.\n- The leader owns final graph consistency and readiness state.\n\n## Completion Rule\n\nBefore reporting completion:\n\n- run `C:\\Users\\11034\\.specify\\bin\\project-cognition.exe validate-scan --format json` before graph import\n- run `C:\\Users\\11034\\.specify\\bin\\project-cognition.exe build-from-scan --format json`; if it returns `status=blocked`, report its `errors`, identity reconciliation details from `identity_reconciliation`, `rejections`, `merge_records`, and `recovery_action`\n- run `C:\\Users\\11034\\.specify\\bin\\project-cognition.exe validate-build --format json` after `build-from-scan`\n- report completion only after `validate-build` returns `status=ok` and `readiness=query_ready`\n- confirm that `.specify\u002Fproject-cognition\u002Fproject-cognition.db` was written and can be queried through `C:\\Users\\11034\\.specify\\bin\\project-cognition.exe compass --intent implement --query=\\\"$ARGUMENTS\\\" --format json`. Read top-level `minimal_live_reads` first, then use lane-level `first_pass_paths`, `claim_refs`, `coverage_diagnostics`, and `before_fix_claim`. 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. Do not infer final edit scope from first-pass reads or graph claims.\n- confirm claim-aware routing preserves the bounded rerank contract: `match_score` alone establishes candidate eligibility; `claim_ranking.adjustment` cannot create candidates and cannot replace live verification. Fresh supported or graph-generation-verified claims add at most `+1`; stale and contradicted claims subtract `-1` and `-2`. `stale_claim_signal` and `contradicted_claim_signal` must keep the packet `usable_with_review` and route through `reconcile_claims_with_minimal_live_reads` plus lane-specific live repository reconciliation.\n- preserve the advanced `lexicon -> semantic_intake -> query` flow for explicit concept decisions or unresolved coverage. In that escalation, write `semantic_intake` from the alias catalog, select candidates by facet coverage, write `concept_decisions` with `covered_facets`, `missing_facets`, and `match_sources`, carry `lexicon_generation_id`, add `repository_search_terms`, and run `C:\\Users\\11034\\.specify\\bin\\project-cognition.exe query --intent implement --query-plan \\\"\u003Cquery_plan_json>\\\" --format json`. Agent-owned semantic normalization is mandatory: raw lexicon ranking and `agent_normalization` are only bootstrap signals, not route decisions. If `agent_normalization.required=true`, every raw candidate is `score=0`, or the prompt is localized, mixed-language, CJK, colloquial, symptom-first, or mixed-language or CJK text, extract embedded project terms and write `semantic_intake` from the alias catalog before selecting or rejecting concepts. If `agent_normalization` is omitted, treat it as `required=false`; CJK or mixed CJK\u002FASCII input still requires agent normalization even when positive raw lexical matches exist because embedded project tokens do not translate the surrounding user language. The agent still owns translation; `agent_normalization` is advisory guidance, not a route decision. (raw lexicon ranking is only a bootstrap; action: write_semantic_intake_from_alias_catalog) Derive project-language search terms from the alias catalog before source search. Do not search only the raw user words; include component names, state names, file names, command names, UI labels, and route names from candidates, aliases, matched_terms, colloquial_matches, returned paths, `normalized_query`, and `expanded_queries`. Use these project-language search terms before broad repository search\n- if `validate-build` returns `status=blocked`, report the specific DB, schema, active generation, status, or smoke-query error and do not mark the baseline fresh\n- confirm that `status.json` reflects a query-ready baseline\n- confirm that the runtime remains query-backed and does not advertise raw graph JSON or handbook-first outputs as runtime truth\n- report whether follow-on localized maintenance should continue through `map-update` for future touched-area drift\n- every `critical` row is covered by active runtime path and route indexes\n- every `important` row is reachable through active runtime path and route indexes when graph-eligible\n- every `P0`\u002F`P1` row with `scan_decision=scan` is covered by accepted evidence and active runtime path or route indexes\n- every `P3`, `inventory_only`, or `excluded` row remains out of graph-facing runtime outputs unless explicitly promoted with accepted evidence\n- every scan packet is consumed\n- every accepted packet result has paths read and confidence\n- every runtime node, edge, observation, path row, and alias row is backed by accepted packet evidence where the row requires evidence\n- query bundle and route reachability are validated through runtime query surfaces\n- no final report claims success for a structural-only refresh\n- `map_state_file` records accepted packet results\n- owner, consumer, change propagation, and verification routes remain explicit\n- known unknowns or known-unknowns remain visible\n- the excluded bucket has a reason and revisit condition\n- every critical shared surface can be discovered through runtime query surfaces\n- every key verification entry point can be located through runtime query surfaces\n- required_reads contain only reference-only or hard-excluded exceptions when runtime compatibility outputs are mentioned\n\n## Claude Code Map 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- Keep map packet\u002Fresult schemas from this workflow authoritative; do not substitute implementation `WorkerTaskResult` fields for map scan\u002Fbuild\u002Fupdate packet contracts.\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 scan baseline exists and the project cognition runtime must be built or rebuilt from that evidence.\n- **Primary objective**: Validate value-weighted scan evidence, reconstruct graph nodes, edges, observations, typed graph claims, path indexes, and alias indexes from high-value evidence into the schema v5 SQLite cognition database, derive revisioned claim lifecycle state, assign confidence, and publish queryable task-oriented cognition bundles.\n- **Primary outputs**: `.specify\u002Fproject-cognition\u002Fstatus.json`, `.specify\u002Fproject-cognition\u002Fproject-cognition.db`, and query\u002Fupdate helper readiness metadata.\n- **Default handoff**: Return to the blocked brownfield workflow once the query-backed cognition baseline is ready.\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\nReconstruct or refresh the query-backed project cognition runtime from a completed evidence baseline.\n\n## Context\n\n- Primary inputs: `.specify\u002Fproject-cognition\u002Fstatus.json`, `.specify\u002Fproject-cognition\u002Fevidence\u002F`, `.specify\u002Fproject-cognition\u002Fprovisional\u002Fnodes.json`, `.specify\u002Fproject-cognition\u002Fprovisional\u002Fedges.json`, `.specify\u002Fproject-cognition\u002Fprovisional\u002Fobservations.json`, and live repository evidence.\n- This command owns the query-backed cognition runtime outputs: `.specify\u002Fproject-cognition\u002Fstatus.json` and `.specify\u002Fproject-cognition\u002Fproject-cognition.db`.\n- Run `C:\\Users\\11034\\.specify\\bin\\project-cognition.exe build-from-scan --format json` after scan and package validation. It adapts the accepted canonical scan package into a versioned proposal and runs the deterministic cognition proposal compiler before any graph-store mutation; only a publishable result may continue to DB import, metadata, status publication, and DB\u002Fstatus agreement.\n- Treat `compilation.publication_allowed=false` as a hard pre-publication block and stop without creating, archiving, replacing, or publishing the graph store.\n- Successful compilation preserves advisory graph material as route candidates rather than repository facts; prove behavioral claims from live repository evidence.\n- [AGENT] Treat sparse path-index gates as build preflight; do not publish query-ready status when `validate-build` would fail `path_index_to_included_ratio`, critical path, or important path checks.\n- Do not construct `.specify\u002Fproject-cognition\u002Fproject-cognition.db` with manual SQL as the normal workflow path.\n- If the evidence baseline is incomplete or the accepted evidence cannot support graph reconstruction, produce a scan gap report and return to `sp-map-scan`.\n- If scan packet intake exposes contract-invalid, systemic packet-family failures, or `paths_read` values that are not concrete path arrays, preserve the scan gap report and route back to `sp-map-scan`; this is not only a local patch in build.\n- Record accepted and rejected reconstruction evidence as DB\u002Fruntime update records and queryable task-local bundle readiness metadata. Treat any raw graph or slice files as compatibility\u002Fexport artifacts, not runtime truth.\n- Apply project cognition ignore rules from root `.cognitionignore` and `.specify\u002Fproject-cognition\u002F.cognitionignore`; rejected paths remain outside graph evidence and DB route indexes even when scan artifacts mention them.\n- Validate `repository-universe.json` as the canonical scan boundary before graph reconstruction; excluded paths are boundary facts, not graph evidence.\n- If native subagent dispatch is unavailable or a substantive build lane cannot complete, persist `subagent_blocked` in machine-readable state and block baseline activation until recovery. `coverage-ledger.json.open_gaps[]` may use `low_risk_open_gap` only with owner, reason, evidence expectation, and revisit condition.\n\n[AGENT] For project-cognition-backed semantic intake, routing, audit, resume, or final-claim gates, read `references\u002Fsemantic-work-contract.md`.\n\n## Detailed References\n\nRead [Reference index](references\u002FINDEX.md) before applying shared semantic contracts.\n\n- [semantic work contract](references\u002Fsemantic-work-contract.md)\n\n## Mandatory Subagent Execution\n\nAll substantive tasks in ordinary `sp-*` workflows default to and must use subagents.\n\nThe leader orchestrates: route, split tasks, prepare task contracts, dispatch subagents, wait for structured handoffs, integrate results, verify, and update state.\n\nBefore dispatch, every subagent lane needs a task contract with objective, authoritative inputs, allowed read\u002Fwrite scope, forbidden paths, acceptance checks, verification evidence, and structured handoff format.\n\nUse `execution_model: subagent-mandatory`.\nUse `dispatch_shape: one-subagent | parallel-subagents`.\nUse `execution_surface: native-subagents`.\n\n## Objective\n\nReconstruct or refresh the query-backed project cognition runtime from a completed value-weighted evidence baseline.\n\n## Project Learning\n\nThe CLI is the only agent-facing Learning read surface:\n\n1. Run `uvx --from git+https:\u002F\u002Fgithub.com\u002Fchenziyang110\u002Fspec-kit-plus.git@4a631657f75460886dbd12ebe48b14fc11cfe0bf specify learning start --command \u003Cclassic-command-name> --format json` before deeper non-trivial work.\n2. Select summaries by applicability and triggers; use `uvx --from git+https:\u002F\u002Fgithub.com\u002Fchenziyang110\u002Fspec-kit-plus.git@4a631657f75460886dbd12ebe48b14fc11cfe0bf specify learning list --command \u003Cclassic-command-name> --format json` only to filter or page.\n3. Execute one matching card's `show_argv`. Do not parse Learning storage.\n\n`start`, `list`, and `show` are read-only. Current repository evidence,\n`.specify\u002Fmemory\u002Fconstitution.md`, and explicit user direction override stale or\ncandidate Learning.\n\nAt closeout, corrections, retries, route changes, recovery, false leads, hidden\ndependencies, validation\u002Ftooling\u002Fstate\u002Fcognition gaps, constraints, and near\nmisses are capture signals. Prefer `uvx --from git+https:\u002F\u002Fgithub.com\u002Fchenziyang110\u002Fspec-kit-plus.git@4a631657f75460886dbd12ebe48b14fc11cfe0bf specify learning capture-auto`\nfrom owning state; manual capture includes summary, problem, action, triggers,\nsuccess criteria, avoid items, exceptions, and evidence.\n\n- `fast`: skip unless the task escalates.\n- `accept`, `analyze`, `ask`, `auto`, `constitution`, `explain`,\n  `implement-teams`, `taskstoissues`, and `team`: consume-only; do not violate\n  their write boundaries to capture.\n- Other non-trivial workflows: consume before deeper work; capture reusable\n  signals at closeout or record a no-learning decision.\n\nThe `policy` returned by the CLI is authoritative when prompt wording drifts.\n\n## Process\n\n- Start with validation, not writing.\n- Update `map-state.md` before long-running reconstruction, join-point acceptance, compaction-risk transitions, or any stop where resume will depend on more than the visible conversation.\n- Validate scan inputs before execution and compile\u002Fvalidate `MapBuildPacket` inputs before dispatch.\n- Validate both `.specify\u002Fproject-cognition\u002Fworkbench\u002Frepository-universe.json` and `.specify\u002Fproject-cognition\u002Fworkbench\u002Fscan-targets.json` before graph import. `repository-universe.json` is full path accounting; `scan-targets.json` is the high-value execution target set.\n- Treat `P0`\u002F`P1` `scan_decision=scan` rows as graph-build candidates that must be backed by accepted packet evidence before they can publish queryable runtime truth.\n- Treat `P2` rows according to their recorded `scan_decision`: scanned or sampled rows can support graph truth when evidence-backed; inventory-only rows remain boundary accounting.\n- Treat `P3`, `inventory_only`, and `excluded` rows as boundary accounting only unless explicit accepted scan evidence and a high-value reason promote them. Do not derive graph, path_index, alias_index, route rows, or `minimal_live_reads` from raw inventory-only rows.\n- Dispatch only validated packetized build lanes as `one-subagent` or `parallel-subagents`.\n- If overlap, missing packet data, missing required references, or unsafe acceptance criteria prevent safe dispatch, record `subagent-blocked` and stop for escalation or recovery.\n- Run `C:\\Users\\11034\\.specify\\bin\\project-cognition.exe validate-scan --format json` before graph import.\n- Run `C:\\Users\\11034\\.specify\\bin\\project-cognition.exe build-from-scan --format json` after scan and package validation. It adapts the accepted canonical scan package into a versioned proposal and runs the deterministic cognition proposal compiler before any graph-store mutation, then rebuilds the graph store into schema v5 and owns DB import, metadata, status publication, and DB\u002Fstatus agreement.\n- Treat `compilation.publication_allowed=false` as a hard pre-publication block. Report the bounded compiler conflicts and stop without creating, archiving, replacing, or publishing a graph store.\n- A successful compile means the proposal is structurally safe and deterministic enough to publish as advisory graph material. Compiled nodes, edges, paths, aliases, and graph claims remain route candidates rather than repository facts; even `verified_in_graph_generation` requires bounded live repository evidence before behavioral or workflow final claims.\n- If `build-from-scan` returns `status=blocked`, report its `errors`, identity reconciliation details from `identity_reconciliation`, `rejections`, `merge_records`, and `recovery_action` and do not proceed to build validation.\n- Run `C:\\Users\\11034\\.specify\\bin\\project-cognition.exe validate-build --format json` after `build-from-scan`.\n\n## Machine-Readable Blocked State\n\nHuman workflow prose may say `subagent-blocked`, but persisted machine fields use\n`subagent_blocked`.\n\nIf a substantive scan\u002Fbuild lane cannot dispatch or complete, write:\n\n- `.specify\u002Fproject-cognition\u002Fstatus.json` with `baseline_state=blocked` and\n  `subagent_blocked` in `stale_reasons` or `dirty_reasons`\n- `.specify\u002Fproject-cognition\u002Fworkbench\u002Fmap-state.md` with\n  `readiness=blocked`, `blocking_reason=subagent_blocked`, blocked lane ids,\n  blocked scope, and recovery condition\n- `.specify\u002Fproject-cognition\u002Fworkbench\u002Fcoverage-ledger.json.open_gaps[]` with\n  `reason=\"subagent_blocked\"`, `lane_id`, `packet_id`, `blocked_scope`,\n  `criticality`, `owner`, `status=\"blocked\"`, and `recovery_condition`\n\n`unknown` blocks, `blocked`, `critical_open_gap`, and `subagent_blocked` block baseline\nactivation. `low_risk_open_gap` may pass only with owner, reason,\n`evidence_expectation`, and `revisit_condition`.\n\n## Hard Boundary\n\n- `sp-map-build` is the command that publishes query-backed cognition truth.\n- `sp-map-build` must not fall back to handbook-first runtime output.\n- `sp-map-build` owns schema v5 SQLite runtime publication, confidence assignment, revisioned typed graph-claim lifecycle derivation, route validation, reconciliation-basis support, and alias catalog readiness.\n- Existing narratives may inform continuity, but final runtime rows must be backed by scan evidence. Map points, code proves: the alias catalog is route vocabulary, not evidence by itself.\n\n## Required Inputs\n\nBefore writing query-backed truth, read:\n\n- `.specify\u002Fproject-cognition\u002Fstatus.json`\n- `.specify\u002Fproject-cognition\u002Fevidence\u002F`\n- `.specify\u002Fproject-cognition\u002Fprovisional\u002Fnodes.json`\n- `.specify\u002Fproject-cognition\u002Fprovisional\u002Fedges.json`\n- `.specify\u002Fproject-cognition\u002Fprovisional\u002Fobservations.json`\n- optional `.specify\u002Fproject-cognition\u002Fprovisional\u002Fclaims.json`\n- `.specify\u002Fproject-cognition\u002Fcoverage.json`\n- `.specify\u002Fproject-cognition\u002Fworkbench\u002Frepository-universe.json`\n- `.specify\u002Fproject-cognition\u002Fworkbench\u002Fscan-targets.json`\n- `.specify\u002Fproject-cognition\u002Fworkbench\u002Fcoverage-ledger.json`\n- `.specify\u002Fproject-cognition\u002Fworkbench\u002Fscan-queue.json`\n- `.specify\u002Fproject-cognition\u002Fworkbench\u002Fhandoff-ledger.json`\n- `.specify\u002Fproject-cognition\u002Fworkbench\u002Fscan-packets\u002F`\n\nIf those artifacts are missing, stop and route back to `\u002Fsp-map-scan`.\n\n## Boundary Acceptance\n\n`sp-map-build` must validate `.specify\u002Fproject-cognition\u002Fworkbench\u002Frepository-universe.json` and `.specify\u002Fproject-cognition\u002Fworkbench\u002Fscan-targets.json` before publishing runtime truth.\n\n- Every `included_paths` entry in `repository-universe.json` must have one explicit boundary disposition: `deep_read`, `sampled`, `inventory_only`, `excluded`, or `blocked`.\n- For graph-eligible selected paths, every included path is represented in scan coverage or an accepted gap.\n- Every `selected_paths` entry in `scan-targets.json` must appear in `coverage.json`, `coverage-ledger.json`, or an accepted non-blocking gap.\n- Every `P0` or `P1` row with `scan_decision=scan` must have accepted packet evidence before runtime publication, or the build must return a scan gap report and route back to `sp-map-scan`.\n- `P2` rows may be sampled or inventory-only only when `scan-targets.json` records the lower-depth decision and `coverage-ledger.json` preserves the evidence expectation and revisit condition.\n- `P3`, `inventory_only`, and `excluded` rows are not missing graph evidence. They are complete only as boundary accounting and must not inflate graph-readiness failure counts.\n- Every `excluded_paths` entry must stay only in the boundary artifact or grouped exclusion ledger.\n- Excluded paths are represented only by the boundary artifact or grouped accounting ledgers, not by graph-facing coverage rows. Inventory-only paths follow the same boundary-accounting rule unless explicitly promoted.\n- Excluded paths must not appear in graph-facing coverage rows, evidence rows, provisional graph rows, DB path indexes, route indexes, alias indexes, or `minimal_live_reads`. Inventory-only paths follow the same rule unless the scan target explicitly promoted them with accepted evidence.\n- If repository-universe, scan-targets, coverage, and packet handoffs cannot explain the same selected path universe, return a scan gap report and route back to `sp-map-scan`.\n- If scan packet acceptance reports `fail_contract` or `fail_systemic`, route back to `sp-map-scan` with a scan gap report because the repair is not only a local patch.\n- `path_index_to_included_ratio` must be computed from graph-eligible paths: selected `P0`\u002F`P1` paths plus evidence-backed selected `P2` paths, minus true exclusions and `accepted_nonblocking_gap_paths`.\n- Critical and important graph-eligible paths must remain in the sparse path-index denominator unless they are true repository-universe exclusions or explicitly accepted nonblocking gaps.\n- `build-from-scan` must not set `freshness=fresh`, must not set `readiness=query_ready`, and must not set `graph_ready=true` until sparse path-index gates pass.\n\n## Schema V5 Runtime Contract\n\nSchema v5 is current-only. `project-cognition build-from-scan --format json`\ncreates schema v5 only for a missing database or consumes a complete current\nschema v5 database. The current runtime does not migrate schema v4 or older\ndatabases and does not archive or replace them. Remove the incompatible project-cognition.db\nexplicitly, then run `sp-map-scan -> sp-map-build` with the current binary.\nSchema v5 keeps the\nimplemented runtime tables: `metadata`, `generations`, `evidence`, `nodes`,\n`node_evidence`, `edges`, `edge_evidence`, `observations`,\n`observation_evidence`, `path_index`, `alias_index`, `claims`, `claim_evidence`,\n`claim_verifications`, `claim_transitions`, `claim_reconciliations`, and `updates`.\n\nConflicts, symbols, entrypoints, tests, slices, query examples, FTS tables, and compatibility `query_examples` are not current readiness requirements.\n\nGraph claims use `graph_claim_type` and a compiler-derived lifecycle state:\n`candidate`, `supported`, `verified_in_graph_generation`, `contradicted`, or\n`stale`. `claim_evidence` records supporting and contradicting evidence,\n`claim_verifications` records bounded verification inputs, and\n`claim_transitions` makes lifecycle changes auditable. Schema v5 also records\n`claim_reconciliations`; `claim_evidence.basis_state` distinguishes the current\nevidence basis used for routing from superseded or historical evidence. An Agent-provided\n`requested_state` is never authoritative. `verified_in_graph_generation` means\nonly that the active graph generation contains supporting evidence and a current\npassed graph verification; it is not current repository truth and never grants\nworkflow authorization or final claim readiness.\n\nFor brownfield baselines, `alias_index` is required: every active node must have\nat least one active-generation alias row, no alias may point at a missing node,\nand no alias may reference a missing non-empty evidence id. The schema v5 alias\ncatalog helps agents normalize user input before query planning; it does not prove behavior\nwithout live repository evidence.\n\nIf validation reports schema v1 through schema v4, an old broad schema, or\nrebuild-required readiness, leave the old database untouched and route the user\nto remove it explicitly before `sp-map-scan -> sp-map-build`.\nWhen writing the recommendation in plain text, use: run sp-map-scan -> sp-map-build.\n\n## Path Index Source Contract\n\nbuild-from-scan creates DB path_index rows from nodes.json `paths`. It does not read `attrs_json.path`, raw node metadata, `repository-universe.json`, `scan-targets.json`, or `coverage.json` as path-index sources.\ncoverage.json rows without matching node paths are recorded as rejected coverage with reason `no_node_relation`. Inventory-only and excluded rows do not need path_index rows and must not be inserted into nodes solely to satisfy raw path-count coverage. If `validate-build` reports\n`active_generation_has_no_path_index_rows`, route back to `sp-map-scan` to repair\nnode `paths` in the scan package instead of inserting SQL manually.\n\n## Output Contract\n\nThe only canonical runtime outputs for this command are:\n\n- `.specify\u002Fproject-cognition\u002Fstatus.json`\n- `.specify\u002Fproject-cognition\u002Fproject-cognition.db`\n- query\u002Fupdate helper readiness metadata\n- join-point `worker-results` evidence for delegated build lanes until the leader accepts the final query-ready baseline\n- `.specify\u002Fproject-cognition\u002Fworkbench\u002Fworker-results\u002F\u003Cpacket-id>.json`\n\nDo not publish handbook-first runtime truth from this command. Do not publish raw graph JSON artifacts or slices as runtime truth.\n\n## Guardrails\n\n- Do not rebuild the scan from chat memory.\n- Do not guess and continue when required scan inputs are incomplete.\n- Do not treat raw scan prose or raw Markdown checklist items alone as accepted build evidence.\n- Do not accept packet results without inspected paths, evidence, and confidence.\n- Do not accept packet results whose `paths_read` is a boolean, summary flag, or anything other than a non-empty array of concrete paths.\n- Do not accept read\u002Fdeep_read packet results whose `evidence_ids` are missing from the scan evidence package or point only to a different `source_path`.\n- Do not accept orphan packet results that do not correspond to a `scan-packets\u002F\u003Clane-id>.md` input packet.\n- Do not perform a structural-only refresh and call it success.\n- Do not accept manual SQL, sqlite shell scripting, hand-picked node subsets, or leader-memory graph reconstruction as normal build paths.\n- Do not locally patch around contract-invalid or systemic scan packet failures.\n- If the build lane cannot be safely packetized or delegated, record `subagent-blocked` and stop for escalation or recovery.\n- If a delegated lane returns unresolved evidence gaps, preserve the scan gap report and stop for escalation or recovery instead of inventing closure.\n\n## Project Cognition Workbench State Protocol\n\n- Project Map State Protocol remains active during build acceptance.\n- Validate Scan Inputs Before Execution.\n- Compile And Validate MapBuildPacket Inputs.\n- Treat `coverage-ledger.json` as the machine-readable row source.\n- `MapBuildPacket` is required for delegated build lanes.\n- Raw scan prose or raw Markdown checklist items alone are insufficient.\n- raw scan prose or raw Markdown checklist items alone\n- Packet evidence intake must reject packet results without paths read.\n- Packet evidence intake must require `paths_read` to be a non-empty array of concrete paths, not `true` or another summary flag.\n- Packet evidence intake must reject packet results that only summarize without evidence.\n- Packet evidence intake must reject non-`pass` packet outcomes until the scan lane is repacked, repaired, or recorded as an explicit unresolved gap.\n- derived-only evidence is insufficient for final graph acceptance.\n- Structural-only refresh is a failed build.\n- The build phase is not a scaffold, migration, or file-moving command.\n- Treat scan artifacts as inputs, not evidence, until packet evidence is accepted.\n- `.specify\u002F**` inputs are workbench\u002Fcontrol artifacts, not graph evidence rows.\n- DB publication must not write `.specify\u002F**` into `evidence.source_path`, `path_index.path`, or `alias_index` target material.\n- Build intake must reject `.cognitionignore`-excluded paths from scan coverage, evidence rows, provisional nodes, provisional edges, observations, packet results, and `repository-universe.json` included paths.\n- DB publication must not write `.cognitionignore`-excluded paths into `evidence.source_path`, `path_index.path`, or `alias_index` target material.\n- DB publication must not write raw inventory-only paths into `evidence.source_path`, `nodes.paths`, `path_index.path`, `alias_index`, route rows, or `minimal_live_reads` unless the path was promoted by `scan-targets.json` and backed by accepted evidence.\n\n## Build Duties\n\n`sp-map-build` must:\n\n- begins with validation, not writing\n- validate scan completeness for graph reconstruction through the value-weighted target set\n- validate that `scan-targets.json` selects high-value graph evidence and keeps low-value inventory-only surfaces out of graph publication\n- deduplicate provisional nodes into graph nodes\n- convert candidate edges into validated graph edges\n- build schema v5 `alias_index` rows from alias-ready node titles, types, paths, and bounded attrs\n- compile optional graph claim candidates, validate all node\u002Fevidence references, derive lifecycle state, and persist claim evidence, verification, and transition rows atomically with the generation\n- assign node, edge, observation, path, and alias confidence\n- publish queryable task-oriented bundles for downstream agent work\n- produce workflow-operational reachability validation\n- produce reverse coverage validation\n- project graph truth into retrieval outputs by building evidence-backed route rows\n- preserve compatibility `query_examples` only as non-readiness route examples when present\n- synthesize `concept_candidates` from graph-backed aliases, ownership,\n  capabilities, symptoms, generated surfaces, and verification routes\n- publish `route_pack` entries that connect selected concepts to owners,\n  consumers, affected paths, verification routes, conflicts, and\n  `minimal_live_reads`\n- do not rebuild the scan from chat memory\n- must not guess and continue when required scan inputs are incomplete\n- must reject `.cognitionignore`-excluded paths before graph reconstruction; if scan artifacts contain them, return a scan gap report instead of publishing runtime truth\n- must reject raw inventory-only paths before graph reconstruction unless they were promoted by `scan-targets.json` and backed by accepted evidence\n- maintain a scan gap report when unresolved critical rows remain in the graph-eligible set\n\nThe build must keep graph truth projection explicit: every route row that feeds\n`concept_candidates`, `query_examples`, or `route_pack` must be evidence-backed,\ntraceable to accepted scan evidence, and rejectable when confidence, ownership,\nor route semantics are weak.\n\n## Consequence Substrate Synthesis\n\n`sp-map-build` must synthesize consequence-analysis substrate from scan evidence so downstream workflows can query dependency impact without rebuilding the map:\n\n- owner edges for files, modules, commands, APIs, templates, generated assets, state files, and verification entry points\n- consumer edges for direct callsites, generated-surface propagation, adjacent workflows, user-facing commands, and automation\u002Fruntime entry points\n- lifecycle\u002Fstate edges for active actors, running work, queues, sessions, locks, caches, persisted state, cleanup, retry, rollback, and idempotency behavior\n- shared-state and destructive-operation edges where close\u002Fdelete\u002Farchive\u002Frename\u002Fmigrate actions can affect members, consumers, or in-flight work\n- verification-route records for the checks that prove owners, consumers, state transitions, and recovery behavior\n- known-unknown, stale-route, confidence, and `minimal_live_reads` records that `sp-map-update` can preserve or narrow incrementally\n\nThe resulting query-backed runtime must be able to answer which owners, consumers, state surfaces, generated surfaces, and verification routes are implicated by a changed path or requested behavior.\n\n## Required Graph Semantics\n\nEvery accepted schema v5 graph build must make room for:\n\n- nodes\n- edges\n- observations\n- path_index\n- alias_index\n- updates\n- queryable task-local bundles\n\nThe alias catalog must be route vocabulary backed by `alias_index` rows. It helps\nnormalize user input into project vocabulary; it is not evidence by itself.\n\n## Dispatch Guidance\n\n- Use `choose_subagent_dispatch(command_name=\"map-build\", snapshot, workload_shape)` before lane execution.\n- Dispatch each build lane from a validated `MapBuildPacket`.\n- Recommended build lanes include DB normalization, alias readiness review, route validation, and queryable task-local bundle generation.\n- The leader owns final graph consistency and readiness state.\n\n## Completion Rule\n\nBefore reporting completion:\n\n- run `C:\\Users\\11034\\.specify\\bin\\project-cognition.exe validate-scan --format json` before graph import\n- run `C:\\Users\\11034\\.specify\\bin\\project-cognition.exe build-from-scan --format json`; if it returns `status=blocked`, report its `errors`, identity reconciliation details from `identity_reconciliation`, `rejections`, `merge_records`, and `recovery_action`\n- run `C:\\Users\\11034\\.specify\\bin\\project-cognition.exe validate-build --format json` after `build-from-scan`\n- report completion only after `validate-build` returns `status=ok` and `readiness=query_ready`\n- confirm that `.specify\u002Fproject-cognition\u002Fproject-cognition.db` was written and can be queried through `C:\\Users\\11034\\.specify\\bin\\project-cognition.exe compass --intent implement --query=\\\"$ARGUMENTS\\\" --format json`. Read top-level `minimal_live_reads` first, then use lane-level `first_pass_paths`, `claim_refs`, `coverage_diagnostics`, and `before_fix_claim`. 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. Do not infer final edit scope from first-pass reads or graph claims.\n- confirm claim-aware routing preserves the bounded rerank contract: `match_score` alone establishes candidate eligibility; `claim_ranking.adjustment` cannot create candidates and cannot replace live verification. Fresh supported or graph-generation-verified claims add at most `+1`; stale and contradicted claims subtract `-1` and `-2`. `stale_claim_signal` and `contradicted_claim_signal` must keep the packet `usable_with_review` and route through `reconcile_claims_with_minimal_live_reads` plus lane-specific live repository reconciliation.\n- preserve the advanced `lexicon -> semantic_intake -> query` flow for explicit concept decisions or unresolved coverage. In that escalation, write `semantic_intake` from the alias catalog, select candidates by facet coverage, write `concept_decisions` with `covered_facets`, `missing_facets`, and `match_sources`, carry `lexicon_generation_id`, add `repository_search_terms`, and run `C:\\Users\\11034\\.specify\\bin\\project-cognition.exe query --intent implement --query-plan \\\"\u003Cquery_plan_json>\\\" --format json`. Agent-owned semantic normalization is mandatory: raw lexicon ranking and `agent_normalization` are only bootstrap signals, not route decisions. If `agent_normalization.required=true`, every raw candidate is `score=0`, or the prompt is localized, mixed-language, CJK, colloquial, symptom-first, or mixed-language or CJK text, extract embedded project terms and write `semantic_intake` from the alias catalog before selecting or rejecting concepts. If `agent_normalization` is omitted, treat it as `required=false`; CJK or mixed CJK\u002FASCII input still requires agent normalization even when positive raw lexical matches exist because embedded project tokens do not translate the surrounding user language. The agent still owns translation; `agent_normalization` is advisory guidance, not a route decision. (raw lexicon ranking is only a bootstrap; action: write_semantic_intake_from_alias_catalog) Derive project-language search terms from the alias catalog before source search. Do not search only the raw user words; include component names, state names, file names, command names, UI labels, and route names from candidates, aliases, matched_terms, colloquial_matches, returned paths, `normalized_query`, and `expanded_queries`. Use these project-language search terms before broad repository search\n- if `validate-build` returns `status=blocked`, report the specific DB, schema, active generation, status, or smoke-query error and do not mark the baseline fresh\n- confirm that `status.json` reflects a query-ready baseline\n- confirm that the runtime remains query-backed and does not advertise raw graph JSON or handbook-first outputs as runtime truth\n- report whether follow-on localized maintenance should continue through `map-update` for future touched-area drift\n- every `critical` row is covered by active runtime path and route indexes\n- every `important` row is reachable through active runtime path and route indexes when graph-eligible\n- every `P0`\u002F`P1` row with `scan_decision=scan` is covered by accepted evidence and active runtime path or route indexes\n- every `P3`, `inventory_only`, or `excluded` row remains out of graph-facing runtime outputs unless explicitly promoted with accepted evidence\n- every scan packet is consumed\n- every accepted packet result has paths read and confidence\n- every runtime node, edge, observation, path row, and alias row is backed by accepted packet evidence where the row requires evidence\n- query bundle and route reachability are validated through runtime query surfaces\n- no final report claims success for a structural-only refresh\n- `map_state_file` records accepted packet results\n- owner, consumer, change propagation, and verification routes remain explicit\n- known unknowns or known-unknowns remain visible\n- the excluded bucket has a reason and revisit condition\n- every critical shared surface can be discovered through runtime query surfaces\n- every key verification entry point can be located through runtime query surfaces\n- required_reads contain only reference-only or hard-excluded exceptions when runtime compatibility outputs are mentioned\n\n## Claude Code Map 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- Keep map packet\u002Fresult schemas from this workflow authoritative; do not substitute implementation `WorkerTaskResult` fields for map scan\u002Fbuild\u002Fupdate packet contracts.\n",{"name":5,"metadata":24,"description":7,"argument-hint":27,"compatibility":28,"user-invocable":29},{"author":25,"source":26},"github-spec-kit","templates\u002Fcommands\u002Fmap-build.md","Optional scan package or atlas area to emphasize while building the project map","Requires spec-kit project structure with .specify\u002F directory",true,"main","021f5cbe02157229460a577e9a585f2da6d78cb0",".claude\u002Fskills\u002Fsp-map-build","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-map-build",{"tool":42,"command":43},"bunx","bunx skills add chenziyang110\u002Flaunchdeck --skill sp-map-build",{"tool":45,"command":46},"pnpm","pnpm dlx skills add chenziyang110\u002Flaunchdeck --skill sp-map-build","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fchenziyang110\u002Flaunchdeck\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fsp-map-build\u002FSKILL.md",[49,55],{"path":50,"resourceType":51,"resourceTypeDesc":52,"sizeBytes":53,"sourceHtmlUrl":54},"references\u002FINDEX.md","REFERENCE","参考文档",607,"https:\u002F\u002Fgithub.com\u002Fchenziyang110\u002Flaunchdeck\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fsp-map-build\u002Freferences\u002FINDEX.md",{"path":56,"resourceType":51,"resourceTypeDesc":52,"sizeBytes":57,"sourceHtmlUrl":58},"references\u002Fsemantic-work-contract.md",32216,"https:\u002F\u002Fgithub.com\u002Fchenziyang110\u002Flaunchdeck\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fsp-map-build\u002Freferences\u002Fsemantic-work-contract.md",[60,67,73,79,86,95],{"skillNo":61,"name":62,"nameZh":6,"description":63,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":64,"categories":65,"keywords":66,"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":68,"name":62,"nameZh":6,"description":69,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":70,"categories":71,"keywords":72,"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":74,"name":62,"nameZh":6,"description":75,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":76,"categories":77,"keywords":78,"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":80,"name":81,"nameZh":6,"description":82,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":83,"categories":84,"keywords":85,"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":87,"name":88,"nameZh":6,"description":89,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":90,"licenseFileUrl":91,"sourceHtmlUrl":92,"categories":93,"keywords":94,"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":96,"name":97,"nameZh":6,"description":98,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":99,"categories":100,"keywords":101,"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",[],[]]