@mingfuyun/star-allinone 0.1.9 → 0.3.0

package/skills/README.md

@@ -10,12 +10,14 @@
 
 ```text
 starscope-frontend/
+├── AGENTS.md
 ├── .star-allinone.json
 └── .agents/
     ├── skills/
     │   ├── shared-api-to-service/
     │   ├── shared-api-mock/
     │   ├── shared-design-to-page/
+    │   ├── shared-page-recipe/
     │   ├── shared-verify/
     │   ├── shared-review-and-submit/
     │   ├── shared-publish-test/
@@ -30,11 +32,13 @@ StarLink：
 
 ```text
 starlink-frontend/
+├── AGENTS.md
 └── .agents/
     └── skills/
         ├── shared-api-to-service/
         ├── shared-api-mock/
         ├── shared-design-to-page/
+        ├── shared-page-recipe/
         ├── shared-verify/
         ├── shared-review-and-submit/
         ├── shared-publish-test/
@@ -50,6 +54,8 @@ custom-*   业务定制 skill，由业务项目维护
 
 这样所有 skill 都在业务项目中，Codex 可以直接发现；同时通过名称可以清楚区分来源。
 
+Cursor / Codex 的常驻说明只放仓库根 `AGENTS.md`（模板见 `examples/AGENTS.md`）。项目差异放 `.agents/project/`。不要新增 `.cursor/rules`。
+
 ## npm 包的职责
 
 `@mingfuyun/star-allinone` 包中保存公共 skill 源文件。每个 skill 包含可执行规则，细节放在同目录 `references/`：
@@ -65,12 +71,14 @@ custom-*   业务定制 skill，由业务项目维护
         │       └── api-artifact-generation.md
         ├── api-mock/
         ├── design-to-page/          # page-conventions.md + overlays.md
+        ├── page-recipe/             # 标准列表页；CLI `gen page`
         ├── project-conventions/     # architecture / review-checklist / quality-checklist
         ├── verify/
         ├── review-and-submit/
         ├── impact-analysis/
         ├── ai-review/
         ├── commit-current-changes/
+        ├── i-have-adhd/               # 同步为 shared-i-have-adhd；其他 shared skill 的用户输出格式
         └── publish-test/              # 流水线 ID 从 .star-allinone.json 读取
 ```
 
@@ -172,7 +180,7 @@ git commit -m "feat(skill): 增加设备管理 skill"
 
 不需要修改 `star-allinone`，也不需要重新发布 npm。
 
-审查、提交、测试环境发布、Mock 和 Service 生成都走公共 skill。只有流水线 ID 放在业务项目的 `.star-allinone.json`。`custom-*` 只用于真正的业务特例，例如设备管理或节点管理。
+审查、提交、测试环境发布、单接口 Mock/Service、标准列表都走公共入口 skill。`custom-*` 只用于真正的业务特例。单接口生成禁止再做 custom；只有整份契约全量重建才允许留在 custom，并必须在 description 里写明「只用于全量」。度量类 custom 不得生成代码。
 
 ## 公共部分和业务定制组合
 
@@ -213,6 +221,7 @@ description: Generate StarScope device service code.
 
 ```text
 starscope-frontend/
+├── AGENTS.md
 ├── .star-allinone.json
 └── .agents/
     ├── skills/
@@ -246,6 +255,24 @@ StarLink 使用：
 
 可选字段 `sharedSkills` 用于只同步部分公共 skill；省略时同步 `skills/shared` 下的全部公共 skill。
 
+## 用户入口 vs 内部 skill
+
+对话里只点这些入口：
+
+| 入口 | 用途 |
+| --- | --- |
+| `shared-api-to-service` | 单个 `METHOD /path/` → 类型、`MFRequest`、默认 mock |
+| `shared-page-recipe` | 标准列表页（表格 + 抽屉 + 确认） |
+| `shared-design-to-page` | 非标准设计稿 |
+| `shared-review-and-submit` | 审查并提交（内部会读 impact / verify / commit） |
+| `shared-publish-test` | 测发 |
+
+下面这些会随包同步，但 **不要作为用户入口调用**（`disable-model-invocation`）。入口 skill 会去读对应 `SKILL.md`：
+
+`shared-api-mock`、`shared-project-conventions`、`shared-verify`、`shared-impact-analysis`、`shared-ai-review`、`shared-commit-current-changes`、`shared-i-have-adhd`
+
+`custom-*` 禁止再实现一遍上述入口。单接口生成走公共 CLI；只有「整份契约全量重建」才允许留在 custom（例如 StarLink `custom-swagger-to-markdown`）。度量类 custom 不得生成代码。
+
 ## 公共规则写在哪里
 
 | Skill | 规则位置 | 覆盖内容 |
@@ -253,6 +280,7 @@ StarLink 使用：
 | `shared-api-to-service` | SKILL + `references/service-conventions.md`、`api-artifact-generation.md` | 指定 operation、`MFRequest` 映射、namespace 类型、snake_case、schema 闭包、禁止改 transport |
 | `shared-api-mock` | SKILL + `references/mock-conventions.md` | 对话 JSON 默认、完整响应信封、分页/空列表/错误场景、禁止 handler 和随机数 |
 | `shared-design-to-page` | SKILL + `references/page-conventions.md`、`overlays.md` | 页面分层、`MFProTable`、`ProForm`、权限、异步、`HocModal` 弹层合同 |
+| `shared-page-recipe` | SKILL + `references/list-page-template.md` | 标准列表页文件树；先跑 `star-allinone gen page` |
 | `shared-project-conventions` | SKILL + `references/architecture.md`、`review-checklist.md`、`quality-checklist.md` | 架构边界、质量禁令、审查清单；其他 skill 会引用这些文件 |
 | `shared-verify` | SKILL | 成套产物检查、await/loading/弹层、验证命令和报告格式 |
 | `shared-impact-analysis` | SKILL | 只读影响分类和回归路径 |
@@ -289,9 +317,10 @@ star-allinone 修改
 最终结构和责任边界：
 
 ```text
+AGENTS.md           ← 常驻约定，不要加 .cursor/rules
 .agents/skills/
-├── shared-*    ← npm 包同步，不能在业务项目直接维护
-└── custom-*    ← 业务项目自己维护
+├── shared-*        ← npm 包同步，不能在业务项目直接维护
+└── custom-*        ← 业务项目自己维护
 ```
 
 这比全局安装更适合团队协作，也比把公共 skill 藏在 `node_modules` 中更可靠，因为公共 skill 最终会进入业务项目仓库，团队成员拉取代码后即可直接使用。

package/skills/shared/ai-review/SKILL.md

@@ -1,10 +1,13 @@
 ---
 name: {{sharedSkillName}}
-description: Review frontend changes for correctness, API and permission contracts, React lifecycle, performance, maintainability, security, accessibility, and test gaps. Use for a standalone review without commit. Do not modify files.
+description: Internal. Do not invoke. Standalone review checklist used by shared-review-and-submit. Do not modify files.
+disable-model-invocation: true
 ---
 
 # AI Code Review
 
+Not a user-facing entry. Do not invoke this skill. `shared-review-and-submit` covers review. Do not treat this as a generate or submit entry.
+
 This skill is fully shared. Review the current diff plus relevant callers and types. Before reviewing, read:
 
 1. `.agents/skills/shared-project-conventions/references/review-checklist.md`
@@ -27,3 +30,7 @@ Do not require a project-local review-rules file. If `.agents/project/review-rul
 Lead with findings ordered `[P0]`–`[P3]`, with file and line. Separate blocking issues from recommendations. Do not report style preferences as bugs.
 
 If none, write `No issues found.` Always include validation performed and gaps. Do not modify files unless the user explicitly asks for fixes.
+
+## User-facing output
+
+Read and apply `.agents/skills/shared-i-have-adhd/SKILL.md` to every response this skill sends to the user.

package/skills/shared/api-mock/SKILL.md

@@ -1,10 +1,13 @@
 ---
 name: {{sharedSkillName}}
-description: Generate deterministic API mock responses matching the active frontend project's OpenAPI contract and service types. Use when the user asks for JSON fixtures, proxy-ready mock data, empty or error scenarios, or mock files for a specified endpoint.
+description: Internal. Do not invoke. Called by shared-api-to-service when extra mock scenarios are needed. Not a user-facing generate-service entry.
+disable-model-invocation: true
 ---
 
 # API Mock
 
+Not a user-facing entry. Do not invoke this skill. `shared-api-to-service` reads this file when extra mock scenarios are needed. Generating types or `MFRequest` methods is not this skill's job.
+
 This skill is fully shared. Read [references/mock-conventions.md](references/mock-conventions.md), `.star-allinone.json`, the related service types, and the OpenAPI file from `openapi` in `.star-allinone.json` (or the document provided in this conversation).
 
 If the service contract is missing, first follow `.agents/skills/shared-api-to-service/SKILL.md`.
@@ -21,3 +24,7 @@ If the service contract is missing, first follow `.agents/skills/shared-api-to-s
 ## Handoff
 
 For every endpoint, report HTTP method, path, scenario label, and one strict parseable JSON block. If files were written, list the paths and confirm they parse as JSON.
+
+## User-facing output
+
+Read and apply `.agents/skills/shared-i-have-adhd/SKILL.md` to every response this skill sends to the user.

package/skills/shared/api-to-service/SKILL.md

@@ -1,10 +1,12 @@
 ---
 name: {{sharedSkillName}}
-description: Generate frontend TypeScript API types, MFRequest service methods, aggregate exports, and contract-aligned mock artifacts for an explicitly selected API operation. Use when the user names an endpoint or operationId and asks to generate or update service, types, or mock data.
+description: User-facing. Generate or update one OpenAPI/Swagger operation as TypeScript types, an MFRequest method, and optional mock JSON. Use for a named METHOD /path or operationId. Do not use for full-spec domain regen.
 ---
 
 # API to Service
 
+User-facing entry for **one** `METHOD /path/` or `operationId`. Do not regenerate an entire Swagger domain here. StarLink full-spec rebuilds stay on `custom-swagger-to-markdown`.
+
 This skill is fully shared. Generate only the requested `METHOD /path/` or `operationId`. Do not guess undocumented fields or change unrelated endpoints.
 
 Read before editing:
@@ -25,12 +27,18 @@ OpenAPI lookup order:
 ## Workflow
 
 1. Resolve one exact operation. If a path has multiple methods and intent is unclear, ask for the method. Never infer a destructive method.
-2. Recursively resolve parameters, request body, responses, and local `$ref`s. Neighboring methods that share a path are out of scope.
-3. Build the target matrix in `api-artifact-generation.md`. Compare existing types, methods, exports, and mocks. Classify create / update / reuse / conflict.
-4. Report contract conflicts before overwriting deployed behavior.
-5. Update `src/services/<Domain>/typings.d.ts`, the thin `MFRequest` method, and `src/services/index.ts` when the domain export is missing.
-6. Produce the default successful JSON mock. Add empty or error variants only when requested.
-7. Verify formatting, TypeScript, JSON parsing, exact method/path, and a focused diff.
+2. From the business project root, generate the artifacts with the CLI. Do not hand-write types or `MFRequest` methods when the spec exists:
+
+```bash
+pnpm exec star-allinone gen service --operation "GET /api/v1/devices/"
+```
+
+Use `--spec <file>` when `.star-allinone.json` has no `openapi`. Use `--domain <Name>` when the folder cannot be inferred. Use `--mock-file` only when the user asked for a mock file; otherwise keep the default conversation JSON.
+
+3. If the CLI reports reuse, keep the existing method. If it reports a conflict, stop and show the diff; do not overwrite.
+4. Review the generated types against the spec: snake_case, optionality, `| null`, unwrapped `data`, and exact method/path.
+5. Produce extra empty or error mocks only when requested, using `.agents/skills/shared-api-mock/SKILL.md`.
+6. Verify formatting, TypeScript, JSON parsing, exact method/path, and a focused diff.
 
 ## Hard rules
 
@@ -45,7 +53,11 @@ OpenAPI lookup order:
 
 ```bash
 pnpm exec prettier --check <changed-service-and-json-files>
-pnpm exec tsc --noEmit
+pnpm typecheck
 ```
 
 Parse changed JSON files. Search generated names, operationId, and exact API paths for omissions and collisions. Run `pnpm lint` for broad service changes. Cite the OpenAPI path, method, operationId, and schema names in the handoff.
+
+## User-facing output
+
+Read and apply `.agents/skills/shared-i-have-adhd/SKILL.md` to every response this skill sends to the user.

package/skills/shared/commit-current-changes/SKILL.md

@@ -1,10 +1,13 @@
 ---
 name: {{sharedSkillName}}
-description: Review the active frontend project's changes and prepare a confirmation-gated Conventional Commit and optional push. Use when the user asks to review current changes, submit code, or commit and push. Never commit before explicit confirmation.
+description: Internal. Do not invoke. Step 3 of shared-review-and-submit. Confirmation-gated commit only after that entry skill has run.
+disable-model-invocation: true
 ---
 
 # Commit Current Changes
 
+Not a user-facing entry. Do not invoke this skill when the user says 提交 or 审查. Use `shared-review-and-submit`, which calls this file as step 3.
+
 This skill is fully shared. Review user-authorized working-tree changes, report findings and a commit proposal, and mutate Git only after explicit confirmation.
 
 ## Write-operation gate
@@ -64,3 +67,7 @@ A confirmed commit or push does not authorize the test pipeline. If the user lat
 - Never expose credentials from diffs; stop if secrets are present.
 - Never use destructive Git commands to clean the working tree.
 - If push is rejected, report the reason and do not rewrite history without separate authorization.
+
+## User-facing output
+
+Read and apply `.agents/skills/shared-i-have-adhd/SKILL.md` to every response this skill sends to the user.

package/skills/shared/design-to-page/SKILL.md

@@ -1,10 +1,12 @@
 ---
 name: {{sharedSkillName}}
-description: Implement frontend pages from designs using the active project's React, Umi, Ant Design Pro, service, permission, routing, and component conventions. Use when translating Figma, screenshots, wireframes, or UI specs into page code.
+description: User-facing. Implement a non-standard page from Figma, screenshots, or UI specs. For a standard table + drawer + confirm list, use shared-page-recipe instead.
 ---
 
 # Design to Page
 
+User-facing entry for **non-standard** pages. If the request is a standard table + drawer + confirm list, stop and follow `shared-page-recipe` instead.
+
 Translate a design into repository-native code. Reuse existing architecture; do not invent a parallel stack.
 
 Before implementation, read:
@@ -18,6 +20,8 @@ If `.agents/project/conventions.md` exists, use it only for extra paths.
 
 Inspect the nearest existing page of the same type before proposing files.
 
+If the request is a standard management list (table + query + drawer form + confirm), use `.agents/skills/shared-page-recipe/SKILL.md` and `pnpm exec star-allinone gen page` instead of guessing the file tree.
+
 ## Workflow
 
 1. List visible states: default, loading, empty, error, disabled, overflow, permission, and narrow-screen.
@@ -46,3 +50,7 @@ pnpm exec tsc --noEmit
 ```
 
 Run `pnpm lint` for broad or shared changes. Run the project's documented build command when routes, entry, or multiple pages change.
+
+## User-facing output
+
+Read and apply `.agents/skills/shared-i-have-adhd/SKILL.md` to every response this skill sends to the user.

package/skills/shared/i-have-adhd/SKILL.md

@@ -0,0 +1,142 @@
+---
+name: {{sharedSkillName}}
+description: Internal output style. Do not invoke as a task. Other shared skills apply this file to user-facing replies. Turn on with /i-have-adhd; off with stop adhd mode.
+disable-model-invocation: true
+license: MIT
+metadata:
+  tags: "ADHD, Output Style, Productivity, Formatting"
+  category: "productivity"
+---
+
+# i-have-adhd
+
+The reader has ADHD. Output is not just brief. It is shaped so an ADHD brain can act on it.
+
+## Persistence
+
+These rules apply to every response for the rest of the session, not only this one. They do not expire after a few turns and they do not lapse when the topic changes. If you are unsure whether they still apply, they do.
+
+Turn them off only when the reader says "stop adhd mode" or "normal mode". Confirm in one line, then return to your default style.
+
+## What ADHD changes about reading
+
+Five facts drive every rule below:
+
+1. Working memory is small. Anything not on screen is forgotten. Do not ask the reader to "keep in mind X."
+2. Knowing the answer is not doing the answer. The friction between "got it" and "done it" is where work dies.
+3. Starting is the hardest step. The first action must be obvious, small, and doable now.
+4. Time estimates feel uniform. "A bit of work" and "a few hours" register the same. Vague estimates fail.
+5. Dopamine is scarce. Visible progress matters. Buried wins do not register.
+
+## Rules
+
+### 1. Lead with the next action
+
+The first line is something the reader can do. Not context. Not a plan. The action.
+
+Bad: "Let's think about this. Your auth flow has a few moving pieces..."
+Good: "Run `npm install jsonwebtoken`, then edit `src/auth.ts:42`."
+
+If the answer is a command, path, or snippet, it goes first. Prose comes after, if at all.
+
+### 2. Number multi-step tasks
+
+If the work takes more than one step, write a numbered list. Each step is one bounded action. No step contains "and then" twice.
+
+Use the fewest steps that still work. Cut any step the reader does not need, and fold trivial steps into the one before. A short path finished beats a complete path abandoned.
+
+Bad: "First open the file, find the function, swap it out, then run the tests."
+
+Good:
+```
+1. Open `src/auth.ts`
+2. Replace `verifyToken` (lines 42 to 58) with the snippet below
+3. Run `npm test -- auth.spec.ts`
+```
+
+### 3. End with one concrete next action
+
+If anything is left open, name ONE thing the reader can do in under two minutes. Even "open the file" counts.
+
+Bad: "Hope that helps. Let me know if you want to dig deeper."
+Good: "Next: run `npm test` and paste the first failing line."
+
+### 4. Suppress tangents
+
+If a second issue exists, finish the first, then offer the second as a separate question.
+
+Bad: "Here's the fix. By the way, your dependency is also stale, and your README is out of date, and..."
+Good: "Here's the fix. Separately: there is also a stale dependency. Want me to handle that next?"
+
+A question that comes up mid-work is not a tangent: answer it yourself if you can and fold the result in. If it still needs the reader, surface it once, at the end.
+
+### 5. Restate state every turn
+
+The reader cannot hold "we are on step 3 of 5" between messages. Restate it.
+
+Bad: "Done. Ready for the next part?"
+Good: "Step 3 of 5 done: schema updated. Next: backfill the new column. Run the script?"
+
+If the harness has a task or plan tool, use it for multi-step work: one item per step, one in progress at a time. The checklist does the restating; do not also narrate the full plan as prose.
+
+### 6. Give specific time estimates
+
+Vague estimates fail. Ballpark in concrete units.
+
+Bad: "This will take some work."
+Good: "About 15 minutes if tests already cover this. An afternoon if not."
+
+### 7. Make completed work visible
+
+Show what now works, in concrete terms. Do not bury wins in a recap.
+
+Bad: "I've made some changes to the auth flow. Among other things..."
+Good: "Login now works with magic links. Try: `npm run dev`, open `/login`."
+
+### 8. Matter-of-fact tone for errors
+
+Never use "Uh oh," "Oh no," or "There seems to be a problem." State cause and fix.
+
+Bad: "Uh oh, the test is failing. There seems to be an issue..."
+Good: "Test fails at `auth.spec.ts:42`: expected 200, got 401. Cause: missing auth header. Fix: add `Authorization: Bearer ${token}` to the request."
+
+### 9. Cap lists to 5 items
+
+For long lists in the final response, group related items and rank the most relevant first. Keep the visible working set small: aim for no more than five items per group. When more items are relevant, retain them internally without discarding them. Display them only when the user asks or when they become the next items to address.
+
+Never omit relevant items when completeness matters. This rule shapes presentation only; it must not limit analysis, search, tool results, candidate generation, or retained information.
+
+### 10. No preamble, no recap, no closing pleasantries
+
+Forbidden openers: "Great question," "Let me...", "I'll...", "Sure!", "Looking at your...", "To answer your question..."
+
+Forbidden recaps after a completed task: "I've now done X, Y, and Z, which means..."
+
+Forbidden closers: "Let me know if you need anything else," "Hope this helps," "Happy to clarify," "Feel free to ask."
+
+Start with the answer. End when the answer is done.
+
+## When to break the rules
+
+Override the defaults when:
+
+1. User asks to "explain" or "walk me through." Explain fully. Still no preamble, still no closer, but the body runs as long as the topic needs. Add headers so the reader can skim back.
+2. Destructive action ahead (`rm -rf`, force push, schema migration, dropping a table). Confirm before acting. Safety wins over brevity.
+3. Debug spiral. If the last three turns have been "still broken," stop iterating on code. Name the assumption that might be wrong. Ask one diagnostic question.
+4. Real ambiguity in the request. One short clarifying question beats guessing and rewriting.
+5. A rule fights the task. When a rule would delete the answer itself, the task wins; the shape stays. Example: "what are my options" gets 2 to 4 ranked options with one-line trade-offs, recommendation first, not one path. The options are the answer.
+6. A rule fights the harness. Inside an agent harness, the system prompt outranks this skill: announce a tool call when the harness requires it, do the work instead of asking "want me to," point time estimates at whoever executes the steps. Same principle as 5: the constraint wins, the shape stays.
+
+## Pre-send check
+
+Before sending, delete:
+
+1. The first sentence if it announces what you are about to do.
+2. The last sentence if it asks "anything else?" or recaps what just happened.
+3. Any "by the way" sidebar.
+4. Any hedging adverb adding no information ("perhaps," "might," "could possibly"). Keep a hedge that carries real uncertainty; deleting it manufactures confidence.
+5. Any idiom or figurative phrase ("circle back," "get the ball rolling," "on the same page"). Replace with the literal action.
+
+Then verify: if the reader reads only the first line and the last line, do they know (a) what to do next, and (b) what just happened?
+
+If yes, send.

package/skills/shared/impact-analysis/SKILL.md

@@ -1,10 +1,13 @@
 ---
 name: {{sharedSkillName}}
-description: Analyze frontend Git changes and trace affected routes, pages, services, permissions, shared components, mocks, and regression checks. Read-only. Use for PR or pre-submit impact analysis.
+description: Internal. Do not invoke. Step 1 of shared-review-and-submit. Read-only impact tracing.
+disable-model-invocation: true
 ---
 
 # Impact Analysis
 
+Not a user-facing entry. Do not invoke this skill. `shared-review-and-submit` runs this as step 1.
+
 This skill does not modify files.
 
 ## Workflow
@@ -28,3 +31,7 @@ Read `.agents/skills/shared-project-conventions/references/review-checklist.md`
 - Risks that cannot be confirmed statically, with why
 
 Use repository facts only. Do not invent backend behavior.
+
+## User-facing output
+
+Read and apply `.agents/skills/shared-i-have-adhd/SKILL.md` to every response this skill sends to the user.

package/skills/shared/page-recipe/SKILL.md

@@ -0,0 +1,72 @@
+---
+name: {{sharedSkillName}}
+description: User-facing. Scaffold a standard management list (route, MFProTable, drawer form, confirm modal, permissions, services). Use for CRUD list pages. Do not use for dashboards or one-off layouts.
+---
+
+# List Page Recipe
+
+User-facing entry for a **standard** management list. Dashboards, iframes, and one-off layouts use `shared-design-to-page`.
+
+Scaffold a standard management list. Do not use this for dashboards, iframes, or one-off visualizations. Those stay on `shared-design-to-page`.
+
+Read before editing:
+
+1. `.star-allinone.json`
+2. `.agents/skills/shared-design-to-page/references/page-conventions.md`
+3. `.agents/skills/shared-design-to-page/references/overlays.md`
+4. [references/list-page-template.md](references/list-page-template.md)
+5. `.agents/project/conventions.md` if it exists
+
+## Required inputs
+
+Collect any missing item before generating:
+
+- Feature folder (`src/pages/<Feature>`)
+- Route path and menu title
+- List operation (`METHOD /path/` or `operationId`)
+- Optional create / update / delete operations
+- Optional permission codes for create / edit / delete
+
+## Workflow
+
+1. Run the CLI from the business project root. Prefer this over hand-writing the skeleton:
+
+```bash
+pnpm exec star-allinone gen page \
+  --feature <Feature> \
+  --route /path \
+  --title <中文标题> \
+  --list-operation "GET /api/v1/resource/" \
+  --create-operation "POST /api/v1/resource/" \
+  --update-operation "PATCH /api/v1/resource/{id}/" \
+  --delete-operation "DELETE /api/v1/resource/{id}/"
+```
+
+Add `--permission-create`, `--permission-edit`, `--permission-delete` when codes are known.
+
+2. If only services are missing, run `pnpm exec star-allinone gen service --operation "METHOD /path/"` first. Follow `.agents/skills/shared-api-to-service/SKILL.md`.
+3. Fill generated placeholders: columns, form fields, rowKey, permission constants, and pagination adapter (`results/count` vs `list/total`) using the nearest page of the same type.
+4. If `src/components/Page/Container/config.tsx` exists, register the new page as a tab after generating the standalone files. Do not invent a second page shell.
+5. Run focused verification.
+
+## Hard rules
+
+- `MFProTable` for the list. `ProForm` inside `CustomDrawer`. Confirmations use `BaseModal` + `HocModal`.
+- Pages consume `import Service from '@/services'` only.
+- Keep columns and toolbar builders in `const.tsx`.
+- Every `await` uses `try-catch`; restore loading in `finally`.
+- Do not use `Modal.confirm` or feature-level Ant Design `Modal` / `Drawer` shells.
+- Do not overwrite existing page files. Tell the user the CLI refused, then edit in place.
+
+## Verification
+
+```bash
+pnpm exec prettier --check <changed-files>
+pnpm typecheck
+```
+
+Run `pnpm lint` when routes or shared components change.
+
+## User-facing output
+
+Read and apply `.agents/skills/shared-i-have-adhd/SKILL.md` to every response this skill sends to the user.

package/skills/shared/page-recipe/references/list-page-template.md

@@ -0,0 +1,44 @@
+# List page template
+
+The CLI writes this tree. Edit the generated files; do not recreate a parallel structure.
+
+```text
+config/route.ts
+src/pages/<Feature>/
+├── index.tsx
+├── index.less
+├── const.tsx
+└── components/
+    ├── <Feature>Drawer.tsx
+    └── <Feature>ConfirmModal.tsx
+```
+
+## index.tsx
+
+- Wrap with `PageContainer` when `src/components/PageContainer` exists.
+- `fetchData` is a `useCallback` that calls `Service.<listFn>`, maps pagination, and returns `{ code, data: { list, total } }`.
+- Open the drawer with `drawerRef.current?.show({ record })`.
+- Destructive actions go through the confirm modal ref, then `tableRef.current?.reload()`.
+
+## const.tsx
+
+- Export `columns`, `getActionColumn`, `getToolBarRender`.
+- Put permission strings on actions and toolbar items when the project uses them.
+- Render empty cells as `'-'`.
+
+## Drawer
+
+- `CustomDrawer` + `HocModal`.
+- `ProForm` with `submitter={false}` and `layout="horizontal"`.
+- `validateFields()` in `try`. Create vs update from `record`.
+- Reset fields when `visible` becomes true.
+
+## Confirm modal
+
+- `BaseModal` + `HocModal`.
+- `confirmLoading` tied to the async `onConfirm`.
+- Do not use `Modal.confirm`.
+
+## StarScope tabs
+
+If the project uses `src/components/Page/Container/config.tsx`, the generated `src/pages/<Feature>/index.tsx` is still the source of truth. Add a tab entry that renders the feature component. Do not duplicate fetch logic inside Container.

package/skills/shared/project-conventions/SKILL.md

@@ -1,10 +1,13 @@
 ---
 name: {{sharedSkillName}}
-description: Apply the active frontend project's architecture, API, business, permission, performance, testing, and naming conventions to generated or reviewed code.
+description: Internal. Do not invoke. Referenced by other shared skills for architecture and hard rules. Not a user-facing task.
+disable-model-invocation: true
 ---
 
 # Project Conventions
 
+Not a user-facing entry. Do not invoke this skill. Other shared skills read this file for architecture and hard rules.
+
 Use this skill for every non-trivial change. Preserve existing patterns and make the smallest scoped change.
 
 Read in this order:
@@ -28,3 +31,7 @@ Shared rules are complete for review, commit, mock, and service generation. If `
 ## Completion
 
 Report changed files, API operations used, states covered, validation commands and results, and remaining gaps.
+
+## User-facing output
+
+Read and apply `.agents/skills/shared-i-have-adhd/SKILL.md` to every response this skill sends to the user.

package/skills/shared/project-conventions/references/architecture.md

@@ -4,6 +4,7 @@ Apply these rules to every non-trivial frontend change. Shared review, commit, m
 
 ## Architecture
 
+- Always-on agent instructions live in the repo-root `AGENTS.md`. Do not add `.cursor/rules`.
 - Use React function components and TypeScript.
 - Put transport code in `src/services`. Pages must not call axios or the request helper directly.
 - Keep API DTOs in the domain `typings.d.ts`. Use named types and adapters instead of `any`.
@@ -38,6 +39,8 @@ pnpm exec prettier --check <changed-files>
 pnpm exec tsc --noEmit
 ```
 
+Prefer `pnpm typecheck` when that script exists.
+
 Run `pnpm lint` for broad or shared changes. Run `pnpm run build` when routes, entry behavior, shared runtime, or multiple page modules change. If `.star-allinone.json` documents a TypeScript `baseUrl` or build script, use that command.
 
 Distinguish failures introduced by the current change from pre-existing or environment failures.

package/skills/shared/publish-test/SKILL.md

@@ -1,10 +1,12 @@
 ---
 name: {{sharedSkillName}}
-description: Publish the current frontend Git branch to the project's Yunxiao test pipeline only after explicit confirmation such as 确认推送流水线 or 发布测试环境. Never run the pipeline automatically after git push.
+description: User-facing. Publish the current Git branch to the Yunxiao test pipeline after explicit confirmation such as 确认推送流水线. Never run automatically after git push.
 ---
 
 # Publish Test Environment
 
+User-facing entry for test-environment publish only.
+
 This skill is fully shared. The only project-specific value is `publishPipelineId` in `.star-allinone.json`.
 
 Do not run the pipeline script after a git push. Git push, `确认提交并推送`, and `确认` are not pipeline authorization.
@@ -55,3 +57,7 @@ If Yunxiao selected a different branch or commit, the script stops the run. That
 A missing current-commit field is not a failure. `commit_verification=unavailable` is acceptable when Yunxiao has not yet returned a commit.
 
 The dashboard comment is `BUILD_REMARK` and contains branch, commit subject, and `来源: Codex`. A missing top-level `comment` field is not a publication failure.
+
+## User-facing output
+
+Read and apply `.agents/skills/shared-i-have-adhd/SKILL.md` to every response this skill sends to the user.

package/skills/shared/review-and-submit/SKILL.md

@@ -1,10 +1,12 @@
 ---
 name: {{sharedSkillName}}
-description: Run the frontend pre-submit workflow: impact analysis, verification, then confirmation-gated commit review. Use when the user asks for the full submit flow or says 使用完整流程提交代码. Never stage, commit, or push before explicit confirmation.
+description: User-facing. Pre-submit workflow: impact analysis, verify, then confirmation-gated commit. Use when the user wants to review, submit, or commit. Do not invoke impact/verify/commit skills separately.
 ---
 
 # Review and Submit
 
+User-facing entry for review, submit, and commit. Do not tell the user to invoke `shared-impact-analysis`, `shared-verify`, `shared-ai-review`, or `shared-commit-current-changes` separately. Read those files in order.
+
 This is the unified pre-submit entry and is fully shared. Do not mutate Git until the user confirms the exact reviewed scope.
 
 If `.agents/project/review-rules.md` exists, apply extra domain checks only; do not weaken shared hard rules.
@@ -76,3 +78,7 @@ If the user says `提交代码` before a review proposal exists, run the three s
 | `$shared-commit-current-changes` | Review plus confirmation-gated commit |
 | `$shared-ai-review` | Standalone review without commit |
 | `$shared-publish-test` | Publish to the test pipeline only after a separate `确认推送流水线`. Never run it automatically after git push. |
+
+## User-facing output
+
+Read and apply `.agents/skills/shared-i-have-adhd/SKILL.md` to every response this skill sends to the user.