create-yss-spec 1.1.2 → 1.1.4

package/template/.codex/skills/product-design/skills/user-context/scripts/user_context_preflight.py

@@ -0,0 +1,204 @@
+#!/usr/bin/env python3
+"""Read local Product Design context and print compact JSON."""
+
+from __future__ import annotations
+
+import argparse
+import hashlib
+import json
+import os
+import re
+import sys
+from datetime import datetime, timezone
+from pathlib import Path
+from typing import Any
+
+PLUGIN_STATE_DIR = Path("state/plugins/product-design")
+DEFAULT_MAX_CONTEXT_BYTES = 2_000_000
+
+
+def parse_args() -> argparse.Namespace:
+    parser = argparse.ArgumentParser(
+        description="Read Product Design user-context.md and return saved context as JSON."
+    )
+    parser.add_argument(
+        "--codex-home",
+        type=Path,
+        default=None,
+        help="Codex home directory. Defaults to $CODEX_HOME or ~/.codex.",
+    )
+    parser.add_argument(
+        "--state-dir",
+        type=Path,
+        default=None,
+        help="Override the Product Design state directory.",
+    )
+    parser.add_argument(
+        "--max-context-bytes",
+        type=int,
+        default=DEFAULT_MAX_CONTEXT_BYTES,
+        help="Maximum user-context.md size to read.",
+    )
+    return parser.parse_args()
+
+
+def resolve_state_dir(codex_home: Path | None, state_dir: Path | None) -> Path:
+    if state_dir is not None:
+        return state_dir.expanduser().resolve()
+    home = codex_home or Path(os.environ.get("CODEX_HOME", "~/.codex"))
+    return (home.expanduser() / PLUGIN_STATE_DIR).resolve()
+
+
+def file_mtime(path: Path) -> str | None:
+    try:
+        return datetime.fromtimestamp(path.stat().st_mtime, tz=timezone.utc).isoformat()
+    except OSError:
+        return None
+
+
+def sha256_text(text: str) -> str:
+    return hashlib.sha256(text.encode("utf-8")).hexdigest()
+
+
+def parse_resource_name(line: str) -> dict[str, str]:
+    link_match = re.match(r"^\[(.+?)\]\((.+?)\)\s*$", line)
+    if link_match:
+        return {"name": link_match.group(1).strip(), "url": link_match.group(2).strip()}
+    url_match = re.match(r"^(https?://\S+)\s*$", line)
+    if url_match:
+        return {"name": url_match.group(1).strip(), "url": url_match.group(1).strip()}
+    return {"name": line.strip()}
+
+
+def summarize_user_context(markdown: str) -> dict[str, Any]:
+    entries: list[dict[str, Any]] = []
+    unresolved_categories: list[str] = []
+    category: str | None = None
+    in_saved_context = False
+    current_entry: dict[str, Any] | None = None
+
+    def flush_entry() -> None:
+        nonlocal current_entry
+        if current_entry:
+            entries.append(current_entry)
+            current_entry = None
+
+    for raw_line in markdown.splitlines():
+        line = raw_line.strip()
+        if not line or line.startswith(("<!--", "-->")):
+            continue
+
+        category_match = re.match(r"^# ([^#].*?)\s*$", line)
+        if category_match:
+            flush_entry()
+            category = category_match.group(1).strip()
+            in_saved_context = False
+            continue
+
+        if line == "## Saved Links And Context":
+            flush_entry()
+            in_saved_context = True
+            continue
+
+        if not category or not in_saved_context:
+            continue
+
+        if line.casefold() == "status: not provided" or line.casefold() == "status: not provided.":
+            flush_entry()
+            unresolved_categories.append(category)
+            continue
+
+        if not line.startswith("- "):
+            flush_entry()
+            current_entry = {"category": category, **parse_resource_name(line)}
+            continue
+
+        if not current_entry:
+            continue
+
+        bullet = line[2:].strip()
+        for prefix, key in (
+            ("Date Added:", "date_added"),
+            ("File:", "file"),
+            ("Useful Context:", "useful_context"),
+            ("Future Use:", "future_use"),
+        ):
+            if bullet.startswith(prefix):
+                current_entry[key] = bullet[len(prefix) :].strip().rstrip(".")
+                break
+        else:
+            current_entry.setdefault("notes", []).append(bullet)
+
+    flush_entry()
+    return {"entries": entries, "unresolved_categories": unresolved_categories}
+
+
+def missing_payload(state_dir: Path, context_path: Path) -> dict[str, Any]:
+    return {
+        "plugin": "product-design",
+        "state_dir": str(state_dir),
+        "user_context": {
+            "path": str(context_path),
+            "exists": False,
+            "status": "missing",
+            "entries": [],
+            "unresolved_categories": [],
+        },
+    }
+
+
+def main() -> int:
+    args = parse_args()
+    state_dir = resolve_state_dir(args.codex_home, args.state_dir)
+    context_path = state_dir / "user-context.md"
+
+    if not context_path.exists():
+        print(json.dumps(missing_payload(state_dir, context_path), indent=2))
+        return 0
+
+    size = context_path.stat().st_size
+    if size > args.max_context_bytes:
+        print(
+            json.dumps(
+                {
+                    "plugin": "product-design",
+                    "state_dir": str(state_dir),
+                    "user_context": {
+                        "path": str(context_path),
+                        "exists": True,
+                        "status": "too_large",
+                        "size_bytes": size,
+                        "max_context_bytes": args.max_context_bytes,
+                        "entries": [],
+                        "unresolved_categories": [],
+                    },
+                },
+                indent=2,
+            )
+        )
+        return 0
+
+    markdown = context_path.read_text(encoding="utf-8")
+    summary = summarize_user_context(markdown)
+    print(
+        json.dumps(
+            {
+                "plugin": "product-design",
+                "state_dir": str(state_dir),
+                "user_context": {
+                    "path": str(context_path),
+                    "exists": True,
+                    "status": "present",
+                    "sha256": sha256_text(markdown),
+                    "modified_at": file_mtime(context_path),
+                    **summary,
+                },
+            },
+            indent=2,
+        )
+    )
+    return 0
+
+
+if __name__ == "__main__":
+    sys.exit(main())

package/template/.codex/skills/product-design/templates/prototype/AGENTS.md

@@ -0,0 +1,7 @@
+# Prototype Instructions
+
+Run the local server yourself and open the preview in the in-app browser. Do not give the user server-start instructions when you can run it.
+
+Before making substantial visual changes, use the Product Design plugin's `get-context` skill when the visual source is unclear or no longer matches the current goal. When the user gives durable prototype-specific design feedback, preferences, or decisions, record them in `AGENTS.md`.
+
+When implementing from a selected generated mock, treat that image as the source of truth for layout, component anatomy, density, spacing, color, typography, visible content, and hierarchy.

package/template/.codex/skills/product-design/templates/prototype/index.html

@@ -0,0 +1,12 @@
+<!doctype html>
+<html lang="en">
+  <head>
+    <meta charset="UTF-8" />
+    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
+    <title>Prototype</title>
+  </head>
+  <body>
+    <div id="root"></div>
+    <script type="module" src="/src/main.jsx"></script>
+  </body>
+</html>

package/template/.codex/skills/product-design/templates/prototype/package.json

@@ -0,0 +1,18 @@
+{
+  "name": "design-prototype",
+  "version": "0.0.0",
+  "private": true,
+  "type": "module",
+  "scripts": {
+    "dev": "vite --host 127.0.0.1",
+    "build": "vite build",
+    "preview": "vite preview --host 127.0.0.1"
+  },
+  "dependencies": {
+    "@vitejs/plugin-react": "5.0.4",
+    "vite": "6.4.2",
+    "react": "19.2.0",
+    "react-dom": "19.2.0"
+  },
+  "devDependencies": {}
+}

package/template/.codex/skills/product-design/templates/prototype/src/App.jsx

@@ -0,0 +1,5 @@
+export function App() {
+  return (
+    <main></main>
+  );
+}

package/template/.codex/skills/product-design/templates/prototype/src/main.jsx

@@ -0,0 +1,10 @@
+import React from "react";
+import { createRoot } from "react-dom/client";
+import { App } from "./App.jsx";
+import "./styles.css";
+
+createRoot(document.getElementById("root")).render(
+  <React.StrictMode>
+    <App />
+  </React.StrictMode>,
+);

package/template/.codex/skills/product-design/templates/prototype/src/styles.css

@@ -0,0 +1,13 @@
+:root {
+}
+
+* {
+  box-sizing: border-box;
+}
+
+body {
+  margin: 0;
+  min-width: 320px;
+  min-height: 100vh;
+  -webkit-font-smoothing: antialiased;
+}

package/template/.codex/skills/product-design/templates/prototype/vite.config.mjs

@@ -0,0 +1,14 @@
+import { defineConfig } from "vite";
+import react from "@vitejs/plugin-react";
+
+export default defineConfig({
+  optimizeDeps: {
+    include: ["react", "react-dom/client"],
+  },
+  server: {
+    warmup: {
+      clientFiles: ["./src/main.jsx"],
+    },
+  },
+  plugins: [react()],
+});

package/template/.codex/skills/product-design-prototype/SKILL.md

@@ -18,7 +18,7 @@ If no PRD baseline exists, route back to `yss-product-lifecycle` / `grill-with-d
 
 ## Core Flow
 
-1. Inspect current assets: PRD, `docs/design/`, `docs/api/specs/`, `docs/architecture/`, and active OpenSpec/Comet changes.
+1. Inspect current assets: PRD, `docs/design/`, `docs/api/specs/`, `docs/architecture/`, and active Spec Delta changes.
 2. Create or update a design artifact under `docs/design/<feature>-interaction-spec.md` using `docs/design/templates/interaction-spec-template.md`.
 3. Capture page map, primary user flow, exception flow, and low-fidelity prototype or wireframe link.
 4. Fill the state matrix using `docs/design/templates/state-matrix-template.md`.

package/template/.codex/skills/yss-api-integration/SKILL.md

@@ -18,7 +18,7 @@ description: Guide AI to correctly use Orval-generated API clients in Vue 3 micr
 
 1. **契约状态已明确**：
    - 已有生成客户端：可以直接集成。
-   - 新增或变更 API：必须先在 `docs/api/specs/` 形成 OpenAPI Draft，经工程基线 / 架构 / OpenSpec / Comet design 和设计审查后 Freeze，再进入生成和集成。
+   - 新增或变更 API：必须先在 `docs/api/specs/` 形成 OpenAPI Draft，经工程基线 / 架构 / Spec Delta 设计和设计审查后 Freeze，再进入生成和集成。
    - 如果接口尚未冻结或生成函数不存在，先回到 `yss-product-lifecycle` / `yss-openapi`，不要手写临时路径、DTO 或响应结构。
 2. **API 已生成**：运行 `pnpm generate:api` 生成最新 API
 3. **了解 OpenAPI**：查看 `openapi/openapi.json` 了解接口定义

package/template/.codex/skills/yss-ddd-scaffold-generator/references/yss-backend-scaffold-parent/SKILL.md

@@ -107,7 +107,7 @@ description: "YSS 服务的后端开发脚手架框架和技术指南。在开
   - 单个对象: `SingleResult<T>`
   - 列表: `MultiResult<T>`
   - 分页: `PageResult<T>`
-- 涉及新增或变更前后端契约时，先在 `docs/api/specs/` 形成 OpenAPI Draft，经工程基线、架构 / OpenSpec / Comet design 和设计审查后 Freeze，再实现 Controller、DTO、前端调用和契约测试。
+- 涉及新增或变更前后端契约时，先在 `docs/api/specs/` 形成 OpenAPI Draft，经工程基线、架构 / Spec Delta 设计和设计审查后 Freeze，再实现 Controller、DTO、前端调用和契约测试。
 
 ## 4. 工程基线检查清单
 

package/template/.codex/skills/yss-filerunner/SKILL.md

@@ -22,7 +22,7 @@ Read `references/source-index.md` as a path-hint index whenever the task depends
 1. Identify whether the task is running SQL/Python files, exposing file-runner APIs, parsing scheduler logs, or adding a new file execution type.
 2. Read `references/source-index.md`, then inspect `FileRunnerController`, `FileRunnerService`, `FileExecuterManager`, and concrete executers.
 3. Current supported `FileType` values are `SQL` and `PYTHON`; unsupported types throw `BizException`.
-4. `FileExecuterManager` depends on `SchedulerFacadeApi`; load `yss-anti-scheduler` when execution delegates to scheduler APIs.
+4. `FileExecuterManager` depends on `SchedulerFacadeApi`; inspect the filerunner source index and local scheduler integration code directly when execution delegates to scheduler APIs.
 5. For logs, inspect `DolphinLogParser` and `LogType`.
 6. For starter integration, inspect `DefaultFileRunnerConfiguration`.
 

package/template/.codex/skills/yss-openapi/SKILL.md

@@ -9,7 +9,7 @@ Use this skill to move an already implemented backend controller/DTO contract in
 
 This is an implementation/generation skill, not the product API design step and not the unified OpenAPI specification governance skill. It generates `openapi.json` from controller methods, request DTOs, response DTOs, annotations, and Java comments; it does not decide naming conventions, resource modeling, error taxonomy, pagination policy, permission semantics, or organization-wide OpenAPI style rules.
 
-For new or changed API contracts, first produce OpenAPI Draft in `docs/api/specs/`, pass engineering baseline, architecture / OpenSpec / Comet design, and Design Review, then Freeze the contract before using this skill to refresh generated clients. When the backend is already the implemented source of truth, use this skill to regenerate and inspect the emitted contract before updating call sites.
+For new or changed API contracts, first produce OpenAPI Draft in `docs/api/specs/`, pass engineering baseline, architecture / Spec Delta design, and Design Review, then Freeze the contract before using this skill to refresh generated clients. When the backend is already the implemented source of truth, use this skill to regenerate and inspect the emitted contract before updating call sites.
 
 ## Scope Boundary
 

package/template/.codex/skills/yss-openapi-draft-review/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: yss-openapi-draft-review
-description: "Use when reviewing a docs/api/specs OpenAPI Draft before Engineering Baseline, YSS DDD Review, architecture/OpenSpec/Comet design, OpenAPI Freeze, vertical slicing, frontend/backend implementation, or when checking P0 requirement coverage, page action to endpoint mapping, YSS response wrappers, errors, permissions, pagination, optimistic locking, security red lines, and contract test seams."
+description: "Use when reviewing a docs/api/specs OpenAPI Draft before Engineering Baseline, YSS DDD Review, architecture/Spec Delta design, OpenAPI Freeze, vertical slicing, frontend/backend implementation, or when checking P0 requirement coverage, page action to endpoint mapping, YSS response wrappers, errors, permissions, pagination, optimistic locking, security red lines, and contract test seams."
 ---
 
 # YSS OpenAPI Draft Review

package/template/.codex/skills/yss-openapi-governance/SKILL.md

@@ -15,13 +15,13 @@ Use `yss-openapi-governance` for:
 - Running Spectral or Redocly CLI against `docs/api/specs/*.yaml`.
 - Checking YSS response wrappers, error contracts, pagination, permissions, security red lines, and contract-test seams.
 - Comparing generated `openapi.json` against frozen design rules when backend code is already implemented.
-- Writing or updating governance notes under `docs/api/`, `docs/architecture/`, or the active OpenSpec / Comet design.
+- Writing or updating governance notes under `docs/api/`, `docs/architecture/`, or the active Spec Delta design.
 
 Use other skills for:
 
 - `yss-openapi`: generate `target/openapi/openapi.json` from implemented controllers/DTOs and refresh Orval clients.
 - `yss-openapi-draft-review`: perform fail-closed semantic review against PRD, prototype, page actions, P0 coverage, and architecture readiness.
-- `openspec-*` or `comet-*`: formalize behavior changes and implementation tasks after the contract is frozen.
+- `docs/specs/*-spec-delta.md` and `to-issues`: formalize behavior changes and implementation tasks after the contract is frozen.
 
 ## Preferred Tooling
 
@@ -71,7 +71,7 @@ If neither tool is configured, do not invent project policy silently. Create or
 5. Produce governance output.
    - For quick checks, report lint command, pass/fail result, and blocking findings with file paths.
    - For durable decisions, write or update a Chinese governance artifact under `docs/api/` or `docs/architecture/`.
-   - For active OpenSpec / Comet work, reference the active change and keep rules aligned with `proposal.md`, `design.md`, `tasks.md`, and specs.
+   - For active Spec Delta work, reference the active change and keep rules aligned with the related design, task, and spec artifacts.
 
 ## Minimal Spectral Baseline
 

package/template/.codex/skills/yss-product-lifecycle/SKILL.md

@@ -38,21 +38,25 @@ Use this lifecycle skill to decide the stage and route to the right workflow. Do
 
 | Layer | Owner | Responsibility | Canonical artifacts |
 |---|---|---|---|
-| Product / requirements | `competitive-intelligence`, `grill-with-docs`, `to-prd` | Clarify market / competitor facts, users, pain, boundaries, acceptance criteria, and PRD scope | `CONTEXT.md`, `docs/adr/`, `docs/discovery/`, `docs/requirements/<feature>-prd.md` |
+| Product / requirements | `competitive-intelligence`, `research`, `grill-with-docs`, `prototype`, `to-prd` | Clarify market / competitor / technical facts, users, pain, boundaries, acceptance criteria, PRD scope, and runnable answers to hard design questions | `CONTEXT.md`, `docs/adr/`, `docs/discovery/`, `docs/research/`, `docs/requirements/<feature>-prd.md` |
 | Contract | OpenAPI / YSS API skills, OpenSpec-style Spec Delta | Define and freeze frontend/backend API contracts, plus behavior deltas for medium/high-risk changes | `docs/api/specs/*.yaml`, `docs/specs/<feature>-spec-delta.md`, OpenAPI Draft Review / Freeze records |
-| Delivery planning | `to-issues`, Issue tracker | Split PRD / frozen contract into end-to-end vertical slices | GitLab / GitHub Issues or `docs/requirements/issues/*` |
-| Implementation | `implement`, `tdd`, `diagnosing-bugs`, `code-review` | Build with feedback loops, bug diagnosis, independent review, and fresh verification | tests, review reports, verification records, implementation notes |
+| Delivery planning | `to-issues`, `handoff` / equivalent handoff record, Issue tracker | Split PRD / frozen contract into end-to-end vertical slices and preserve context across threads or implementation repos | GitLab / GitHub Issues or `docs/requirements/issues/*`, `docs/implementation/*` |
+| Implementation | `implement`, `tdd`, `diagnosing-bugs`, `resolving-merge-conflicts`, `code-review` | Build with feedback loops, bug diagnosis, conflict resolution, independent review, and fresh verification | tests, review reports, verification records, implementation notes |
 | YSS engineering | `yss-router` and selected YSS skills | Apply YSS DDD, UI, DTO, Repository, Controller, OpenAPI, and component rules | implementation routing record, Build Architecture Checklist, code/test evidence |
 
 Rules:
 
-- Prefer Matt skills for generic engineering workflow: `grill-with-docs`, `to-prd`, `to-issues`, `implement`, `tdd`, `diagnosing-bugs`, `code-review`, `domain-modeling`, `codebase-design`, and `improve-codebase-architecture`.
+- Prefer Matt skills for generic engineering workflow: `research`, `grill-with-docs`, `prototype`, `to-prd`, `to-issues`, `implement`, `tdd`, `diagnosing-bugs`, `resolving-merge-conflicts`, `code-review`, `domain-modeling`, `codebase-design`, and `improve-codebase-architecture`.
 - Use `competitive-intelligence` when market, competitor, pricing, positioning, or customer sentiment facts are needed before Discovery / PRD decisions.
+- Use `research` when technical facts, standards, third-party API behavior, framework behavior, or official documentation need primary-source evidence before PRD, OpenAPI, architecture, or acceptance decisions.
+- Use `prototype` only for throwaway runnable feedback on logic, state-machine, or UI direction questions. Feed the conclusion back into PRD, design, ADR, or issues; do not treat prototype code as production implementation or as the required Ant Design v6 high-fidelity HTML prototype.
 - Preserve OpenAPI 3.1 Draft / Freeze as the API contract gate. Draft is review-only until Freeze.
 - Use OpenSpec-style Spec Delta for API, permission, state-machine, data-model, cross-client, new-module, or high-risk behavior changes. It is a lightweight behavior-delta artifact, not OpenSpec CLI, change-state files, or an extra state machine.
 - After OpenAPI Freeze, route to `to-issues` or an equivalent vertical-slice issue record; do not require extra state-machine artifacts.
 - Before frontend/backend implementation, first decide whether the impacted frontend/backend runtime projects already exist and can be reused. If an impacted side has no reusable project yet, route to `yss-ddd-scaffold-generator` or `yss-frontend-scaffold-generator` before business implementation.
 - Use `yss-router` before frontend/backend implementation when the task crosses multiple YSS areas. The route output becomes implementation guidance inside the current slice.
+- Use `handoff` or an equivalent handoff record when crossing threads, implementation repositories, prototype branches, or context-window limits.
+- Use `resolving-merge-conflicts` or an equivalent conflict-resolution flow for merge / rebase conflicts before release or merge decisions.
 - Use `code-review` or an independent review agent before merge/release decisions.
 - Require fresh verification evidence before claiming completion.
 
@@ -76,6 +80,7 @@ Use `excalidraw-diagram-generator` when diagrams will make boundaries, flows, da
 1. Inspect existing context before asking questions:
    - `CONTEXT.md`
    - `docs/discovery/` and `docs/discovery/reports/`
+   - `docs/research/`
    - `docs/requirements/`
    - `docs/design/`
    - `docs/api/specs/`
@@ -86,15 +91,18 @@ Use `excalidraw-diagram-generator` when diagrams will make boundaries, flows, da
 3. For small changes or iterations, identify the nearest trustworthy existing stage and only expand from the earliest impacted artifact:
    - wording / style / local configuration -> direct minimal change, then verify;
    - UI behavior or page state -> product design / prototype review / PRD calibration as needed;
+   - unclear state-machine, complex rules, or UI direction -> `prototype` for throwaway runnable feedback, then feed the conclusion into PRD/design/ADR/issue;
    - API request, response, error, permission, pagination, or concurrency -> system / data architecture, engineering contract, and Design Review with API impact analysis / contract draft / OpenAPI Draft Review / Freeze downstream gates;
    - service boundary, state machine, integration, NFR, rollout, or rollback -> system / data architecture, engineering contract, and Design Review downstream gates;
    - persistence, metadata, versioning, lineage, query, or index -> system / data architecture, engineering contract, and Design Review downstream gates.
 4. Check whether required upstream artifacts exist.
    - Before PRD calibration, product design, API impact analysis, OpenAPI Draft, requirement freeze, or formal vertical slicing, verify PRD baseline and product overview design / functional architecture exist. If the task does not enter the PRD lifecycle, record the not-applicable reason in the impact assessment.
-   - For UI work, before PRD calibration, API impact analysis, OpenAPI Draft, or requirement freeze, verify low-fidelity `prototype-review` is approved and `docs/design/prototypes/<feature>/index.html` exists as an Ant Design v6 high-fidelity HTML prototype.
+   - For UI work, before PRD calibration, API impact analysis, OpenAPI Draft, or requirement freeze, verify low-fidelity `prototype-review` is approved, `docs/design/prototypes/<feature>/index.html` exists as an Ant Design v6 high-fidelity HTML prototype, AntD v6 CLI validation evidence is recorded, and user confirmation is recorded after the prototype is produced. This prototype is a required lifecycle artifact and may be generated automatically by the system / Agent after low-fidelity prototype review; it does not have to be manually supplied by the user.
    - Before formal vertical slicing, verify PRD, product overview design / functional architecture, OpenAPI Freeze or no-API-impact record, architecture review as needed, and a clear issue destination.
    - For medium/high-risk API, permission, state-machine, data-model, cross-client, new-module, or safety-sensitive changes, verify an OpenSpec-style Spec Delta exists or record why it is not needed.
+   - When technical, standard, framework, or third-party API facts influence downstream decisions, verify `research` or an equivalent primary-source record exists and is cited.
    - Before frontend/backend implementation, verify vertical slice scope, implementation repo/location, whether the impacted frontend/backend runtime projects already exist and are reusable, YSS skill routing, Build Architecture Checklist, test command, and review strategy.
+   - Before crossing threads, implementation repos, prototype branches, or long contexts, verify `handoff` or an equivalent handoff record captures source artifacts, current stage, open questions, verification commands, and next owner.
 5. Output the next action:
    - artifact to create/update,
    - specialist skill to invoke,
@@ -143,17 +151,21 @@ Default routing:
 |---|---|
 | Start a new business product/module | intake -> opportunity and Discovery -> `competitive-intelligence` when market / competitor facts are needed -> `grill-with-docs` -> `to-prd` -> product overview design / functional architecture -> product design and requirement freeze when UI exists |
 | Analyze competitors, substitute workflows, pricing, positioning, or market facts | `competitive-intelligence`; then feed stable findings into `grill-with-docs` and `to-prd` |
-| Design UI flow after PRD baseline | Verify product overview design / functional architecture first, then use `product-design-prototype`; add `wireframe-prototype` only when a low-fidelity page or flow sketch is needed |
+| Research technical facts, standards, framework behavior, or third-party APIs | `research`; feed cited findings into PRD, OpenAPI, architecture, ADR, or acceptance criteria |
+| Answer a design question that needs runnable feedback | `prototype`; feed the conclusion into PRD, design, ADR, or issue, then delete or absorb throwaway code |
+| Design UI flow after PRD baseline | Verify product overview design / functional architecture first, then use `product-design:index` as the primary Product Design router; follow its focused routing such as `$get-context`, `$ideate`, `$prototype`, `$image-to-code`, or `$url-to-code` |
 | Review low-fidelity prototype before high-fidelity design | `prototype-review` |
-| Build high-fidelity interactive HTML prototype | `high-fidelity-html-prototype` with Ant Design v6 after low-fidelity prototype review is approved |
+| Build high-fidelity interactive HTML prototype | Use `product-design:index` as the primary entrypoint and route to the appropriate Product Design focused workflow for prototype/code output; query AntD v6 design/component/demo/token/semantic facts with `antd` CLI before output; the required stage output must be Ant Design v6 HTML at `docs/design/prototypes/<feature>/index.html`, may be system / Agent generated, must record AntD CLI validation evidence, and must be confirmed by the user before downstream gates |
 | Review contract draft / OpenAPI Draft inside architecture/design review | `yss-openapi-draft-review` |
 | Record behavior deltas for medium/high-risk changes | OpenSpec-style Spec Delta at `docs/specs/<feature>-spec-delta.md` using `docs/templates/spec-delta-template.md` |
 | Clarify architecture artifact timing or gaps | this skill plus `docs/process/lifecycle-artifact-map.md` and `references/artifact-checklist.md` |
 | Create architecture/process/data diagrams | `excalidraw-diagram-generator` as a support skill |
 | Design meta-model / metadata / lineage data architecture | architecture/design workflow plus `yss-domain-modeling` or `yss-domain`; use `excalidraw-diagram-generator` for ER, lineage, DFD, or class diagrams when helpful |
 | Split delivery scope after PRD / OpenAPI Freeze | `to-issues`; record whether impacted frontend/backend projects already exist, and whether scaffold initialization is needed |
+| Cross threads, repos, prototype branches, or long contexts | `handoff` or equivalent handoff record; preserve source artifacts, current stage, open questions, verification commands, and next owner |
 | Implement a slice | first check impacted frontend/backend project existence; route missing backend to `yss-ddd-scaffold-generator`, missing frontend to `yss-frontend-scaffold-generator`, then use `implement` plus `tdd`; use `yss-router` first when multiple YSS areas are touched |
 | Fix a bug or test failure | `diagnosing-bugs` then `tdd` |
+| Resolve merge or rebase conflicts | `resolving-merge-conflicts`; record both intents, resolution trade-offs, and fresh verification |
 | Review implementation | `code-review` plus YSS-specific review inputs |
 | Build Vue page | `yss-ui` plus related frontend skills chosen by `yss-router` |
 | Build backend module from scratch | `yss-ddd-scaffold-generator` |
@@ -204,7 +216,9 @@ When the user explicitly asks for a full delivery plan, include stage-by-stage t
 ## Guardrails
 
 - Do not skip opportunity exploration for new product/module work; use `competitive-intelligence` when market/competitor facts are needed, or record why it is not needed.
+- Do not make technical, standards, framework, or third-party API claims that affect PRD, OpenAPI, architecture, acceptance, or release decisions without `research` or equivalent primary-source evidence.
 - Do not treat Discovery outputs as frozen downstream design. Discovery can provide product capability guidance and downstream impact signals, but PRD, functional architecture, OpenAPI, system architecture, and data architecture still require their own gates.
+- Do not treat throwaway `prototype` code as production code, as an implementation shortcut, or as the required Ant Design v6 high-fidelity HTML prototype. Keep the conclusion, delete or absorb the code.
 - Do not start implementation before PRD is calibrated, product overview design / functional architecture exists, required architecture artifacts are explicit, product design / prototype / interaction design exists, low-fidelity `prototype-review` passes, high-fidelity Ant Design v6 HTML prototype exists when UI exists, OpenAPI Freeze decision, engineering baseline, design review, and vertical slice are clear.
 - Do not start implementation before deciding whether the impacted frontend/backend runtime projects already exist and can be reused. Missing or conflicting runtime projects must route back to implementation routing and scaffold initialization first.
 - Do not skip business architecture for new products unless the product boundary, users, ecosystem, and value stream are already captured elsewhere.
@@ -217,7 +231,9 @@ When the user explicitly asks for a full delivery plan, include stage-by-stage t
 - Do not require Spec Delta for small wording, local style, configuration, or low-risk bug fixes unless the change expands into API, permission, state-machine, data-model, cross-client, or security impacts.
 - Do not move an OpenAPI Draft into Engineering Baseline / YSS DDD Review until `yss-openapi-draft-review` or an equivalent persistent review verifies P0 feature coverage, page action to endpoint mapping, YSS response wrappers, error structures, permissions, concurrency, security red lines, and contract test seams.
 - Do not route directly to frontend/backend skills before `yss-router` when the task crosses multiple YSS areas.
+- Do not cross threads, implementation repos, prototype branches, or context-window limits without `handoff` or an equivalent handoff record when downstream agents need continuity.
 - Do not generate production code from this skill; hand off to the selected specialist skill.
+- Do not complete merge/rebase conflict work without documenting resolution intent and rerunning relevant checks.
 - Treat TDD as the default for business behavior implementation; generated code, configuration, or throwaway prototypes may use a documented exception with a verification command.
 - Require independent review and fresh verification evidence before calling work complete.
 - Flag security red lines from `AGENTS.md` as human-review items.

package/template/.codex/skills/yss-router/SKILL.md

@@ -61,7 +61,6 @@ When the request is already narrowly scoped, use the matching specialist directl
 | Work with current user info propagation or user info starter | `yss-userinfo` |
 | Work with variable component APIs | `yss-variable` |
 | Work with quality starter behavior | `yss-quality` |
-| Work with DolphinScheduler anti-corrosion/anti-scheduler integration | `yss-anti-scheduler` |
 | Work with exception component or unified exception handling | `yss-exception` |
 | Work with mail starter or email sending | `yss-mail` |
 | Work with file runner component | `yss-filerunner` |
@@ -98,7 +97,7 @@ Backend component skills have generated source indexes under `references/source-
 中文说明：当问题涉及真实类名、配置项、注解、拦截器、自动配置或排障时，先读对应 `source-index.md`，它会指向后端组件源码库里的真实入口。
 
 - Core framework/component examples: `yss-cache`, `yss-mybatis`, `yss-dto`, `yss-audit-log`, `yss-excel-mvc`, `yss-distributed-id`, `yss-jdbc`.
-- Extended component examples: `yss-dictionary`, `yss-dir`, `yss-file`, `yss-log`, `yss-liquibase`, `yss-resilience4j`, `yss-sql-condition`, `yss-sql-tpl`, `yss-taskflow`, `yss-validation`, `yss-security-algorithm`, `yss-userinfo`, `yss-variable`, `yss-quality`, `yss-anti-scheduler`, `yss-exception`, `yss-mail`, `yss-filerunner`, `yss-valuation`, `yss-duckdb`, `yss-mapper-dynamic`.
+- Extended component examples: `yss-dictionary`, `yss-dir`, `yss-file`, `yss-log`, `yss-liquibase`, `yss-resilience4j`, `yss-sql-condition`, `yss-sql-tpl`, `yss-taskflow`, `yss-validation`, `yss-security-algorithm`, `yss-userinfo`, `yss-variable`, `yss-quality`, `yss-exception`, `yss-mail`, `yss-filerunner`, `yss-valuation`, `yss-duckdb`, `yss-mapper-dynamic`.
 
 Regenerate these indexes with `yss-source-index/scripts/refresh-yss-skill-index.py` after `yss-cloud-microservice` changes. Read `yss-source-index/references/source-map-config.md` when you need the full skill-to-source mapping.
 

package/template/.codex/skills/yss-router/references/boundaries.md

@@ -54,7 +54,6 @@ Default for backend CRUD: use `yss-domain`, `yss-dto`, `yss-repository`, and `ys
 - `yss-userinfo`: Current-user info propagation and starter integration.
 - `yss-variable`: Variable component APIs and variable resolution.
 - `yss-quality`: Quality starter behavior.
-- `yss-anti-scheduler`: DolphinScheduler anti-corrosion/anti-scheduler integration.
 - `yss-exception`: Exception component and unified exception handling.
 - `yss-mail`: Mail starter and email sending.
 - `yss-filerunner`: File runner component behavior.

package/template/.codex/skills/yss-source-index/references/source-map-config.md

@@ -27,7 +27,6 @@ The refresh script maps component source path hints to skill references. These p
 | `yss-userinfo` | `yss-microservice-components/yss-component-userinfo-starter` |
 | `yss-variable` | `yss-microservice-components/yss-component-variable` |
 | `yss-quality` | `yss-microservice-components/yss-component-quality-starter` |
-| `yss-anti-scheduler` | `yss-microservice-components/yss-component-anti-corrosion/yss-component-anti-scheduler` |
 | `yss-exception` | `yss-microservice-components/yss-component-exception` |
 | `yss-mail` | `yss-microservice-components/yss-component-mail-starter` |
 | `yss-filerunner` | `yss-microservice-components/yss-component-filerunner-parent` |

package/template/.codex/skills/yss-source-index/scripts/refresh-yss-skill-index.py

@@ -76,9 +76,6 @@ BACKEND_SKILLS = {
     "yss-quality": [
         "yss-microservice-components/yss-component-quality-starter",
     ],
-    "yss-anti-scheduler": [
-        "yss-microservice-components/yss-component-anti-corrosion/yss-component-anti-scheduler",
-    ],
     "yss-exception": [
         "yss-microservice-components/yss-component-exception",
     ],

package/template/.hermes/skills/grill-me/SKILL.md

@@ -0,0 +1,7 @@
+---
+name: grill-me
+description: A relentless interview to sharpen a plan or design.
+disable-model-invocation: true
+---
+
+Run a `/grilling` session.

package/template/.hermes/skills/grilling/SKILL.md

@@ -0,0 +1,12 @@
+---
+name: grilling
+description: Grill the user relentlessly about a plan or design. Use when the user wants to stress-test a plan before building, or uses any 'grill' trigger phrases.
+---
+
+Interview me relentlessly about every aspect of this plan until we reach a shared understanding. Walk down each branch of the design tree, resolving dependencies between decisions one-by-one. For each question, provide your recommended answer.
+
+Ask the questions one at a time, waiting for feedback on each question before continuing. Asking multiple questions at once is bewildering.
+
+If a *fact* can be found by exploring the codebase, look it up rather than asking me. The *decisions*, though, are mine — put each one to me and wait for my answer.
+
+Do not enact the plan until I confirm we have reached a shared understanding.

package/template/.hermes/skills/handoff/SKILL.md

@@ -0,0 +1,16 @@
+---
+name: handoff
+description: Compact the current conversation into a handoff document for another agent to pick up.
+argument-hint: "What will the next session be used for?"
+disable-model-invocation: true
+---
+
+Write a handoff document summarising the current conversation so a fresh agent can continue the work. Save to the temporary directory of the user's OS - not the current workspace.
+
+Include a "suggested skills" section in the document, which suggests skills that the agent should invoke.
+
+Do not duplicate content already captured in other artifacts (PRDs, plans, ADRs, issues, commits, diffs). Reference them by path or URL instead.
+
+Redact any sensitive information, such as API keys, passwords, or personally identifiable information.
+
+If the user passed arguments, treat them as a description of what the next session will focus on and tailor the doc accordingly.

package/template/.hermes/skills/to-issues/SKILL.md

@@ -54,7 +54,7 @@ Iterate until the user approves the breakdown.
 
 For each approved slice, publish a new issue to the issue tracker. Use the issue body template below. These issues are considered ready for AFK agents, so publish them with the correct triage label unless instructed otherwise.
 
-Publish issues in dependency order (blockers first) so you can reference real issue identifiers in the "Blocked by" field.
+Publish issues in dependency order (blockers first) so you can reference real issue identifiers. Where the tracker supports it, link each slice to its parent as a native **sub-issue** and wire each blocker as a native **blocking edge** (mechanics in the issue-tracker doc); the `## Parent` and `## Blocked by` body sections are the fallback otherwise.
 
 <issue-template>
 ## Parent
@@ -65,7 +65,7 @@ A reference to the parent issue on the issue tracker (if the source was an exist
 
 A concise description of this vertical slice. Describe the end-to-end behavior, not layer-by-layer implementation.
 
-Avoid specific file paths or code snippets — they go stale fast. Exception: if a prototype produced a snippet that encodes a decision more precisely than prose can (state machine, reducer, schema, type shape), inline it here and note briefly that it came from a prototype. Trim to the decision-rich parts — not a working demo, just the important bits.
+Avoid specific file paths or code snippets — they go stale fast. Exception: if the `/prototype` skill produced code that encodes a decision more precisely than prose can (state machine, reducer, schema, type shape), add a context pointer to where that prototype code lives rather than inlining it.
 
 ## Acceptance criteria
 

package/template/.pi/skills/grill-me/SKILL.md

@@ -0,0 +1,7 @@
+---
+name: grill-me
+description: A relentless interview to sharpen a plan or design.
+disable-model-invocation: true
+---
+
+Run a `/grilling` session.

package/template/.pi/skills/grilling/SKILL.md

@@ -0,0 +1,12 @@
+---
+name: grilling
+description: Grill the user relentlessly about a plan or design. Use when the user wants to stress-test a plan before building, or uses any 'grill' trigger phrases.
+---
+
+Interview me relentlessly about every aspect of this plan until we reach a shared understanding. Walk down each branch of the design tree, resolving dependencies between decisions one-by-one. For each question, provide your recommended answer.
+
+Ask the questions one at a time, waiting for feedback on each question before continuing. Asking multiple questions at once is bewildering.
+
+If a *fact* can be found by exploring the codebase, look it up rather than asking me. The *decisions*, though, are mine — put each one to me and wait for my answer.
+
+Do not enact the plan until I confirm we have reached a shared understanding.