create-yss-spec 3.0.0 → 3.1.0

package/template/.hermes/skills/frontend-commit/references/scope-and-examples.md

@@ -1,111 +0,0 @@
-# 前端 Type、Scope 与示例
-
-## 目录
-
-- [规则优先级](#规则优先级)
-- [Type 选择](#type-选择)
-- [Scope 选择](#scope-选择)
-- [原子提交边界](#原子提交边界)
-- [消息示例](#消息示例)
-- [前端验证](#前端验证)
-- [规范依据](#规范依据)
-
-## 规则优先级
-
-1. 仓库 commitlint 的 resolved config 和 hooks。
-2. 仓库 `AGENTS.md`、`CONTRIBUTING.md`、提交模板及明确文档。
-3. 当前 monorepo 的包或应用名称，以及目标路径近期的有效提交。
-4. 本参考的通用回退规则。
-
-仓库允许空 scope 时仍优先使用能帮助团队定位业务影响的 scope；跨全仓且没有清晰主域时可以省略。只有 commitlint 明确支持且团队历史稳定使用时才采用多 scope。
-
-## Type 选择
-
-| Type | 使用条件 | 不要用于 |
-|---|---|---|
-| `feat` | 增加用户、调用方或运维人员可感知的能力 | 纯重构或依赖升级 |
-| `fix` | 修复错误、回归、异常状态或不符合预期的行为 | 仅格式化代码 |
-| `docs` | 只修改文档 | 代码行为变化 |
-| `style` | 仅空格、格式、分号等，不改变语义 | UI 样式或视觉功能变更 |
-| `refactor` | 不增功能、不修 bug 的结构调整 | 性能优化或行为修复 |
-| `perf` | 有明确性能收益的代码变化 | 无证据的“优化”措辞 |
-| `test` | 只增加或修正测试 | 功能代码及其配套测试 |
-| `build` | 构建系统、外部依赖、打包或编译配置 | 一般业务配置 |
-| `ci` | CI/CD 配置和流水线脚本 | 本地构建配置 |
-| `chore` | 其他不改变产品行为的维护工作 | 无法理解改动时的兜底 |
-| `revert` | 明确回滚一个或多个既有提交 | 普通修复 |
-
-## Scope 选择
-
-按以下顺序选择首个清晰候选：
-
-1. **仓库限定值**：若 `scope-enum` 生效，只能使用允许值或按规则省略。
-2. **monorepo 包或应用**：`apps/admin-portal` 使用 `admin-portal`；`packages/design-system` 使用 `design-system`。
-3. **业务模块**：`views/DataPush`、相关 API、hook 和测试共同实现推送任务时使用 `data-push`，不使用 `views`。
-4. **共享能力**：确实跨业务复用时使用 `auth`、`router`、`store`、`i18n`、`api-client`、`design-system` 等已有名称。
-5. **工程边界**：依赖升级可用 `deps`，构建和 CI 可用 `build`、`ci`；scope 不应重复无意义信息。
-
-命名使用小写 kebab-case。优先采用仓库或产品已有术语，不自行翻译稳定模块名。`components`、`hooks`、`utils`、`views`、`index` 和具体文件名通常信息不足，只有它们本身就是对外包或仓库既定 scope 时才使用。
-
-## 原子提交边界
-
-- 同一功能的页面、API 适配、状态逻辑、测试和最小测试配置可以同提交。
-- `package.json` 与对应 lockfile 必须同提交；与业务功能无关的批量依赖升级单独使用 `build(deps)`。
-- 生成 API 客户端和消费端若共同实现同一契约能力，可按业务域提交；无关的大规模重新生成必须拆分。
-- 顺手格式化、调试日志、个人 IDE 配置和无关文件不要混入。
-- 两个独立业务模块或不同发布风险的改动应拆分；同一文件内无法安全分离时先请求用户决定。
-
-## 消息示例
-
-```text
-feat(data-push): 优化推送任务数据源与调度规则展示
-
-- 将英文星期转换为中文调度描述
-- 按数据源目录映射业务名称并补充单元测试
-```
-
-```text
-fix(auth): 修复令牌刷新并发请求重复跳转登录的问题
-
-- 复用进行中的刷新请求，避免多个失败响应重复触发跳转
-- 保持刷新失败后的退出流程不变
-```
-
-```text
-build(deps): 升级 Vue 与类型检查工具链
-```
-
-```text
-feat(api-client)!: 统一分页响应字段命名
-
-- 将列表响应统一为 items 和 total
-- 更新调用方与契约测试
-
-BREAKING CHANGE: 原 records 字段改为 items，所有自定义适配器需同步迁移
-```
-
-错误与修正：
-
-| 错误 | 修正方向 |
-|---|---|
-| `fix：修复问题` | 使用 ASCII 冒号并说明具体行为 |
-| `fixL 新增下载` | 选择合法 type，例如 `feat(download): 支持导出任务文件` |
-| `fix: useDataPushTasks.ts` | 描述修复结果，而不是文件名 |
-| `feat(views): 新增用户管理` | 优先使用 `feat(user-management): ...` |
-| `chore: 修改代码` | 先理解真实意图，再选择准确 type 和摘要 |
-
-## 前端验证
-
-- 根据 lockfile 选择 `pnpm`、`npm`、`yarn` 或 `bun`，优先运行 `package.json` 已有脚本。
-- 功能或修复至少运行相关测试；类型相关变更运行 type-check；lint、format 只使用不会意外重写无关文件的检查模式。
-- monorepo 优先运行受影响包的过滤命令，除非仓库要求全量检查。
-- 不把“hook 会跑”当作跳过必要验证的理由；也不要编造不存在的脚本。
-
-## 规范依据
-
-- [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)
-- [Angular Commit Message Guidelines](https://github.com/angular/angular/blob/main/contributing-docs/commit-message-guidelines.md)
-- [Git SubmittingPatches](https://git-scm.com/docs/SubmittingPatches)
-

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

@@ -1,7 +0,0 @@
----
-name: grill-me
-description: A relentless interview to sharpen a plan or design.
-disable-model-invocation: true
----
-
-Call the Skill tool with `grilling`.

package/template/.hermes/skills/grill-me/agents/openai.yaml

@@ -1,5 +0,0 @@
-interface:
-  display_name: "Grill Me"
-  short_description: "Sharpen a plan through interview"
-policy:
-  allow_implicit_invocation: false

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

@@ -1,19 +0,0 @@
----
-name: grill-with-docs
-description: Use when the user explicitly requests a relentless design interview that must preserve resolved glossary terms, ADR-worthy decisions, and factual research evidence.
-disable-model-invocation: true
----
-
-Call the Skill tool with `grilling`, then call it separately with `domain-modeling`.
-
-## Output Contract
-
-1. Read the repository identity and current glossary before the first round.
-2. Separate discoverable facts from user decisions; investigate facts instead of asking the user.
-3. Ask the entire current decision frontier, with a recommendation for every question, then wait.
-4. Record resolved stable terms in the authoritative `CONTEXT.md` only when they are true glossary entries.
-5. Create an ADR only when the decision is hard to reverse, surprising without context, and a real trade-off.
-6. Persist factual research/validation records in the repository's existing review or research convention.
-7. Do not modify implementation skills, contracts, or code until the user confirms shared understanding and the intended change scope.
-
-The final grilling round must list confirmed decisions, unresolved assumptions, documents changed, and the next authorized action. A research note is evidence, not an architecture approval or release claim.

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

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

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

@@ -1,28 +0,0 @@
----
-name: grilling
-description: Grill the user relentlessly about a plan, decision, or idea. Use when the user wants to stress-test their thinking, or uses any 'grill' trigger phrases.
----
-
-Interview the user relentlessly until you reach a shared understanding. Map this as a **design tree**: every decision branches into the decisions that hang off it.
-
-Work the tree in **rounds**. The **frontier** is every decision whose prerequisites are already settled — the questions you can ask _now_ without guessing at answers you haven't heard yet. Ask the whole frontier in one round: number each question and give your recommended answer. Then wait for the user's answers before the next round.
-
-Format a round like so:
-
-```
-❓ **Q1** - **<question title>**: <question body, might be multiple paragraphs, including multiple choices>
-
-➡️ <your recommended answer>
-
----
-
-❓ **Q2** - **<question title>**: <question body, might be multiple paragraphs, including multiple choices>
-
-➡️ <your recommended answer>
-```
-
-Each round the user answers reshapes the tree — settled decisions push the frontier outward and unblock questions that depended on them. Recompute the frontier and ask the next round. A question whose answer depends on another question still open in this round belongs to a _later_ round, not this one.
-
-Finding _facts_ is your job, never the user's. When a frontier question needs a fact from the environment (filesystem, tools, etc.), dispatch a sub-agent to find it — don't ask the user for anything you could look up yourself. Don't block on it: a running exploration is an unsettled prerequisite, so only the questions downstream of it wait for the sub-agent to report — ask the rest of the frontier now. The _decisions_ are the user's — put each to them and wait.
-
-The session is done when the frontier is empty: every branch of the design tree visited, nothing left silently assumed. Do not act on it until the user confirms you have reached a shared understanding.

package/template/.hermes/skills/grilling/agents/openai.yaml

@@ -1,3 +0,0 @@
-interface:
-  display_name: "Grilling"
-  short_description: "Stress-test thinking a round of questions at a time"

package/template/.hermes/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/.hermes/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/.hermes/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/.hermes/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/.hermes/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/.hermes/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/.hermes/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/.hermes/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/.hermes/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/.hermes/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