create-yss-spec 3.3.1 → 3.3.3

package/template/.claude/skills/page-skeleton/examples/StandardListPage/hooks/useRuleActions.ts

@@ -1,65 +0,0 @@
-import { computed } from 'vue';
-import { message } from 'ant-design-vue';
-import type { YTableActionConfig } from '@yss-ui/components';
-import { getApiApi } from '@/api/generated/quality';
-import type { QualityRuleItem } from '../constant';
-
-const { deleteQualityRule } = getApiApi();
-
-/** 行操作与页面容器的通信回调。 */
-export interface RuleActionCallbacks {
-  refreshList: () => Promise<void>;
-  onCreate: () => void;
-  onEdit: (row: QualityRuleItem) => void;
-  onView: (row: QualityRuleItem) => void;
-}
-
-/** YTable 气泡确认助手。 */
-interface ActionHelpers {
-  close: () => void;
-  hideLoading: () => void;
-}
-
-/** 管理质量规则行操作和 YTable 操作列配置。 */
-export const useRuleActions = (callbacks: RuleActionCallbacks) => {
-  /** 删除规则并刷新列表。 */
-  const handleDelete = async (row: QualityRuleItem): Promise<void> => {
-    if (!row.id) return;
-
-    try {
-      await deleteQualityRule(row.id);
-      message.success('删除成功');
-      await callbacks.refreshList();
-    } catch {
-      // mutator 已展示错误，此处不重复 message.error。
-    }
-  };
-
-  /** 标准操作列：查看/编辑立即执行，删除使用气泡确认。 */
-  const actionConfig = computed<YTableActionConfig>(() => ({
-    title: '操作',
-    width: 180,
-    fixed: 'right',
-    buttons: [
-      { label: '查看', value: 'view', click: ({ row }) => callbacks.onView(row) },
-      { label: '编辑', value: 'edit', click: ({ row }) => callbacks.onEdit(row) },
-      {
-        label: '删除',
-        value: 'delete',
-        type: 'link',
-        isConfirm: true,
-        confirmProps: { title: '确认删除此规则吗？删除后无法恢复', needLoading: true },
-        click: async ({ row }, _button, helpers: ActionHelpers) => {
-          try {
-            await handleDelete(row);
-          } finally {
-            helpers.hideLoading();
-            helpers.close();
-          }
-        },
-      },
-    ],
-  }));
-
-  return { actionConfig, handleCreate: callbacks.onCreate };
-};

package/template/.claude/skills/page-skeleton/examples/StandardListPage/index.vue

@@ -1,91 +0,0 @@
-<script setup lang="ts">
-import { onMounted, ref } from 'vue';
-import { Input as AInput } from 'ant-design-vue';
-import { YButton, YCard, YTable } from '@yss-ui/components';
-import { useTableHeight } from '@yss-ui/hooks';
-import { TABLE_COLUMNS, type QualityRuleItem } from './constant';
-import { useQualityRuleList } from './hooks/useQualityRuleList';
-import { useRuleActions } from './hooks/useRuleActions';
-
-defineOptions({ name: 'StandardListPage' });
-
-const emit = defineEmits<{
-  create: [];
-  edit: [row: QualityRuleItem];
-  view: [row: QualityRuleItem];
-}>();
-
-const tableAreaRef = ref<HTMLDivElement>();
-const { tableHeight, isReady } = useTableHeight(tableAreaRef, {
-  withPagination: true,
-  withToolbar: true,
-});
-const { tableData, loading, pagination, searchForm, fetchList, handlePageChange, handleSearch, handleReset } =
-  useQualityRuleList();
-const { actionConfig, handleCreate } = useRuleActions({
-  refreshList: fetchList,
-  onCreate: () => emit('create'),
-  onEdit: row => emit('edit', row),
-  onView: row => emit('view', row),
-});
-
-/** 查看规则详情。 */
-const handleRuleNameClick = (row: QualityRuleItem): void => {
-  emit('view', row);
-};
-
-onMounted(() => {
-  void fetchList();
-});
-</script>
-
-<template>
-  <div class="quality-rule-page">
-    <YCard class="quality-rule-page__search-card">
-      <div class="quality-rule-page__search-content">
-        <AInput
-          v-model:value="searchForm.ruleName"
-          class="quality-rule-page__keyword"
-          placeholder="请输入规则名称"
-          allow-clear
-          @press-enter="handleSearch"
-        />
-        <div class="quality-rule-page__search-actions">
-          <YButton @click="handleReset">重置</YButton>
-          <YButton type="primary" :loading="loading" @click="handleSearch">查询</YButton>
-        </div>
-      </div>
-    </YCard>
-
-    <YCard class="quality-rule-page__table-card">
-      <div ref="tableAreaRef" class="quality-rule-page__table-area">
-        <YTable
-          v-if="isReady"
-          :data="tableData"
-          :columns="TABLE_COLUMNS"
-          :loading="loading"
-          :height="tableHeight"
-          :action-config="actionConfig"
-          :toolbar-config="{ custom: true }"
-          pageable
-          v-model:pagination="pagination"
-          @page-change="handlePageChange"
-        >
-          <template #toolbar-right>
-            <YButton @click="fetchList">刷新</YButton>
-            <YButton type="primary" @click="handleCreate">新增质量规则</YButton>
-          </template>
-          <template #ruleName="{ row }">
-            <button class="quality-rule-page__rule-link" type="button" @click="handleRuleNameClick(row)">
-              {{ row.ruleName ?? '-' }}
-            </button>
-          </template>
-        </YTable>
-      </div>
-    </YCard>
-  </div>
-</template>
-
-<style scoped lang="less">
-@import url('./style.less');
-</style>

package/template/.claude/skills/page-skeleton/examples/StandardListPage/style.less

@@ -1,49 +0,0 @@
-.quality-rule-page {
-  display: flex;
-  flex-direction: column;
-  width: 100%;
-  height: 100%;
-  min-height: 0;
-  gap: 12px;
-
-  &__search-content {
-    display: flex;
-    flex-direction: column;
-    gap: 12px;
-  }
-
-  &__keyword {
-    width: min(100%, 360px);
-  }
-
-  &__search-actions {
-    display: flex;
-    justify-content: flex-end;
-    gap: 8px;
-  }
-
-  &__table-card,
-  &__table-area {
-    flex: 1;
-    min-height: 0;
-  }
-
-  &__rule-link {
-    padding: 0;
-    color: var(--primary-color, #3371ff);
-    background: transparent;
-    border: 0;
-    cursor: pointer;
-
-    &:hover,
-    &:focus-visible {
-      color: var(--primary-color-hover, #4096ff);
-      text-decoration: underline;
-    }
-
-    &:focus-visible {
-      outline: 2px solid color-mix(in srgb, var(--primary-color, #3371ff) 35%, transparent);
-      outline-offset: 2px;
-    }
-  }
-}

package/template/.claude/skills/prototype/LOGIC.md

@@ -1,67 +0,0 @@
-# Logic Prototype
-
-A single, self-contained HTML file — a **shareable demo** — that lets anyone drive a state model by clicking buttons. Use this when the question is about **business logic, state transitions, or data shape** — the kind of thing that looks reasonable on paper but only feels wrong once you push it through real cases.
-
-Because it's one file with nothing to install, you can hand it to a non-developer — a designer, a PM, a domain expert — and let them feel the model for themselves. So it speaks their language, not the code's.
-
-## When this is the right shape
-
-- "I'm not sure if this state machine handles the edge case where X then Y."
-- "Does this data model actually let me represent the case where..."
-- "I want to feel out what the API should look like before writing it."
-- Anything where someone wants to **press buttons and watch state change**.
-
-If the question is "what should this look like" — wrong branch. Use [UI.md](UI.md).
-
-## Process
-
-### 1. State the question
-
-Before writing code, write down what state model and what question you're prototyping. One paragraph, at the top of the demo (in a visible intro, not just a comment). A logic prototype that answers the wrong question is pure waste — make the question explicit so it can be checked later, whether the user is watching now or returning to it AFK.
-
-### 2. Isolate the logic in a portable module
-
-Put the actual logic — the bit that's answering the question — in a single `<script>` block written as a small, pure module that could be lifted out and dropped into the real codebase later. The page around it is throwaway; this module isn't.
-
-The right shape depends on the question:
-
-- **A pure reducer** — `(state, action) => state`. Good when actions are discrete events and state is a single value.
-- **A state machine** — explicit states and transitions. Good when "which actions are even legal right now" is part of the question.
-- **A small set of pure functions** over a plain data type. Good when there's no implicit current state — just transformations.
-- **A class or module with a clear method surface** when the logic genuinely owns ongoing internal state.
-
-Pick whichever shape best fits the question being asked, *not* whichever is easiest to wire to a page. Keep it pure: no DOM, no `document`, no button handlers reaching inside it. The page calls into it; nothing flows the other direction. This is what makes the prototype useful past its own lifetime: once the question's answered, the validated reducer / machine / function set lifts into the real module on its own.
-
-### 3. Build the shareable HTML file
-
-One file, plain HTML/CSS/JS — no framework, no bundler, no server, everything inline so it opens by double-click and survives being emailed around. Anyone should be able to run it by opening it.
-
-Write it for a non-developer. Every label is in **domain language**, not code — buttons and state read like the business, not the reducer. Explain in plain words what's happening.
-
-Lay it out with a clean hierarchy, top to bottom:
-
-1. **Title and one-line explanation** of what this demo lets you explore (the question from step 1).
-2. **Current state** — the full relevant state, rendered as a readable panel (labelled fields, not a raw JSON dump), re-rendered after every click so the change is visible. Where it helps a non-developer follow, call out what just changed.
-3. **Free-play buttons** — one button per action, always available, so anyone can poke at the model in any order. Each click dispatches its action and re-renders the state.
-4. **Guided walkthroughs** — a set of **scenarios**, one per tab. Each tab holds a short plain-language description of the scenario — the situation it sets up and what to watch for — and underneath it, the ordered **buttons to press** for that scenario. Each step is a real button: clicking it performs that action and moves to the next step. Starting a walkthrough resets to a known initial state so the scenario runs the same way every time.
-
-Choose scenarios that demonstrate the awkward cases — the happy path, a tricky edge case, an attempt at something that should be illegal — the ones hard to reason about on paper.
-
-Keep it beautiful but restrained: clean typography, generous spacing, one accent colour. No animations, no gimmicks — nothing that competes with the state and the buttons.
-
-### 4. Hand it over
-
-Send them the file, or open it for them. They'll click through the walkthroughs and free-play whenever they get to it; the interesting moments are when they say "wait, that shouldn't be possible" or "huh, I assumed X would be different" — those are the bugs in the _idea_, which is the whole point. If they want new actions or a new scenario, add them. Prototypes evolve.
-
-### 5. Capture the answer and the prototype
-
-Once the prototype has answered its question, capture the answer, then capture the prototype the way the [SKILL](SKILL.md) describes. The logic-specific mapping: the validated reducer / machine / function set lifts into the real module (the decision, absorbed); the HTML shell rides along to the throwaway branch that keeps the prototype as a primary source — and being one self-contained file, it stays trivially re-runnable there.
-
-## Anti-patterns
-
-- **Don't add tests.** A prototype that needs tests is no longer a prototype.
-- **Don't wire it to the real database.** Use in-memory state unless the question is specifically about persistence.
-- **Don't generalise.** No "what if we wanted to support X later." The prototype answers one question.
-- **Don't blur the logic and the page together.** If the pure module references the DOM, `document`, or button handlers, it's no longer liftable. Keep the page as a thin shell over a pure module.
-- **Don't reach for a framework, bundler, or server.** One file the recipient double-clicks; a React app or a dev server defeats "shareable".
-- **Don't ship the HTML shell into production.** The page is optimised for being clicked through by hand. The logic module behind it is the bit worth keeping.

package/template/.claude/skills/prototype/SKILL.md

@@ -1,26 +0,0 @@
----
-name: prototype
-description: Build a throwaway prototype to answer a design question. Use when the user wants to sanity-check whether a state model or logic feels right, or explore what a UI should look like.
----
-
-# Prototype
-
-A prototype is **throwaway code that answers a question**. The question decides the shape.
-
-## Pick a branch
-
-Identify which question is being answered — from the user's prompt, the surrounding code, or by asking if the user is around:
-
-- **"Does this logic / state model feel right?"** → [LOGIC.md](LOGIC.md). Build a single shareable HTML file — free-play buttons plus tabbed guided walkthroughs — that pushes the state machine through cases that are hard to reason about on paper, and that a non-developer can drive.
-- **"What should this look like?"** → [UI.md](UI.md). Generate several radically different UI variations on a single route, switchable via a URL search param and a floating bottom bar.
-
-The two branches produce very different artifacts — getting this wrong wastes the whole prototype. If the question is genuinely ambiguous and the user isn't reachable, default to whichever branch better matches the surrounding code (a backend module → logic; a page or component → UI) and state the assumption at the top of the prototype.
-
-## Rules that apply to both
-
-1. **Throwaway from day one, and clearly marked as such.** Locate the prototype code close to where it will actually be used (next to the module or page it's prototyping for) so context is obvious — but name it so a casual reader can see it's a prototype, not production. For throwaway UI routes, obey whatever routing convention the project already uses; don't invent a new top-level structure.
-2. **Trivial to run.** A UI prototype starts from one command in the project's task runner — `pnpm <name>`, `python <path>`, `bun <path>`, etc. A logic demo is a single HTML file the user double-clicks. Either way, no thinking required to start it.
-3. **No persistence by default.** State lives in memory. Persistence is the thing the prototype is _checking_, not something it should depend on. If the question explicitly involves a database, hit a scratch DB or a local file with a clear "PROTOTYPE — wipe me" name.
-4. **Skip the polish.** No tests, no error handling beyond what makes the prototype _runnable_, no abstractions. The point is to learn something fast.
-5. **Surface the state.** After every action (logic) or on every variant switch (UI), print or render the full relevant state so the user can see what changed.
-6. **Capture it when done.** Fold any validated decision into the real code, then capture the prototype itself as a **primary source**: commit it to a throwaway branch, out of main, and leave a context pointer to that branch on the implementation issue. Capture the answer too — the verdict and the question it settled — in the issue or a commit. The main branch keeps only the validated decision.

package/template/.claude/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/.claude/skills/prototype/agents/openai.yaml

@@ -1,3 +0,0 @@
-interface:
-  display_name: "Prototype"
-  short_description: "Prototype to answer a design question"

package/template/.claude/skills/prototype-review/SKILL.md

@@ -1,75 +0,0 @@
----
-name: prototype-review
-description: Use when independently reviewing low-fidelity UI, interaction specs, or state matrices before choosing an H1/H2 prototype profile, calibrating Spec/OpenAPI, slicing, or implementation.
----
-
-# Prototype Review
-
-Use this skill as the independent low-fidelity review in `yss-prototype-stage`. The review is fail-closed: if the design cannot drive calibrated requirements, API, frontend acceptance, and slices, send it back to product design. `yss-product-lifecycle` alone records the resulting `gate.prototype-reviewed` decision.
-
-## Trigger Boundary
-
-Run this independent gate only when UI changes affect a primary user flow, navigation, permissions, exception/recovery states, state transitions, or OpenAPI implications. For copy edits, token/color/spacing adjustments, and isolated visual fixes with no behavior, state, permission, navigation, or API impact, record `not-applicable` with the impact assessment; do not create prototype-review artifacts.
-
-## Required Inputs
-
-- Spec baseline or confirmed user stories.
-- `docs/.scratch/<feature>/design/<feature>-interaction-spec.md` or prototype link.
-- State matrix, preferably based on `docs/design/templates/state-matrix-template.md`.
-- Existing OpenAPI Draft only if the review is checking alignment; do not require OpenAPI before product design.
-- `docs/.scratch/<feature>/verification/prototype-evidence.yaml` may be created as a pending schema v3 record, but档位构建与浏览器验证属于后续 `gate.prototype-verified`。
-
-## Review Gates
-
-| Gate | Pass condition |
-|---|---|
-| Page coverage | All primary pages, entry points, and navigation exits are named |
-| Flow coverage | Main path, cancel/back, failure, retry, and completion paths are explicit |
-| State coverage | loading, empty, error, readonly, disabled, no-permission, conflict, and dirty-form states are addressed or explicitly not applicable |
-| State transition coverage | 每个状态列出进入事件、允许转换、guard、动作和退出路径；不存在只能进入不能退出的状态 |
-| Permission coverage | Hidden vs disabled vs rejected actions are clear |
-| Data coverage | Visible fields, filters, sort, pagination, forms, tables, drawers, modals, and audit/version data are listed |
-| API implication | Request/response fields, error structure, pagination/filtering, permissions, and concurrency implications can be drafted |
-| Action contract coverage | Every primary page action has an `actionKey`, endpoint or explicit non-goal, permission behavior, state transition, idempotency/concurrency rule, and error codes |
-| P0 contract coverage | Every P0 requirement with manage/maintain/configure/create/update/archive/retry/cancel/publish/export/create-draft semantics is mapped to an API implication or an explicit non-goal |
-| Rule/source coverage | Validation, approval, coverage, and publish gates state where rules come from, who can configure them, whether they are fixed, and how blocker/warning decisions are represented |
-| Frontend acceptance | A frontend engineer can tell which components, visible states, data dependencies, and E2E paths are needed |
-
-## Decision Rules
-
-- If a feature has UI impact and lacks page map, user flow, prototype/wireframe, or state matrix, block prototype profile selection, Spec calibration, and OpenAPI Draft.
-- If the prototype hides business rules behind generic text such as "校验失败", require field-level errors and recovery behavior.
-- If a page shows a user action but the OpenAPI implication list lacks endpoint/non-goal mapping, block prototype profile selection, Spec calibration, or OpenAPI Draft.
-- If Spec P0 scope says a user can manage or configure an object but the design only shows read-only data, block until the write path or scope downgrade is explicit.
-- If a state is intentionally out of scope, record why and who owns the decision.
-- If implementation dependencies are unclear, route to `yss-implementation-contract-compiler` only after the prototype passes this review.
-
-## Output Contract
-
-```markdown
-### Review Result
-<Approved / Blocked>
-
-### Blocking Findings
-- <missing asset or decision>
-
-### Non-Blocking Suggestions
-- <improvement that can wait>
-
-### OpenAPI Draft Readiness
-- <paths, fields, errors, permissions, pagination/YSS wrappers, action mappings, rule sources, concurrency notes>
-
-### Spec Calibration Readiness
-- <requirements gaps, acceptance criteria updates, non-goals, pending decisions>
-
-### Frontend Prototype Readiness
-- <component states, data dependencies, profile triggers, frontend acceptance notes>
-
-### Lifecycle Evidence
-- <persistent review path; blockers; `gate.prototype-reviewed` candidate result>
-
-### Next Action
-- <yss-prototype-stage / return to product design>
-```
-
-Use `docs/design/templates/prototype-review-checklist.md` when writing a persistent review artifact.

package/template/.claude/skills/prototype-review/agents/openai.yaml

@@ -1,4 +0,0 @@
-interface:
-  display_name: "Prototype Review"
-  short_description: "Gate UI prototypes before Spec calibration"
-  default_prompt: "Use $prototype-review to review prototype readiness before Spec calibration and OpenAPI Draft."

package/template/.claude/skills/resolving-merge-conflicts/SKILL.md

@@ -1,14 +0,0 @@
----
-name: resolving-merge-conflicts
-description: "Use when you need to resolve an in-progress git merge/rebase conflict."
----
-
-1. **See the current state** of the merge/rebase. Check git history, and the conflicting files.
-
-2. **Find the primary sources** for each conflict. Understand deeply why each change was made, and what the original intent was. Read the commit messages, check the PRs, check original issues/tickets.
-
-3. **Resolve each hunk.** Preserve both intents where possible. Where incompatible, pick the one matching the merge's stated goal and note the trade-off. Do **not** invent new behaviour. Always resolve; never `--abort`.
-
-4. Discover the project's **automated checks** and run them — typically typecheck, then tests, then format. Fix anything the merge broke.
-
-5. **Finish the merge/rebase.** Stage everything and commit. If rebasing, continue the rebase process until all commits are rebased.

package/template/.claude/skills/resolving-merge-conflicts/agents/openai.yaml

@@ -1,3 +0,0 @@
-interface:
-  display_name: "Resolving Merge Conflicts"
-  short_description: "Resolve merge and rebase conflicts"

package/template/.claude/skills/setup-matt-pocock-skills/SKILL.md

@@ -1,124 +0,0 @@
----
-name: setup-matt-pocock-skills
-description: Configure this repo for the engineering skills — set up its issue tracker, triage label vocabulary, and domain doc layout. Run once before first use of the other engineering skills.
-disable-model-invocation: true
----
-
-# Setup Matt Pocock's Skills
-
-Scaffold the per-repo configuration that the engineering skills assume:
-
-- **Issue tracker** — where issues live (GitHub by default; local markdown is also supported out of the box)
-- **Triage labels** — the strings used for the five canonical triage roles
-- **Domain docs** — where `CONTEXT.md` and ADRs live, and the consumer rules for reading them
-
-This is a prompt-driven skill, not a deterministic script. Explore, present what you found, confirm with the user, then write.
-
-## Process
-
-### 1. Explore
-
-Look at the current repo to understand its starting state. Read whatever exists; don't assume:
-
-- `git remote -v` and `.git/config` — is this a GitHub repo? Which one?
-- `AGENTS.md` and `CLAUDE.md` at the repo root — does either exist? Is there already an `## Agent skills` section in either?
-- The case-sensitive `CONTEXT.md` at the Git repository root; also detect lowercase, nested, or duplicate context files as migration problems
-- `docs/adr/` and any `src/*/docs/adr/` directories
-- `docs/agents/` — does this skill's prior output already exist?
-- `docs/.scratch/` — sign that the canonical local-markdown issue tracker convention is already in use
-- `.scratch/` and `docs/requirements/tickets/` — legacy local-tracker roots; inspect them read-only for migration and never use them as new write targets
-- Is the `triage` skill installed? (a `triage` skill folder alongside this one, or `triage` in your available skills.) This decides whether Section B runs at all.
-
-### 2. Present findings and ask
-
-Summarise what's present and what's missing. Then take the sections in order — one section, one answer, then the next.
-
-Lead each section with the recommended answer so the user can accept it in a word. Give a one-line explainer only when the choice genuinely branches; skip Section B entirely when `triage` isn't installed.
-
-**Section A — Issue tracker.**
-
-> Explainer: The "issue tracker" is where issues live for this repo. Skills like `to-tickets`, `triage`, and `to-spec` read from and write to it — they need to know whether to call `gh issue create`, write a markdown file under `docs/.scratch/`, or follow some other workflow you describe. Pick the place you actually track work for this repo.
-
-Path resolution is configuration-first: every Local-aware skill must read the
-persisted `tracker.root` from `docs/agents/issue-tracker.md` before resolving an
-artifact path. If the field is absent, use `docs/.scratch` as the default. Do
-not infer a tracker or replace the configured root from `git remote`; the legacy
-`.scratch/` and `docs/requirements/tickets/` roots are read-only migration
-sources.
-
-The supported tracker choices in this template are exactly `local-markdown`, `github`, and `gitlab`. A `git remote` may be displayed as code-host context only; it must not choose or rank a tracker. Ask for one explicit project choice, with Local Markdown as the template default:
-
-- **Local markdown (recommended)** — issues live as files under `docs/.scratch/<feature>/` in this repo.
-- **GitHub** — use GitHub Issues and the `gh` CLI only when the user explicitly selects GitHub.
-- **GitLab** — use GitLab Issues and the [`glab`](https://gitlab.com/gitlab-org/cli) CLI only when the user explicitly selects GitLab.
-
-Do not offer an `Other` tracker or write an unsupported platform into the project configuration; extending the YSS tracker contract must happen before adding another platform.
-
-Record the choice in `docs/agents/issue-tracker.md`. The GitHub and GitLab templates carry a "PRs as a request surface" flag, defaulted **off** — leave it off and don't raise it; a user who wants external PRs in the triage queue can flip the flag in the file later.
-
-**Section B — Triage label vocabulary.** Skip this section entirely if the `triage` skill isn't installed (exploration told you) — an uninstalled skill needs no labels.
-
-If it is installed, ask exactly one question:
-
-> Do you want to keep the default triage labels? (recommended: **yes**)
-
-The defaults are the five canonical roles, each label string equal to its name: `needs-triage`, `needs-info`, `ready-for-agent`, `ready-for-human`, `wontfix`. On **yes**, write them as-is. Only if the user says no — usually because their tracker already uses other names (e.g. `bug:triage` for `needs-triage`) — collect the overrides so `triage` applies existing labels instead of creating duplicates.
-
-**Section C — Business vocabulary and decisions.** The layout does not branch: every YSS Git repository has exactly one case-sensitive `CONTEXT.md` at its root. Multiple business responsibility areas share that glossary and are distinguished by each business term's `适用业务责任区` and stable `<ContextId>/<EnglishIdentifier>` reference. ADRs live under root `docs/adr/` and are created lazily when the first qualifying decision is accepted.
-
-If the root `CONTEXT.md` is missing, initialize it with `context_schema_version: 1`, the process-term table (`术语 | 含义 | 英文标识 | 避免 / 备注`) and the business-term table (`术语 | 含义 | 英文标识 | 适用业务责任区 | 避免 / 备注`). Do not invent business terms during setup. If a lowercase, nested, duplicate, or mapped context layout exists, stop and report `migration-required`; do not preserve or extend it as a second supported layout.
-
-### 3. Confirm and edit
-
-Show the user a draft of:
-
-- The `## Agent skills` block to add to whichever of `CLAUDE.md` / `AGENTS.md` is being edited (see step 4 for selection rules)
-- The contents of `docs/agents/issue-tracker.md`, `docs/agents/domain.md`, and `docs/agents/triage-labels.md` (the last only when `triage` is installed)
-
-Let them edit before writing.
-
-### 4. Write
-
-**Pick the file to edit:**
-
-- If `CLAUDE.md` exists, edit it.
-- Else if `AGENTS.md` exists, edit it.
-- If neither exists, ask the user which one to create — don't pick for them.
-
-Never create `AGENTS.md` when `CLAUDE.md` already exists (or vice versa) — always edit the one that's already there.
-
-If an `## Agent skills` block already exists in the chosen file, update its contents in-place rather than appending a duplicate. Don't overwrite user edits to the surrounding sections.
-
-The block:
-
-```markdown
-## Agent skills
-
-### Issue tracker
-
-[one-line summary of where issues are tracked]. See `docs/agents/issue-tracker.md`.
-
-### Triage labels
-
-[one-line summary of the label vocabulary]. See `docs/agents/triage-labels.md`.
-
-### Domain docs
-
-[one-line summary: one root `CONTEXT.md`, with bounded contexts represented inside its business glossary]. See `docs/agents/domain.md`.
-```
-
-Include the `### Triage labels` sub-block, and write `docs/agents/triage-labels.md`, only when `triage` is installed and Section B ran. When it isn't, both are omitted.
-
-Then write the docs files using the seed templates in this skill folder as a starting point:
-
-- [issue-tracker-github.md](./issue-tracker-github.md) — GitHub issue tracker
-- [issue-tracker-gitlab.md](./issue-tracker-gitlab.md) — GitLab issue tracker
-- [issue-tracker-local.md](./issue-tracker-local.md) — local-markdown issue tracker
-- [triage-labels.md](./triage-labels.md) — label mapping (only if `triage` is installed)
-- [domain.md](./domain.md) — domain doc consumer rules + layout
-
-For an unsupported tracker request, stop and require a YSS tracker-contract extension; do not write an unsupported platform into `docs/agents/issue-tracker.md`.
-
-### 5. Done
-
-Tell the user the setup is complete and which engineering skills will now read from these files. Mention they can edit `docs/agents/*.md` directly later — re-running this skill is only necessary if they want to switch issue trackers or restart from scratch.