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

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

@@ -1,205 +0,0 @@
----
-name: receiving-code-review
-description: Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation
----
-
-# Code Review Reception
-
-## Overview
-
-Code review requires technical evaluation, not emotional performance.
-
-**Core principle:** Verify before implementing. Ask before assuming. Technical correctness over social comfort.
-
-## The Response Pattern
-
-```
-WHEN receiving code review feedback:
-
-1. READ: Complete feedback without reacting
-2. UNDERSTAND: Restate requirement in own words (or ask)
-3. VERIFY: Check against codebase reality
-4. EVALUATE: Technically sound for THIS codebase?
-5. RESPOND: Technical acknowledgment or reasoned pushback
-6. IMPLEMENT: One item at a time, test each
-```
-
-## Forbidden Responses
-
-**NEVER:**
-- "You're absolutely right!" (explicit instruction-file violation)
-- "Great point!" / "Excellent feedback!" (performative)
-- "Let me implement that now" (before verification)
-
-**INSTEAD:**
-- Restate the technical requirement
-- Ask clarifying questions
-- Push back with technical reasoning if wrong
-- Just start working (actions > words)
-
-## Handling Unclear Feedback
-
-```
-IF any item is unclear:
-  STOP - do not implement anything yet
-  ASK for clarification on unclear items
-
-WHY: Items may be related. Partial understanding = wrong implementation.
-```
-
-**Example:**
-```
-your human partner: "Fix 1-6"
-You understand 1,2,3,6. Unclear on 4,5.
-
-❌ WRONG: Implement 1,2,3,6 now, ask about 4,5 later
-✅ RIGHT: "I understand items 1,2,3,6. Need clarification on 4 and 5 before proceeding."
-```
-
-## Source-Specific Handling
-
-### From your human partner
-- **Trusted** - implement after understanding
-- **Still ask** if scope unclear
-- **No performative agreement**
-- **Skip to action** or technical acknowledgment
-
-### From External Reviewers
-```
-BEFORE implementing:
-  1. Check: Technically correct for THIS codebase?
-  2. Check: Breaks existing functionality?
-  3. Check: Reason for current implementation?
-  4. Check: Works on all platforms/versions?
-  5. Check: Does reviewer understand full context?
-
-IF suggestion seems wrong:
-  Push back with technical reasoning
-
-IF can't easily verify:
-  Say so: "I can't verify this without [X]. Should I [investigate/ask/proceed]?"
-
-IF conflicts with your human partner's prior decisions:
-  Stop and discuss with your human partner first
-```
-
-**your human partner's rule:** "External feedback - be skeptical, but check carefully"
-
-## YAGNI Check for "Professional" Features
-
-```
-IF reviewer suggests "implementing properly":
-  grep codebase for actual usage
-
-  IF unused: "This endpoint isn't called. Remove it (YAGNI)?"
-  IF used: Then implement properly
-```
-
-**your human partner's rule:** "You and reviewer both report to me. If we don't need this feature, don't add it."
-
-## Implementation Order
-
-```
-FOR multi-item feedback:
-  1. Clarify anything unclear FIRST
-  2. Then implement in this order:
-     - Blocking issues (breaks, security)
-     - Simple fixes (typos, imports)
-     - Complex fixes (refactoring, logic)
-  3. Test each fix individually
-  4. Verify no regressions
-```
-
-## When To Push Back
-
-Push back when:
-- Suggestion breaks existing functionality
-- Reviewer lacks full context
-- Violates YAGNI (unused feature)
-- Technically incorrect for this stack
-- Legacy/compatibility reasons exist
-- Conflicts with your human partner's architectural decisions
-
-**How to push back:**
-- Use technical reasoning, not defensiveness
-- Ask specific questions
-- Reference working tests/code
-- Involve your human partner if architectural
-
-**If you're uncomfortable pushing back out loud:** Name that tension, then tell your partner about the issue you've seen. They'll appreciate your honesty.
-
-## Acknowledging Correct Feedback
-
-When feedback IS correct:
-```
-✅ "Fixed. [Brief description of what changed]"
-✅ "Good catch - [specific issue]. Fixed in [location]."
-✅ [Just fix it and show in the code]
-
-❌ "You're absolutely right!"
-❌ "Great point!"
-❌ "Thanks for catching that!"
-❌ "Thanks for [anything]"
-❌ ANY gratitude expression
-```
-
-**Why no thanks:** Actions speak. Just fix it. The code itself shows you heard the feedback.
-
-**If you catch yourself about to write "Thanks":** DELETE IT. State the fix instead.
-
-## Gracefully Correcting Your Pushback
-
-If you pushed back and were wrong:
-```
-✅ "You were right - I checked [X] and it does [Y]. Implementing now."
-✅ "Verified this and you're correct. My initial understanding was wrong because [reason]. Fixing."
-
-❌ Long apology
-❌ Defending why you pushed back
-❌ Over-explaining
-```
-
-State the correction factually and move on.
-
-## Common Mistakes
-
-| Mistake | Fix |
-|---------|-----|
-| Performative agreement | State requirement or just act |
-| Blind implementation | Verify against codebase first |
-| Batch without testing | One at a time, test each |
-| Assuming reviewer is right | Check if breaks things |
-| Avoiding pushback | Technical correctness > comfort |
-| Partial implementation | Clarify all items first |
-| Can't verify, proceed anyway | State limitation, ask for direction |
-
-## Real Examples
-
-**Performative Agreement (Bad):**
-```
-Reviewer: "Remove legacy code"
-❌ "You're absolutely right! Let me remove that..."
-```
-
-**Technical Verification (Good):**
-```
-Reviewer: "Remove legacy code"
-✅ "Checking... build target is 10.15+, this API needs 13+. Need legacy for backward compat. Current impl has wrong bundle ID - fix it or drop pre-13 support?"
-```
-
-**YAGNI (Good):**
-```
-Reviewer: "Implement proper metrics tracking with database, date filters, CSV export"
-✅ "Grepped codebase - nothing calls this endpoint. Remove it (YAGNI)? Or is there usage I'm missing?"
-```
-
-**Unclear Item (Good):**
-```
-your human partner: "Fix items 1-6"
-You understand 1,2,3,6. Unclear on 4,5.
-✅ "Understand 1,2,3,6. Need clarification on 4 and 5 before implementing."
-```
-
-## GitHub Thread Replies
-
-When replying to inline review comments on GitHub, reply in the comment thread (`gh api repos/{owner}/{repo}/pulls/{pr}/comments/{id}/replies`), not as a top-level PR comment.

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

@@ -1,95 +0,0 @@
----
-name: requesting-code-review
-description: Use when completing tasks, implementing major features, or before merging to verify work meets requirements
----
-
-# Requesting Code Review
-
-Dispatch a code reviewer subagent to catch issues before they cascade. The reviewer gets precisely crafted context for evaluation — never your session's history.
-
-**Core principle:** Review early, review often.
-
-## When to Request Review
-
-**Mandatory:**
-- After each task in subagent-driven development
-- After completing major feature
-- Before merge to main
-
-**Optional but valuable:**
-- When stuck (fresh perspective)
-- Before refactoring (baseline check)
-- After fixing complex bug
-
-## How to Request
-
-**1. Get git SHAs:**
-```bash
-BASE_SHA=$(git rev-parse HEAD~1)  # or origin/main
-HEAD_SHA=$(git rev-parse HEAD)
-```
-
-**2. Dispatch code reviewer subagent:**
-
-Dispatch a `general-purpose` subagent, filling the template at [code-reviewer.md](code-reviewer.md)
-
-**Placeholders:**
-- `{DESCRIPTION}` - Brief summary of what you built
-- `{PLAN_OR_REQUIREMENTS}` - What it should do
-- `{BASE_SHA}` - Starting commit
-- `{HEAD_SHA}` - Ending commit
-
-**3. Act on feedback:**
-- Fix Critical issues immediately
-- Fix Important issues before proceeding
-- Note Minor issues for later
-- Push back if reviewer is wrong (with reasoning)
-
-## Example
-
-```
-[Just completed Task 2: Add verification function]
-
-You: Let me request code review before proceeding.
-
-BASE_SHA=$(git log --oneline | grep "Task 1" | head -1 | awk '{print $1}')
-HEAD_SHA=$(git rev-parse HEAD)
-
-[Dispatch code reviewer subagent]
-  DESCRIPTION: Added verifyIndex() and repairIndex() with 4 issue types
-  PLAN_OR_REQUIREMENTS: Task 2 from docs/superpowers/plans/deployment-plan.md
-  BASE_SHA: a7981ec
-  HEAD_SHA: 3df7661
-
-[Subagent returns]:
-  Strengths: Clean architecture, real tests
-  Issues:
-    Important: Missing progress indicators
-    Minor: Magic number (100) for reporting interval
-  Assessment: Ready to proceed
-
-You: [Fix progress indicators]
-[Continue to Task 3]
-```
-
-## Common Rationalizations
-
-| Excuse | Reality |
-|--------|---------|
-| "I'll just review the diff myself instead of dispatching a reviewer" | You're the coordinator — reviewing the diff inline burns the context window you need to keep driving the work. Dispatch a reviewer subagent: the diff and the evaluation live in its context, and only the findings come back to you. |
-| "The reviewer needs my whole session history to understand the change" | Hand it precisely crafted context, never your session's history. That keeps the reviewer on the work product, not your thought process. |
-
-## Red Flags
-
-**Never:**
-- Skip review because "it's simple"
-- Ignore Critical issues
-- Proceed with unfixed Important issues
-- Argue with valid technical feedback
-
-**If reviewer wrong:**
-- Push back with technical reasoning
-- Show code/tests that prove it works
-- Request clarification
-
-See template at: [code-reviewer.md](code-reviewer.md)

package/skills/requesting-code-review/code-reviewer.md

@@ -1,172 +0,0 @@
-# Code Reviewer Prompt Template
-
-Use this template when dispatching a code reviewer subagent.
-
-**Purpose:** Review completed work against requirements and code quality standards before it cascades into more work.
-
-```
-Subagent (general-purpose):
-  description: "Review code changes"
-  prompt: |
-    You are a Senior Code Reviewer with expertise in software architecture,
-    design patterns, and best practices. Your job is to review completed work
-    against its plan or requirements and identify issues before they cascade.
-
-    ## What Was Implemented
-
-    [DESCRIPTION]
-
-    ## Requirements / Plan
-
-    [PLAN_OR_REQUIREMENTS]
-
-    ## Git Range to Review
-
-    **Base:** [BASE_SHA]
-    **Head:** [HEAD_SHA]
-
-    ```bash
-    git diff --stat [BASE_SHA]..[HEAD_SHA]
-    git diff [BASE_SHA]..[HEAD_SHA]
-    ```
-
-    ## Read-Only Review
-
-    Your review is read-only on this checkout. Do not mutate the working tree, the index, HEAD, or branch state in any way. Use tools like `git show`, `git diff`, and `git log` to inspect history. If you need a working copy of a different revision, check it out into a separate temporary directory (e.g. `git worktree add /tmp/review-[SHA] [SHA]`) — never move HEAD on this checkout.
-
-    ## What to Check
-
-    **Plan alignment:**
-    - Does the implementation match the plan / requirements?
-    - Are deviations justified improvements, or problematic departures?
-    - Is all planned functionality present?
-
-    **Code quality:**
-    - Clean separation of concerns?
-    - Proper error handling?
-    - Type safety where applicable?
-    - DRY without premature abstraction?
-    - Edge cases handled?
-
-    **Architecture:**
-    - Sound design decisions?
-    - Reasonable scalability and performance?
-    - Security concerns?
-    - Integrates cleanly with surrounding code?
-
-    **Testing:**
-    - Tests verify real behavior, not mocks?
-    - Edge cases covered?
-    - Integration tests where they matter?
-    - All tests passing?
-
-    **Production readiness:**
-    - Migration strategy if schema changed?
-    - Backward compatibility considered?
-    - Documentation complete?
-    - No obvious bugs?
-
-    ## Calibration
-
-    Categorize issues by actual severity. Not everything is Critical.
-    Acknowledge what was done well before listing issues — accurate praise
-    helps the implementer trust the rest of the feedback.
-
-    If you find significant deviations from the plan, flag them specifically
-    so the implementer can confirm whether the deviation was intentional.
-    If you find issues with the plan itself rather than the implementation,
-    say so.
-
-    ## Output Format
-
-    ### Strengths
-    [What's well done? Be specific.]
-
-    ### Issues
-
-    #### Critical (Must Fix)
-    [Bugs, security issues, data loss risks, broken functionality]
-
-    #### Important (Should Fix)
-    [Architecture problems, missing features, poor error handling, test gaps]
-
-    #### Minor (Nice to Have)
-    [Code style, optimization opportunities, documentation polish]
-
-    For each issue:
-    - File:line reference
-    - What's wrong
-    - Why it matters
-    - How to fix (if not obvious)
-
-    ### Recommendations
-    [Improvements for code quality, architecture, or process]
-
-    ### Assessment
-
-    **Ready to merge?** [Yes | No | With fixes]
-
-    **Reasoning:** [1-2 sentence technical assessment]
-
-    ## Critical Rules
-
-    **DO:**
-    - Categorize by actual severity
-    - Be specific (file:line, not vague)
-    - Explain WHY each issue matters
-    - Acknowledge strengths
-    - Give a clear verdict
-
-    **DON'T:**
-    - Say "looks good" without checking
-    - Mark nitpicks as Critical
-    - Give feedback on code you didn't actually read
-    - Be vague ("improve error handling")
-    - Avoid giving a clear verdict
-```
-
-**Placeholders:**
-- `[DESCRIPTION]` — brief summary of what was built
-- `[PLAN_OR_REQUIREMENTS]` — what it should do (plan file path, task text, or requirements)
-- `[BASE_SHA]` — starting commit
-- `[HEAD_SHA]` — ending commit
-
-**Reviewer returns:** Strengths, Issues (Critical / Important / Minor), Recommendations, Assessment
-
-## Example Output
-
-```
-### Strengths
-- Clean database schema with proper migrations (db.ts:15-42)
-- Comprehensive test coverage (18 tests, all edge cases)
-- Good error handling with fallbacks (summarizer.ts:85-92)
-
-### Issues
-
-#### Important
-1. **Missing help text in CLI wrapper**
-   - File: index-conversations:1-31
-   - Issue: No --help flag, users won't discover --concurrency
-   - Fix: Add --help case with usage examples
-
-2. **Date validation missing**
-   - File: search.ts:25-27
-   - Issue: Invalid dates silently return no results
-   - Fix: Validate ISO format, throw error with example
-
-#### Minor
-1. **Progress indicators**
-   - File: indexer.ts:130
-   - Issue: No "X of Y" counter for long operations
-   - Impact: Users don't know how long to wait
-
-### Recommendations
-- Add progress reporting for user experience
-- Consider config file for excluded projects (portability)
-
-### Assessment
-
-**Ready to merge: With fixes**
-
-**Reasoning:** Core implementation is solid with good architecture and tests. Important issues (help text, date validation) are easily fixed and don't affect core functionality.
-```

package/skills/requirement-low-level-check/SKILL.md

@@ -1,84 +0,0 @@
----
-name: requirement-low-level-check
-description: 需求设计低级问题检查 | 触发条件：低级问题检查、文档预检、需求预审、设计预审 | 检查需求文档和设计文档中的低级问题（命名/数字/状态/流程/规范/安全），发现明显的低级错误，作为正式评审前的快速预检工具
-author: maohan
-source: project
-date_added: "2026-07-08"
-risk: low
----
-
-# 需求设计低级问题检查
-
-本技能用于在正式评审前快速发现需求文档和设计文档中的**低级问题**，作为预检工具。
-
----
-
-## 使用方法
-
-1. 加载检查清单 `references/低级问题检查清单.md`
-2. 加载检查报告模板 `references/低级问题检查报告模板.md`
-3. 按 6 大类清单逐项检查
-4. 输出检查报告
-
----
-
-## 6 大类检查项
-
-| # | 类别 | 关键检查点 |
-|---|------|-----------|
-| 一 | 命名规范 | 术语不一致、拼写错误、临时命名 |
-| 二 | 数字/单位 | 数字错误、单位缺失、范围错误 |
-| 三 | 状态/枚举 | 枚举不完整、状态机缺失路径 |
-| 四 | 流程/逻辑 | 流程断裂、逻辑矛盾、边界遗漏 |
-| 五 | 文档规范 | 版本、结构、格式、表述、图表 |
-| 六 | 安全/合规 | 敏感信息、权限、审计、SQL安全 |
-
-**合计 60+ 项低级问题检查**
-
----
-
-## 常见低级错误 Top 10
-
-| # | 错误类型 |
-|---|---------|
-| 1 | 中英文标点混用 |
-| 2 | 数字无单位 |
-| 3 | 时间单位歧义 |
-| 4 | 同一概念命名不一致 |
-| 5 | 英文单词拼写错误 |
-| 6 | 缺少异常分支 |
-| 7 | 边界值缺失 |
-| 8 | 章节编号不连续 |
-| 9 | 状态枚举不全 |
-| 10 | 流程图与文字不一致 |
-
----
-
-## 适用场景
-
-- 正式评审前的快速预检
-- 需求/设计文档初稿的快速筛查
-- 跨团队交付前的最后检查
-
-## 不适用场景
-
-- 正式需求评审（使用 requirement-review）
-- 设计方案评审（使用 design-review）
-- 架构决策审查
-
----
-
-## 输出格式
-
-根据模板 `references/低级问题检查报告模板.md` 生成检查报告，输出后保存到 `docs/低级问题检查报告-项目名-日期.md`
-
----
-
-## 触发场景
-
-- "低级问题检查"
-- "文档预检"
-- "需求预审"
-- "设计预审"
-- "检查低级问题"
-- "文档低级错误检查"

package/skills/requirement-low-level-check/references//344/275/216/347/272/247/351/227/256/351/242/230/346/243/200/346/237/245/346/212/245/345/221/212/346/250/241/346/235/277.md

@@ -1,139 +0,0 @@
-# 低级问题检查报告 — [项目名]
-
-**检查对象**：[需求/设计文档名称] V1.0
-**检查日期**：YYYY-MM-DD
-**检查人员**：xxx
-
----
-
-## 一、检查总览
-
-| 类别 | 发现问题数 | 严重 | 一般 | 建议 |
-|------|-----------|------|------|------|
-| 命名规范 | __ | __ | __ | __ |
-| 数字/单位 | __ | __ | __ | __ |
-| 状态/枚举 | __ | __ | __ | __ |
-| 流程/逻辑 | __ | __ | __ | __ |
-| 文档规范 | __ | __ | __ | __ |
-| 安全/合规 | __ | __ | __ | __ |
-| **合计** | **__** | **__** | **__** | **__** |
-
----
-
-## 二、严重问题（必须修复）
-
-| # | 类别 | 位置 | 问题描述 | 建议修改 |
-|---|------|------|----------|----------|
-| 1 | 命名规范/数字/单位/状态/流程/文档/安全 | [章节号] | xxx | xxx |
-| 2 | xxx | xxx | xxx | xxx |
-
----
-
-## 三、一般问题（建议修复）
-
-| # | 类别 | 位置 | 问题描述 | 建议修改 |
-|---|------|------|----------|----------|
-| 1 | xxx | xxx | xxx | xxx |
-| 2 | xxx | xxx | xxx | xxx |
-
----
-
-## 四、建议项（可选）
-
-| # | 类别 | 位置 | 问题描述 | 建议修改 |
-|---|------|------|----------|----------|
-| 1 | xxx | xxx | xxx | xxx |
-| 2 | xxx | xxx | xxx | xxx |
-
----
-
-## 五、按类别详细问题
-
-### 5.1 命名规范
-
-#### 严重
-- xxx
-
-#### 一般
-- xxx
-
-#### 建议
-- xxx
-
-### 5.2 数字/单位
-
-#### 严重
-- xxx
-
-#### 一般
-- xxx
-
-#### 建议
-- xxx
-
-### 5.3 状态/枚举
-
-#### 严重
-- xxx
-
-#### 一般
-- xxx
-
-#### 建议
-- xxx
-
-### 5.4 流程/逻辑
-
-#### 严重
-- xxx
-
-#### 一般
-- xxx
-
-#### 建议
-- xxx
-
-### 5.5 文档规范
-
-#### 严重
-- xxx
-
-#### 一般
-- xxx
-
-#### 建议
-- xxx
-
-### 5.6 安全/合规
-
-#### 严重
-- xxx
-
-#### 一般
-- xxx
-
-#### 建议
-- xxx
-
----
-
-## 六、结论
-
-- ✅ **通过**（无严重问题）
-- ⚠️ **有保留通过**（一般问题 ≤ 5 个）
-- ❌ **不通过**（严重问题 ≥ 1 个）
-
-**本检查结论**：[通过/有保留通过/不通过]
-
----
-
-## 七、改进建议
-
-1. xxx
-2. xxx
-3. xxx
-
----
-
-**检查人**：xxx
-**检查日期**：YYYY-MM-DD