360 Secure SkillHub
360 安全技能中心

quality

面向已完成开发任务的质量门禁:先加载项目原则,再依次检查改动是否超出计划范围、go vet 与 go test 是否通过、是否违反既定原则、是否有对应新测试与运行时验证,最后通过事件通道给出通过或拒绝结论,并把轻微问题登记为待办。

poteto
热度 0.00
最近更新 2026-10-19 06:44:39
分类:开发依赖:代码执行 / 读写文件 / 内部调用大模型应用场景:代码审查 / 工作流 / DevOps

安装技能

复制下面的话术发给你的 Agent,它会通过 secure-skills 检索并安装该技能。

执行命令安装此 skill: npx secure-skills-cli add poteto/noodle/quality
Metadata
name
quality
description
Post-cook quality gate. Reviews completed cook work for correctness, scope discipline, and principle compliance. Emits stage_message events with findings. Triggers after execute stages, on '/quality', 'review this', 'check the work', 'assess quality'.
schedule
Follow-up stage after execute. Cross-provider review preferred — if codex executed, schedule quality on claude; if claude executed, schedule on codex.

Quality

Review completed cook work. Emit a stage_message event with your assessment. See references/stage-message-schema.md for the event schema.

Operate fully autonomously. Never ask the user.

Step 0 -- Load Principles

Read brain/principles.md and follow every [[wikilink]]. These govern the review. Do NOT skip this.

Assessment Pipeline

Run in order. Stop early and reject on any high-severity finding.

1. Scope Check

  • Read the plan phase the cook was assigned (from the cook's initial prompt or mise context).
  • Run git diff --stat and git log --oneline for the cook's commits.
  • Flag files changed outside the plan phase's stated scope as scope violations.

2. Code Quality

  • go vet ./... and go test ./... must pass.
  • Run sh scripts/lint-arch.sh if it exists.
  • Check error handling follows project conventions (failure-state messages, not expectation messages).

3. Principle Compliance

  • For each changed file, check against loaded principles.
  • Common violations: bolted-on changes instead of redesign (redesign-from-first-principles), missing verification (prove-it-works), unnecessarily added complexity (subtract-before-you-add).

4. Test Evidence

  • New behavior must have new tests.
  • Tests must assert outcomes, not implementation details.
  • Check coverage of edge cases mentioned in the plan phase.

5. Runtime Verification

  • If the plan phase specifies runtime checks, verify they were performed.
  • "It compiles" is not verification.

Verdict

Emit a stage_message event with your assessment:

noodle event emit --session $NOODLE_SESSION_ID stage_message --payload '<json>'

Accept: Emit with blocking: false. The pipeline continues and the scheduler sees the green light.

{ "message": "All checks pass. Tests green, scope clean.", "blocking": false }

Reject: Emit with blocking: true (or omit blocking). The scheduler reads findings and decides (retry, add oops stage, or abort).

{ "message": "Rejected: 3 high issues. [1] Missing test for edge case in handleCompletion. [2] Scope violation: modified cook_merge.go outside plan phase scope. [3] Error message uses expectation form.", "blocking": true }

Write the message as natural language the scheduler can act on. Include specific file paths, line context, and principle violations so the scheduler can brief the retry cook.

Non-blocking Issues

Issues that don't warrant rejection (style nits, minor improvements, documentation gaps): file as backlog items via the backlog adapter.

Principles

  • [[prove-it-works]]
  • [[outcome-oriented-execution]]