菜单
Single-task execution loop (plan, execute, verify, hand off). Keeps one agent on one unit of work with a structured context handoff so progress survives across sessions.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | focus |
| description | Single-task execution loop (plan, execute, verify, hand off). Keeps one agent on one unit of work with a structured context handoff so progress survives across sessions. |
| scope | universal |
| ported-from | focus command (task-tracker mechanics made generic) |
Enforces the discipline of plan → execute → verify → close on exactly one unit of work. The original is coupled to a specific task tracker; this version is tracker-agnostic: "the task" can be an issue, a tracker ID, a TODO entry, or a written description.
implement-review) delegates the implementation phase here.[task | "description"] [--no-close]
--no-close → run plan/execute/verify but leave finalization to the caller
(used when a wrapping workflow writes its own completion record or routes to
an external reviewer). Manual use rarely needs this.Read the task: description, acceptance criteria, linked context, and any prior rejection reason. If resuming, reconstruct where the last session stopped from the task's notes and the working tree. Do not start coding until you can state what "done" looks like.
Produce a short, concrete plan: the files you'll touch, the order, and how you'll verify each piece. Keep it proportional to the task; a one-file fix gets a two-line plan.
Implement the plan step by step. Commit in logical units. If context fills up, write progress to the task and hand off to a fresh session rather than continuing in a degraded window; a clean context that re-reads the plan beats a full one that's lost the thread.
Check the work against the acceptance criteria using the actual diff, not your memory of what you implemented. Run the project's tests. Fix and re-verify until the criteria are demonstrably met.
--no-close)Record what was done, key decisions, and a diff summary on the task. Mark it complete.
The point of focus is that work survives session boundaries cleanly: the task
record + commits are the durable state, so a new session running this skill can
pick up mid-task with no artifact clutter. Never leave half-state only in your
context window.
Index of this project's coding-practice rules — architecture, coding style, testing, security, git workflow, task management, context layering, anti-slop, performance, and language-specific rules. The thin always-on essentials live in .claude/rules/common/house-rules.md; the full per-topic detail ships under .claude/rules/reference/ and .claude/rules/<lang>/ and is read on demand. Invoke this skill when you need the project's standards for a task, then open the specific rule file it points to.
Thin methodology for end-to-end tests of critical user journeys — define journeys by risk, use semantic locators and condition-based waits, quarantine flaky tests with a tracked reason, and capture artifacts on failure. Use when adding or stabilizing E2E coverage; the e2e-runner agent applies it in depth.
Design rigorous evaluations and benchmarks for AI agents, developer tools, retrieval systems, and repository-scale automation. Covers task selection, contamination control, metric choice tied to engineering decisions, and statistical validity. Use when asked to design an eval/benchmark, critique an existing benchmark, choose metrics for an agent or RAG system, or decide whether a measured improvement is real. NOT for running an existing performance-benchmark suite or a per-feature acceptance checklist, or one-off model spot-checks.
Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree one at a time. Use for ambiguous or complex collaborative specs before any code is written.
Decision framework for choosing between regex and LLM when parsing structured text — start with regex, add LLM only for low-confidence edge cases. Use when parsing quizzes, forms, invoices, or documents with repeating structure and cost matters.
Review a repository for long-term architectural leverage rather than code quality — system structure, module boundaries, dependency graph, coupling, and drift. Produces a ranked set of highest-ROI improvements with evidence, effort, and risk. Use when asked to review the architecture, assess a codebase's structure/design, find where complexity is concentrated, or decide what to refactor next. NOT for style, naming, formatting, or line-level bugs (use a code-review skill for those).