create-yss-spec 3.5.2 → 3.5.4

package/template.manifest.json

@@ -92,9 +92,14 @@
     "scripts/lib/skill-governance.mjs",
     "scripts/lib/template-commit-cache.mjs",
     "scripts/lib/template-verification.mjs",
-    "scripts/lib/template-verification-runner.mjs"
+    "scripts/lib/template-verification-runner.mjs",
+    "scripts/lib/verification-selection.mjs",
+    "scripts/lib/verification-report.mjs",
+    "scripts/lib/maintenance-counterexample.mjs"
+  ],
+  "excludePathSuffixes": [
+    "-scenarios"
   ],
-  "excludePathSuffixes": ["-scenarios"],
   "renderPaths": [
     ".gitignore",
     "AGENTS.md",
@@ -128,44 +133,129 @@
     "version": 1,
     "default": "managed",
     "rules": [
-      { "pattern": ".git/**", "ownership": "protected" },
-      { "pattern": ".template-source/**", "ownership": "protected" },
-      { "pattern": ".cursor/environment.json", "ownership": "protected" },
-      { "pattern": ".gitmodules", "ownership": "user-owned" },
-      { "pattern": ".gitignore", "ownership": "managed-customizable" },
-      { "pattern": "apps/**", "ownership": "user-owned" },
-      { "pattern": "packages/**", "ownership": "user-owned" },
-      { "pattern": "wiki/**", "ownership": "user-owned" },
-      { "pattern": "docs/reviews/**", "ownership": "user-owned" },
-      { "pattern": "docs/.scratch/**", "ownership": "user-owned" },
-      { "pattern": ".template-spec/agents/issue-tracker.md", "ownership": "managed-customizable" },
-      { "pattern": "yss-project.yaml", "ownership": "generated" },
-      { "pattern": "skills-lock.json", "ownership": "generated" },
-      { "pattern": "yss-public-skills.json", "ownership": "generated" },
-      { "pattern": ".agents/skills/.yss-skills-manifest.json", "ownership": "generated" },
-      { "pattern": "AGENTS.md", "ownership": "managed-customizable" },
-      { "pattern": "CONTEXT.md", "ownership": "managed-customizable" },
-      { "pattern": "DESIGN.md", "ownership": "managed-customizable" },
-      { "pattern": "README.md", "ownership": "user-owned" }
+      {
+        "pattern": ".git/**",
+        "ownership": "protected"
+      },
+      {
+        "pattern": ".template-source/**",
+        "ownership": "protected"
+      },
+      {
+        "pattern": ".cursor/environment.json",
+        "ownership": "protected"
+      },
+      {
+        "pattern": ".gitmodules",
+        "ownership": "user-owned"
+      },
+      {
+        "pattern": ".gitignore",
+        "ownership": "managed-customizable"
+      },
+      {
+        "pattern": "apps/**",
+        "ownership": "user-owned"
+      },
+      {
+        "pattern": "packages/**",
+        "ownership": "user-owned"
+      },
+      {
+        "pattern": "wiki/**",
+        "ownership": "user-owned"
+      },
+      {
+        "pattern": "docs/reviews/**",
+        "ownership": "user-owned"
+      },
+      {
+        "pattern": "docs/.scratch/**",
+        "ownership": "user-owned"
+      },
+      {
+        "pattern": ".template-spec/agents/issue-tracker.md",
+        "ownership": "managed-customizable"
+      },
+      {
+        "pattern": "yss-project.yaml",
+        "ownership": "generated"
+      },
+      {
+        "pattern": "skills-lock.json",
+        "ownership": "generated"
+      },
+      {
+        "pattern": "yss-public-skills.json",
+        "ownership": "generated"
+      },
+      {
+        "pattern": ".agents/skills/.yss-skills-manifest.json",
+        "ownership": "generated"
+      },
+      {
+        "pattern": "AGENTS.md",
+        "ownership": "managed-customizable"
+      },
+      {
+        "pattern": "CONTEXT.md",
+        "ownership": "managed-customizable"
+      },
+      {
+        "pattern": "DESIGN.md",
+        "ownership": "managed-customizable"
+      },
+      {
+        "pattern": "README.md",
+        "ownership": "user-owned"
+      }
     ]
   },
   "customizationPolicy": {
     "version": 1,
     "defaultStrategy": "replace-with-force",
     "rules": [
-      { "pattern": ".gitignore", "strategy": "manual" },
-      { "pattern": ".template-spec/agents/issue-tracker.md", "strategy": "manual" },
-      { "pattern": "CONTEXT.md", "strategy": "manual" },
-      { "pattern": "DESIGN.md", "strategy": "manual" }
+      {
+        "pattern": ".gitignore",
+        "strategy": "manual"
+      },
+      {
+        "pattern": ".template-spec/agents/issue-tracker.md",
+        "strategy": "manual"
+      },
+      {
+        "pattern": "CONTEXT.md",
+        "strategy": "manual"
+      },
+      {
+        "pattern": "DESIGN.md",
+        "strategy": "manual"
+      }
     ]
   },
   "generatorPolicy": {
     "version": 1,
     "rules": [
-      { "pattern": "yss-project.yaml", "generatorId": "repository-identity", "generatorVersion": 1 },
-      { "pattern": "skills-lock.json", "generatorId": "skills-lock", "generatorVersion": 1 },
-      { "pattern": "yss-public-skills.json", "generatorId": "public-skills", "generatorVersion": 1 },
-      { "pattern": ".agents/skills/.yss-skills-manifest.json", "generatorId": "skills-manifest", "generatorVersion": 1 }
+      {
+        "pattern": "yss-project.yaml",
+        "generatorId": "repository-identity",
+        "generatorVersion": 1
+      },
+      {
+        "pattern": "skills-lock.json",
+        "generatorId": "skills-lock",
+        "generatorVersion": 1
+      },
+      {
+        "pattern": "yss-public-skills.json",
+        "generatorId": "public-skills",
+        "generatorVersion": 1
+      },
+      {
+        "pattern": ".agents/skills/.yss-skills-manifest.json",
+        "generatorId": "skills-manifest",
+        "generatorVersion": 1
+      }
     ]
   }
 }

package/template.snapshot.json

@@ -3,13 +3,12 @@
   "templateName": "yss-spec-project-template",
   "templateSource": "github:iloveZzz/yss-spec-project-template",
   "templateRepository": "https://github.com/iloveZzz/yss-spec-project-template.git",
-  "requestedRef": "13d8d9c9304a73d65d1e2e6842744b9578f4876a",
-  "templateCommit": "13d8d9c9304a73d65d1e2e6842744b9578f4876a",
+  "requestedRef": "8cc9764ca3d69069dc4fba3765c6c3c038d317a8",
+  "templateCommit": "8cc9764ca3d69069dc4fba3765c6c3c038d317a8",
   "sourceState": "committed",
-  "manifestHash": "d5a3b1e8f7b1bfe2f616acbe31abb4710927cd61d432d5e07990c59149435f3d",
+  "manifestHash": "b8e3fc9b7eecd3155ec4515afb151d344191410a8b3f18305f107a54ce1b337a",
   "encodedPaths": {
     ".agents/skills/yss-frontend-scaffold-generator/assets/data-quality-v1/.gitignore": ".agents/skills/yss-frontend-scaffold-generator/assets/data-quality-v1/__yss_dotfile__.gitignore",
-    ".codex/skills/data-analytics/.gitignore": ".codex/skills/data-analytics/__yss_dotfile__.gitignore",
     ".codex/skills/product-design/.npmignore": ".codex/skills/product-design/__yss_dotfile__.npmignore",
     ".codex/skills/product-design/templates/prototype/.npmrc": ".codex/skills/product-design/templates/prototype/__yss_dotfile__.npmrc",
     ".codex/skills/yss-frontend-scaffold-generator/assets/data-quality-v1/.gitignore": ".codex/skills/yss-frontend-scaffold-generator/assets/data-quality-v1/__yss_dotfile__.gitignore",
@@ -17,6 +16,6 @@
     ".gitignore": "__yss_dotfile__.gitignore",
     ".pi/skills/yss-frontend-scaffold-generator/assets/data-quality-v1/.gitignore": ".pi/skills/yss-frontend-scaffold-generator/assets/data-quality-v1/__yss_dotfile__.gitignore"
   },
-  "snapshotHash": "747545a4222871b8cd201d0b42b64a946bb4f11f3fd63e9f5434bcc32a8b8a5a",
-  "generatedAt": "2026-09-27T14:53:54.985Z"
+  "snapshotHash": "c055086fadfc1a00c0770b5d6f0a49fea5b9f268175beb3ab6ba86440474b86f",
+  "generatedAt": "2026-10-01T01:02:49.512Z"
 }

package/template/.agents/skills/grill-with-docs/SKILL.md

@@ -1,20 +0,0 @@
----
-name: grill-with-docs
-description: Use when the user explicitly requests a relentless design interview that must preserve resolved glossary terms, ADR-worthy decisions, and factual research evidence.
-disable-model-invocation: true
----
-
-Call the Skill tool with `grilling`, then call it separately with `domain-modeling`. This compatibility entry does not define a second glossary format: it consumes `domain-modeling/CONTEXT-FORMAT.md`, the repository Context Contract validator, and the lifecycle reconciliation contract.
-
-## Output Contract
-
-1. Read `yss-project.yaml` and the root glossary before the first round, then run `scripts/verify-context-contract --root . --json`. Missing or lowercase root files, nested `CONTEXT.md`, `CONTEXT-MAP.md`, unsupported schema, absolute/cross-repository references, and Markdown pseudo-anchors are `blocked` or `migration-required`.
-2. Separate discoverable facts from user decisions; investigate facts instead of asking the user.
-3. Ask the entire current decision frontier, with a recommendation for every question, then wait.
-4. Keep candidate or disputed terms in the Plan decision frontier. Only after confirmation, use `domain-modeling` to record true stable glossary entries in the repository root's single, case-sensitive `CONTEXT.md`; business rows use the five-column format and `<ContextId>/<EnglishIdentifier>` identity. Non-`Global` Context IDs must come from the approved business responsibility areas in the business-boundary asset.
-5. Create an ADR only when the decision is hard to reverse, surprising without context, and a real trade-off.
-6. Persist factual research/validation records in the repository's existing review or research convention.
-7. For `project-instance`, before requesting approval or returning a next work unit, generate and validate `context_reconciliation` with a readable ref, `document_digest`, `referenced_terms_digest`, and `term_refs`. Unresolved candidates, scope conflicts, aliases, or digest drift are `blocked`; reconciliation does not create another gate. For `template-source`, do not add fictional business terms and return a reasoned `not-applicable` after validating the template contract.
-8. Do not modify implementation skills, contracts, or code until the user confirms shared understanding and the intended change scope.
-
-The final grilling round must list confirmed decisions, unresolved assumptions, documents changed, `context_reconciliation` status/ref, and the next authorized action, then return control to `yss-product-lifecycle` (or the active YSS lifecycle orchestrator). It cannot approve an asset or advance a stage itself. A research note is evidence, not an architecture approval or release claim.

package/template/.agents/skills/grill-with-docs/agents/openai.yaml

@@ -1,5 +0,0 @@
-interface:
-  display_name: "Grill with Docs"
-  short_description: "Grill a design and write its docs"
-policy:
-  allow_implicit_invocation: false

package/template/.agents/skills/improve-codebase-architecture/SKILL.md

@@ -1,75 +0,0 @@
----
-name: improve-codebase-architecture
-description: 显式分析代码结构的维护成本、模块边界与可测试性，提出有证据的重构候选。
-disable-model-invocation: true
----
-
-# Improve Codebase Architecture
-
-Surface architectural friction and propose **deepening opportunities** — refactors that turn shallow modules into deep ones. The aim is testability and AI-navigability.
-
-This command is _informed_ by the project's domain model and built on a shared design vocabulary:
-
-- Run the `/codebase-design` skill for the architecture vocabulary (**module**, **interface**, **depth**, **seam**, **adapter**, **leverage**, **locality**) and its principles (the deletion test, "the interface is the test surface", "one adapter = hypothetical seam, two = real"). Use this analysis vocabulary without overriding CONTEXT or the project's component/service/API terminology.
-- The domain language in `CONTEXT.md` gives names to good seams; ADRs in `docs/adr/` record decisions this command should not re-litigate.
-
-## Process
-
-### 1. Explore
-
-**Scope before you scan — YAGNI.** Deepening a module pays off by making future changes to it easier, so put extra weight on the parts of the codebase that have recently changed. Decide *where* to look before you look:
-
-- If the user named a direction — a module, a subsystem, a pain point — take it, and skip the inference below.
-- Otherwise, walk back a good stretch of the commit history (`git log --oneline`) to find the codebase's hot spots — the files and areas that keep coming up — and let those paths pull your attention first. If the changes are scattered with no clear hot spot, widen the net.
-
-Read the project's domain glossary (`CONTEXT.md`) and any ADRs in the area you're touching first.
-
-Inspect the bounded area directly; delegate an independent reading task only when useful parallel work exists. Note evidence of friction:
-
-- Where does understanding one concept require bouncing between many small modules?
-- Where are modules **shallow** — interface nearly as complex as the implementation?
-- Where have pure functions been extracted just for testability, but the real bugs hide in how they're called (no **locality**)?
-- Where do tightly-coupled modules leak across their seams?
-- Which parts of the codebase are untested, or hard to test through their current interface?
-
-Apply the **deletion test** to anything you suspect is shallow: would deleting it concentrate complexity, or just move it? A "yes, concentrates" is the signal you want.
-
-### 2. Present candidates in the requested format
-
-Default to concise Markdown with grounded paths, tradeoffs and a small diagram when useful. Use the HTML branch below only when requested or when interaction materially aids comparison. Local/offline delivery uses bundled assets, not mandatory CDN dependencies.
-
-#### Optional HTML report
-
-Write a self-contained HTML file to the OS temp directory so nothing lands in the repo. Resolve the temp dir from `$TMPDIR`, falling back to `/tmp` (or `%TEMP%` on Windows), and write to `<tmpdir>/architecture-review-<timestamp>.html` so each run gets a fresh file. Open it for the user — `xdg-open <path>` on Linux, `open <path>` on macOS, `start <path>` on Windows — and tell them the absolute path.
-
-When an online HTML report is explicitly selected, Tailwind and Mermaid are optional tools for layout and diagrams where a graph/flow/sequence reliably communicates the structure. Mix Mermaid with hand-crafted CSS/SVG visuals — use Mermaid when relationships are graph-shaped (call graphs, dependencies, sequences), and hand-built divs/SVG when you want something more editorial (mass diagrams, cross-sections, collapse animations). Each candidate gets a **before/after visualisation**. Be visual.
-
-For each candidate, render a card with:
-
-- **Files** — which files/modules are involved
-- **Problem** — why the current architecture is causing friction
-- **Solution** — plain English description of what would change
-- **Benefits** — explained in terms of locality and leverage, and how tests would improve
-- **Before / After diagram** — side-by-side, custom-drawn, illustrating the shallowness and the deepening
-- **Recommendation strength** — one of `Strong`, `Worth exploring`, `Speculative`, rendered as a badge
-
-End the report with a **Top recommendation** section: which candidate you'd tackle first and why.
-
-**Use CONTEXT.md vocabulary for the domain, and the `/codebase-design` vocabulary for the architecture.** If `CONTEXT.md` defines "Order," talk about "the Order intake module" — not "the FooBarHandler," and not "the Order service."
-
-**ADR conflicts**: if a candidate contradicts an existing ADR, only surface it when the friction is real enough to warrant revisiting the ADR. Mark it clearly in the card (e.g. a warning callout: _"contradicts ADR-0007 — but worth reopening because…"_). Don't list every theoretical refactor an ADR forbids.
-
-See [HTML-REPORT.md](HTML-REPORT.md) for the full HTML scaffold, diagram patterns, and styling guidance.
-
-Do NOT propose interfaces yet. After presenting candidates, ask which unresolved design direction to explore only if that choice has not already been made.
-
-### 3. Grilling loop
-
-Once the user picks a candidate, run the `/grilling` skill to walk the decision tree with them — constraints, dependencies, the shape of the deepened module, what sits behind the seam, what tests survive.
-
-Side effects happen inline as decisions crystallize — run the `/domain-modeling` skill to keep the domain model current as you go:
-
-- **Naming a deepened module after a concept not in `CONTEXT.md`?** Add the term to `CONTEXT.md`. Create the file lazily if it doesn't exist.
-- **Sharpening a fuzzy term during the conversation?** Update `CONTEXT.md` right there.
-- **User rejects the candidate with a load-bearing reason?** Offer an ADR, framed as: _"Want me to record this as an ADR so future architecture reviews don't re-suggest it?"_ Only offer when the reason would actually be needed by a future explorer to avoid re-suggesting the same thing — skip ephemeral reasons ("not worth it right now") and self-evident ones.
-- **Want to explore alternative interfaces for the deepened module?** Run the `/codebase-design` skill and use its design-it-twice parallel sub-agent pattern.

package/template/.agents/skills/improve-codebase-architecture/agents/openai.yaml

@@ -1,5 +0,0 @@
-interface:
-  display_name: "Improve Codebase Architecture"
-  short_description: "Find and grill architecture improvements"
-policy:
-  allow_implicit_invocation: false

package/template/.agents/skills/prototype/UI.md

@@ -1,112 +0,0 @@
-# UI Prototype
-
-Generate **several radically different UI variations** on a single route, switchable from a floating bottom bar. The user flips between variants in the browser, picks one (or steals bits from each), then throws the rest away.
-
-If the question is about logic/state rather than what something looks like — wrong branch. Use [LOGIC.md](LOGIC.md).
-
-## When this is the right shape
-
-- "What should this page look like?"
-- "I want to see a few options for this dashboard before committing."
-- "Try a different layout for the settings screen."
-- Any time the user would otherwise spend a day picking between three vague mockups in their head.
-
-## Two sub-shapes — strongly prefer sub-shape A
-
-A UI prototype is much easier to judge when it's **butting up against the rest of the app** — real header, real sidebar, real data, real density. A throwaway route on its own is a vacuum: every variant looks fine in isolation. Default to sub-shape A whenever there's a plausible existing page to host the variants. Only reach for sub-shape B if the prototype genuinely has no nearby home.
-
-### Sub-shape A — adjustment to an existing page (preferred)
-
-The route already exists. Variants are rendered **on the same route**, gated by a `?variant=` URL search param. The existing data fetching, params, and auth all stay — only the rendering swaps. This is the default; pick it unless there's a specific reason not to.
-
-If the prototype is for something that doesn't yet have a page but *would naturally live inside one* (a new section of the dashboard, a new card on the settings screen, a new step in an existing flow) — that's still sub-shape A. Mount the variants inside the host page.
-
-### Sub-shape B — a new page (last resort)
-
-Only use this when the thing being prototyped genuinely has no existing page to live inside — e.g. an entirely new top-level surface, or a flow that can't be embedded anywhere sensible.
-
-Create a **throwaway route** following whatever routing convention the project already uses — don't invent a new top-level structure. Name it so it's obviously a prototype (e.g. include the word `prototype` in the path or filename). Same `?variant=` pattern.
-
-Before committing to sub-shape B, sanity-check: is there really no existing page this could be embedded in? An empty route hides design problems that a populated one would expose.
-
-In both sub-shapes the floating bottom bar is identical.
-
-## Process
-
-### 1. State the question and pick N
-
-Default to **3 variants**. More than 5 stops being radically different and starts being noise — cap there.
-
-Write down the plan in one line, in the prototype's location or a top-of-file comment:
-
-> "Three variants of the settings page, switchable via `?variant=`, on the existing `/settings` route."
-
-This works whether the user is here to push back or not.
-
-### 2. Generate radically different variants
-
-Draft each variant. Hold each one to:
-
-- The page's purpose and the data it has access to.
-- The project's component library / styling system (TailwindCSS, shadcn, MUI, plain CSS, whatever).
-- A clear exported component name, e.g. `VariantA`, `VariantB`, `VariantC`.
-
-Variants must be **structurally different** — different layout, different information hierarchy, different primary affordance, not just different colours. Three slightly-tweaked card grids isn't a UI prototype, it's wallpaper. If two drafts come out too similar, redo one with explicit "do not use a card grid" guidance.
-
-### 3. Wire them together
-
-Create a single switcher component on the route:
-
-```tsx
-// pseudo-code — adapt to the project's framework
-const variant = searchParams.get('variant') ?? 'A';
-return (
-  <>
-    {variant === 'A' && <VariantA {...data} />}
-    {variant === 'B' && <VariantB {...data} />}
-    {variant === 'C' && <VariantC {...data} />}
-    <PrototypeSwitcher variants={['A','B','C']} current={variant} />
-  </>
-);
-```
-
-For sub-shape A (existing page): keep all the existing data fetching above the switcher; only the rendered subtree changes per variant.
-
-For sub-shape B (new page): the throwaway route under `/prototype/<name>` mounts the same switcher.
-
-### 4. Build the floating switcher
-
-A small fixed-position bar at the bottom-centre of the screen with three pieces:
-
-- **Left arrow** — cycles to the previous variant (wraps around).
-- **Variant label** — shows the current variant key and, if the variant exports a name, that name too. e.g. `B — Sidebar layout`.
-- **Right arrow** — cycles forward (wraps around).
-
-Behaviour:
-
-- Clicking an arrow updates the URL search param (use the framework's router — `router.replace` on Next, `navigate` on React Router, etc) so the variant is shareable and reload-stable.
-- Keyboard: `←` and `→` arrow keys also cycle. Don't intercept arrow keys when an `<input>`, `<textarea>`, or `[contenteditable]` is focused.
-- Visually distinct from the page (e.g. high-contrast pill, subtle shadow) so it's obviously not part of the design being evaluated.
-- Hidden in production builds — gate on `process.env.NODE_ENV !== 'production'` or an equivalent check, so a stray prototype merge can't ship the bar to users.
-
-Put the switcher in a single shared component so both sub-shapes can reuse it. Locate it wherever shared UI lives in the project.
-
-### 5. Hand it over
-
-Surface the URL (and the `?variant=` keys). The user will flip through whenever they get to it. The interesting feedback is usually **"I want the header from B with the sidebar from C"** — that's the actual design they want.
-
-### 6. Capture the answer and clean up
-
-Once a variant has won, capture the answer — which variant and why — then capture the prototype the way the [SKILL](SKILL.md) describes. Fold the winner into the real code and move the rest onto the throwaway branch, not into main:
-
-- **Sub-shape A** — fold the winner into the existing page; drop the losing variants and the switcher from main.
-- **Sub-shape B** — promote the winning variant to a real route; drop the throwaway route and the switcher from main.
-
-The full set of variants is the primary source, so it lands on the throwaway branch, not the bin — variant components and the switcher left in the main branch rot fast and confuse the next reader.
-
-## Anti-patterns
-
-- **Variants that differ only in colour or copy.** That's a tweak, not a prototype. Real variants disagree about structure.
-- **Sharing too much code between variants.** A shared `<Header>` is fine; a shared `<Layout>` defeats the point. Each variant should be free to throw out the layout.
-- **Wiring variants to real mutations.** Read-only prototypes are fine. If a variant needs to mutate, point it at a stub — the question is "what should this look like", not "does the backend work".
-- **Promoting the prototype directly to production.** The variant code was written under prototype constraints (no tests, minimal error handling). Rewrite it properly when you fold it in.

package/template/.agents/skills/setup-matt-pocock-skills/domain.md

@@ -1,37 +0,0 @@
-# Domain Docs
-
-How the engineering skills should consume this repo's domain documentation when exploring the codebase.
-
-## Before exploring, read these
-
-- **`CONTEXT.md`** — the single case-sensitive glossary at the Git repository root. Its `context_schema_version` must be supported. A missing root file, lowercase or nested replacement, duplicate, or map-based layout is `blocked` / `migration-required`, not an optional omission.
-- **`docs/adr/`** — if it exists, read ADRs that touch the area you're about to work in. This directory is created lazily when the first qualifying decision is accepted.
-
-When the repository exposes `scripts/verify-context-contract`, run it before creating or changing stable domain, product, architecture, implementation, review, release, or retrospective assets.
-
-## File structure
-
-Every YSS Git repository:
-
-```
-/
-├── CONTEXT.md
-├── docs/adr/
-│   ├── 0001-event-sourced-orders.md
-│   └── 0002-postgres-for-write-model.md
-└── src/
-```
-
-Multiple business responsibility areas do not create additional glossary files. Each stable business term records its approved PascalCase `适用业务责任区`, and consumers reference it as `<ContextId>/<EnglishIdentifier>`. Use `Global/<EnglishIdentifier>` only for language that is genuinely shared across responsibility areas.
-
-## Use the glossary's vocabulary
-
-When your output names a domain concept (in an issue title, a refactor proposal, a hypothesis, a test name), use the term and stable reference defined in `CONTEXT.md`. Don't drift to synonyms the glossary explicitly avoids.
-
-If the concept you need isn't in the glossary yet, that's a signal — either you're inventing language the project doesn't use (reconsider) or there's a real gap (note it for `/domain-modeling`).
-
-## Flag ADR conflicts
-
-If your output contradicts an existing ADR, surface it explicitly rather than silently overriding:
-
-> _Contradicts ADR-0007 (event-sourced orders) — but worth reopening because…_

package/template/.agents/skills/to-questionnaire/SKILL.md

@@ -1,55 +0,0 @@
----
-name: to-questionnaire
-description: Turn a decision you can't fully answer into a questionnaire for someone else to fill in.
-disable-model-invocation: true
----
-
-Turn something the user can't answer alone into a **questionnaire** — a Markdown document they hand to one person to fill in async, or fill out together over a meeting. The recipient holds knowledge the user lacks; the questionnaire pulls it out of them.
-
-**Grill the send, not the subject.** Interview the user only about the _send_, which they can always answer: who it goes to, and what they need back. The questions in the document then target the **gap** between what the recipient knows and what the user needs.
-
-Reuse the recipient, purpose and constraints already provided. Ask only for missing information that changes the questionnaire; when both are known, draft directly.
-
-1. **Who is it going to?** If missing, ask for the recipient's role, expertise, and relationship to the user. This fixes the questionnaire's tone and how much context it must carry. Done when you know who the recipient is and what they know that the user doesn't.
-
-2. **What do you need back?** If missing, ask for the specific decisions or facts the user can't resolve alone and needs from this person. Done when you have a concrete list of what the user must walk away able to do or decide.
-
-3. **Write the questionnaire.** Draft questions aimed at the gap from steps 1–2, following the Document structure below. Write it to `to-questionnaire-<slug>.md` in the current directory (slug from the topic) and report the path. Done when the file exists and every item the user named in step 2 is covered by a question.
-
-## Document structure
-
-Frame the document as a **discovery questionnaire**: the user lacks context, the recipient holds it. Order questions most-important-first — async means you may only get one pass — and group them under `##` headings by theme once there are more than a handful. Write it using the template below.
-
-<questionnaire-template>
-
-# <Questionnaire title>
-
-**Purpose:** why this questionnaire exists and the decision riding on it.
-
-**From:** <the user> — **To:** <the recipient> — **How your answers will be used:** <where they go>
-
-## Context
-
-One paragraph orienting a recipient who wasn't in the user's head. Enough to answer well, not a page.
-
-## How to answer
-
-Deadline and rough effort. Partial answers and "I don't know" are useful — flag anything you're unsure of rather than skipping it.
-
-## <Theme heading>
-
-One `##` section per theme. Under each, its questions, most-important-first. Every question is one idea — never compound — with an answer stub directly beneath, and a one-line _why this matters_ only where the question could be misread or invite a throwaway answer.
-
-<question-example>
-### What load is the system expected to handle at launch?
-
-_Why this matters: it decides whether we provision for burst traffic now or defer it._
-
->
-</question-example>
-
-## Anything else?
-
-A closing catch-all: anything we didn't ask that we should know?
-
-</questionnaire-template>

package/template/.agents/skills/to-questionnaire/agents/openai.yaml

@@ -1,5 +0,0 @@
-interface:
-  display_name: "To Questionnaire"
-  short_description: "Front-load questions into a doc for someone to answer"
-policy:
-  allow_implicit_invocation: false

package/template/.agents/skills/wait-what/SKILL.md

@@ -1,7 +0,0 @@
----
-name: wait-what
-description: "Stop. That last message did not land: re-pitch it."
-disable-model-invocation: true
----
-
-用用户当前使用的语言，补足刚才说明所缺的背景并重新解释。保持简明、具体，复用仓库根目录唯一 `CONTEXT.md` 的词汇；跨业务责任区按 `<ContextId>/<EnglishIdentifier>` 定位。只改表达，不启动完整生命周期或重建上下文。

package/template/.agents/skills/wait-what/agents/openai.yaml

@@ -1,5 +0,0 @@
-interface:
-  display_name: "Wait What"
-  short_description: "Re-pitch that — simpler, with the context I'm missing"
-policy:
-  allow_implicit_invocation: false

package/template/.agents/skills/yss-prototype-stage/assets/antd-authoring/package.json

@@ -1,16 +0,0 @@
-{
-  "name": "yss-antd-prototype-authoring",
-  "version": "1.0.0",
-  "private": true,
-  "type": "module",
-  "packageManager": "pnpm@10.15.0",
-  "dependencies": {
-    "antd": "6.6.4",
-    "react": "19.2.4",
-    "react-dom": "19.2.4"
-  },
-  "devDependencies": {
-    "esbuild": "0.28.2",
-    "@ant-design/cli": "6.6.4"
-  }
-}