hujianbest

Use when starting an existing-code bug audit on a repository or large directory tree. First detects project language + architecture (e.g. C/C++ embedded SOA, Python web service, frontend SPA), proposes a tailored review checklist (scenario-specific bug categories) for user confirmation, then slices the codebase into modules within a per-module token budget. Produces plan.json with profile + review_checklist + modules that downstream audit-reviewer consumes module-by-module. Not for PR diff review (use hf-code-review) or for actually finding bugs (use audit-reviewer).

Use as the FINAL stage of the code-audit pipeline. Reads confirmed.json (output of audit-verifier) and renders a self-contained single-file HTML report (always) and optionally an Excel workbook. The HTML contains summary stats by severity/category/module, filterable finding cards with code snippets and audit trails (reviewer + verifier). Not for emitting findings (use audit-reviewer) or verifying findings (use audit-verifier).

Use when scanning an existing-code module for bugs and emitting finding drafts. Reads source files within one module from the plan.json produced by audit-planner, walks files line-by-line, emits findings/<module>.json with file path, line numbers, category, severity, confidence, code snippet evidence, and reasoning. The set of allowed finding categories is sourced from plan.json's review_checklist (scenario preset such as c-cpp-embedded-soa / python-web-service / frontend-spa / generic) rather than a fixed taxonomy — keep findings scoped to the user-confirmed checklist. This is the PRIMARY (first-stage) reviewer in the two-agent confirmation pipeline; downstream audit-verifier independently confirms each finding. Not for PR diff review (use hf-code-review) or for verifying findings (use audit-verifier).

Use as the SECOND-STAGE independent confirmer in the two-agent code-audit pipeline. Reads finding drafts produced by audit-reviewer and independently re-examines each one against the actual source code, writes verifications/<module>.json with status (confirmed/rejected/upgrade/downgrade/needs_more_evidence), reason, and evidence_check. Operates with FRESH context — does not see reviewer's internal reasoning beyond what is recorded in the finding's description+evidence fields, to enable independent judgement. Not for emitting new findings (use audit-reviewer) or rendering the report (use audit-reporter).

Use when hf-test-driven-dev finishes GREEN on a frontend-touching active task whose spec declares a UI surface, and fresh browser runtime evidence (screenshot / console log / network trace) is required for downstream gates. Not for issuing verdicts (gates do that), not for replacing hf-test-review's test-quality review, not for backend-only tasks.

适用于 test review 通过后评审代码质量、用户要求 code review 的场景。不适用于评审测试（→ hf-test-review）、写/修代码（→ hf-test-driven-dev）、阶段不清（→ hf-workflow-router）。

适用于 regression gate 之后需判断任务完成走向、确认任务可宣告完成、用户要求\"能不能算完成\"的场景。不适用于缺回归记录/实现交接块需补齐（→ hf-regression-gate）、需状态收尾（→ hf-finalize）、阶段不清（→ hf-workflow-router）。

Use when a host project (vendoring HF) wants per-directory hierarchical context (project root / mid-directory / leaf-directory) auto-generated for any AI agent reading the codebase. Generates `AGENTS.md` (OpenCode), `.​cursor/rules/*.mdc` (Cursor), or `CLAUDE.md` (Claude Code) skeletons; architect fills in conventions. Not for HF's own `docs/principles/` (untouched); not for spec / design / tasks artifacts (use upstream skills).

在规格、设计、测试或代码需要独立评审时使用：阶段产物完成后的把关、人要求 review、或对既有产物做专项检查时。评审必须由作者之外的独立上下文执行，产出 findings 与 verdict。

在实现任何功能或修复任何缺陷、即将编写实现代码时使用；设计确认后的整个实现期都适用。强制测试先行的 RED→GREEN→REFACTOR 循环。不用于规格编写、设计决策或纯文档修改。

在车载软件工作项（ECU、域控、车载服务、整车平台）的规格、设计、实现或评审中使用，涉及功能安全/ASIL、车载 SOA 服务、DTC/诊断、整车启动/休眠/唤醒、SELinux 或跨 ECU 协同时。只承载车载专属约束；内存/实时性、通用服务接口或其他相邻领域规则由命中 description 的领域技能叠加，语言级规则见适用 `<language>-coding-standards`。

在后端/服务端工作项（HTTP/REST/GraphQL API、服务与仓库层、数据库访问、缓存、鉴权、限流、后台任务、可观测性、配置与机密、弹性容错、生产就绪）的规格、设计、实现或评审中使用，涉及接口契约、分层与依赖方向、配置与机密、错误模型、数据一致性、幂等、认证授权、依赖超时重试熔断、过载保护、优雅停机时。只承载服务端/API 领域约束；客户端/UI、行业专属服务或其他相邻领域规则由命中 description 的领域技能叠加，语言级规则见适用 `<language>-coding-standards`。

在编写、修改或评审 C 代码（.c 源文件、.h 头文件、C 单元测试、C ABI 边界）时使用。提供指针所有权、手动内存与资源释放、缓冲区容量、整数转换、宏、头文件、错误返回的具体规则与正反例。只适用于 C 语言；其他语言或 C++ 代码使用对应语言自己的 coding-standards 技能。

在需要为某种编程语言新建或修订 coding-standards 技能时使用：把团队内部编码规范文档转化为符合 DevFlow 形态的 <language>-coding-standards 技能，或把新的团队规则并入既有语言技能。不用于编写业务代码或直接做代码评审。

在编写、修改或评审 C++ 代码（.cpp/.cc/.hpp、类、模板、RAII、智能指针、C++ 测试、C++ ABI 边界）时使用。提供资源管理、所有权签名、类设计、错误策略、模板纪律与 ABI 的具体规则与正反例。只适用于 C++；C 或其他语言代码使用对应语言自己的 coding-standards 技能。

在编写、修改或重构任何实现代码与测试代码时使用；TDD implementer 进入 GREEN/REFACTOR 和返回 clean_code_check 时必须作为通用基准加载。也在代码评审需要内在质量判据，或发现命名混乱、函数过长、嵌套过深、直接变异状态、类型/契约含混、错误处理散乱等代码异味时使用。语言无关的整洁代码标准；语言细则见对应的 <language>-coding-standards 技能，领域或框架规范按各自 description 叠加在本技能之上，不能替代本技能。

C++ 编程规范扩展。绑定阶段: build。触发条件: 项目主要语言为 C++(存在 CMakeLists.txt / *.cpp 主体代码)。约束 C++ 项目在实现阶段的测试组织(GoogleTest)、资源管理与常见测试反模式。

UI 设计领域扩展。绑定阶段: plan、build、verify。触发条件: 特性包含用户界面(页面、组件、可视交互)。为计划阶段追加 UI 设计章节要求(信息架构、交互状态、design token、可访问性),为实现与验证阶段追加前端验收纪律(交互三态测试、真实渲染冒烟证据)。

HarnessFlow build 阶段(TDD)。计划已批准(或档位 1 的 frame 已完成)、任务清单存在未完成任务时使用,也用于代码评审返回"需修改"后的修订。以红-绿-重构循环逐个完成任务,每次测试运行都必须通过 hf_gate.py run 落盘为证据日志。gate check --to build 未通过时不得使用,先回上游。

HarnessFlow frame 阶段(主链入口)。任何新特性、行为变更或缺陷修复开始时使用:把用户意图定格为一页 frame.md——意图、范围、风险档位(1 微改/2 标准/3 高危)及理由,并用 hf_gate.py run 建立环境基线(全量测试/构建能否真实运行)。不写需求细节、不做设计。产出的档位决定后续流程形态。

HarnessFlow plan 阶段。frame 完成且风险档位 ≥2 时使用:档位 2 产出一份 plan.md(需求+设计+任务清单),档位 3 先产出 spec.md 评审通过后再产出 design.md。也用于 plan 层评审返回"需修改"后的修订。档位 1 不使用本技能。前提不满足(gate check --to plan 失败)时回 hf-frame。

HarnessFlow 独立评审。plan 层工件(plan.md / spec.md / design.md)与实现代码完成后,必须经本技能给出落盘的评审结论才能推进。核心纪律:评审只承认 subagent 或全新会话,主会话冷读是降级路径且不得自我确认;代码评审者必须自己跑测试、自己读 diff。不修改被评审对象,只产出结论与 findings。

HarnessFlow ship 阶段。verify 完成(gate check --to ship 通过)后使用:逐条对照需求验收闭环、同步文档、收尾状态并向用户交付总结报告。gate check --to ship 未通过时不得使用。

HarnessFlow verify 阶段。build 全部任务完成、gate check --to verify 通过后使用。三层验证:运行时冒烟(真实运行最薄端到端路径并留证)、独立代码评审(评审者自己跑测试、读 diff)、机械门禁收口(gate check --to ship)。全部通过才进入 hf-ship。