npm - @alanwang-merit/meritdata-platform-skill-package - Versions diffs - 1.0.10 → 1.0.12 - Mend

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

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (631) hide show

package/skills/architecture-readiness-check/SKILL.md DELETED Viewed

@@ -1,80 +0,0 @@
----
-name: architecture-readiness-check
-description: 架构设计准备度检查 | 触发条件：架构设计前检查、设计准备度检查、信息完备性检查、需求→设计过渡检查 | 在读入需求文档后、开始技术设计前，以专业架构师视角发散检查设计所需信息是否完善，识别缺失项并提示用户补充
-author: maohan
-source: project
-date_added: "2026-07-08"
-risk: low
----
-# 架构设计准备度检查
-本技能用于在**读入需求文档后、开始技术设计前**，以专业架构师视角**发散性**检查设计所需信息是否完善，识别缺失项并提示用户补充。
-> ⚠️ **重要**：本技能强调**发散性思考**，不局限于固定检查项。架构师应根据需求文档的实际情况，自主识别可能影响设计的关键信息。
----
-## 使用方法
-1. 加载检查清单 `references/架构设计准备度检查清单.md`（10 大类 + 其他维度）
-2. 加载需求文档
-3. 按发散性思维逐项检查设计所需信息
-4. 按模板 `references/架构设计准备度检查报告模板.md` 输出检查报告
-5. **必须等到关键信息补齐后**才进入技术设计环节
----
-## 使用时机
-| 时机 | 说明 |
-|------|------|
-| ✅ 适用 | 需求文档已确定，技术设计开始前 |
-| ✅ 适用 | 接手历史项目，需要做架构设计前 |
-| ❌ 不适用 | 需求文档本身还不清晰（应先完善需求） |
-| ❌ 不适用 | 已经在设计过程中（应直接继续设计） |
----
-## 检查原则
-### 1. 架构师视角
-- **全局性**：从系统整体考虑，不局限于单个模块
-- **前瞻性**：考虑未来扩展和演进
-- **风险性**：识别潜在技术风险和业务风险
-- **落地性**：考虑团队能力和实施成本
-### 2. 关键问题意识
-- 哪些信息**缺失会导致设计走偏**？
-- 哪些信息**缺失会导致返工**？
-- 哪些信息**缺失会导致后期冲突**？
-### 3. 分级处理
-- **必须补充**（关键信息缺失，无法开始设计）
-- **建议补充**（有助于设计更准确）
-- **可选**（锦上添花）
-### 4. 主动沟通
-- 不要只列出问题清单
-- 应主动与用户/PM 沟通关键信息
-- 必要时组织评审会议
----
-## 输出格式
-根据模板 `references/架构设计准备度检查报告模板.md` 生成检查报告，输出后保存到 `docs/架构设计准备度检查报告-项目名-日期.md`
----
-## 触发场景
-- "架构设计准备度检查"
-- "设计前信息检查"
-- "架构信息完备性检查"
-- "需求→设计过渡检查"
-- "开始技术设计前检查"

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 DELETED Viewed

@@ -1,129 +0,0 @@
-# 架构设计准备度检查报告 — [项目名]
-**检查对象**：[需求文档名称] 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

@@ -1,251 +0,0 @@
-# 架构设计准备度检查清单
-> ⚠️ **重要**：本清单仅作为参考框架，**架构师应发散性识别更多关键检查项**。
----
-## 一、需求完整性
-### 关键信息
-- [ ] 需求文档齐全且最新版本
-- [ ] 需求已评审定稿
-- [ ] 业务背景清晰
-- [ ] 痛点量化（数据/事实）
-- [ ] 解决方向明确
-- [ ] 验收标准明确
-- [ ] 边界场景已考虑
-- [ ] 业务角色清晰
-- [ ] 主流程完整
-- [ ] 异常场景已说明
-### 常见问题
-- 需求版本不明确
-- 业务规则定义不清
-- 验收标准模糊
-- 异常场景遗漏
----
-## 二、技术栈选型
-### 关键信息
-- [ ] 整体技术栈明确（语言/框架/中间件）
-- [ ] 后端技术栈（语言、框架、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 DELETED Viewed

@@ -1,78 +0,0 @@
----
-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 DELETED Viewed

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