zhjai

Use before declaring a long, multi-stage, or artifact-producing task done — prepare a completion CANDIDATE (not a completion). Enumerate touched user-visible surfaces, reconcile thread expectations against the plan, gather real evidence paths, and run the external gate; any uncovered surface, failed check, or review item forces blocked. Use at task wrap-up for long/high-stakes work. Do not use to declare completion yourself — only an external verifier grants `complete`.

Use when the user asks to set up / install / initialize the completion gate in their project (e.g. "set up the completion gate", "add the completion gate to this repo"). Runs the bundled deterministic scaffolder (scripts/init.sh) to create gate/, control/, state/, and a CI workflow, then tells the user what THEY must protect. Does NOT make the gate authoritative — branch protection + CODEOWNERS are the human's job and must not be done by the agent.

Use when the user sets a substantial, multi-step or long-running goal/task — naturally phrased, no prefix needed: "设计goal: ...", "goal: ...", "我的目标是...", "帮我完成这个任务/目标", "help me build/implement X", "做一个X". For work that produces a user-visible artifact (feature, page, report, export, copy/文案, schema, release, migration, experiment) — short length does not exempt it — or spans multiple files/steps. Do NOT use for typo fixes, one-line tweaks, one-off questions, lookups, or trivial edits — handle those directly unless the user explicitly asks for the gate. STEP 1: read this SKILL.md (path given) in full first. HARD RULE — the user stating a goal is NOT approval of scope or done; you only DRAFT criteria. Before ANY draft, outline, sample, placeholder, artifact, file edit, or command, reply with the acceptance criteria in plain language and STOP for the user's explicit OK. Do not preview or partially produce the deliverable before that OK. Only the external gate grants complete; never self-certify.

Use the moment evidence appears that should influence FUTURE execution and would be wrong for the worker to treat as authority on its own — a user correction/clarification ("actually…", "you skipped X again"), exposed drift (a check fails, a miss is pointed out), a proven repo pitfall, a "never do X" constraint, or an authority-relevant architecture constraint. Record it to the task's correction journal with a type, and add active ones to run_state constraints. Do not use for routine progress, or for things that belong in the repo (test commands, conventions, env) or built-in memory. Captures evidence when something exposes it; it does not make the agent notice drift on its own.

Use at task wrap-up, after a mistake, or on a postmortem to turn the correction journal and observations into review PROPOSALS — classify each candidate lesson by target tier (working-only / approved-lesson / policy / gate-candidate) and write a proposal note, without self-approving. Use when wrapping up, after something went wrong, or when a correction should persist. Do not grant a lesson authority — the worker proposes, a human promotes.

Use at the start or resume of any task (especially long or multi-session tasks) to load the lessonbook before acting — read the read-only control rules and approved lessons plus the task's working state, and surface the active constraints for this run. Use when starting/resuming work, picking up a long task, or when continuity across sessions matters. Do not use for one-shot factual lookups with no prior state.

Use when the user asks for a second opinion, independent/heterogeneous review, architecture red-team, cross-model critique (Codex/Claude/GLM/DeepSeek/Qwen/Kimi), review my plan, challenge this design, evidence-checked code/PR review, or multi-agent critique of a high-stakes plan, design, research claim, or bug root-cause. Not for simple lookups, formatting, or low-stakes tasks. On error_max_turns before any answer: mechanical failure, not a result — check if you boxed an open design review (needs broad read-only tools + ample turns) as bounded verification; retry ONCE with lossless moves only. Disabling the reviewer's tools, feeding excerpts, or narrowing scope are LOSSY — never automatic; STOP and ask the user. Keep packet AND output on disk (stage packet via stdin, redirect claude -p output to a file); read back only a structured digest preserving dissent, never the raw JSON; checkpoint each round to disk — else the prompt+output inflate your context, trigger compaction, and loop into re-running arena.

Use when comparing non-trivial options or making a design/architecture/experiment/product/research/strategy decision with real tradeoffs, unclear criteria, or commitment risk, and the user says things like "比较一下 A 和 B", "还有别的方案吗", "方案的利弊/权衡是什么", "这样设计好不好", "换个角度", "深入分析", "review my plan", "compare A vs B vs A+B", "what are the alternatives", "what are the tradeoffs", "is this the right approach", or "think this through". Also self-trigger when you only have A/B/A+B, the options are minor variants, success criteria or flip conditions are unclear, or one hidden assumption is deciding the answer; expand the option space and challenge the framing before choosing. Escalate to agent-arena when external evidence or an independent reviewer is needed. Not for simple lookups, formatting, translation, trivial naming/style choices, routine code review without design uncertainty, or when the user asked for a fast answer.

Use when running experiments or long/unattended tasks where a critical or ambiguous decision needs human input but the human may not be watching. Asks the human over a configurable transport — preferring delegation to your agent harness (OpenClaw/Hermes, channel-agnostic), else the official larksuite/cli or a Feishu webhook + file inbox — waits asynchronously, applies the reply if it arrives, and falls back (provisional / agent-arena / block) if it does not. On first use it runs a soft init and remembers the transport, target, timing, and fallback policy in a project config so you do not re-choose each session. Combines grill-all question routing + human-interruptible-unattended-runner fallback protocol.

Use when a CHEAP/small model (gpt5.4-mini, Claude Haiku, GLM-4.7-Flash, etc.) is the primary worker on a long or multi-step task and should escalate the hard parts to a STRONG senior model instead of guessing; invoke it as "kyl". Fires on OBJECTIVE tripwires, never on "do you feel unsure" (a weak model won't notice it is stuck): escalate at the START of a substantial/risky task to review the plan; when the SAME error survives 2 different fix attempts; before any IRREVERSIBLE or wide-blast action (schema/migration/delete/deploy/auth/new-dep); at a phase boundary; and before proposing done on a large/risky diff. Escalation goes through agent-arena (the mechanism); this skill is the POLICY of WHEN. Budget senior calls (they cost money) and send only a minimal evidence packet; the senior replies in a compact schema the worker can act on. If the senior also can't resolve it, escalate to the HUMAN — do not loop. Not for short tasks where just using the senior outright is cheaper, or trivial reversible steps.

Use when the user wants to package, publish, ship, or distribute an Agent Skill to GitHub — structuring the repo, getting the frontmatter spec-compliant, naming for discoverability, releasing with tags, pre-publish review, and getting it listed (skills.sh, directories). Complements an authoring/skill-creator skill (which writes the SKILL.md body); this takes a ready skill to a discoverable, published, spec-valid repo. Do not use for application code, non-skill docs, or general Git questions.

Use when the user wants to fact-check, verify, or ground existing content — checking generated text, an answer, a report, RAG output, documentation, or code for fabricated or unsupported claims. Triggers on requests like "verify these claims", "check for hallucinations", "are these citations / numbers / APIs real", "fact-check this before I publish", or "is this actually supported by the source". Extracts atomic claims, gathers evidence (web, source files, docs, RAG context), assigns a per-claim verdict with citations, and flags which claims to retract, qualify, or send back. This is SINGLE-agent claim verification grounded in evidence — NOT multi-agent debate over which decision is best (that is agent-arena). Do not use for pure opinions, creative content, or code logic already covered by deterministic tests.

Use when stress-testing a coding plan or design and the right answers may come from the human, project docs, codebase, or the web.

Use when running long unattended agent tasks, model training, evaluations, batch jobs, experiment loops, or autonomous coding sessions where work should continue without immediate user feedback but remain observable, interruptible, and adjustable after feedback arrives.