@alanwang-merit/meritdata-platform-skill-package 1.0.9 → 1.0.10

package/skills/architecture-readiness-check/references//346/236/266/346/236/204/350/256/276/350/256/241/345/207/206/345/244/207/345/272/246/346/243/200/346/237/245/346/212/245/345/221/212/346/250/241/346/235/277.md

@@ -0,0 +1,129 @@
+# 架构设计准备度检查报告 — [项目名]
+
+**检查对象**：[需求文档名称] V1.0
+**检查日期**：YYYY-MM-DD
+**检查人员**：[架构师姓名]
+**检查视角**：专业架构师
+
+---
+
+## 一、总体判定
+
+**[就绪 / 有保留就绪 / 不就绪]**
+
+**核心结论**：
+- 完备项：xxx
+- 缺失项：xxx
+- 建议：xxx
+
+---
+
+## 二、信息完备性总览
+
+| 类别 | 完备性 | 关键信息 | 缺失项数 |
+|------|--------|----------|----------|
+| 需求完整性 | 完备/部分完备/缺失 | xxx | __ |
+| 技术栈选型 | 完备/部分完备/缺失 | xxx | __ |
+| 已有组件/资产 | 完备/部分完备/缺失 | xxx | __ |
+| 非功能性需求 | 完备/部分完备/缺失 | xxx | __ |
+| 部署与运维 | 完备/部分完备/缺失 | xxx | __ |
+| 团队与协作 | 完备/部分完备/缺失 | xxx | __ |
+| 时间与资源 | 完备/部分完备/缺失 | xxx | __ |
+| 业务上下文 | 完备/部分完备/缺失 | xxx | __ |
+| 风险与依赖 | 完备/部分完备/缺失 | xxx | __ |
+| 架构决策约束 | 完备/部分完备/缺失 | xxx | __ |
+| **其他维度** | 完备/部分完备/缺失 | xxx | __ |
+
+> 说明：10 大类详细检查项见 `references/架构设计准备度检查清单.md`
+
+---
+
+## 三、必须补充项（阻塞）
+
+> 缺失会导致设计走偏/返工/后期冲突，必须补充后才能开始设计
+
+| # | 类别 | 缺失项 | 影响 | 补充建议 |
+|---|------|--------|------|----------|
+| 1 | xxx | xxx | xxx | xxx |
+| 2 | xxx | xxx | xxx | xxx |
+| 3 | xxx | xxx | xxx | xxx |
+
+---
+
+## 四、建议补充项（非阻塞）
+
+> 缺失会导致设计不准确，建议补充
+
+| # | 类别 | 缺失项 | 影响 | 补充建议 |
+|---|------|--------|------|----------|
+| 1 | xxx | xxx | xxx | xxx |
+| 2 | xxx | xxx | xxx | xxx |
+
+---
+
+## 五、可选项（锦上添花）
+
+| # | 类别 | 缺失项 | 备注 |
+|---|------|--------|------|
+| 1 | xxx | xxx | xxx |
+| 2 | xxx | xxx | xxx |
+
+---
+
+## 六、按类别详细问题
+
+> 按需填写，只记录有缺失项的类别。每个类别下按"关键信息检查 → 缺失项记录"格式展开。
+
+### 6.X [类别名称]
+
+#### 缺失项
+
+- xxx
+
+---
+
+（可按需复制 6.X 章节，添加更多类别）
+
+---
+
+## 七、建议补充路径
+
+### 7.1 立即补充（必须）
+
+1. xxx
+2. xxx
+3. xxx
+
+### 7.2 设计过程中补充（建议）
+
+1. xxx
+2. xxx
+
+### 7.3 不影响设计的可选项
+
+1. xxx
+2. xxx
+
+---
+
+## 八、最终判定
+
+**是否可以开始技术设计**：
+- ✅ 是（所有必须项已补齐）
+- ⚠️ 有保留可以（必须项已补齐，建议项可在设计过程中补充）
+- ❌ 否（必须项缺失，需要先补充）
+
+**本报告结论**：[是 / 有保留可以 / 否]
+
+---
+
+## 九、下一步行动
+
+1. xxx
+2. xxx
+3. xxx
+
+---
+
+**架构师**：xxx
+**检查日期**：YYYY-MM-DD

package/skills/architecture-readiness-check/references//346/236/266/346/236/204/350/256/276/350/256/241/345/207/206/345/244/207/345/272/246/346/243/200/346/237/245/346/270/205/345/215/225.md

@@ -0,0 +1,251 @@
+# 架构设计准备度检查清单
+
+> ⚠️ **重要**：本清单仅作为参考框架，**架构师应发散性识别更多关键检查项**。
+
+---
+
+## 一、需求完整性
+
+### 关键信息
+
+- [ ] 需求文档齐全且最新版本
+- [ ] 需求已评审定稿
+- [ ] 业务背景清晰
+- [ ] 痛点量化（数据/事实）
+- [ ] 解决方向明确
+- [ ] 验收标准明确
+- [ ] 边界场景已考虑
+- [ ] 业务角色清晰
+- [ ] 主流程完整
+- [ ] 异常场景已说明
+
+### 常见问题
+
+- 需求版本不明确
+- 业务规则定义不清
+- 验收标准模糊
+- 异常场景遗漏
+
+---
+
+## 二、技术栈选型
+
+### 关键信息
+
+- [ ] 整体技术栈明确（语言/框架/中间件）
+- [ ] 后端技术栈（语言、框架、ORM）
+- [ ] 前端技术栈（框架、UI库、状态管理）
+- [ ] 数据库选型（关系型/NoSQL/搜索引擎）
+- [ ] 缓存选型（Redis/Memcached）
+- [ ] 消息队列选型（Kafka/RabbitMQ/RocketMQ）
+- [ ] 搜索方案（ES/Solr）
+- [ ] 强制约束（必须用某个技术）
+- [ ] 禁用约束（不能使用某个技术）
+
+### 常见问题
+
+- 技术栈选型理由未说明
+- 前后端技术栈不匹配
+- 强制约束未明确
+
+---
+
+## 三、已有组件/资产
+
+### 关键信息
+
+- [ ] 现有公共组件/服务清单
+- [ ] 现有代码库结构（模块/包）
+- [ ] 已有数据模型/数据库 schema
+- [ ] 已有 API 规范或 OpenAPI 文档
+- [ ] 已有认证/权限基础设施
+- [ ] 已有日志/监控基础设施
+- [ ] 历史项目的技术债务清单
+- [ ] 可复用中间件
+
+### 常见问题
+
+- 未盘点现有资产导致重复造轮子
+- 现有组件能力不清楚
+- 技术债务未识别
+
+---
+
+## 四、非功能性需求
+
+### 关键信息
+
+- [ ] 性能指标（QPS、响应时间、并发量）
+- [ ] 安全要求（认证、授权、数据加密、审计）
+- [ ] 可靠性要求（可用性 SLA、容灾、备份）
+- [ ] 扩展性要求（横向/纵向扩展）
+- [ ] 兼容性要求（浏览器、客户端版本）
+- [ ] 数据合规要求（GDPR、等保、个人信息保护）
+- [ ] 可维护性要求（日志规范、监控告警）
+- [ ] 可测试性要求
+
+### 常见问题
+
+- 性能指标不量化
+- 安全要求笼统
+- 可用性目标未明确
+
+---
+
+## 五、部署与运维
+
+### 关键信息
+
+- [ ] 部署环境（开发/测试/生产）
+- [ ] 部署方式（容器/虚拟机/物理机）
+- [ ] 是否需要集群部署
+- [ ] 域名/证书/网络规划
+- [ ] CI/CD 流程
+- [ ] 监控告警体系（Prometheus/Grafana/ELK）
+- [ ] 日志收集方案
+- [ ] 数据库运维方案（备份、恢复）
+- [ ] 容灾方案
+
+### 常见问题
+
+- 部署架构不明确
+- 监控告警未规划
+- 容灾方案缺失
+
+---
+
+## 六、团队与协作
+
+### 关键信息
+
+- [ ] 团队规模与技术能力
+- [ ] 与其他团队的协作/依赖关系
+- [ ] 上下游系统对接负责人
+- [ ] 文档规范与代码规范
+- [ ] 沟通协作工具
+- [ ] 知识储备情况
+- [ ] 学习成本评估
+
+### 常见问题
+
+- 团队能力与方案不匹配
+- 协作流程不清晰
+- 上游下游系统未识别
+
+---
+
+## 七、时间与资源
+
+### 关键信息
+
+- [ ] 项目时间节点要求
+- [ ] 资源投入（人天/人数）
+- [ ] 是否有外部资源依赖
+- [ ] 关键里程碑
+- [ ] 排期合理性
+- [ ] 风险缓冲
+
+### 常见问题
+
+- 排期过于激进
+- 资源不足
+- 外部依赖不可控
+
+---
+
+## 八、业务上下文
+
+### 关键信息
+
+- [ ] 业务领域知识（行业术语、规则）
+- [ ] 关键业务规则和约束
+- [ ] 业务异常处理流程
+- [ ] 数据生命周期（保留期/归档/销毁）
+- [ ] 业务流程的状态机和转换规则
+- [ ] 业务高峰期和低谷期
+- [ ] 用户规模和使用场景
+- [ ] 业务变化频率
+
+### 常见问题
+
+- 业务规则不清晰
+- 状态机不完整
+- 数据生命周期未规划
+
+---
+
+## 九、风险与依赖
+
+### 关键信息
+
+- [ ] 外部系统/第三方服务依赖
+- [ ] 关键风险点识别
+- [ ] 风险应对预案
+- [ ] 回滚方案
+- [ ] 关键技术难点
+- [ ] 供应商风险
+- [ ] 法律合规风险
+
+### 常见问题
+
+- 外部依赖未识别
+- 回滚方案缺失
+- 风险应对预案不充分
+
+---
+
+## 十、架构决策约束
+
+### 关键信息
+
+- [ ] 架构原则/规范
+- [ ] 强制架构模式（微服务/单体/Serverless）
+- [ ] 合规/审计要求
+- [ ] 预算/成本约束
+- [ ] 采购/供应商约束
+- [ ] 公司技术栈偏好
+- [ ] 历史架构债务
+
+### 常见问题
+
+- 架构原则未明确
+- 合规要求未识别
+- 成本约束未考虑
+
+---
+
+## 十一、其他维度（架构师自主识别）
+
+> 架构师应根据具体项目特点，自主识别可能影响设计的关键信息
+
+### 关键信息
+
+- xxx（架构师根据项目特点自主识别）
+
+### 常见问题
+
+- xxx
+
+---
+
+## 使用说明
+
+- 本清单覆盖**10 大类核心检查项**，外加"其他维度"供架构师发散
+- 每个类别包含：
+  - 关键信息 Checklist（具体可勾选）
+  - 常见问题（提示架构师注意）
+- 适用于：架构设计前的信息完备性检查
+- 不适用于：架构设计本身
+- 使用时机：需求文档已确定，技术设计开始前
+- 使用方式：架构师按清单逐项勾选，识别缺失项，与用户/PM 沟通补充
+
+---
+
+## 检查流程
+
+1. **加载需求文档**
+2. **按 10 大类逐项勾选** Checklist
+3. **识别缺失项** 并分类（必须/建议/可选）
+4. **主动与用户/PM 沟通** 缺失的关键信息
+5. **生成检查报告**（使用 `references/架构设计准备度检查报告模板.md`）
+6. **等待关键信息补齐** 后才进入技术设计环节

package/skills/ask-matt/SKILL.md

@@ -0,0 +1,78 @@
+---
+name: ask-matt
+description: Ask which skill or flow fits your situation. A router over the skills in this repo.
+disable-model-invocation: true
+---
+
+# Ask Matt
+
+You don't remember every skill, so ask.
+
+A **flow** is a path through the skills. Most paths run along one **main flow**, and two **on-ramps** merge onto it. Everything else is standalone, or a vocabulary layer that runs underneath.
+
+## The main flow: idea → ship
+
+The route most work travels. You have an idea and want it built.
+
+1. **`/grill-with-docs`** — sharpen the idea by interview. Start here when you **have a codebase**: it's stateful, retaining what it learns in `CONTEXT.md` and ADRs. (No codebase? Use `/grill-me` — see Standalone. Both run the same `/grilling` primitive; `grill-with-docs` is the one that leaves a paper trail.)
+2. **Branch — can you settle every question in conversation?** If a question needs a runnable answer (state, business logic, a UI you have to see), detour through a prototype, bridged by **`/handoff`** in both directions (see Crossing sessions):
+   - **`/handoff`** out, then open a fresh session against that file,
+   - **`/prototype`** to answer the question with throwaway code,
+   - **`/handoff`** back what you learned, and reference it from the original idea thread.
+3. **Branch — is this a multi-session build?**
+   - **Yes** → **`/to-spec`** (turn the thread into a spec), then **`/to-tickets`** to split it into tracer-bullet tickets, each declaring its **blocking edges**. On a local tracker that's one file per ticket under `.scratch/<feature>/issues/`, worked blockers-first by hand; on a real tracker the edges become native blocking links, so any ticket whose blockers are done can be grabbed — kick off **`/implement`** per ticket, **clearing context between each one**.
+   - **No** → **`/implement`** right here, in the same context window.
+
+   Either way, **`/implement`** builds each issue by driving **`/tdd`** internally — one red-green slice at a time — then closes out by running **`/code-review`**, a two-axis review (Standards + Spec) of the diff, before committing. Reach for **`/tdd`** on its own when you just want to build a concrete behaviour test-first without a full spec, and **`/code-review`** on its own whenever you want to review a branch or PR against a fixed point.
+
+### Context hygiene
+
+Keep steps 1–3 in **one unbroken context window** — don't compact or clear until after `/to-tickets` — so the grilling, spec, and tickets all build on the same thinking. Each `/implement` then starts fresh, working from the ticket.
+
+The limit on this is the **[smart zone](https://www.aihero.dev/ai-coding-dictionary/smart-zone)**: the window (~120k tokens on state-of-the-art models) within which the model still reasons sharply. If a session approaches it before `/to-tickets`, don't push on degraded — `/handoff` and continue in a fresh thread.
+
+## On-ramps
+
+A starting situation that generates work, then merges onto the main flow.
+
+- **Bugs and requests piling up** → **`/triage`**. It moves issues through triage roles and produces agent-ready issues, which **`/implement`** later picks up.
+
+  Triage is only for issues **you didn't create** — bug reports, incoming feature requests, anything that arrives raw. Tickets that `/to-tickets` produced are already agent-ready, so **don't triage them**.
+
+- **Something's broken** → **`/diagnosing-bugs`**. For the hard ones: the bug that resists a first glance, the intermittent flake, the regression that crept in between two known-good states. It refuses to theorise until it has a **tight feedback loop** — one command that already goes red on *this* bug — then fixes with a regression test. Its post-mortem hands off to **`/improve-codebase-architecture`** when the real finding is that there's no good seam to lock the bug down.
+
+- **A huge, foggy effort — a greenfield project or a huge feature build, too big for one session** → **`/wayfinder`**, the most cognitively demanding flow here. When the way from here to the destination isn't visible yet, it charts a **shared map** of **decision tickets** on the issue tracker and resolves them one at a time — producing **decisions, not deliverables** — until the fog is pushed back and the way is clear. Where **`/grill-with-docs`** sharpens an idea you can hold in one session, wayfinder is for the idea you can't — and it's slower and denser, so save it for exactly that, never a well-scoped feature.
+
+  When the map clears, **it hands off, it doesn't build**: merge onto the main flow at **`/to-spec`**, which collapses the map's linked decisions into a buildable plan, then `/to-tickets` and `/implement` as usual. Looping the map straight into `/implement` skips that collapse and throws the linked detail away — go straight to `/implement` only when the effort turned out genuinely small.
+
+## Codebase health
+
+Not feature work — upkeep.
+
+- **`/improve-codebase-architecture`** — run whenever you have a spare moment to keep the codebase good for agents to operate in. It surfaces **deepening opportunities**; picking one _generates an idea_ you can take into the main flow at `/grill-with-docs`. It's the survey that finds the candidates; **`/codebase-design`** (below) is the bench you design the chosen one on.
+
+## Vocabulary underneath
+
+Two model-invoked references that run *beneath* the other skills — each the single source of truth for its vocabulary. Reach for them directly when the **words**, not the process, are the problem; or let the skills above pull them in.
+
+- **`/domain-modeling`** — sharpen the project's *domain* language: challenge a fuzzy term, resolve an overloaded word ("account" doing three jobs), record a hard-to-reverse decision as an ADR. It's the active discipline `/grill-with-docs` drives to keep `CONTEXT.md` a clean glossary.
+- **`/codebase-design`** — the deep-module vocabulary (module, interface, depth, seam, adapter, leverage, locality) for designing a module's *shape*: a lot of behaviour behind a small interface at a clean seam. `/tdd` and `/improve-codebase-architecture` both speak it.
+
+## Crossing sessions
+
+- **`/handoff`** — when a thread is full or you need to branch off (e.g. into a `/prototype` session), this compacts the conversation into a markdown file. You don't continue in place — you **open a new session and reference that file** to carry the context across. It's the bridge between context windows, in either direction. Use it when you want a **fresh session** but need the **current conversation preserved**.
+- **`/compact`** (built-in) — stay in the **same conversation**, letting the earlier turns be summarized. Use it at **intentional breaks between phases**, when you don't mind losing the verbatim history. Don't compact mid-phase — the agent can lose its way. `/handoff` forks; `/compact` continues.
+
+## Standalone
+
+Off the main flow entirely.
+
+- **`/grill-me`** — the same relentless interview as `/grill-with-docs`, but for when you have **no codebase**. Stateless: it saves nothing locally, builds no `CONTEXT.md`. Reach for it to sharpen any plan or design that doesn't live in a repo.
+- **`/prototype`** — a small, throwaway program that answers one design question: does this state model feel right, or what should this UI look like. Throwaway from day one — keep the answer, delete the code. It's the detour in step 2 of the main flow, but reach for it any time a design question is hard to settle on paper.
+- **`/research`** — delegate reading legwork to a **background agent**: it investigates a question against **primary sources**, then leaves a cited Markdown file in the repo. Keep working while it reads. The file it produces is something to take *into* the main flow at `/grill-with-docs` — research feeds the thinking, it doesn't replace it.
+- **`/teach`** — learn a concept over multiple sessions, using the current directory as a stateful workspace.
+- **`/writing-great-skills`** — reference for writing and editing skills well.
+
+## Precondition
+
+**`/setup-matt-pocock-skills`** — run before your first engineering flow to configure the issue tracker, triage labels, and doc layout the other skills assume. Custom issue trackers also work.

package/skills/ask-matt/agents/openai.yaml

@@ -0,0 +1,5 @@
+interface:
+  display_name: "Ask Matt"
+  short_description: "Find the right skill or workflow"
+policy:
+  allow_implicit_invocation: false

package/skills/backend-code-review/SKILL.md

@@ -0,0 +1,168 @@
+---
+name: backend-code-review
+description: Review backend code for quality, security, maintainability, and best practices based on established checklist rules. Use when the user requests a review, analysis, or improvement of backend files (e.g., `.py`) under the `api/` directory. Do NOT use for frontend files (e.g., `.tsx`, `.ts`, `.js`). Supports pending-change review, code snippets review, and file-focused review.
+---
+
+# Backend Code Review
+
+## When to use this skill
+
+Use this skill whenever the user asks to **review, analyze, or improve** backend code (e.g., `.py`) under the `api/` directory. Supports the following review modes:
+
+- **Pending-change review**: when the user asks to review current changes (inspect staged/working-tree files slated for commit to get the changes).
+- **Code snippets review**: when the user pastes code snippets (e.g., a function/class/module excerpt) into the chat and asks for a review.
+- **File-focused review**: when the user points to specific files and asks for a review of those files (one file or a small, explicit set of files, e.g., `api/...`, `api/app.py`).
+
+Do NOT use this skill when:
+
+- The request is about frontend code or UI (e.g., `.tsx`, `.ts`, `.js`, `web/`).
+- The user is not asking for a review/analysis/improvement of backend code.
+- The scope is not under `api/` (unless the user explicitly asks to review backend-related changes outside `api/`).
+
+## How to use this skill
+
+Follow these steps when using this skill:
+
+1. **Identify the review mode** (pending-change vs snippet vs file-focused) based on the user’s input. Keep the scope tight: review only what the user provided or explicitly referenced.
+2. Follow the rules defined in **Checklist** to perform the review. If no Checklist rule matches, apply **General Review Rules** as a fallback to perform the best-effort review.
+3. Compose the final output strictly follow the **Required Output Format**.
+
+Notes when using this skill:
+- Always include actionable fixes or suggestions (including possible code snippets).
+- Use best-effort `File:Line` references when a file path and line numbers are available; otherwise, use the most specific identifier you can.
+
+## Checklist
+
+- db schema design: if the review scope includes code/files under `api/models/` or `api/migrations/`, follow [references/db-schema-rule.md](references/db-schema-rule.md) to perform the review
+- architecture: if the review scope involves controller/service/core-domain/libs/model layering, dependency direction, or moving responsibilities across modules, follow [references/architecture-rule.md](references/architecture-rule.md) to perform the review
+- repositories abstraction: if the review scope contains table/model operations (e.g., `select(...)`, `session.execute(...)`, joins, CRUD) and is not under `api/repositories`, `api/core/repositories`, or `api/extensions/*/repositories/`, follow [references/repositories-rule.md](references/repositories-rule.md) to perform the review
+- sqlalchemy patterns: if the review scope involves SQLAlchemy session/query usage, db transaction/crud usage, or raw SQL usage, follow [references/sqlalchemy-rule.md](references/sqlalchemy-rule.md) to perform the review
+
+## General Review Rules
+
+### 1. Security Review
+
+Check for:
+- SQL injection vulnerabilities
+- Server-Side Request Forgery (SSRF)
+- Command injection
+- Insecure deserialization
+- Hardcoded secrets/credentials
+- Improper authentication/authorization
+- Insecure direct object references
+
+### 2. Performance Review
+
+Check for:
+- N+1 queries
+- Missing database indexes
+- Memory leaks
+- Blocking operations in async code
+- Missing caching opportunities
+
+### 3. Code Quality Review
+
+Check for:
+- Code forward compatibility
+- Code duplication (DRY violations)
+- Functions doing too much (SRP violations)
+- Deep nesting / complex conditionals
+- Magic numbers/strings
+- Poor naming
+- Missing error handling
+- Incomplete type coverage
+
+### 4. Testing Review
+
+Check for:
+- Missing test coverage for new code
+- Tests that don't test behavior
+- Flaky test patterns
+- Missing edge cases
+
+## Required Output Format
+
+When this skill invoked, the response must exactly follow one of the two templates:
+
+### Template A (any findings)
+
+```markdown
+# Code Review Summary
+
+Found <X> critical issues need to be fixed:
+
+## 🔴 Critical (Must Fix)
+
+### 1. <brief description of the issue>
+
+FilePath: <path> line <line>
+<relevant code snippet or pointer>
+
+#### Explanation
+
+<detailed explanation and references of the issue>
+
+#### Suggested Fix
+
+1. <brief description of suggested fix>
+2. <code example> (optional, omit if not applicable)
+
+---
+... (repeat for each critical issue) ...
+
+Found <Y> suggestions for improvement:
+
+## 🟡 Suggestions (Should Consider)
+
+### 1. <brief description of the suggestion>
+
+FilePath: <path> line <line>
+<relevant code snippet or pointer>
+
+#### Explanation
+
+<detailed explanation and references of the suggestion>
+
+#### Suggested Fix
+
+1. <brief description of suggested fix>
+2. <code example> (optional, omit if not applicable)
+
+---
+... (repeat for each suggestion) ...
+
+Found <Z> optional nits:
+
+## 🟢 Nits (Optional)
+### 1. <brief description of the nit>
+
+FilePath: <path> line <line>
+<relevant code snippet or pointer>
+
+#### Explanation
+
+<explanation and references of the optional nit>
+
+#### Suggested Fix
+
+- <minor suggestions>
+
+---
+... (repeat for each nits) ...
+
+## ✅ What's Good
+
+- <Positive feedback on good patterns>
+```
+
+- If there are no critical issues or suggestions or option nits or good points, just omit that section.
+- If the issue number is more than 10, summarize as "Found 10+ critical issues/suggestions/optional nits" and only output the first 10 items.
+- Don't compress the blank lines between sections; keep them as-is for readability.
+- If there is any issue requires code changes, append a brief follow-up question to ask whether the user wants to apply the fix(es) after the structured output. For example: "Would you like me to use the Suggested fix(es) to address these issues?"
+
+### Template B (no issues)
+
+```markdown
+## Code Review Summary
+✅ No issues found.
+```