ln-402-task-reviewer by levnikolaevich/claude-code-skills
npx skills add https://github.com/levnikolaevich/claude-code-skills --skill ln-402-task-reviewer路径说明: 文件路径 (
shared/,references/,../ln-*) 是相对于技能仓库根目录的。如果在当前工作目录未找到,请定位此 SKILL.md 文件所在的目录并向上返回一级以找到仓库根目录。如果缺少shared/目录,请通过 WebFetch 从https://raw.githubusercontent.com/levnikolaevich/claude-code-skills/master/skills/{path}获取文件。
每次任务执行后必须执行。 审查“待审查”列表中的单个任务,并决定是“完成”还是“待返工”,同时提供即时修复或清晰的返工说明。
此技能不是可选的。 每个已执行的任务必须立即审查。没有例外,不得批量处理,不得跳过。
get_issue;文件模式:读取任务文件)。广告位招租
在这里展示您的产品或服务
触达数万 AI 开发者,精准高效
| 输入 | 是否必需 | 来源 | 描述 |
|---|---|---|---|
taskId | 是 | 参数、父级用户故事、看板、用户 | 待审查的任务 |
解析方式: 任务解析链。状态过滤器: 待审查
必须阅读: 加载 shared/references/tools_config_guide.md、shared/references/storage_mode_detection.md 和 shared/references/input_resolution_pattern.md
提取:task_provider = 任务管理 → 提供者 (linear | file)。
| 方面 | Linear 模式 | 文件模式 |
|---|---|---|
| 加载任务 | get_issue(task_id) | Read("docs/tasks/epics/.../tasks/T{NNN}-*.md") |
| 加载用户故事 | get_issue(parent_id) | Read("docs/tasks/epics/.../story.md") |
| 更新状态 | save_issue(id, state: "Done"/"To Rework") | Edit 文件中的 **Status:** 行 |
| 添加评论 | create_comment({issueId, body}) | Write 评论到 .../comments/{ISO-timestamp}.md |
| 创建 [BUG] 任务 | save_issue({title, parentId, team, labels, state}) | Write("docs/tasks/.../T{NNN}-bug-{slug}.md") |
文件模式状态值: 完成,待返工(审查仅产生这两种结果)
在启动时检测操作模式:
计划模式激活:
正常模式:
必须阅读: 加载 shared/references/plan_mode_pattern.md 工作流 A(仅预览)以了解计划模式行为。
关键:在计划模式下,计划文件 = 审查计划(将要检查的内容)。切勿将审查发现或裁决写入计划文件。
审查计划格式:
REVIEW PLAN for Task {ID}: {Title}
| Field | Value |
|-------|-------|
| Task | {ID}: {Title} |
| Status | {To Review} |
| Type | {impl/test/refactor} |
| Story | {Parent ID}: {Parent Title} |
Files to review:
- {file1} (交付物)
- {file2} (受影响组件)
| # | Check | Will Verify |
|---|-------|-------------|
| 1 | Approach | Technical Approach alignment |
| 2 | Clean Code | No dead code, no backward compat shims |
| 3 | Config | No hardcoded creds/URLs |
| 4 | Errors | try/catch on external calls |
| 5 | Logging | ERROR/INFO/DEBUG levels |
| 6 | Comments | WHY not WHAT, docstrings |
| 7 | Naming | Project conventions |
| 8 | Docs | API/env/README updates |
| 9 | Tests | Updated/risk-based limits |
| 10 | AC | 4 criteria validation |
| 11 | Side-effects | Pre-existing bugs in touched files |
| 12 | Destructive ops | Safety guards from destructive_operation_safety.md (loaded in step 4) |
| 13 | Algorithm correctness | Loop invariants, collection keys, unbounded ops, shared state leaks |
| 14 | Event channels | Channel name consistency in diff |
| 15 | CI Checks | lint/typecheck pass per ci_tool_detection.md |
Expected output: Verdict (Done/To Rework) + Issues + Fix actions
在任何模式下操作时,技能必须创建详细的待办事项清单来跟踪所有步骤。
规则:
in_progress,完成后标记为 completed待办事项模板(约 11 项):
Step 1: Resolve taskId
- Resolve via args / Story context / kanban / AskUserQuestion (To Review filter)
Step 2: Load Task
- Load task by ID, detect type
Step 3: Read Context
- Load full task + parent Story + affected components
Step 3b: Goal Articulation Gate
- State what specific quality question this review must answer (<=25 tokens each)
Step 4: Review Checks
- Verify approach alignment with Story Technical Approach
- Check clean code: no dead code, no backward compat shims
- Cross-file DRY: Grep src/ for new function/class names (count mode). 3+ similar → CONCERN
- Check config hygiene, error handling, logging
- Check comments, naming, docs updates
- Verify tests updated/run (risk-based limits for test tasks)
Step 5: AC Validation
- Validate implementation against 4 AC criteria
Step 6: Side-Effect Bug Detection
- Scan for bugs outside task scope, create [BUG] tasks
Step 7: Decision
- Apply minor fixes or set To Rework with guidance
Step 8: Mechanical Verification
- Run lint/typecheck per ci_tool_detection.md (only if verdict=Done)
Step 9: Update & Commit
- Set task status, update kanban, post review comment
- If Done: commit ALL uncommitted changes in branch (git add -A)
解析 taskId: 根据指南运行任务解析链(状态过滤器:[待审查])。
加载任务: 独立加载完整任务和父级用户故事。检测类型(标签 "tests" -> 测试任务,否则为实施/重构任务)。
读取上下文: 完整任务 + 父级用户故事;加载受影响组件/文档;如果可用则审查差异。3b) 目标关卡: 必须阅读: shared/references/goal_articulation_gate.md — 在审查之前,说明:(1) 真实目标:本次审查必须为此任务回答什么具体的质量问题?(2) 完成:什么证据证明质量足够?(3) 非目标:表面上的橡皮图章审查会是什么样子?(4) 不变性:存在哪些不明显的约束(对其他模块的副作用、隐式验收标准)?
审查检查项: 必须阅读: shared/references/clean_code_checklist.md、shared/references/destructive_operation_safety.md
* **目标验证(恢复悖论):** 如果执行者阐明了真实目标(在任务评论或实现中可见),验证其是否与用户故事的目标交付物匹配。如果执行者围绕次要主题构建目标(例如,“实现端点”而不是“启用用户数据导出”)→ 关注:`GOAL-MISFRAME: executor goal targets secondary subject, may miss hidden constraints.`
* 方法:差异与用户故事中的技术方法一致。如果不同 → 在代码注释中记录理由。
* **整洁代码:** 根据清单 — 验证所有 4 个类别。已替换的实现完全移除。如果重构更改了 API — 调用方已更新,旧签名已移除。
* **跨文件 DRY:** 对于任务创建的每个新函数/类/处理程序,在 `src/` 中 Grep 查找相似名称/模式(计数模式)。如果 3+ 个文件包含类似逻辑 → 添加关注:`MNT-DRY-CROSS: {pattern} appears in {count} files — consider extracting to shared module.` 这可以捕获每次任务审查遗漏的跨用户故事重复。
* **跨文件 DRY 首选(六边形图):** 如果六边形图已索引,使用 `find_clones(scope="src/**", kind="function", cross_file=true, format="json")`。筛选任何成员位于任务修改文件中的组。每个匹配项 = 关注:`MNT-DRY-CROSS`。如果六边形图不可用,则回退到上述 Grep 名称搜索。
* 没有硬编码的凭据/URL/魔法数字;配置在环境变量/配置文件中。
* 破坏性操作防护:使用来自 `destructive_operation_safety.md`(上面已加载)的代码级防护表。关键/高严重性 → 阻塞项:`SEC-DESTR-{ID}`。中等严重性 → 关注:`SEC-DESTR-{ID}`。
* 错误处理:所有外部调用(API、数据库、文件 I/O)都包装在 try/catch 或等效结构中。没有吞掉的异常。尊重分层;重用现有组件。
* 副作用广度:具有 3+ 个副作用类别的**叶子**服务函数 → 关注:`ARCH-AI-SEB`。例外:编排器/协调器函数(导入 3+ 个服务并按顺序委托)**预期**具有多个副作用类别 — 不要标记。
* 接口诚实性:具有写入副作用的读取命名函数(`get_`/`find_`/`check_`)→ 关注:`ARCH-AI-AH`
* 日志记录:错误记录在 ERROR 级别;身份验证/支付事件记录在 INFO 级别;调试数据记录在 DEBUG 级别。日志中没有敏感数据。
* 注释:解释**为什么**而不是**是什么**;没有注释掉的代码;公共方法有文档字符串。
* 命名:遵循项目现有约定(检查 3+ 个类似文件)。除领域术语外,没有缩写。没有单字母变量(循环除外)。
* 实体泄漏:ORM 实体不得直接从 API 端点返回。使用 DTO/响应模型。(对于身份验证/支付是阻塞项,对于其他情况是关注项)
* 方法签名:公共方法中没有布尔标志参数(使用枚举/选项对象);没有 DTO 时参数不超过 5 个。(细微问题)
* **算法正确性(循环、集合、边界):** 循环内的 `break`/`continue`/`return` 是否处理**所有**匹配项,而不仅仅是第一项?字典/集合推导式是否正确处理重复键(最后胜出可能丢失数据)?是否存在对用户控制数据没有 LIMIT 的 `list(query.all())` 或无界循环?是否存在跨请求泄漏的可变共享状态(连接池 GUC、会话全局变量)?(如果导致数据丢失/损坏则为阻塞项,否则为关注项)
* **事件通道一致性(任务范围):** 当任务差异触及事件相关代码(`NOTIFY`/`LISTEN`/`emit`/`subscribe`/`publish`/`on`)时,验证:(1) 发布者中的通道名称字符串与订阅者中的通道名称字符串匹配;(2) 如果通道名称是新的字符串字面量,则在 `src/` 中 Grep 查找匹配的监听器/发布者对应项。不匹配 → 关注:`ARCH-EVENT-MISMATCH: publisher '{pub_name}' has no matching subscriber`。孤立项 → 关注:`ARCH-EVENT-ORPHAN: subscriber '{sub_name}' has no matching publisher`。
* **简洁性标准(任务范围):** **必须阅读:** `references/simplicity_criterion.md` — 检查 `MNT-KISS-SCOPE`(工作量-S 级任务包含 3+ 个新抽象)和 `MNT-YAGNI-SCOPE`(重构添加了新依赖项或创建了比修改文件多 2 倍的文件)。仅为建议性关注项。
* **代码效率(任务范围):** 抽查差异中的 2-3 个关键函数,查找不必要的中间变量、存在惯用法的冗长模式或框架处理的样板代码。如果发现 → 关注:`MNT-EFF-SCOPE: {pattern} in {file}`。仅为建议性关注项。(`shared/references/code_efficiency_criterion.md`)
* **前端审查(条件性):** 如果审查的文件包括 `.tsx/.vue/.svelte/.html/.css`:**必须阅读:** `shared/references/frontend_design_guide.md`。(a) WCAG 2.1 AA:对比度、键盘导航、ARIA 标签、焦点管理 → 阻塞项:`A11Y-{ID}`。(b) 组合:单一用途部分,没有仪表板卡片马赛克 → 关注:`UI-COMP-{ID}`。(c) 排版克制:最多 2 种字体,1 种强调色 → 关注:`UI-TYPE`。(d) 文案质量:产品语言,没有占位符文本 → 细微问题:`UI-COPY`。(e) 动效合理性:每个动画服务于层次结构/氛围 → 细微问题:`UI-MOTION`。(f) 设计系统遵循性:如果项目有 `design_guidelines.md`,验证令牌匹配 → 关注:`UI-SYSTEM`。
* 文档:如果公共 API 更改 → API 文档已更新。如果新增环境变量 → `.env.example` 已更新。如果新增概念 → README/架构文档已更新。
* 测试已更新/运行:对于实施/重构,确保受影响的测试已调整;对于测试任务,根据规划器模板验证基于风险的限制和优先级(≤15)。
5. 验收标准验证(对实施任务为必须): 必须阅读: 加载 references/ac_validation_checklist.md。根据 4 条标准验证实现:
* **验收标准完整性:** 所有验收标准场景已覆盖(成功路径 + 错误 + 边界情况)。
* **验收标准具体性:** 确切要求已满足(HTTP 状态码 200/401/403,时间 <200ms,确切消息)。
* **任务依赖关系:** 任务 N 仅使用任务 1 到 N-1(不向前依赖 N+1, N+2)。
* **数据库创建:** 任务仅创建用户故事范围内的表(没有大爆炸式模式)。如果**任何**标准失败 → 待返工,并附上清单中的具体指导。
6. 副作用错误检测(必须): 在审查受影响代码时,主动扫描与当前任务无关的错误/问题:
* 被触及文件中预先存在的错误
* 相邻代码中的损坏模式
* 相关组件中的安全问题
* 已弃用的 API、过时的依赖项
* 调用方/被调用方函数中缺失的错误处理
对于发现的每个副作用错误:
* 在同一用户故事中创建新任务:
* 如果 `task_provider` = `linear`:`save_issue({title: "[BUG] {desc}", description, parentId: Story.id, team: teamId, labels: ["bug", "discovered-in-review"], state: "Backlog", priority})`
* 如果 `task_provider` = `file`:`Write("docs/tasks/epics/.../tasks/T{NNN}-bug-{slug}.md")`,包含 `**Status:** Backlog`、`**Labels:** bug, discovered-in-review`、`**Story:** US{NNN}`、`**Created:** {date}`
* 标题:`[BUG] {简短描述}`
* 描述:位置、问题、建议的修复方法
* 标签:`bug`、`discovered-in-review`
* 优先级:基于严重性(安全 → 1 紧急,逻辑 → 2 高,样式 → 4 低)
* **不要推迟** — 立即创建任务,审查员捕获执行者遗漏的内容
7. 裁决(仅针对当前任务):
* 如果只有细微问题:应用小修复并设置为完成。
* 如果仍有问题:设置为待返工,并在评论中解释原因(最佳实践参考)以及如何修复。
* 副作用错误**不**阻止当前任务的完成状态(它们是独立的任务)。
* **如果完成:** 提交分支中**所有**未提交的更改(不仅仅是与任务相关的文件):`git add -A && git commit -m "Implement {task_id}: {task_title}"`。这包括来自先前任务的任何更改、自动修复或生成的文件 — 当前所有未暂存/已暂存的更改都将进入此提交。
8. 机械验证(如果完成): 必须阅读: shared/references/ci_tool_detection.md 如果裁决 == 完成:
* 根据 `ci_tool_detection.md` 中的发现层次结构检测 lint/类型检查命令
* 运行检测到的检查(根据指南设置超时:linters 2 分钟,类型检查 5 分钟)**必须阅读:** 加载 `shared/references/output_normalization.md`
* 如果任何检查**失败** → 根据 §1 标准化 → §2 去重 → §4 截断至 50 行 → 将裁决覆盖为待返工,并附上标准化输出
* 如果未检测到工具 → 跳过并显示信息性消息
9. 更新: 在 Linear 中设置任务状态;更新看板:如果完成 → 从看板中移除任务(完成部分仅跟踪用户故事,而非单个任务);如果待返工 → 将任务移至待返工部分;添加包含发现/操作的审查评论。如果创建了副作用错误,请在评论中提及它们。
背景: 量化的审查结果有助于 ln-400 编排器做出数据驱动的决策并跟踪审查一致性。
公式: 质量评分 = 100 - (20 × 阻塞项_数量) - (10 × 关注项_数量) - (3 × 细微问题_数量)
对步骤 3-5 中的每个发现进行分类:
| 类别 | 权重 | 示例 |
|---|---|---|
| 阻塞项 | -20 | 验收标准未满足、安全问题、缺少错误处理、方法错误 |
| 关注项 | -10 | 次优模式、缺少文档、测试缺口 |
| 细微问题 | -3 | 命名、样式、次要清理 |
裁决映射:
| 评分 | 裁决 | 操作 |
|---|---|---|
| 90-100 | 完成 | 接受,内联应用细微问题修复 |
| 70-89 | 完成(附说明) | 接受,记录关注项供将来参考 |
| <70 | 待返工 | 退回,并根据发现提供修复指导 |
注意: 副作用错误(步骤 5)不影响当前任务的质量评分 — 它们成为独立的 [BUG] 任务。
git add -A)并附带任务 ID;任务已从看板移除。如果待返工:任务已移动并附有修复指导。shared/references/tools_config_guide.mdshared/references/storage_mode_detection.mdshared/references/problem_solving.mdshared/references/ac_validation_rules.mdreferences/ac_validation_checklist.md(4 条标准:完整性、具体性、依赖关系、数据库创建)shared/references/clean_code_checklist.mdshared/references/ci_tool_detection.mdshared/references/output_normalization.mddocs/tasks/kanban_board.md版本: 5.1.0 最后更新: 2026-03-15
每周安装次数
151
仓库
GitHub 星标数
245
首次出现
2026年2月2日
安全审计
安装于
claude-code138
cursor136
gemini-cli136
codex136
opencode136
github-copilot134
Paths: File paths (
shared/,references/,../ln-*) are relative to skills repo root. If not found at CWD, locate this SKILL.md directory and go up one level for repo root. Ifshared/is missing, fetch files via WebFetch fromhttps://raw.githubusercontent.com/levnikolaevich/claude-code-skills/master/skills/{path}.
MANDATORY after every task execution. Reviews a single task in To Review and decides Done vs To Rework with immediate fixes or clear rework notes.
This skill is NOT optional. Every executed task MUST be reviewed immediately. No exceptions, no batching, no skipping.
| Input | Required | Source | Description |
|---|---|---|---|
taskId | Yes | args, parent Story, kanban, user | Task to review |
Resolution: Task Resolution Chain. Status filter: To Review
MANDATORY READ: Load shared/references/tools_config_guide.md, shared/references/storage_mode_detection.md, and shared/references/input_resolution_pattern.md
Extract: task_provider = Task Management → Provider (linear | file).
| Aspect | Linear Mode | File Mode |
|---|---|---|
| Load task | get_issue(task_id) | Read("docs/tasks/epics/.../tasks/T{NNN}-*.md") |
| Load Story | get_issue(parent_id) | Read("docs/tasks/epics/.../story.md") |
| Update status | save_issue(id, state: "Done"/"To Rework") | Edit the line in file |
File Mode status values: Done, To Rework (only these two outcomes from review)
Detect operating mode at startup:
Plan Mode Active:
Normal Mode:
MANDATORY READ: Load shared/references/plan_mode_pattern.md Workflow A (Preview-Only) for plan mode behavior.
CRITICAL: In Plan Mode, plan file = REVIEW PLAN (what will be checked). NEVER write review findings or verdicts to plan file.
Review Plan format:
REVIEW PLAN for Task {ID}: {Title}
| Field | Value |
|-------|-------|
| Task | {ID}: {Title} |
| Status | {To Review} |
| Type | {impl/test/refactor} |
| Story | {Parent ID}: {Parent Title} |
Files to review:
- {file1} (deliverable)
- {file2} (affected component)
| # | Check | Will Verify |
|---|-------|-------------|
| 1 | Approach | Technical Approach alignment |
| 2 | Clean Code | No dead code, no backward compat shims |
| 3 | Config | No hardcoded creds/URLs |
| 4 | Errors | try/catch on external calls |
| 5 | Logging | ERROR/INFO/DEBUG levels |
| 6 | Comments | WHY not WHAT, docstrings |
| 7 | Naming | Project conventions |
| 8 | Docs | API/env/README updates |
| 9 | Tests | Updated/risk-based limits |
| 10 | AC | 4 criteria validation |
| 11 | Side-effects | Pre-existing bugs in touched files |
| 12 | Destructive ops | Safety guards from destructive_operation_safety.md (loaded in step 4) |
| 13 | Algorithm correctness | Loop invariants, collection keys, unbounded ops, shared state leaks |
| 14 | Event channels | Channel name consistency in diff |
| 15 | CI Checks | lint/typecheck pass per ci_tool_detection.md |
Expected output: Verdict (Done/To Rework) + Issues + Fix actions
When operating in any mode, skill MUST create detailed todo checklist tracking ALL steps.
Rules:
in_progress before starting step, completed after finishingTodo Template (~11 items):
Step 1: Resolve taskId
- Resolve via args / Story context / kanban / AskUserQuestion (To Review filter)
Step 2: Load Task
- Load task by ID, detect type
Step 3: Read Context
- Load full task + parent Story + affected components
Step 3b: Goal Articulation Gate
- State what specific quality question this review must answer (<=25 tokens each)
Step 4: Review Checks
- Verify approach alignment with Story Technical Approach
- Check clean code: no dead code, no backward compat shims
- Cross-file DRY: Grep src/ for new function/class names (count mode). 3+ similar → CONCERN
- Check config hygiene, error handling, logging
- Check comments, naming, docs updates
- Verify tests updated/run (risk-based limits for test tasks)
Step 5: AC Validation
- Validate implementation against 4 AC criteria
Step 6: Side-Effect Bug Detection
- Scan for bugs outside task scope, create [BUG] tasks
Step 7: Decision
- Apply minor fixes or set To Rework with guidance
Step 8: Mechanical Verification
- Run lint/typecheck per ci_tool_detection.md (only if verdict=Done)
Step 9: Update & Commit
- Set task status, update kanban, post review comment
- If Done: commit ALL uncommitted changes in branch (git add -A)
Resolve taskId: Run Task Resolution Chain per guide (status filter: [To Review]).
Load task: Load full task and parent Story independently. Detect type (label "tests" -> test task, else implementation/refactor).
Read context: Full task + parent Story; load affected components/docs; review diffs if available. 3b) Goal gate: MANDATORY READ: shared/references/goal_articulation_gate.md — Before reviewing, state: (1) REAL GOAL: what specific quality question must this review answer for THIS task? (2) DONE: what evidence proves quality is sufficient? (3) NOT THE GOAL: what would a surface-level rubber-stamp look like? (4) INVARIANTS: what non-obvious constraint exists (side-effects on other modules, implicit AC)?
Review checks: MANDATORY READ: shared/references/clean_code_checklist.md, shared/references/destructive_operation_safety.md
GOAL-MISFRAME: executor goal targets secondary subject, may miss hidden constraints.For each side-effect bug found:
* Create new task in same Story:
* IF `task_provider` = `linear`: `save_issue({title: "[BUG] {desc}", description, parentId: Story.id, team: teamId, labels: ["bug", "discovered-in-review"], state: "Backlog", priority})`
* IF `task_provider` = `file`: `Write("docs/tasks/epics/.../tasks/T{NNN}-bug-{slug}.md")` with `**Status:** Backlog`, `**Labels:** bug, discovered-in-review`, `**Story:** US{NNN}`, `**Created:** {date}`
* Title: `[BUG] {Short description}`
* Description: Location, issue, suggested fix
* Label: `bug`, `discovered-in-review`
* Priority: based on severity (security → 1 Urgent, logic → 2 High, style → 4 Low)
* **Do NOT defer** — create task immediately, reviewer catches what executor missed
7. Decision (for current task only):
* If only nits: apply minor fixes and set Done.
* If issues remain: set To Rework with comment explaining why (best-practice ref) and how to fix.
* Side-effect bugs do NOT block current task's Done status (they are separate tasks).
* **If Done:** commit ALL uncommitted changes in the branch (not just task-related files): `git add -A && git commit -m "Implement {task_id}: {task_title}"`. This includes any changes from previous tasks, auto-fixes, or generated files — everything currently unstaged/staged goes into this commit.
8. Mechanical Verification (if Done): MANDATORY READ: shared/references/ci_tool_detection.md IF verdict == Done:
* Detect lint/typecheck commands per discovery hierarchy in ci_tool_detection.md
* Run detected checks (timeouts per guide: 2min linters, 5min typecheck) **MANDATORY READ:** Load `shared/references/output_normalization.md`
* IF any FAIL → apply output normalization per §1 normalize → §2 deduplicate → §4 truncate to 50 lines → override verdict to To Rework with normalized output
* IF no tooling detected → SKIP with info message
9. Update: Set task status in Linear; update kanban: if Done → remove task from kanban (Done section tracks Stories only, not individual Tasks); if To Rework → move task to To Rework section; add review comment with findings/actions. If side-effect bugs created, mention them in comment.
Context: Quantitative review result helps ln-400 orchestrator make data-driven decisions and tracks review consistency.
Formula: Quality Score = 100 - (20 × BLOCKER_count) - (10 × CONCERN_count) - (3 × NIT_count)
Classify each finding from Steps 3-5:
| Category | Weight | Examples |
|---|---|---|
| BLOCKER | -20 | AC not met, security issue, missing error handling, wrong approach |
| CONCERN | -10 | Suboptimal pattern, missing docs, test gaps |
| NIT | -3 | Naming, style, minor cleanup |
Verdict mapping:
| Score | Verdict | Action |
|---|---|---|
| 90-100 | Done | Accept, apply nit fixes inline |
| 70-89 | Done (with notes) | Accept, document concerns for future |
| <70 | To Rework | Send back with fix guidance per finding |
Note: Side-effect bugs (Step 5) do NOT affect current task's quality score — they become separate [BUG] tasks.
git add -A) with task ID; task removed from kanban. If To Rework: task moved with fix guidance.shared/references/tools_config_guide.mdshared/references/storage_mode_detection.mdshared/references/problem_solving.mdshared/references/ac_validation_rules.mdreferences/ac_validation_checklist.md (4 criteria: Completeness, Specificity, Dependencies, DB Creation)shared/references/clean_code_checklist.mdshared/references/ci_tool_detection.mdVersion: 5.1.0 Last Updated: 2026-03-15
Weekly Installs
151
Repository
GitHub Stars
245
First Seen
Feb 2, 2026
Security Audits
Gen Agent Trust HubWarnSocketWarnSnykFail
Installed on
claude-code138
cursor136
gemini-cli136
codex136
opencode136
github-copilot134
通过 LiteLLM 代理让 Claude Code 对接 GitHub Copilot 运行 | 高级变通方案指南
36,300 周安装
**Status:**| Add comment | create_comment({issueId, body}) | Write comment to .../comments/{ISO-timestamp}.md |
| Create [BUG] task | save_issue({title, parentId, team, labels, state}) | Write("docs/tasks/.../T{NNN}-bug-{slug}.md") |
src/ for similar names/patterns (count mode). If 3+ files contain similar logic → add CONCERN: MNT-DRY-CROSS: {pattern} appears in {count} files — consider extracting to shared module. This catches cross-story duplication that per-task review misses.find_clones(scope="src/**", kind="function", cross_file=true, format="json"). Filter groups where any member is in task-modified files. Each match = CONCERN: MNT-DRY-CROSS. Fall back to Grep name search above if hex-graph unavailable.ARCH-AI-SEB. Exception: orchestrator/coordinator functions (imports 3+ services AND delegates sequentially) are EXPECTED to have multiple side-effect categories — do NOT flag.ARCH-AI-AHbreak/continue/return inside loops handle ALL matching items, not just the first? Do dict/set comprehensions handle duplicate keys correctly (last-wins may lose data)? Any list(query.all()) or unbounded loop on user-controlled data without LIMIT? Any mutable shared state (connection pool GUCs, session globals) that leaks across requests? (BLOCKER if data loss/corruption, CONCERN otherwise)src/ for matching listener/publisher counterpart. Mismatch → CONCERN: ARCH-EVENT-MISMATCH: publisher '{pub_name}' has no matching subscriber. Orphan → CONCERN: ARCH-EVENT-ORPHAN: subscriber '{sub_name}' has no matching publisher.references/simplicity_criterion.md — Check MNT-KISS-SCOPE (effort-S task with 3+ new abstractions) and MNT-YAGNI-SCOPE (refactoring added new dependencies or created 2x more files than modified). Advisory CONCERNs only.MNT-EFF-SCOPE: {pattern} in {file}. Advisory only. (shared/references/code_efficiency_criterion.md).tsx/.vue/.svelte/.html/.css: MANDATORY READ: shared/references/frontend_design_guide.md. (a) WCAG 2.1 AA: contrast ratios, keyboard nav, ARIA labels, focus management → BLOCKER: A11Y-{ID}. (b) Composition: single-purpose sections, no dashboard card mosaics → CONCERN: UI-COMP-{ID}. (c) Typography restraint: max 2 typefaces, 1 accent → CONCERN: UI-TYPE. (d) Copy quality: product language, no placeholder text → NIT: UI-COPY. (e) Motion justification: each animation serves hierarchy/atmosphere → NIT: UI-MOTION. (f) Design system adherence: if project has design_guidelines.md, verify tokens match → CONCERN: UI-SYSTEM.AC Validation (MANDATORY for implementation tasks): MANDATORY READ: Load references/ac_validation_checklist.md. Verify implementation against 4 criteria:
Side-Effect Bug Detection (MANDATORY): While reviewing affected code, actively scan for bugs/issues NOT related to current task:
shared/references/output_normalization.mddocs/tasks/kanban_board.md