[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6FXEDTBHBHTPV3396Z370K3":3,"skill-same:01M6FXEDTBHBHTPV3396Z370K3":73},{"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":39,"linkOnly":40,"markdownContent":41,"markdownBody":42,"frontMatter":43,"refName":49,"commitSha":50,"skillDirectory":51,"forksCount":52,"repositoryHtmlUrl":53,"repositoryHomepageUrl":54,"ownerHtmlUrl":55,"ownerBlogUrl":56,"ownerDescription":57,"updatedAt":58,"install":59,"resources":72},"01M6FXEDTBHBHTPV3396Z370K3","state-model",null,"Orchestrator — author the flow-anchored logical domain model (entities, state machines, events\u002Fcommands, read models, policies, logical contracts) from an approved user-flow map, running one domain-modeling framework per session, before UX variation work","GeorgeQLe\u002Fagentic-skills","GeorgeQLe","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F21134126?v=4","01M6D2JP418S0VGJGF8M93EC3H","George Le","01M6D2JPBAKYD82TA5FS6HKQ3D",1,"MIT","https:\u002F\u002Fgithub.com\u002FGeorgeQLe\u002Fagentic-skills\u002Fblob\u002Fmaster\u002Fpacks\u002Fproduct-design\u002Fclaude\u002Fstate-model\u002Farchive\u002Fv0.1\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"state model","model","state","contracts","events","state machines","feature","modeling","commands","synthesize","map","domain","v0","orchestrator","read","work","flow","chunk","framework","ux","2026-11-10 10:12:30",false,"---\nname: state-model\ndescription: Orchestrator — author the flow-anchored logical domain model (entities, state machines, events\u002Fcommands, read models, policies, logical contracts) from an approved user-flow map, running one domain-modeling framework per session, before UX variation work\ntype: research\nversion: v0.1\nargument-hint: \"[optional: topic, user-flow, or feature] [--synthesize] [--no-chunk]\"\ninvocation: orchestrator\ncontext_intake: scoped\nvisual_tier: visual\n---\n\n## Pack Availability Guard\n\nBefore telling the user to run a skill from another project-local pack, check `.agents\u002Fproject.json.enabled_packs`. If the target pack is not enabled, recommend `npx skillpacks install \u003Cpack>` from the project shell, instead of the target skill. Only the currently running skill and skills verified available in the active session or project-local install state are directly recommendable. For unavailable pack skills, recommend `npx skillpacks install \u003Cpack-or-skill>`; for unavailable base skills, recommend `npx skillpacks init` before the skill.\n\n# State Model — Orchestrator\n\nInvoke as `\u002Fstate-model`.\n\nThis is an **orchestrator skill** that authors the **logical** domain\u002Fstate\u002Flogic model anchored to an approved user-flow map, running **one domain-modeling framework per session** and synthesizing their outputs into a single canonical domain model plus a `model-tree` manifest. It sits **after `\u002Fuser-flow-map`, before `\u002Fux-variations`** in the product-design prototype pipeline.\n\nThe model it produces is a property of the *flow*, not of any one UI presentation: UX variations re-skin the same underlying entities, actions, and states, so authoring the logical model once gives `\u002Fux-variations` and `\u002Fui-interview` a real substrate to present, and turns `\u002Fspec-interview` into \"harden this model to production\" rather than \"invent it.\"\n\n**Logical only.** This skill owns entities, value objects, aggregates, state machines, events, commands, read models, policies, and logical command\u002Fquery contracts (request\u002Fresponse\u002Ferror *shapes*). It does **not** own physical concerns — storage engines, real endpoints\u002FURLs, authentication, migrations, indexes, or deployment. Those stay owned by `\u002Fspec-interview` downstream. See Constraints.\n\nFollow `docs\u002Fprototype-session-loop-convention.md` for prototype-phase routing, state storage, approval boundaries, and task classification. This skill is a prototype-phase orchestrator: its live loop cursor is **filesystem existence of per-framework intermediates**, not a Pattern A selected-framework run manifest. It does not use `tasks\u002Ftodo.md` for framework progress.\n\n## Architecture — Orthogonal Sibling To The Flow Tree\n\n`state-model` is an **orthogonal sibling** of the flow tree, not a stage inside it:\n\n- The flow-tree `route` array stays a locked six-step sequence (`user-flow-map, ux-variations, ui-interview, prototype, consolidate-variations, spec-interview`). This skill does **not** appear in or modify that array. Ordering is enforced by next-step recommendations, not the route enum.\n- This skill owns its own `design\u002Fmodel-tree-{topic}.yaml` manifest, a domain-shaped sibling to `design\u002Fflow-tree-{topic}.yaml`.\n- On synthesis it writes an **optional** top-level `model_tree_ref` pointer into the flow-tree manifest so downstream skills can discover the model. The pointer is backward-compatible and never required.\n- **Flow bindings are authoritative in the model-tree only.** Every model element records `flow_bindings[]` pointing at flow-tree nodes. These bindings are never duplicated into the flow tree, to prevent drift.\n\n## Prerequisites\n\n- **Hard**: an approved `design\u002Fflow-tree-{topic}.yaml` (or `design\u002F{slug}\u002Fflow-tree-{topic}.yaml`) and its companion `design\u002Fuser-flow-{topic}.md` user-flow doc must exist. If they do not, stop and recommend `\u002Fuser-flow-map [topic]` first — the logical model anchors to named flow nodes, so there must be a flow to anchor to.\n- **Soft**: read these if they exist:\n  - `research\u002Fpositioning.md`, `research\u002Fjourney-map.md`, `research\u002Ficp.md` — domain language and lifecycle context.\n  - Existing `design\u002Fux-variations-*.md`, `design\u002Fui-requirements-*.md` — only as supplementary domain evidence; the model must not encode any single UI presentation.\n  - `research\u002Fglossary.md` (or scoped) — existing ubiquitous-language terms.\n\n## Execution Model — Prototype Session Loop (intra-skill substep chunking)\n\nThis orchestrator runs as a **prototype-phase intra-skill substep loop** per `docs\u002Fprototype-session-loop-convention.md` (Intra-Skill Substep Chunking + Shared Context Brief). Each invocation starts cold, resolves its state from the filesystem, runs **one heavy phase**, and stops. The user advances the loop by clearing context and re-invoking `\u002Fstate-model` with the same topic argument.\n\nThree-tier state, exactly as the convention defines it:\n\n| Tier | Store | Role |\n|---|---|---|\n| Machine cursor | `design\u002Fmodel-tree-{topic}.yaml` (committed, **post-approval** synthesized manifest) | Authoritative model state. Written **only** at synthesis, never as a live run-manifest. |\n| Shared context brief | `design\u002F{slug}\u002F_working\u002Fstate-model-{topic}-brief.md` (flat: `design\u002F_working\u002F...`) | **Pure context, no step list**: confirmed scope\u002Fassumptions, the flow nodes in play, the planned framework set + run order with each framework's thesis, ubiquitous-language seeds, carried cross-framework decisions. |\n| Per-framework intermediates | `design\u002F{slug}\u002Fstate-model-{topic}\u002F{framework}.md` (flat: `design\u002Fstate-model-{topic}\u002F...`) | One framework's logical findings each. **Their existence IS the cursor** — the next pending framework is the first planned framework whose intermediate file does not yet exist. |\n\n`pending = planned-frameworks − existing-intermediates`. The brief carries no status field and is never a rival ledger. There is **no `design\u002Fflow-tree.schema.json` change** for the cursor and **no `tasks\u002Ftodo.md` use**.\n\n### Per-session shape\n\n```\nsetup session       §0 scope → §1 run-order detection → §2 load flow context\n                    → present the Domain Modeling Scope Checkpoint inline → on confirm,\n                      write the brief (pure context) → STOP\n   → framework       read brief + scan which {framework}.md intermediates exist\n   sessions          → run the first pending framework inline → write its intermediate\n   (one per fw)      → append cross-framework facts to the brief → STOP \u002F re-invoke\n      → assemble+approve session   when all planned intermediates exist (or --synthesize):\n                                   §4 assemble domain-model-{topic}.md + model-tree-{topic}.yaml\n                                   → ONE alignment-page review → confirmed gate\n                                   → on approval write canonical doc + manifest + flow-tree\n                                     model_tree_ref back-pointer + archive brief\u002Fintermediates\n```\n\n### State resolution (resolve the first match)\n\n| State | Detected when | Heavy phase this session | Emits \u002F stops with |\n|---|---|---|---|\n| **A — done** | canonical `design\u002Fdomain-model-{topic}.md` and `design\u002Fmodel-tree-{topic}.yaml` exist | — | done; emit next-skill route (§5) |\n| **B — synthesize** | brief exists, all planned framework intermediates exist, no canonical domain model (also forced by `--synthesize`) | **synthesis + assemble+approve** (§4) | the single domain-model alignment page |\n| **C — run framework** | brief exists, ≥1 planned framework pending | **run next pending framework inline** (§3) | framework intermediate written, re-invoke handoff |\n| **E — setup** | no brief and no canonical (cold start, after the hard prerequisite is satisfied) | scope → run-order detection → load context → Scope Checkpoint → write brief (§0–§2) | Domain Modeling Scope Checkpoint, then brief written |\n\n**Fold for small domains.** When run-order detection plans **fewer than 3** frameworks (or `--no-chunk` is passed), do **not** spend fresh-context round-trips per framework: run setup, all framework passes, and synthesis straight through in one session, writing no brief and no intermediates, exactly as a single pass through §0–§4. Chunk only when the planned framework count is ≥ 3.\n\n**Approval: exactly one final gate.** The framework sessions are pre-approval `_working\u002F`-band drafting — they write intermediates, not canonical artifacts, so no checkpoint inside them authorizes a canonical write. The Domain Modeling Scope Checkpoint (setup) and any per-framework coverage checkpoints are confirmations, not approvals. The single binding alignment-page `review → confirmed` gate is in the assemble+approve session and approves the whole model at once.\n\n---\n\n## Process\n\n### 0. Product-Path Scope Resolution\n\nResolve scope by product path before using code or app structure as a hint:\n\n1. If `$ARGUMENTS` names a non-archived `research\u002F{slug}\u002F` directory or a product-path ID whose `scope_path` points there, use that path. Treat `{slug}` as the product\u002Fapp name, not the ICP, audience, or segment label.\n2. If `$ARGUMENTS` names only `research\u002F_archive\u002F{slug}\u002F` or a manifest entry with `status: archived` or legacy `status: abandoned`, stop and warn that the path is archived; do not write or update scoped outputs there.\n3. Read `research\u002F.progress.yaml` when present. Normalize legacy `active_path` to `active_paths` on read and write back `active_paths` on manifest updates. Treat legacy `abandoned` as `archived`; exclude `archived`, `abandoned`, `deferred`, `revisit_candidate`, `promoted`, and any `scope_path` under `research\u002F_archive\u002F` from active target selection.\n4. If active product paths exist in the manifest, use those paths. If multiple active paths exist, ask which one to target.\n5. If no active manifest target exists, list non-archived product directories under `research\u002F`, excluding `research\u002F_archive\u002F` and dot directories. Auto-select only when exactly one exists; ask when multiple exist.\n6. If no product directories exist, use flat single-product mode.\n7. Detect monorepo\u002Fapp\u002Fpackage structure only as a secondary hint.\n\nWhen product path `{slug}` is active, read and write pre-prototype design artifacts under `design\u002F{slug}\u002F` and treat top-level `design\u002F*.md` files as flat-mode documents. The topic slug derives from the flow-tree `topic` being modeled.\n\n### 1. Run-Order Detection\n\nInspect the approved flow tree and user-flow doc to plan **which of the six domain-modeling frameworks run, and in what order**. All six are available; the engagement determines the set and sequence the way `journey-map` detects mode.\n\nThe six frameworks:\n\n- `event-modeling` — timeline of events\u002Fcommands\u002Fread-models across the flow; best first when the flow is workflow-heavy and temporal.\n- `event-storming` — big-picture domain-event discovery; best first when the domain is novel or vocabulary is unsettled.\n- `domain-model` — DDD entities, value objects, aggregates, and aggregate boundaries.\n- `state-machine` — statecharts for each stateful subject (states, transitions, events, guards, actions).\n- `data-model` — logical ERD: entities, attributes, relationships, cardinalities (logical, never physical storage).\n- `contract-map` — logical command\u002Fquery contracts: request\u002Fresponse\u002Ferror shapes per action (logical I\u002FO, never real endpoints).\n\nDetection signals (read from the flow tree and user-flow doc):\n\n- **Domain novelty \u002F unsettled vocabulary** → lead with `event-storming`, then `domain-model`.\n- **Workflow\u002Ftemporal complexity (many ordered steps, handoffs, async waits)** → lead with `event-modeling`.\n- **High stateful-entity count (many statuses, lifecycles, approval\u002Fretry transitions)** → ensure `state-machine` runs and weight it early.\n- **High entity\u002Frelationship count (rich data with many associations)** → ensure `data-model` runs.\n- **Many distinct user\u002Fsystem actions per screen** → ensure `contract-map` runs.\n- **Simple domains** (few entities, one or two flows, settled vocabulary) → plan a reduced set (e.g. `domain-model` + `state-machine`, or add `data-model`) and fold per the Execution Model.\n\nAlways include `domain-model` (the DDD spine). Order the rest by the dominant signal; `data-model` and `contract-map` typically run after the conceptual frameworks so they can reference settled entities and states. Record the planned set, order, and the one-line rationale per framework.\n\n### 2. Load Flow Context + Domain Modeling Scope Checkpoint (setup session)\n\n- Read the approved `design\u002F{flow-tree, user-flow}-{topic}` artifacts: flow nodes, screens\u002Froutes, actions, decisions, branches, states, failure paths, handoffs.\n- Read soft prerequisites (positioning, journey, glossary) for domain language.\n- Identify the candidate ubiquitous-language seeds the flow already implies.\n\nPresent a **Domain Modeling Scope Checkpoint** inline as the final message text of its own turn (never only as mid-turn text in a turn that ends with a tool call). Cover:\n\n- The flow nodes in play and the topic being modeled.\n- The detected framework set + run order, with the one-line rationale per framework.\n- Confirmed assumptions about domain boundaries and explicit non-goals (especially the logical-only boundary — no storage\u002Fendpoints\u002Fauth\u002Fmigrations).\n- Candidate ubiquitous-language seeds.\n\nAsk the user to confirm, correct, or adjust the framework set\u002Forder in the next turn. This checkpoint is a confirmation, not a final approval. On confirmation, write the **shared context brief** to `design\u002F{slug}\u002F_working\u002Fstate-model-{topic}-brief.md` (flat: `design\u002F_working\u002Fstate-model-{topic}-brief.md`) containing **pure context only** — confirmed scope\u002Fassumptions, the flow nodes in play, the planned framework set + order with each framework's thesis, ubiquitous-language seeds, and carried decisions — with **no step list and no status field**. Then STOP and emit the **Terminal handoff format** from `docs\u002Fprototype-session-loop-convention.md`: state the brief was written, name the **first** pending framework to run in **plain English** (what that framework models, never only its internal `{framework-slug}`), and give the **exact** resolved next command with `{topic}` filled in, e.g. `\u002Fstate-model alignment-page-review`, so the first framework runs in its own cold spec session (§3). (Unless folding per the Execution Model, in which case continue directly to §3.)\n\n### 3. Run Next Pending Framework (framework session)\n\nEach framework session resolves its work purely from the filesystem: read the brief, scan which `{framework}.md` intermediates already exist under `design\u002F{slug}\u002Fstate-model-{topic}\u002F`, and run the **first planned framework whose intermediate does not yet exist**.\n\nRun that one framework inline against the flow context in the brief, producing **logical** findings only, and write them to `design\u002F{slug}\u002Fstate-model-{topic}\u002F{framework}.md`. Each intermediate must, where the framework applies:\n\n- Name the model elements it introduces or refines (entities\u002Fvalue-objects\u002Faggregates, states\u002Ftransitions, events, commands, read models, policies, contracts).\n- Record each element's `flow_bindings` — which flow node(s) it reads, writes, triggers, displays, or transitions — using flow-tree node references.\n- Map state-machine states to UI states (`maps_to_ui_state`) where a flow state exists, so UX variations can present them.\n- Flag any term that belongs in the ubiquitous-language glossary.\n- Keep strictly to logical concerns; defer every physical concern to `\u002Fspec-interview` with an explicit note rather than inventing storage\u002Fendpoint\u002Fauth detail.\n\nAppend any cross-framework facts (renamed entities, merged aggregates, newly discovered events) to the brief so later frameworks inherit them. Then STOP and emit the **Terminal handoff format** from `docs\u002Fprototype-session-loop-convention.md`. After writing, recalculate `pending`: if frameworks remain, the handoff states the intermediate just written, names the next pending framework in **plain English** (what it models, never only its internal `{framework-slug}`), and gives the **exact** resolved next command with `{topic}` filled in, e.g. `\u002Fstate-model alignment-page-review`; if none remain, the handoff points to the synthesis session (§4) and gives its exact command, e.g. `\u002Fstate-model alignment-page-review`. Continue-vs-stop framing follows that convention's Routing Rules.\n\n### 4. Synthesis + Assemble & Approve (assemble session)\n\nEnter when the brief exists, **all** planned framework intermediates exist, and no canonical domain model exists yet (also forced by `\u002Fstate-model --synthesize [topic]`).\n\nAssemble the per-framework intermediates plus the brief into:\n\n1. **Canonical doc** `design\u002Fdomain-model-{topic}.md` (flat) or `design\u002F{slug}\u002Fdomain-model-{topic}.md`, with sections: ubiquitous-language glossary, entities (with kind, attributes, relationships), state machines (states, transitions, `maps_to_ui_state`), events, commands, read models, policies, logical contracts, an evidence\u002Fflow-binding matrix, assumptions\u002Fconfidence, and explicit physical-concern deferrals to `\u002Fspec-interview`.\n2. **Synthesized manifest** `design\u002Fmodel-tree-{topic}.yaml` (flat) or `design\u002F{slug}\u002Fmodel-tree-{topic}.yaml`, per the `design\u002Fmodel-tree.schema.json` contract and the shape below.\n\nBuild the **one** alignment page (`alignment\u002Fstate-model-{topic}.html`) rendering the full proposed domain model, the flow-binding matrix, the state-machine\u002FERD diagrams (visual tier), assumptions\u002Fconfidence, the proposed file changes, the glossary-additions gate, and the approval gate. Stop for compiled YAML.\n\nOn approval (compiled YAML with no unresolved negative feedback):\n\n- Write `design\u002Fdomain-model-{topic}.md` and `design\u002Fmodel-tree-{topic}.yaml`.\n- Write the optional top-level `model_tree_ref` pointer into the flow-tree manifest (`design\u002F{flow-tree}-{topic}.yaml`), pointing at the new model-tree path. Do **not** touch the flow-tree `route` array or duplicate any binding into the flow tree.\n- Append only user-approved glossary terms to the target glossary per the glossary write-forward convention.\n- Archive the brief and per-framework intermediates under `docs\u002Fhistory\u002Farchive\u002FYYYY-MM-DD\u002FHHMMSS\u002F\u003Coriginal-working-path>` (archive-at-canonical-write timing).\n- Emit the downstream next-step route (§5).\n\n### 5. Next Steps (after synthesis only)\n\nAfter the canonical domain model and model-tree are written, recommend the **first** match:\n\n1. **Default** → check `.agents\u002Fproject.json.enabled_packs` for `product-design`; if enabled, recommend `\u002Fux-variations [specific-user-flow]` — the variation work now has a real logical substrate to present. Name the specific user flow from the flow tree.\n2. If `product-design` is not enabled, recommend `npx skillpacks install product-design` from the project shell first.\n3. **Never** recommend `\u002Fspec-interview` here — it is many steps downstream and owns the physical-model hardening pass.\n\nDo not emit cross-skill routing before synthesis is approved and written. While a framework or the synthesis page is pending, the only continuation route is re-invoking `\u002Fstate-model` with the same topic argument.\n\n## Output\n\n- Setup session: the Domain Modeling Scope Checkpoint (inline) + the shared context brief.\n- Framework session: one `design\u002F{slug}\u002Fstate-model-{topic}\u002F{framework}.md` intermediate per planned framework.\n- Assemble session: `design\u002Fdomain-model-{topic}.md`, `design\u002Fmodel-tree-{topic}.yaml`, the flow-tree `model_tree_ref` back-pointer, and the `alignment\u002Fstate-model-{topic}.html` review page.\n\n### `model-tree-{topic}.yaml` shape\n\nSame envelope as `design\u002Fflow-tree.schema.json` (`schema_version`, `topic`, `mode`\u002F`product_path`, `source_artifacts`, kebab `id` pattern, `additionalProperties:false`, status enum `proposed|confirmed|rejected|deferred`). Body:\n\n- `flow_tree_ref` (binding anchor) + `frameworks[]` (record of which frameworks were run\u002Fsynthesized).\n- `entities[]` — `kind: entity|value-object|aggregate-root`; attributes, relationships with cardinality, `lifecycle_ref` to a state machine.\n- `state_machines[]` — subject, states (each with optional `maps_to_ui_state`), transitions (event\u002Fguard\u002Faction).\n- `events[]`, `commands[]`, `read_models[]`, `policies[]`.\n- `contracts[]` — `kind: command|query`; request\u002Fresponse\u002Ferror shapes, **logical only**.\n- Every element carries `flow_bindings[]: {flow_node_ref, access: reads|writes|triggers|displays|transitions}`. Bindings live in the model-tree only and are never duplicated into the flow tree.\n\n## Alignment Page\n\nWhen this skill produces durable deliverables (research, specs, plans, reports, prototypes, or any document output), build a full-depth HTML alignment page following `ALIGNMENT-PAGE.md` in this skill's directory. Output: `alignment\u002Fstate-model-{topic}.html`.\n\n## Archive-First Replacement Policy\n\n- Before replacing or substantively rewriting an existing canonical design document (`design\u002F**\u002F*.md`, `design\u002F**\u002F*.yaml`), copy the current file to `docs\u002Fhistory\u002Farchive\u002FYYYY-MM-DD\u002FHHMMSS\u002F\u003Coriginal-relative-path>`.\n- Preserve the archived snapshot exactly; do not edit it after creating it.\n- After the archive snapshot exists, write the updated document to the original canonical path.\n- New files do not need archive snapshots. Append-only updates do not need archive snapshots unless an existing section is regenerated or rewritten.\n\n## Constraints\n\n- **Logical only.** Do not specify storage engines, databases, real endpoints\u002FURLs, authentication\u002Fauthorization mechanisms, migrations, indexes, deployment, or any physical architecture. When a physical concern arises, record it as an explicit deferral to `\u002Fspec-interview`, not as a decision. The model captures *what* the domain is, not *how* it is stored or served.\n- **Anchor to the flow, not to a UI.** The model is a property of the user flow. Do not encode any single UX variation or UI presentation. UX variations re-skin the same entities\u002Factions\u002Fstates.\n- **Bindings are authoritative in the model-tree only.** Never duplicate `flow_bindings` into the flow tree; never modify the flow-tree `route` array. The only flow-tree write is the optional `model_tree_ref` pointer.\n- **One heavy phase per session.** Run setup, one framework, or synthesis per invocation; advance by re-invoking `\u002Fstate-model`. Fold to a single session only for fewer-than-3-framework domains or `--no-chunk`. Do not queue framework work in `tasks\u002Ftodo.md` or hand it to `\u002Fexec`.\n- **Synthesis requires at least one framework intermediate.** Do not synthesize from zero evidence.\n- The live cursor is per-framework intermediate existence; the model-tree is written only at synthesis as the post-approval manifest, never as a live run-manifest.\n- Present the model before writing canonical artifacts; exactly one binding alignment gate, at synthesis.\n- When recommending a skill from another pack, verify pack availability through `.agents\u002Fproject.json.enabled_packs`.\n\n## Default Shipping Contract\n\nFollow the shared shipping contract convention in CLAUDE.md.\n","## Pack Availability Guard\n\nBefore telling the user to run a skill from another project-local pack, check `.agents\u002Fproject.json.enabled_packs`. If the target pack is not enabled, recommend `npx skillpacks install \u003Cpack>` from the project shell, instead of the target skill. Only the currently running skill and skills verified available in the active session or project-local install state are directly recommendable. For unavailable pack skills, recommend `npx skillpacks install \u003Cpack-or-skill>`; for unavailable base skills, recommend `npx skillpacks init` before the skill.\n\n# State Model — Orchestrator\n\nInvoke as `\u002Fstate-model`.\n\nThis is an **orchestrator skill** that authors the **logical** domain\u002Fstate\u002Flogic model anchored to an approved user-flow map, running **one domain-modeling framework per session** and synthesizing their outputs into a single canonical domain model plus a `model-tree` manifest. It sits **after `\u002Fuser-flow-map`, before `\u002Fux-variations`** in the product-design prototype pipeline.\n\nThe model it produces is a property of the *flow*, not of any one UI presentation: UX variations re-skin the same underlying entities, actions, and states, so authoring the logical model once gives `\u002Fux-variations` and `\u002Fui-interview` a real substrate to present, and turns `\u002Fspec-interview` into \"harden this model to production\" rather than \"invent it.\"\n\n**Logical only.** This skill owns entities, value objects, aggregates, state machines, events, commands, read models, policies, and logical command\u002Fquery contracts (request\u002Fresponse\u002Ferror *shapes*). It does **not** own physical concerns — storage engines, real endpoints\u002FURLs, authentication, migrations, indexes, or deployment. Those stay owned by `\u002Fspec-interview` downstream. See Constraints.\n\nFollow `docs\u002Fprototype-session-loop-convention.md` for prototype-phase routing, state storage, approval boundaries, and task classification. This skill is a prototype-phase orchestrator: its live loop cursor is **filesystem existence of per-framework intermediates**, not a Pattern A selected-framework run manifest. It does not use `tasks\u002Ftodo.md` for framework progress.\n\n## Architecture — Orthogonal Sibling To The Flow Tree\n\n`state-model` is an **orthogonal sibling** of the flow tree, not a stage inside it:\n\n- The flow-tree `route` array stays a locked six-step sequence (`user-flow-map, ux-variations, ui-interview, prototype, consolidate-variations, spec-interview`). This skill does **not** appear in or modify that array. Ordering is enforced by next-step recommendations, not the route enum.\n- This skill owns its own `design\u002Fmodel-tree-{topic}.yaml` manifest, a domain-shaped sibling to `design\u002Fflow-tree-{topic}.yaml`.\n- On synthesis it writes an **optional** top-level `model_tree_ref` pointer into the flow-tree manifest so downstream skills can discover the model. The pointer is backward-compatible and never required.\n- **Flow bindings are authoritative in the model-tree only.** Every model element records `flow_bindings[]` pointing at flow-tree nodes. These bindings are never duplicated into the flow tree, to prevent drift.\n\n## Prerequisites\n\n- **Hard**: an approved `design\u002Fflow-tree-{topic}.yaml` (or `design\u002F{slug}\u002Fflow-tree-{topic}.yaml`) and its companion `design\u002Fuser-flow-{topic}.md` user-flow doc must exist. If they do not, stop and recommend `\u002Fuser-flow-map [topic]` first — the logical model anchors to named flow nodes, so there must be a flow to anchor to.\n- **Soft**: read these if they exist:\n  - `research\u002Fpositioning.md`, `research\u002Fjourney-map.md`, `research\u002Ficp.md` — domain language and lifecycle context.\n  - Existing `design\u002Fux-variations-*.md`, `design\u002Fui-requirements-*.md` — only as supplementary domain evidence; the model must not encode any single UI presentation.\n  - `research\u002Fglossary.md` (or scoped) — existing ubiquitous-language terms.\n\n## Execution Model — Prototype Session Loop (intra-skill substep chunking)\n\nThis orchestrator runs as a **prototype-phase intra-skill substep loop** per `docs\u002Fprototype-session-loop-convention.md` (Intra-Skill Substep Chunking + Shared Context Brief). Each invocation starts cold, resolves its state from the filesystem, runs **one heavy phase**, and stops. The user advances the loop by clearing context and re-invoking `\u002Fstate-model` with the same topic argument.\n\nThree-tier state, exactly as the convention defines it:\n\n| Tier | Store | Role |\n|---|---|---|\n| Machine cursor | `design\u002Fmodel-tree-{topic}.yaml` (committed, **post-approval** synthesized manifest) | Authoritative model state. Written **only** at synthesis, never as a live run-manifest. |\n| Shared context brief | `design\u002F{slug}\u002F_working\u002Fstate-model-{topic}-brief.md` (flat: `design\u002F_working\u002F...`) | **Pure context, no step list**: confirmed scope\u002Fassumptions, the flow nodes in play, the planned framework set + run order with each framework's thesis, ubiquitous-language seeds, carried cross-framework decisions. |\n| Per-framework intermediates | `design\u002F{slug}\u002Fstate-model-{topic}\u002F{framework}.md` (flat: `design\u002Fstate-model-{topic}\u002F...`) | One framework's logical findings each. **Their existence IS the cursor** — the next pending framework is the first planned framework whose intermediate file does not yet exist. |\n\n`pending = planned-frameworks − existing-intermediates`. The brief carries no status field and is never a rival ledger. There is **no `design\u002Fflow-tree.schema.json` change** for the cursor and **no `tasks\u002Ftodo.md` use**.\n\n### Per-session shape\n\n```\nsetup session       §0 scope → §1 run-order detection → §2 load flow context\n                    → present the Domain Modeling Scope Checkpoint inline → on confirm,\n                      write the brief (pure context) → STOP\n   → framework       read brief + scan which {framework}.md intermediates exist\n   sessions          → run the first pending framework inline → write its intermediate\n   (one per fw)      → append cross-framework facts to the brief → STOP \u002F re-invoke\n      → assemble+approve session   when all planned intermediates exist (or --synthesize):\n                                   §4 assemble domain-model-{topic}.md + model-tree-{topic}.yaml\n                                   → ONE alignment-page review → confirmed gate\n                                   → on approval write canonical doc + manifest + flow-tree\n                                     model_tree_ref back-pointer + archive brief\u002Fintermediates\n```\n\n### State resolution (resolve the first match)\n\n| State | Detected when | Heavy phase this session | Emits \u002F stops with |\n|---|---|---|---|\n| **A — done** | canonical `design\u002Fdomain-model-{topic}.md` and `design\u002Fmodel-tree-{topic}.yaml` exist | — | done; emit next-skill route (§5) |\n| **B — synthesize** | brief exists, all planned framework intermediates exist, no canonical domain model (also forced by `--synthesize`) | **synthesis + assemble+approve** (§4) | the single domain-model alignment page |\n| **C — run framework** | brief exists, ≥1 planned framework pending | **run next pending framework inline** (§3) | framework intermediate written, re-invoke handoff |\n| **E — setup** | no brief and no canonical (cold start, after the hard prerequisite is satisfied) | scope → run-order detection → load context → Scope Checkpoint → write brief (§0–§2) | Domain Modeling Scope Checkpoint, then brief written |\n\n**Fold for small domains.** When run-order detection plans **fewer than 3** frameworks (or `--no-chunk` is passed), do **not** spend fresh-context round-trips per framework: run setup, all framework passes, and synthesis straight through in one session, writing no brief and no intermediates, exactly as a single pass through §0–§4. Chunk only when the planned framework count is ≥ 3.\n\n**Approval: exactly one final gate.** The framework sessions are pre-approval `_working\u002F`-band drafting — they write intermediates, not canonical artifacts, so no checkpoint inside them authorizes a canonical write. The Domain Modeling Scope Checkpoint (setup) and any per-framework coverage checkpoints are confirmations, not approvals. The single binding alignment-page `review → confirmed` gate is in the assemble+approve session and approves the whole model at once.\n\n---\n\n## Process\n\n### 0. Product-Path Scope Resolution\n\nResolve scope by product path before using code or app structure as a hint:\n\n1. If `$ARGUMENTS` names a non-archived `research\u002F{slug}\u002F` directory or a product-path ID whose `scope_path` points there, use that path. Treat `{slug}` as the product\u002Fapp name, not the ICP, audience, or segment label.\n2. If `$ARGUMENTS` names only `research\u002F_archive\u002F{slug}\u002F` or a manifest entry with `status: archived` or legacy `status: abandoned`, stop and warn that the path is archived; do not write or update scoped outputs there.\n3. Read `research\u002F.progress.yaml` when present. Normalize legacy `active_path` to `active_paths` on read and write back `active_paths` on manifest updates. Treat legacy `abandoned` as `archived`; exclude `archived`, `abandoned`, `deferred`, `revisit_candidate`, `promoted`, and any `scope_path` under `research\u002F_archive\u002F` from active target selection.\n4. If active product paths exist in the manifest, use those paths. If multiple active paths exist, ask which one to target.\n5. If no active manifest target exists, list non-archived product directories under `research\u002F`, excluding `research\u002F_archive\u002F` and dot directories. Auto-select only when exactly one exists; ask when multiple exist.\n6. If no product directories exist, use flat single-product mode.\n7. Detect monorepo\u002Fapp\u002Fpackage structure only as a secondary hint.\n\nWhen product path `{slug}` is active, read and write pre-prototype design artifacts under `design\u002F{slug}\u002F` and treat top-level `design\u002F*.md` files as flat-mode documents. The topic slug derives from the flow-tree `topic` being modeled.\n\n### 1. Run-Order Detection\n\nInspect the approved flow tree and user-flow doc to plan **which of the six domain-modeling frameworks run, and in what order**. All six are available; the engagement determines the set and sequence the way `journey-map` detects mode.\n\nThe six frameworks:\n\n- `event-modeling` — timeline of events\u002Fcommands\u002Fread-models across the flow; best first when the flow is workflow-heavy and temporal.\n- `event-storming` — big-picture domain-event discovery; best first when the domain is novel or vocabulary is unsettled.\n- `domain-model` — DDD entities, value objects, aggregates, and aggregate boundaries.\n- `state-machine` — statecharts for each stateful subject (states, transitions, events, guards, actions).\n- `data-model` — logical ERD: entities, attributes, relationships, cardinalities (logical, never physical storage).\n- `contract-map` — logical command\u002Fquery contracts: request\u002Fresponse\u002Ferror shapes per action (logical I\u002FO, never real endpoints).\n\nDetection signals (read from the flow tree and user-flow doc):\n\n- **Domain novelty \u002F unsettled vocabulary** → lead with `event-storming`, then `domain-model`.\n- **Workflow\u002Ftemporal complexity (many ordered steps, handoffs, async waits)** → lead with `event-modeling`.\n- **High stateful-entity count (many statuses, lifecycles, approval\u002Fretry transitions)** → ensure `state-machine` runs and weight it early.\n- **High entity\u002Frelationship count (rich data with many associations)** → ensure `data-model` runs.\n- **Many distinct user\u002Fsystem actions per screen** → ensure `contract-map` runs.\n- **Simple domains** (few entities, one or two flows, settled vocabulary) → plan a reduced set (e.g. `domain-model` + `state-machine`, or add `data-model`) and fold per the Execution Model.\n\nAlways include `domain-model` (the DDD spine). Order the rest by the dominant signal; `data-model` and `contract-map` typically run after the conceptual frameworks so they can reference settled entities and states. Record the planned set, order, and the one-line rationale per framework.\n\n### 2. Load Flow Context + Domain Modeling Scope Checkpoint (setup session)\n\n- Read the approved `design\u002F{flow-tree, user-flow}-{topic}` artifacts: flow nodes, screens\u002Froutes, actions, decisions, branches, states, failure paths, handoffs.\n- Read soft prerequisites (positioning, journey, glossary) for domain language.\n- Identify the candidate ubiquitous-language seeds the flow already implies.\n\nPresent a **Domain Modeling Scope Checkpoint** inline as the final message text of its own turn (never only as mid-turn text in a turn that ends with a tool call). Cover:\n\n- The flow nodes in play and the topic being modeled.\n- The detected framework set + run order, with the one-line rationale per framework.\n- Confirmed assumptions about domain boundaries and explicit non-goals (especially the logical-only boundary — no storage\u002Fendpoints\u002Fauth\u002Fmigrations).\n- Candidate ubiquitous-language seeds.\n\nAsk the user to confirm, correct, or adjust the framework set\u002Forder in the next turn. This checkpoint is a confirmation, not a final approval. On confirmation, write the **shared context brief** to `design\u002F{slug}\u002F_working\u002Fstate-model-{topic}-brief.md` (flat: `design\u002F_working\u002Fstate-model-{topic}-brief.md`) containing **pure context only** — confirmed scope\u002Fassumptions, the flow nodes in play, the planned framework set + order with each framework's thesis, ubiquitous-language seeds, and carried decisions — with **no step list and no status field**. Then STOP and emit the **Terminal handoff format** from `docs\u002Fprototype-session-loop-convention.md`: state the brief was written, name the **first** pending framework to run in **plain English** (what that framework models, never only its internal `{framework-slug}`), and give the **exact** resolved next command with `{topic}` filled in, e.g. `\u002Fstate-model alignment-page-review`, so the first framework runs in its own cold spec session (§3). (Unless folding per the Execution Model, in which case continue directly to §3.)\n\n### 3. Run Next Pending Framework (framework session)\n\nEach framework session resolves its work purely from the filesystem: read the brief, scan which `{framework}.md` intermediates already exist under `design\u002F{slug}\u002Fstate-model-{topic}\u002F`, and run the **first planned framework whose intermediate does not yet exist**.\n\nRun that one framework inline against the flow context in the brief, producing **logical** findings only, and write them to `design\u002F{slug}\u002Fstate-model-{topic}\u002F{framework}.md`. Each intermediate must, where the framework applies:\n\n- Name the model elements it introduces or refines (entities\u002Fvalue-objects\u002Faggregates, states\u002Ftransitions, events, commands, read models, policies, contracts).\n- Record each element's `flow_bindings` — which flow node(s) it reads, writes, triggers, displays, or transitions — using flow-tree node references.\n- Map state-machine states to UI states (`maps_to_ui_state`) where a flow state exists, so UX variations can present them.\n- Flag any term that belongs in the ubiquitous-language glossary.\n- Keep strictly to logical concerns; defer every physical concern to `\u002Fspec-interview` with an explicit note rather than inventing storage\u002Fendpoint\u002Fauth detail.\n\nAppend any cross-framework facts (renamed entities, merged aggregates, newly discovered events) to the brief so later frameworks inherit them. Then STOP and emit the **Terminal handoff format** from `docs\u002Fprototype-session-loop-convention.md`. After writing, recalculate `pending`: if frameworks remain, the handoff states the intermediate just written, names the next pending framework in **plain English** (what it models, never only its internal `{framework-slug}`), and gives the **exact** resolved next command with `{topic}` filled in, e.g. `\u002Fstate-model alignment-page-review`; if none remain, the handoff points to the synthesis session (§4) and gives its exact command, e.g. `\u002Fstate-model alignment-page-review`. Continue-vs-stop framing follows that convention's Routing Rules.\n\n### 4. Synthesis + Assemble & Approve (assemble session)\n\nEnter when the brief exists, **all** planned framework intermediates exist, and no canonical domain model exists yet (also forced by `\u002Fstate-model --synthesize [topic]`).\n\nAssemble the per-framework intermediates plus the brief into:\n\n1. **Canonical doc** `design\u002Fdomain-model-{topic}.md` (flat) or `design\u002F{slug}\u002Fdomain-model-{topic}.md`, with sections: ubiquitous-language glossary, entities (with kind, attributes, relationships), state machines (states, transitions, `maps_to_ui_state`), events, commands, read models, policies, logical contracts, an evidence\u002Fflow-binding matrix, assumptions\u002Fconfidence, and explicit physical-concern deferrals to `\u002Fspec-interview`.\n2. **Synthesized manifest** `design\u002Fmodel-tree-{topic}.yaml` (flat) or `design\u002F{slug}\u002Fmodel-tree-{topic}.yaml`, per the `design\u002Fmodel-tree.schema.json` contract and the shape below.\n\nBuild the **one** alignment page (`alignment\u002Fstate-model-{topic}.html`) rendering the full proposed domain model, the flow-binding matrix, the state-machine\u002FERD diagrams (visual tier), assumptions\u002Fconfidence, the proposed file changes, the glossary-additions gate, and the approval gate. Stop for compiled YAML.\n\nOn approval (compiled YAML with no unresolved negative feedback):\n\n- Write `design\u002Fdomain-model-{topic}.md` and `design\u002Fmodel-tree-{topic}.yaml`.\n- Write the optional top-level `model_tree_ref` pointer into the flow-tree manifest (`design\u002F{flow-tree}-{topic}.yaml`), pointing at the new model-tree path. Do **not** touch the flow-tree `route` array or duplicate any binding into the flow tree.\n- Append only user-approved glossary terms to the target glossary per the glossary write-forward convention.\n- Archive the brief and per-framework intermediates under `docs\u002Fhistory\u002Farchive\u002FYYYY-MM-DD\u002FHHMMSS\u002F\u003Coriginal-working-path>` (archive-at-canonical-write timing).\n- Emit the downstream next-step route (§5).\n\n### 5. Next Steps (after synthesis only)\n\nAfter the canonical domain model and model-tree are written, recommend the **first** match:\n\n1. **Default** → check `.agents\u002Fproject.json.enabled_packs` for `product-design`; if enabled, recommend `\u002Fux-variations [specific-user-flow]` — the variation work now has a real logical substrate to present. Name the specific user flow from the flow tree.\n2. If `product-design` is not enabled, recommend `npx skillpacks install product-design` from the project shell first.\n3. **Never** recommend `\u002Fspec-interview` here — it is many steps downstream and owns the physical-model hardening pass.\n\nDo not emit cross-skill routing before synthesis is approved and written. While a framework or the synthesis page is pending, the only continuation route is re-invoking `\u002Fstate-model` with the same topic argument.\n\n## Output\n\n- Setup session: the Domain Modeling Scope Checkpoint (inline) + the shared context brief.\n- Framework session: one `design\u002F{slug}\u002Fstate-model-{topic}\u002F{framework}.md` intermediate per planned framework.\n- Assemble session: `design\u002Fdomain-model-{topic}.md`, `design\u002Fmodel-tree-{topic}.yaml`, the flow-tree `model_tree_ref` back-pointer, and the `alignment\u002Fstate-model-{topic}.html` review page.\n\n### `model-tree-{topic}.yaml` shape\n\nSame envelope as `design\u002Fflow-tree.schema.json` (`schema_version`, `topic`, `mode`\u002F`product_path`, `source_artifacts`, kebab `id` pattern, `additionalProperties:false`, status enum `proposed|confirmed|rejected|deferred`). Body:\n\n- `flow_tree_ref` (binding anchor) + `frameworks[]` (record of which frameworks were run\u002Fsynthesized).\n- `entities[]` — `kind: entity|value-object|aggregate-root`; attributes, relationships with cardinality, `lifecycle_ref` to a state machine.\n- `state_machines[]` — subject, states (each with optional `maps_to_ui_state`), transitions (event\u002Fguard\u002Faction).\n- `events[]`, `commands[]`, `read_models[]`, `policies[]`.\n- `contracts[]` — `kind: command|query`; request\u002Fresponse\u002Ferror shapes, **logical only**.\n- Every element carries `flow_bindings[]: {flow_node_ref, access: reads|writes|triggers|displays|transitions}`. Bindings live in the model-tree only and are never duplicated into the flow tree.\n\n## Alignment Page\n\nWhen this skill produces durable deliverables (research, specs, plans, reports, prototypes, or any document output), build a full-depth HTML alignment page following `ALIGNMENT-PAGE.md` in this skill's directory. Output: `alignment\u002Fstate-model-{topic}.html`.\n\n## Archive-First Replacement Policy\n\n- Before replacing or substantively rewriting an existing canonical design document (`design\u002F**\u002F*.md`, `design\u002F**\u002F*.yaml`), copy the current file to `docs\u002Fhistory\u002Farchive\u002FYYYY-MM-DD\u002FHHMMSS\u002F\u003Coriginal-relative-path>`.\n- Preserve the archived snapshot exactly; do not edit it after creating it.\n- After the archive snapshot exists, write the updated document to the original canonical path.\n- New files do not need archive snapshots. Append-only updates do not need archive snapshots unless an existing section is regenerated or rewritten.\n\n## Constraints\n\n- **Logical only.** Do not specify storage engines, databases, real endpoints\u002FURLs, authentication\u002Fauthorization mechanisms, migrations, indexes, deployment, or any physical architecture. When a physical concern arises, record it as an explicit deferral to `\u002Fspec-interview`, not as a decision. The model captures *what* the domain is, not *how* it is stored or served.\n- **Anchor to the flow, not to a UI.** The model is a property of the user flow. Do not encode any single UX variation or UI presentation. UX variations re-skin the same entities\u002Factions\u002Fstates.\n- **Bindings are authoritative in the model-tree only.** Never duplicate `flow_bindings` into the flow tree; never modify the flow-tree `route` array. The only flow-tree write is the optional `model_tree_ref` pointer.\n- **One heavy phase per session.** Run setup, one framework, or synthesis per invocation; advance by re-invoking `\u002Fstate-model`. Fold to a single session only for fewer-than-3-framework domains or `--no-chunk`. Do not queue framework work in `tasks\u002Ftodo.md` or hand it to `\u002Fexec`.\n- **Synthesis requires at least one framework intermediate.** Do not synthesize from zero evidence.\n- The live cursor is per-framework intermediate existence; the model-tree is written only at synthesis as the post-approval manifest, never as a live run-manifest.\n- Present the model before writing canonical artifacts; exactly one binding alignment gate, at synthesis.\n- When recommending a skill from another pack, verify pack availability through `.agents\u002Fproject.json.enabled_packs`.\n\n## Default Shipping Contract\n\nFollow the shared shipping contract convention in CLAUDE.md.\n",{"name":5,"type":44,"version":45,"invocation":32,"description":7,"visual_tier":46,"argument-hint":47,"context_intake":48},"research","v0.1","visual","[optional: topic, user-flow, or feature] [--synthesize] [--no-chunk]","scoped","master","96e2912af886dd1606b1b97df707715aef062b02","packs\u002Fproduct-design\u002Fclaude\u002Fstate-model\u002Farchive\u002Fv0.1",0,"https:\u002F\u002Fgithub.com\u002FGeorgeQLe\u002Fagentic-skills","https:\u002F\u002Fagentic-skills-blush.vercel.app","https:\u002F\u002Fgithub.com\u002FGeorgeQLe","georgeqle.com","George Le is a futurist and serial tech entrepreneur who wants to work toward a world where humanity is free from robotic tasks.","2026-11-10 04:07:24",{"source":8,"skillName":5,"commands":60,"prompt":70,"zipAvailable":71},[61,64,67],{"tool":62,"command":63},"npx","npx skills add GeorgeQLe\u002Fagentic-skills --skill state-model",{"tool":65,"command":66},"bunx","bunx skills add GeorgeQLe\u002Fagentic-skills --skill state-model",{"tool":68,"command":69},"pnpm","pnpm dlx skills add GeorgeQLe\u002Fagentic-skills --skill state-model","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FGeorgeQLe\u002Fagentic-skills\u002Fblob\u002Fmaster\u002Fpacks\u002Fproduct-design\u002Fclaude\u002Fstate-model\u002Farchive\u002Fv0.1\u002FSKILL.md",true,[],[74,86,96,108,123,134],{"skillNo":75,"name":76,"nameZh":6,"description":77,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":78,"categories":79,"keywords":80,"publishedAt":39},"01M6G0NJES15RJKZE6YZ0TSYGF","source-checkout-allowed","Valid source-checkout-only fixture.","https:\u002F\u002Fgithub.com\u002FGeorgeQLe\u002Fagentic-skills\u002Fblob\u002Fmaster\u002Ftests\u002Ffixtures\u002Fskill-install-routing\u002Fvalid\u002Fsource-checkout-allowed\u002FSKILL.md",[],[81,82,83,84,31,85],"source checkout allowed","checkout","fixture","only","valid",{"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":15,"licenseFileUrl":6,"sourceHtmlUrl":90,"categories":91,"keywords":92,"publishedAt":39},"01M6G0NFZ3R1MNB1E3DVTM0WB7","deck-install-valid","Valid deck install fixture.","https:\u002F\u002Fgithub.com\u002FGeorgeQLe\u002Fagentic-skills\u002Fblob\u002Fmaster\u002Ftests\u002Ffixtures\u002Fskill-install-routing\u002Fvalid\u002Fdeck-install\u002FSKILL.md",[],[93,94,95,85,83,31],"deck install valid","deck","install",{"skillNo":97,"name":98,"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":39},"01M6G0ND3QZQC4MDZ9NVB97PT2","codex-pack-guard-valid","Valid Codex Pack Availability Guard fixture.","https:\u002F\u002Fgithub.com\u002FGeorgeQLe\u002Fagentic-skills\u002Fblob\u002Fmaster\u002Ftests\u002Ffixtures\u002Fskill-install-routing\u002Fvalid\u002Fcodex-pack-guard\u002FSKILL.md",[],[103,104,105,85,106,107,83,31],"codex pack guard valid","pack","guard","codex","availability",{"skillNo":109,"name":110,"nameZh":6,"description":111,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":112,"categories":113,"keywords":119,"publishedAt":39},"01M6G0NA9YB3NKGZKD3S96JMNB","codex-missing-skill-valid","Valid Codex missing skill fallback fixture.","https:\u002F\u002Fgithub.com\u002FGeorgeQLe\u002Fagentic-skills\u002Fblob\u002Fmaster\u002Ftests\u002Ffixtures\u002Fskill-install-routing\u002Fvalid\u002Fcodex-missing-skill-fallback\u002FSKILL.md",[114],{"categoryNo":115,"categoryName":116,"taxonomyType":117,"taxonomyTypeDesc":118},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[120,121,85,106,31,122,83],"codex missing skill valid","missing","fallback",{"skillNo":124,"name":125,"nameZh":6,"description":126,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":127,"categories":128,"keywords":130,"publishedAt":39},"01M6G0N7PC0EKFD40ZWQAXSAQ9","codex-base-skill-fallback-valid","Valid Codex base skill fallback fixture.","https:\u002F\u002Fgithub.com\u002FGeorgeQLe\u002Fagentic-skills\u002Fblob\u002Fmaster\u002Ftests\u002Ffixtures\u002Fskill-install-routing\u002Fvalid\u002Fcodex-base-skill-fallback\u002FSKILL.md",[129],{"categoryNo":115,"categoryName":116,"taxonomyType":117,"taxonomyTypeDesc":118},[85,106,122,131,132,133,31,83],"base skill","codex base skill fallback valid","base",{"skillNo":135,"name":136,"nameZh":6,"description":137,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":138,"categories":139,"keywords":140,"publishedAt":39},"01M6G0N4VRR2YKZQ6N3Y6S2BQA","claude-pack-guard-valid","Valid Claude Pack Availability Guard fixture.","https:\u002F\u002Fgithub.com\u002FGeorgeQLe\u002Fagentic-skills\u002Fblob\u002Fmaster\u002Ftests\u002Ffixtures\u002Fskill-install-routing\u002Fvalid\u002Fclaude-pack-guard\u002FSKILL.md",[],[85,105,104,141,107,31,83],"claude pack guard valid"]