garage-agent

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 verdict、或被指定为 reviewer subagent 执行设计评审的场景。不适用于需继续写或修设计（→ hf-design）、需拆任务或编码（→ hf-tasks）、阶段不清或证据冲突（→ hf-workflow-router）。

适用于需求规格已批准但设计尚未批准、或设计评审返回需修改/阻塞需修订的场景。不适用于规格仍是草稿/待批准（→ hf-specify）、设计已批准需拆任务（→ hf-tasks）、仅需执行设计评审（→ hf-design-review）、阶段不清或证据冲突（→ hf-workflow-router）。

适用于 discovery 草稿已完成需要正式 review verdict、或被指定为 reviewer subagent 执行 discovery 评审的场景。不适用于需继续写 discovery 正文（→ hf-product-discovery）、已明确进入 formal spec（→ hf-specify）、或阶段不清 / 证据冲突（→ hf-workflow-router）。

适用于已通过 hf-regression-gate、即将进入 hf-completion-gate、需要为本任务/本 feature 引入的对外可见行为变化判定相关用户文档（仓库根 README 产品介绍段、模块层 README、公共 API doc / OpenAPI / docstring、i18n 副本、CONTRIBUTING / onboarding doc、用户文档站 source）是否同步刷新的场景。不适用于尚未通过 hf-regression-gate（→ 上游）、纯 prose feature 但 reviewer 误以为强制 lint 工具链、阶段不清或证据冲突（→ hf-workflow-router）。

适用于产品发现或规格阶段存在低 confidence、高风险或 Blocking 的关键假设，需要一次最小可验证 probe 再决定是否推进主链。不适用于无假设驱动的纯澄清（→ hf-specify）、需新起 discovery（→ hf-product-discovery）、进入正式实现（→ hf-test-driven-dev）、阶段不清（→ hf-workflow-router）。

Use when completion gate already allows closeout and the remaining work is state/doc/release-note closure, either for the current completed task or for the whole workflow cycle.

Use when an authoring artifact (spec / design / tasks) draft is complete and the author wants to surface implicit assumptions, AI slop, missing acceptance criteria, or unaddressed edge cases BEFORE submitting to the corresponding Fagan review. Not a review node (does not produce verdict); not a substitute for `hf-spec-review` / `hf-design-review` / `hf-tasks-review`; not for code review (use `hf-code-review`).

适用于线上/紧急缺陷需要修复、用户要求 hotfix 分析、缺陷需要复现路径和最小修复边界的场景。不适用于写/修代码（→ hf-test-driven-dev）、需求变更/范围调整（→ hf-increment）、阶段不清（→ hf-workflow-router）。

适用于用户明确要求增删改需求/范围/验收/约束、hf-workflow-router 判定属于 increment 分支的场景。不适用于实现缺陷修复（→ hf-hotfix）、继续实现（→ hf-test-driven-dev）、阶段不清/证据冲突（→ hf-workflow-router）。

适用于仍在判断产品问题、目标用户、wedge、关键假设或 probe 方向，尚未收敛到 formal spec 的场景。不适用于已明确进入 spec/design/tasks（→ hf-specify / hf-workflow-router）、或只需评审已有 discovery 草稿（→ hf-discovery-review）。

适用于 traceability review 通过后需回归验证、用户要求 regression check 的场景。不适用于判断任务完成（→ hf-completion-gate）、状态收尾（→ hf-finalize）、阶段不清（→ hf-workflow-router）。

适用于把多个已 closed 的 feature/iteration 汇总成 vX.Y.Z 工程级发版（版本切片 + 全量回归 + 发布文档聚合）。当用户表达"切版本/出 release/打 tag/发版本号"时使用。不适用于单 feature closeout（→ hf-finalize）、上线/部署/监控/回滚（不在本 skill 范围；由项目自身的 ops 流程承担）。

适用于规格草稿已完成需正式 review verdict、reviewer subagent 被派发执行规格评审的场景。不适用于缺规格草稿或只需继续写（→ hf-specify）、阶段不清或证据冲突（→ hf-workflow-router）、已有已批准规格需设计评审（→ hf-design-review）。

适用于尚无已批准规格、现有规格仍是草稿、或规格被 hf-spec-review 退回需修订的场景。不适用于已有批准规格（→ hf-design）、需要任务计划（→ hf-tasks）或阶段不清（→ hf-workflow-router）。

适用于任务计划草稿需正式 review verdict、任务计划被退回需复审、或用户显式要求评审任务计划的场景。不适用于写/修任务计划（→ hf-tasks）、阶段不清（→ hf-workflow-router）。

适用于规格与设计都已批准、需要在编码前产出可评审任务计划的场景。不适用于规格/设计未稳定（→ hf-specify / hf-design）、任务计划已批准需进入实现（→ hf-test-driven-dev）、或阶段不清（→ hf-workflow-router）。

适用于任务计划获批后的单任务实现、受控 hotfix 修复实现、review/gate 回流修订。不适用于任务计划未批准（→ 上游）、hotfix 无复现路径（→ hf-hotfix）、需并行多任务（→ hf-workflow-router）。

适用于实现完成后判断测试质量、code review 前的测试评审、用户显式要求评审测试的场景。可吸收已有缺陷模式记录或项目级风险清单作为风险输入，但不以其存在为前置。不适用于写/修测试（→ hf-test-driven-dev）、评审代码（→ hf-code-review）、阶段不清（→ hf-workflow-router）。

适用于 code review 通过后判断追溯完整性、用户显式要求追溯评审的场景。不适用于评审代码质量（→ hf-code-review）、评审测试质量（→ hf-test-review）、阶段不清（→ hf-workflow-router）。

适用于规格含 UI surface（页面/组件/交互/前端）且设计未批准、或 hf-ui-review 返回需修改/阻塞需修订的场景。不适用于纯后端/脚本/API-only（不激活本节点）、架构与 API 契约（→ hf-design）、规格仍是草稿（→ hf-specify）、设计已批准需拆任务（→ hf-tasks）、只需执行 UI 评审（→ hf-ui-review）、阶段不清或证据冲突（→ hf-workflow-router）。

适用于 UI 设计草稿已完成需要正式 review verdict、或被指定为 reviewer subagent 执行 UI 设计评审的场景。不适用于需继续写或修 UI 设计（→ hf-ui-design）、评审架构/技术设计（→ hf-design-review）、需拆任务或编码（→ hf-tasks）、阶段不清或证据冲突（→ hf-workflow-router）。

Use when architect explicitly opts into fast lane via 'auto mode' / 'ultrawork' / 'do not stop' keywords or features/<f>/README.md Metadata `Execution Mode: auto`. Not the default mode; not a review/gate skip mechanism. NEVER skip Fagan review verdicts, gate verdicts, approval-artifact disk writes, closeout pack completeness, or Hard Gates 'stop on unclear standard' clauses (see Hard Gates section for the 5 enumerated non-compressibles per ADR-009 D2).

Use when an `hf-test-driven-dev` task completes and per-task delta must be appended to the feature-level cross-task knowledge notebook; when `hf-workflow-router` needs to inject wisdom summary into the next handoff; when `hf-completion-gate` needs to verify notebook completeness before closeout. Not for review verdicts (use `hf-*-review`); not for closeout pack assembly (use `hf-finalize`); not a substitute for repo-level ADR (use `docs/decisions/`).

适用于用户说"继续/推进"需判断当前节点、review/gate 刚完成需恢复编排、route/stage/profile 不清、工件证据冲突、需判断是否进入 hotfix/increment 的场景。不适用于新会话 family discovery（→ using-hf-workflow）。

适用于新会话不确定从哪进入 HF workflow、用户用 /hf-* 命令表达意图、需判断 direct invoke 还是 route-first 的场景。不适用于 runtime 恢复编排（→ hf-workflow-router）、已在 leaf skill 内部（→ 继续当前 skill）。

Use when the user wants a practical weekly AI roundup from recent X/Twitter posts, especially from a fixed source roster, with a 7-day window, real tweet links, and a Chinese markdown report layered as Priority 1 必看 / Priority 2 值得抄方法 / Priority 3 值得建立认知, optionally with candidate supplements. Not for generic AI news, benchmark recaps, infrastructure updates, funding coverage, or paper-only summaries.

生成"电子杂志 × 电子墨水"风格的横向翻页网页 PPT（单 HTML 文件），含 WebGL 流体背景、衬线标题 + 非衬线正文、章节幕封、数据大字报、图片网格等模板。当用户需要制作分享 / 演讲 / 发布会风格的网页 PPT，或提到"杂志风 PPT"、"horizontal swipe deck"、"editorial magazine"、"e-ink presentation"时使用。

Use when creating new skills, editing existing skills, or verifying skills work before deployment

Use when the user wants to write a blog post (技术博客或思考随笔) for their personal blog. Triggers on: 写博客、写篇文章、blog post、写一篇关于XX的文章、继续写博客系列. Not for 公众号长文 (→ khazix-writer), not for 深度研究报告 (→ hv-analysis), not for 短内容 (小红书/推特/朋友圈).

横纵分析法（Horizontal-Vertical Analysis）深度研究Skill。由数字生命卡兹克提出，融合了索绪尔的历时-共时分析、社会科学的纵向-横截面研究设计、商学院案例研究法与竞争战略分析的核心思想。 当用户想要系统性研究一个产品、公司、概念、技术或人物时使用。核心是双轴分析：纵轴追踪从诞生到当下的完整生命历程（以叙事故事呈现），横轴在当下时间截面上与竞品/同类进行系统性横向对比，最后交叉两条轴产出独到洞察。最终产出一份排版精美的PDF研究报告。 触发词包括但不限于：横纵分析、研究一下、帮我分析、深度研究、做个研究、调研一下、竞品分析、帮我看看这个东西怎么样、这个产品/公司/概念是怎么回事、帮我摸清楚、帮我搞懂、帮我做个deep research。 即使用户只是说"帮我了解一下XX"或"XX是什么来头"，只要上下文暗示需要系统性的深度研究（而非简单的概念解释），都应该触发。也适用于用户丢来一个产品名、公司名、技术名词说"帮我研究一下这个"的场景。 不要用于简单的名词解释（用户只是问"XX是什么"）、不要用于公众号写作（那个用khazix-writer）、不要用于纯标题摘要生成（用wechat-title）。

Use when verifying that Garage packs are correctly installed in the host. Not for actual workflow tasks; this is a sanity-check skill.