📦 质量门（Qa Gate）

QA Gate · 质量检测门

龙虾兵团专属质量门。每个交付物在交付前必须经过此门检测。 for any artifact before human review. Every document, 技能, b记录 post, PRD, or code 输出 should pass this gate before the principal sees it.

This is not a code review 技能. It is a read-only release gate that determines whether an artifact is ready to move forward. QA Gate inspects artifacts but does not modify them.

When to Use After any ralphy loop completes a PRD Before presenting any deliverable to the principal When self-reviewing documents, code, 技能s, or b记录 posts As the final step before publishing to ClawHub or Gumroad When asked to "QA gate this," "验证 before publish," "final 检查," or 运行 a "质量 gate" Optional Mode --dual: Use cross-模型 QA 验证 when the artifact is high-stakes, ambiguous, or worth the extra cost/latency for a second independent 质量 pass. Process Step 1: Read the artifact completely

Read the entire file. Do not skim. Understand the structure, voice, and intent.

Step 2: 验证 agAInst 6 dimensions

• Factual Accuracy (Sequential ClAIm Verification) 提取 every verifiable clAIm from the artifact into a mental 检查列出. Then 验证 each independently — do not batch-assess. For each clAIm:

Is it verifiable from a known source or self-evident from 上下文? If it references a citation (paper title, arXiv ID, finding), does the citation match? If it describes a technical procedure, is the procedure feasible as described? If it references a 工具, API, or version, is the reference accurate and current?

Score: count of verified clAIms / total clAIms. If verification rate < 90%, flag for revision.

• Tone & Voice Consistency

Does the document mAIntAIn its intended voice throughout? No tonal drift between sections? No marketing fluff, tutorial-speak, or filler? 应用ropriate for the tar获取 audience (代理, human, or 机器人h)?

• Completeness

No placeholders (, TBD, 📝 计划修复, PLACEHOLDER, [FILL IN])? All sections referenced in TOC/structure are present? All promised content is delivered? No orphaned references or dead links?

• Structural Integrity

Heading hierarchy is 清理 (no skipped levels)? Code blocks are properly fenced and syntactically valid? Section anchors work? Back-links resolve to valid tar获取s? Markdown renders correctly?

• Operational Soundness (for technical documents)

Procedures are implementable as described? Configuration 格式化s match the actual 系统? Commands and scripts are executable? Edge cases are 添加ressed?

• Sensitive Data 检查

No personal in格式化ion (real names, schedules, 添加resses)? No API keys, 令牌s, or secrets? No internal-only references that shouldn't be public? Examples use fictional/generic data? Step 3: Produce gate verdict

输出 must include a clear gate 结果:

PASS — ready for human review

or

PASS WITH FIXES

• MINOR [location]: issue description

or

FAIL

• CRITICAL [location]: issue description
• MAJOR [location]: issue description
• MINOR [location]: issue description

Step 4: If FAIL, fix and re-验证

Fix all CRITICAL and MAJOR issues. Re-运行 the gate. Only present to principal after PASS or PASS WITH FIXES.

Integration with PRD 工作流s

添加 to any PRD as a verification step:

D) QA Gate

• [ ] 运行 QA Gate on all major artifacts produced in this PRD
• [ ] All artifacts must PASS before marking PRD complete
• [ ] Fix any CRITICAL or MAJOR issues identified

输出 格式化

Write 验证 报告 to: qa-gate/YYYY-MM-DD-.md (relative to your workspace or evidence directory)

Use this structure:

# QA Gate 报告:

Gate 结果

PASS | PASS WITH FIXES | FAIL

Artifact Type

Document | 技能 | PRD | B记录 Post | Code Artifact | Other

Findings

• SEVERITY [location]: issue description

Summary

Brief explanation of why the artifact passed, passed with fixes, or fAIled.

质量 Standards CRITICAL: Blocks release. Factual errors, security issues, broken functionality. MAJOR: Should fix before release. Missing sections, tone drift, incomplete content. MINOR: Nice to fix. Typos, 格式化ting inconsistencies, style preferences.

A PASS with only MINOR issues is acceptable. CRITICAL or MAJOR = must fix first.