create-yss-spec 3.3.1 → 3.3.4

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

@@ -1,16 +0,0 @@
----
-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 (specs, 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/.trae/skills/handoff/agents/openai.yaml

@@ -1,5 +0,0 @@
-interface:
-  display_name: "Handoff"
-  short_description: "Compact a conversation into a handoff"
-policy:
-  allow_implicit_invocation: false

package/template/.trae/skills/implement/SKILL.md

@@ -1,15 +0,0 @@
----
-name: implement
-description: "Implement a piece of work based on a spec or set of tickets."
-disable-model-invocation: true
----
-
-Implement the work described by the user in the spec or tickets.
-
-Use /tdd where possible, at pre-agreed seams.
-
-Run typechecking regularly, single test files regularly, and the full test suite once at the end.
-
-Once done, use /code-review to review the work.
-
-Do not commit or push. Implementation authorization does not include git commit/push. Natural language such as "do it and commit" is not structured Git authorization. Stop after review unless a structured Git authorization is already present.

package/template/.trae/skills/implement/agents/openai.yaml

@@ -1,5 +0,0 @@
-interface:
-  display_name: "Implement"
-  short_description: "Build work from a spec or tickets"
-policy:
-  allow_implicit_invocation: false

package/template/.trae/skills/implementation-repo-onboarding/SKILL.md

@@ -1,50 +0,0 @@
----
-name: implementation-repo-onboarding
-description: Use when connecting an existing frontend, backend, fullstack, or other implementation Git repository to this Harness repository.
----
-
-# Implementation Repo Onboarding
-
-用于把已有前端、后端或其他实现仓库接入当前 Harness / 研发管理仓库。默认只做只读扫描和文档记录，不改实现仓库。
-
-## Inputs
-
-- 外部仓库 URL 或本地路径。
-- `repo_role`: backend / frontend / fullstack / other。
-- 目标 feature / change 名称。
-- 可选：默认分支、CI 平台、验证命令、OpenAPI 位置。
-
-## Workflow
-
-1. 确认当前仓库是 Harness 仓库，读取 `docs/process/implementation-repo-integration.md`。
-2. 如果输入是本地路径，只读检查 Git remote、当前分支、目录结构、构建文件和测试脚本。
-3. 如果输入是远端 URL，优先使用只读 Git 查询。需要完整工作树时：`external-repository` 只能 clone 到临时目录；`git-submodule` 只能通过 `git submodule add` / `git submodule update --init` 在已批准的 `apps/backend/<project>/` 或 `apps/frontend/<project>/` gitlink 挂载点检出，禁止普通 clone 或复制源码进 Harness。
-4. 识别技术栈、包管理器、CI、测试命令、构建命令、OpenAPI 接入和设计 token 接入。
-5. 判定实现位置与 `repository_scope`：`external-repository` 记录真实项目根；`harness-apps` 与 `git-submodule` 只能使用 `apps/backend/<project>/` 或 `apps/frontend/<project>/`。`apps/backend/`、`apps/frontend/` 仅为容器，`app/backend/`、`app/frontend/` 及其子路径必须标记为阻断。gitlink（mode `160000`）必须登记为 `git-submodule` 和 `layout_policy: git-submodule-harness-apps`，不得写成 `harness-apps`。必须对照工作树：`git ls-files --stage`、`.gitmodules` 与声明 scope 不一致时阻断；缺少 `git_entry_mode: 160000` 不得把挂载点当普通目录。
-6. 按 `docs/templates/implementation-repo-registry-template.md` 输出实现仓库登记内容。`git-submodule` 必填 `gitmodules_name`、`gitlink_path`、`git_entry_mode`、`superproject_git_url` 和 `checkout_state`。`harness-apps` / `external-repository` 这些字段填 `不适用`。
-7. 列出 `known_gaps`、人审点、fresh verification 命令和需要回写到 Harness change / Issue / checkpoint 的信息。空 gitlink、detached HEAD、`--force` 覆盖挂载点或缺少递归检出凭据时标记阻断。写入前必须看 `inspectWorkingTreeScope` / `implementationWriteViolation`：只接受对象结果且 `.writable === true` 才可写；字符串、`null` 或 `.writable !== true` 一律不可写。即使已正确登记为 `git-submodule`，空 gitlink 或 detached HEAD 也必须 `.writable === false`，不得当普通目录写文件或脚手架。
-
-## Baseline Checks
-
-| repo_role | 必查项 |
-|---|---|
-| backend | 构建工具、模块结构、测试命令、OpenAPI 产出、YSS DDD 基线、数据库 / 迁移红线 |
-| frontend | 包管理器、框架、路由、YSS UI / Ant Design、Orval / API client、设计 token、lint / type-check / build |
-| fullstack | 前后端边界、契约生成方式、独立测试命令、CI 阶段拆分 |
-| other | owner、构建 / 测试 / 发布命令、与 Harness change 的关系 |
-
-## Boundaries
-
-- 不直接提交、推送、创建 MR / PR 或修改实现仓库。
-- 不把实现仓库源码复制进 Harness 仓库；`git-submodule` 只能形成 gitlink，不能 copy / subtree 冒充。
-- 不把缺失命令编造为已存在；找不到时标记 `unknown` 或 `需人工确认`。
-- 不得把 `app/backend/`、`app/frontend/` 或 `apps/backend/`、`apps/frontend/` 容器根登记为可生成项目根。
-- 触碰认证、授权、SQL、迁移、加密、公共基础库 API 时标记 `TODO-HUMAN-REVIEW`。
-
-## Output
-
-- 实现仓库登记草案。
-- 工程基线发现。
-- known gaps 和补齐计划。
-- fresh verification 命令。
-- Harness 回写位置建议。

package/template/.trae/skills/improve-codebase-architecture/HTML-REPORT.md

@@ -1,123 +0,0 @@
-# HTML Report Format
-
-The architectural review is rendered as a single self-contained HTML file in the OS temp directory. Tailwind and Mermaid both come from CDNs. Mermaid handles graph-shaped diagrams reliably; hand-built divs and inline SVG handle the more editorial visuals (mass diagrams, cross-sections). Mix the two — don't lean on Mermaid for everything, it'll start to look generic.
-
-## Scaffold
-
-```html
-<!doctype html>
-<html lang="en">
-  <head>
-    <meta charset="utf-8" />
-    <title>Architecture review — {{repo name}}</title>
-    <script src="https://cdn.tailwindcss.com"></script>
-    <script type="module">
-      import mermaid from "https://cdn.jsdelivr.net/npm/mermaid@11/dist/mermaid.esm.min.mjs";
-      mermaid.initialize({ startOnLoad: true, theme: "neutral", securityLevel: "loose" });
-    </script>
-    <style>
-      /* small custom layer for things Tailwind doesn't cover cleanly:
-         dashed seam lines, hand-drawn-feeling arrow heads, etc. */
-      .seam { stroke-dasharray: 4 4; }
-      .leak { stroke: #dc2626; }
-      .deep { background: linear-gradient(135deg, #0f172a, #1e293b); }
-    </style>
-  </head>
-  <body class="bg-stone-50 text-slate-900 font-sans">
-    <main class="max-w-5xl mx-auto px-6 py-12 space-y-12">
-      <header>...</header>
-      <section id="candidates" class="space-y-10">...</section>
-      <section id="top-recommendation">...</section>
-    </main>
-  </body>
-</html>
-```
-
-## Header
-
-Repo name, date, and a compact legend: solid box = module, dashed line = seam, red arrow = leakage, thick dark box = deep module. No introduction paragraph — straight into the candidates.
-
-## Candidate card
-
-The diagrams carry the weight. Prose is sparse, plain, and uses the glossary terms (from the `/codebase-design` skill) without ceremony.
-
-Each candidate is one `<article>`:
-
-- **Title** — short, names the deepening (e.g. "Collapse the Order intake pipeline").
-- **Badge row** — recommendation strength (`Strong` = emerald, `Worth exploring` = amber, `Speculative` = slate), plus a tag for the dependency category (`in-process`, `local-substitutable`, `ports & adapters`, `mock`).
-- **Files** — monospaced list, `font-mono text-sm`.
-- **Before / After diagram** — the centrepiece. Two columns, side by side. See patterns below.
-- **Problem** — one sentence. What hurts.
-- **Solution** — one sentence. What changes.
-- **Wins** — bullets, ≤6 words each. e.g. "Tests hit one interface", "Pricing logic stops leaking", "Delete 4 shallow wrappers".
-- **ADR callout** (if applicable) — one line in an amber-tinted box.
-
-No paragraphs of explanation. If the diagram needs a paragraph to be understood, redraw the diagram.
-
-## Diagram patterns
-
-Pick the pattern that fits the candidate. Mix them. Don't make every diagram look the same — variety is part of the point.
-
-### Mermaid graph (the workhorse for dependencies / call flow)
-
-Use a Mermaid `flowchart` or `graph` when the point is "X calls Y calls Z, and look at the mess." Wrap it in a Tailwind-styled card so it doesn't feel parachuted in. Style with classDef to colour leakage edges red and the deep module dark. Sequence diagrams work well for "before: 6 round-trips; after: 1."
-
-```html
-<div class="rounded-lg border border-slate-200 bg-white p-4">
-  <pre class="mermaid">
-    flowchart LR
-      A[OrderHandler] --> B[OrderValidator]
-      B --> C[OrderRepo]
-      C -.leak.-> D[PricingClient]
-      classDef leak stroke:#dc2626,stroke-width:2px;
-      class C,D leak
-  </pre>
-</div>
-```
-
-### Hand-built boxes-and-arrows (when Mermaid's layout fights you)
-
-Modules as `<div>`s with borders and labels. Arrows as inline SVG `<line>` or `<path>` elements positioned absolutely over a relative container. Reach for this when you want the "after" diagram to feel like one thick-bordered deep module with greyed-out internals — Mermaid won't render that with the right weight.
-
-### Cross-section (good for layered shallowness)
-
-Stack horizontal bands (`h-12 border-l-4`) to show layers a call passes through. Before: 6 thin layers each doing nothing. After: 1 thick band labelled with the consolidated responsibility.
-
-### Mass diagram (good for "interface as wide as implementation")
-
-Two rectangles per module — one for interface surface area, one for implementation. Before: interface rectangle is nearly as tall as the implementation rectangle (shallow). After: interface rectangle is short, implementation rectangle is tall (deep).
-
-### Call-graph collapse
-
-Before: a tree of function calls rendered as nested boxes. After: the same tree collapsed into one box, with the now-internal calls shown faded inside it.
-
-## Style guidance
-
-- Lean editorial, not corporate-dashboard. Generous whitespace. Serif optional for headings (`font-serif` works well with stone/slate).
-- Colour sparingly: one accent (emerald or indigo) plus red for leakage and amber for warnings.
-- Keep diagrams ~320px tall so before/after sits comfortably side by side without scrolling.
-- Use `text-xs uppercase tracking-wider` for module labels inside diagrams — they should read as schematic, not as UI.
-- The only scripts are the Tailwind CDN and the Mermaid ESM import. The report is otherwise static — no app code, no interactivity beyond Mermaid's own rendering.
-
-## Top recommendation section
-
-One larger card. Candidate name, one sentence on why, anchor link to its card. That's it.
-
-## Tone
-
-Plain English, concise — but the architectural nouns and verbs come straight from the `/codebase-design` skill. Concision is not an excuse to drift.
-
-**Use exactly:** module, interface, implementation, depth, deep, shallow, seam, adapter, leverage, locality.
-
-**Never substitute:** component, service, unit (for module) · API, signature (for interface) · boundary (for seam) · layer, wrapper (for module, when you mean module).
-
-**Phrasings that fit the style:**
-
-- "Order intake module is shallow — interface nearly matches the implementation."
-- "Pricing leaks across the seam."
-- "Deepen: one interface, one place to test."
-- "Two adapters justify the seam: HTTP in prod, in-memory in tests."
-
-**Wins bullets** name the gain in glossary terms: *"locality: bugs concentrate in one module"*, *"leverage: one interface, N call sites"*, *"interface shrinks; implementation absorbs the wrappers"*. Don't write *"easier to maintain"* or *"cleaner code"* — those terms aren't in the glossary and don't earn their place.
-
-No hedging, no throat-clearing, no "it's worth noting that…". If a sentence could be a bullet, make it a bullet. If a bullet could be cut, cut it. If a term isn't in the `/codebase-design` glossary, reach for one that is before inventing a new one.

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

@@ -1,71 +0,0 @@
----
-name: improve-codebase-architecture
-description: Scan a codebase for deepening opportunities, present them as a visual HTML report, then grill through whichever one you pick.
-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 these terms exactly in every suggestion — don't drift into "component," "service," "API," or "boundary."
-- 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.
-
-Then spawn a sub-agent to walk the codebase. Don't follow rigid heuristics — explore organically and note where you experience 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 as an 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.
-
-The report uses **Tailwind via CDN** for layout and styling, and **Mermaid via CDN** for 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 the file is written, ask the user: "Which of these would you like to explore?"
-
-### 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/.trae/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/.trae/skills/java-backend-commit/SKILL.md

@@ -1,121 +0,0 @@
----
-name: java-backend-commit
-description: 分析并提交 Java、Spring Boot、Maven、Gradle、单体服务和多模块后端项目的 Git 改动；当用户要求生成 commit message、检查提交规范、拆分原子提交、暂存并执行 git commit，或修复 commitlint 与 commit-msg hook 拒绝时使用。读取仓库实际规则、模块结构和 diff，选择服务或业务域 scope，生成英文 type/scope 与中文标题和正文，并安全验证提交。
----
-
-# Java 后端规范提交
-
-## 触发条件
-
-- 用户要求为 Java 后端项目生成 commit message、检查提交规范或执行 `git commit`。
-- 需要将跨层改动（接口、领域、持久化、迁移、测试）拆分为可独立构建和回滚的原子提交。
-- commitlint、`commit-msg` 或 `pre-commit` hook 拒绝提交，需要按规则修复。
-- 适用于 Java、Spring Boot、Maven、Gradle、单体服务和多模块后端仓库。
-
-## 不适用场景
-
-- Vue、React 等前端或微前端仓库：使用 `../frontend-commit/SKILL.md`。
-- yss-ui 组件库仓库自身的提交与发版：使用 `../commit-linting/SKILL.md`。
-- 仅请求代码实现，不涉及提交信息或 `git commit` 操作。
-- 无代码改动，或改动内容与提交请求不匹配。
-- 合并提交、发布提交、自动依赖机器人提交和数据库基线发布：遵循仓库专用流程，不套用本技能的常规模板。
-
-## 硬约束（禁止/必须）
-
-- 必须把仓库规则视为最高优先级：依次遵循 `AGENTS.md`、`CONTRIBUTING.md`、Git hooks、解析后的 commitlint 配置、本地配置和近期历史；通用规则只作回退。
-- 只在用户明确要求提交时执行暂存和 `git commit`；若仅要求提交信息或审查，只输出候选消息与依据。
-- 必须保留用户和他人的既有改动。禁止默认使用 `git add -A`、`git add .`、`git commit -a`、`--no-verify`，也不要自动 amend、rebase、push 或改写已发布历史。
-- 提交必须是可独立理解、构建和回滚的逻辑变更。不要按 `controller/service/repository` 技术分层拆成无法工作的提交。
-- 遇到密钥、令牌、私钥、证书、keystore、生产口令、`.env` 实值或意外大文件时停止提交并报告具体路径，不要在输出中泄露内容。
-- 已有暂存内容视为用户选择，除非用户授权，不要擅自取消暂存或混入其他文件。
-- 不提交 `target/`、`build/`、IDE 缓存、日志或本地运行产物。只提交项目本来就跟踪且由本次意图产生的生成源码。
-- 已在共享环境执行的版本化数据库迁移（Flyway、Liquibase）通常不可重写；发现修改既有迁移时先报告风险。
-- `fixup!` 只用于用户明确要求的评审或 autosquash 工作流；revert 优先使用 Git 生成的回滚信息并保留被回滚 SHA，不要把普通反向修改伪装成 revert。
-
-## 工作流
-
-### 1. 建立仓库契约
-
-1. 确认仓库根目录、当前分支和工作树状态。
-2. 搜索并读取仓库级说明、贡献指南、提交模板、commitlint 配置和 `commit-msg`、`pre-commit` hooks。
-3. 读取根 `pom.xml`、`settings.gradle` 或 `settings.gradle.kts` 以及相关模块构建文件，确认 Maven `artifactId`、Gradle 子项目、服务和限界上下文。
-4. 如果仓库使用 commitlint，优先使用本地依赖读取解析后的配置；不要为了校验联网安装依赖。没有 Node 工具时，直接读取 hook 和配置文件并按仓库命令验证。
-5. 查看相关模块近期的非 merge 提交，了解仓库已经形成的 scope、工单 footer、DCO 和语言习惯，但不要复制历史中的明显错误。
-
-### 2. 审查真实改动
-
-至少检查：
-
-```bash
-git status --short --branch
-git diff --cached --name-status
-git diff --cached
-git diff --name-status
-git diff
-git ls-files --others --exclude-standard
-```
-
-- 同时理解暂存区、未暂存区和未跟踪文件；结合 API、领域模型、持久化、配置和测试判断真实行为。
-- 将同一业务能力所需的接口、应用服务、领域逻辑、持久化、迁移和测试作为候选原子单元，而不是按目录机械拆分。
-- 检查 Flyway、Liquibase 等数据库变更是否触碰既有版本化迁移。
-- 若无改动、改动与请求不符、多个逻辑变更无法安全拆分，先说明并停止。需要逐行拆分同一文件时，不要靠猜测改写暂存区。
-
-### 3. 选择 type、scope 与正文
-
-先读取 `./references/scope-and-examples.md`，再按「标准代码骨架」的格式生成。
-
-- type 默认从 `feat/fix/docs/style/refactor/perf/test/chore/revert/build/ci` 中选择，但仓库枚举优先。
-- scope 优先级为：仓库枚举 → Maven artifactId 或 Gradle 子项目 → 服务或限界上下文 → 跨模块能力。使用小写 kebab-case；不要仅使用 `controller`、`service`、`repository` 或类名。
-- 标题使用英文 type/scope、ASCII `:` 和中文摘要；描述业务、调用方或运维可感知的结果，不写“修改代码”或单个 Java 类名。
-- 默认将完整 header 控制在 72 个字符内；仓库存在更严格限制时服从仓库。标题末尾不加句号，不用 emoji 或全角冒号。
-- 简单单文件变更可以没有 body；跨层实现、数据迁移、并发或事务修复、重要功能和行为变化使用 body 解释做了什么、为什么以及如何验证。
-- REST/GraphQL/RPC 契约、事件格式、公共 Java API、配置语义或数据库兼容性发生真实破坏时，使用 `!` 和 `BREAKING CHANGE:` 并写迁移方式。
-- 仅在已知编号或仓库要求时加入工单、DCO、`Signed-off-by` 等 footer，禁止编造；不要因为 Spring 项目采用 DCO 就推断所有 Java 项目都必须签署。
-
-### 4. 验证并提交
-
-1. 优先使用仓库 wrapper：Maven 使用 `./mvnw`，Gradle 使用 `./gradlew`；根据模块和变更运行已有的最小充分测试、编译、静态检查和格式检查。
-2. 通过仓库已有命令校验完整候选消息。commitlint 存在时使用 stdin 校验 header、body 和 footer；退出码为 0 才继续。
-3. 仅暂存属于当前原子提交的明确路径或安全 hunks，再重新检查 `git diff --cached --check`、`--name-status` 和完整 staged diff。
-4. 执行正常 `git commit`，允许 hooks 运行。
-5. hook 若格式化或修改文件，重新检查 staged 与 working tree，确认实际提交内容没有漂移。
-6. 提交成功后检查 `git show --stat --oneline --decorate HEAD` 和 `git status --short`，向用户报告 commit hash、消息、已运行检查以及剩余未提交改动。
-
-## 标准代码骨架
-
-```text
-type(scope)!: 中文行为摘要
-
-- 说明关键行为或原因
-- 说明兼容性、迁移、测试或必要约束
-
-BREAKING CHANGE: 说明不兼容影响和迁移方式
-Refs: 已知工单号
-```
-
-示例：
-
-```text
-fix(settlement): 修复重复回调导致结算流水重复入账的问题
-
-- 使用业务幂等键拦截已处理回调
-- 保留失败回调的可重试能力
-```
-
-## 交付检查清单
-
-- [ ] type 与 scope 通过仓库校验规则，完整消息经仓库命令校验通过。
-- [ ] scope 来自仓库枚举、构建模块或业务域，未使用 `controller`、`service`、`repository` 或类名兜底。
-- [ ] 标题为英文 type/scope + ASCII 冒号 + 中文摘要，完整 header 不超过 72 字符。
-- [ ] 提交可独立理解、构建和回滚；数据库迁移与对应实体、查询和测试同提交。
-- [ ] 暂存区不包含 `target/`、`build/`、日志或本地运行产物。
-- [ ] 已使用仓库 wrapper 运行与变更范围匹配的最小充分检查。
-- [ ] 提交后已核对 `git show --stat` 与 `git status --short`，并向用户报告 hash 与剩余改动。
-
-## 失败兜底策略
-
-- 无法区分 `feat`、`fix`、`refactor` 时继续检查需求和行为；仍有高影响歧义则询问用户，不自动降级为 `chore`。
-- hook 拒绝时按输出修正并重新校验，绝不使用 `--no-verify`。
-- 仓库 parser 或 hook 不支持标准破坏性标记时，不要绕过校验或静默删掉标记；报告规则冲突，并采用仓库明确批准的兼容方案。
-- 两个独立业务域或不同发布风险的改动无法安全拆分时，先给出拆分方案并停止；同一文件内无法分离时请求用户决定。
-- 发现修改既有版本化迁移、密钥或意外大文件时停止提交，报告具体路径并等待用户处理。

package/template/.trae/skills/java-backend-commit/agents/openai.yaml

@@ -1,7 +0,0 @@
-interface:
-  display_name: "Java 后端规范提交"
-  short_description: "分析真实改动并生成、校验 Java 后端项目的规范化 Git 提交"
-  default_prompt: "使用 $java-backend-commit 检查当前 Java 后端改动并创建一条规范、原子的 Git 提交。"
-
-policy:
-  allow_implicit_invocation: true

package/template/.trae/skills/java-backend-commit/references/scope-and-examples.md

@@ -1,118 +0,0 @@
-# Java 后端 Type、Scope 与示例
-
-## 目录
-
-- [规则优先级](#规则优先级)
-- [Type 选择](#type-选择)
-- [Scope 选择](#scope-选择)
-- [原子提交边界](#原子提交边界)
-- [消息示例](#消息示例)
-- [Java 验证](#java-验证)
-- [规范依据](#规范依据)
-
-## 规则优先级
-
-1. 仓库 commitlint 的 resolved config 和 hooks。
-2. 仓库 `AGENTS.md`、`CONTRIBUTING.md`、提交模板及明确文档。
-3. Maven/Gradle 模块定义、稳定业务术语及目标路径近期的有效提交。
-4. 本参考的通用回退规则。
-
-仓库允许空 scope 时仍优先使用能说明服务或业务域的 scope；跨全仓且没有清晰主域时可以省略。只有仓库明确要求时才添加工单 footer、DCO 或签名。
-
-## Type 选择
-
-| Type | 使用条件 | 不要用于 |
-|---|---|---|
-| `feat` | 新增 API、业务能力、运维能力或可用配置 | 纯重构或依赖升级 |
-| `fix` | 修复错误结果、异常、回归、事务或并发缺陷 | 仅格式化代码 |
-| `docs` | 只修改文档或 Javadoc | 代码行为变化 |
-| `style` | 仅格式、空格、导入排序等，不改变语义 | 接口或 UI 风格变化 |
-| `refactor` | 不增功能、不修 bug 的结构调整 | 性能优化或行为修复 |
-| `perf` | 有明确性能收益的代码或查询变化 | 无证据的“优化”措辞 |
-| `test` | 只增加或修正测试 | 功能代码及其配套测试 |
-| `build` | Maven/Gradle、依赖、插件、打包或编译配置 | 一般业务配置 |
-| `ci` | CI/CD 配置和流水线脚本 | 本地构建配置 |
-| `chore` | 其他不改变产品行为的维护工作 | 无法理解改动时的兜底 |
-| `revert` | 明确回滚一个或多个既有提交 | 普通修复 |
-
-## Scope 选择
-
-按以下顺序选择首个清晰候选：
-
-1. **仓库限定值**：若 `scope-enum` 生效，只能使用允许值或按规则省略。
-2. **构建模块**：Maven 使用稳定的 `artifactId`，Gradle 使用子项目名，例如 `order-service`、`risk-engine`。
-3. **服务或限界上下文**：单模块项目按稳定业务域使用 `order`、`customer`、`settlement`、`valuation` 等名称。
-4. **跨模块能力**：确实横跨业务域时使用仓库已有的 `api`、`db`、`security`、`messaging`、`observability`、`deps`、`build` 或 `ci`。
-
-命名使用小写 kebab-case。优先采用 `pom.xml`、Gradle settings、包名和产品文档中的既有术语。`controller`、`service`、`repository`、`entity`、`common` 和具体类名通常不能表达业务影响，不应作为默认 scope。
-
-## 原子提交边界
-
-- 同一业务能力的 controller、application/domain service、repository、DTO、迁移和测试可以同提交，确保提交可构建和回滚。
-- 公共契约与所有必需调用方修改通常同提交；若仓库支持分阶段兼容迁移，则按兼容阶段拆分。
-- `pom.xml`、version catalog 或 Gradle 文件与其 lock/verification metadata 一起提交；无关依赖升级单独使用 `build(deps)`。
-- Flyway/Liquibase 新迁移与对应实体、查询和测试可同提交；不要顺手重写已发布版本化迁移。
-- 两个独立业务域、不同发布风险或不同回滚策略的改动应拆分；同一文件内无法安全分离时先请求用户决定。
-
-## 消息示例
-
-```text
-feat(order): 支持批量取消待支付订单
-
-- 增加批量取消接口并复用单笔状态校验
-- 保持已支付订单处理和审计记录不变
-- 补充事务回滚与部分非法状态测试
-```
-
-```text
-fix(settlement): 修复重复回调导致结算流水重复入账的问题
-
-- 使用业务幂等键拦截已处理回调
-- 保留失败回调的可重试能力
-```
-
-```text
-build(deps): 升级 Spring Boot 与数据库驱动
-```
-
-```text
-feat(customer-api)!: 统一客户查询响应结构
-
-- 将分页数据统一为 items 和 total
-- 更新 OpenAPI 契约与消费者测试
-
-BREAKING CHANGE: 原 records 字段改为 items，调用方需更新反序列化模型
-```
-
-```text
-perf(valuation): 批量加载估值参数以减少重复查询
-
-- 将逐条查询合并为按产品批量加载
-- 增加查询次数断言并验证计算结果保持一致
-```
-
-错误与修正：
-
-| 错误 | 修正方向 |
-|---|---|
-| `fix：修改 OrderService` | 使用 ASCII 冒号并描述修复结果 |
-| `feat(controller): 新增接口` | 使用服务、模块或业务域 scope |
-| `chore: 修改数据库` | 判断是功能、修复、性能还是构建变化 |
-| `fix(order): 修复 bug` | 说明错误场景和用户可感知结果 |
-
-## Java 验证
-
-- 优先使用 wrapper，避免依赖开发机全局 Maven 或 Gradle 版本。
-- Maven 多模块可基于真实模块使用 `./mvnw -pl <module> -am test`；Gradle 可使用 `./gradlew :<module>:test`。不要编造模块路径或任务。
-- API 变更运行契约或集成测试；数据库变更运行迁移和 repository 测试；并发、事务和性能变更运行能证明关键性质的测试。
-- 使用仓库已有 Checkstyle、SpotBugs、PMD、Error Prone、JaCoCo 或格式检查任务；不要擅自引入新工具。
-- 测试产生的 `target/`、`build/`、日志和报告不得进入提交。
-
-## 规范依据
-
-- [Conventional Commits 1.0.0](https://www.conventionalcommits.org/en/v1.0.0/)
-- [commitlint：AI Agents](https://commitlint.js.org/guides/ai-agents.html)
-- [commitlint 官方 committing-with-commitlint skill](https://github.com/conventional-changelog/commitlint/tree/master/skills/committing-with-commitlint)
-- [Spring Framework CONTRIBUTING](https://github.com/spring-projects/spring-framework/blob/main/CONTRIBUTING.md)
-- [Git SubmittingPatches](https://git-scm.com/docs/SubmittingPatches)
-

package/template/.trae/skills/llm-wiki/SKILL.md

@@ -1,60 +0,0 @@
----
-name: llm-wiki
-description: >
-  Compile and maintain a Karpathy-pattern LLM wiki (raw + wiki + schema) with
-  init, incremental refresh, global rebuild, lint, and narrow ingest. Use when
-  the user wants a local knowledge wiki, incremental wiki refresh, wiki rebuild,
-  compiling a named research note into the wiki, `/llm-wiki`, or an answer from
-  an existing wiki.
----
-
-# llm-wiki
-
-Compile a persistent wiki from live documents and code. The wiki is the IR; live sources are the truth. Read [schema](references/schema.md), then the matching mode file.
-
-One-off notes are out of scope. Use this skill to compile or lint a persistent wiki (`raw/` + `wiki/` + `.wiki-manifest.json`), or to answer from an existing wiki per [query.md](references/query.md).
-
-## Mode
-
-| User intent | Mode | Completion |
-|---|---|---|
-| 从零构建知识库 | `init` | 三层目录 + schema + index + log + 文章 + `.wiki-manifest.json`，lint 退出 0 |
-| 源变了，更新受影响页 | `refresh` | 只改漂移命中的文章；human-owned 不改；lint 0；log 有 REFRESH |
-| 全局按新源重编译 | `rebuild` | raw 对齐 live；稳定 ID 与 human-owned 保留；LLM 页全量重写；lint 0；log 有 REBUILD |
-| 健康检查 | `lint` | 结构脚本 exit 0 + 已跑 advise 并报告条数；对变更页做 live 源抽查 |
-| 把点名外源或已落盘 research 笔记编进 wiki | `ingest` | raw 登记 + manifest 源 + 四态候选经确认后写页；lint 0；log 有 `INGEST` |
-
-Ambiguous → ask. Existing wiki + "构建" → ask refresh vs rebuild, do not init over it.
-
-Query is not a mode. Follow [query.md](references/query.md). Query never writes and never ingests.
-
-## Layout
-
-```
-<wiki-root>/
-  raw/                  # immutable copies + labelled extracts
-  wiki/                 # articles + index.md + log.md + CLAUDE.md
-  .wiki-manifest.json   # compile graph (sources ↔ articles)
-```
-
-Scripts live in this skill's `scripts/` directory (the folder that contains this `SKILL.md`). Run them from the repo root so `--wiki` / `--repo` resolve correctly:
-
-```bash
-node <skill-root>/scripts/inventory.mjs hash --wiki <wiki-root>
-node <skill-root>/scripts/inventory.mjs status --wiki <wiki-root>
-node <skill-root>/scripts/lint-wikilinks.mjs <wiki-root>
-node <skill-root>/scripts/advise.mjs <wiki-root>
-node <skill-root>/scripts/extract.mjs skill-names --in <live-lock.json> --out <wiki-root>/<rawPath>
-```
-
-`status` is a stable alias of `drift`. `<skill-root>` is the canonical skill directory or a projection that points at it. Do not hard-code `.agents/skills/llm-wiki`.
-
-## Steps
-
-1. Detect: `<wiki-root>/wiki/index.md` + `CLAUDE.md` (or `AGENTS.md`) means a wiki exists. Default wiki-root is repo-root `wiki/`. If `yss-project.yaml` is `repository_mode: template-source`, wiki-root is `.template-source/wiki`.
-2. If the user is asking a repository question, load [query.md](references/query.md) and stop. Do not lint, ingest, or append `log.md`.
-3. Load the mode algorithm: [compile.md](references/compile.md) for init/refresh/rebuild, [ingest.md](references/ingest.md) for ingest. For init/rebuild corpus choice, load [discover.md](discover.md). For writing, load [writing.md](references/writing.md). For checks, load [lint.md](references/lint.md).
-4. **Fact order:** called code > table comments / config defaults > stale raw copies. After writing, re-read live sources for a sample of claims (`N = min(5, changed pages)`).
-5. Run structural lint and advise. Append `log.md`. Stop.
-
-`refresh` without a manifest: stop. Rebuild, or reconstruct the manifest from existing「来源」sections — do not guess `sourceIds`.

package/template/.trae/skills/llm-wiki/assets/CLAUDE.md.template

@@ -1,26 +0,0 @@
-# CLAUDE.md — Wiki schema
-
-本文档是本 wiki 的 schema（结构契约）。正文语言遵循宿主项目的文档语言规则；英文专有名词、类名、枚举值、表名与 API 路径保持原样。
-
-## 三层结构
-
-- **`raw/`** — 不可变原始源。从 live 文档拷贝，或从 live 源提取且标明出处的派生摘要。只读，不靠改 raw 来「修正」事实。
-- **文章（`wiki/*.md`）** — LLM 生成的知识文章。文件名（不含 `.md`）即文章 ID，必须全局唯一。使用 `[[wikilink]]` 互引。
-- **`index.md`** — 内容目录。`##` 节标题定义分类；节下列出该分类下的 `[[wikilink]]`。
-
-## 文章写作约定
-
-- 首行为 `# H1`，随后紧跟首段摘要。
-- 正文使用 `[[目标文章名]]`；目标必须是本 wiki 内存在的文章文件名（不含 `.md`）。
-- 论断必须能追溯到 `raw/` 或 live 代码路径。文末使用 `## 来源`。
-- 分类归属由 `index.md` 决定。
-- 可选 frontmatter：`human-owned: true` 时 refresh / rebuild 不得重写正文。
-- 仅当多个来源冲突，或 live 与旧 raw 不一致时写可选 `## Status`（`Disputed` / `Outdated`）。单一 live 正确则不写。
-
-## 基础设施文件
-
-`index.md`、`log.md`、`CLAUDE.md`、`AGENTS.md`、`soul.md`、`concept-table.md` 为基础设施文件，不视为文章。
-
-## 操作日志
-
-`log.md` 只追加。格式：`## [YYYY-MM-DD] OPERATION | 描述`（CREATE / UPDATE / LINK / FIX / REFRESH / REBUILD / RETIRE / LINT / INGEST）。

package/template/.trae/skills/llm-wiki/assets/fixtures/broken-wiki/wiki/CLAUDE.md

@@ -1,3 +0,0 @@
-# CLAUDE.md
-
-fixture schema