菜单
Use when the user explicitly asks the host to keep working until a verifiable result, fix until green, converge without stopping, monitor through completion, or operate within a stated budget; do not use for ordinary one-shot work or infer persistence from task difficulty.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use when a proposed change has major external impact or the user explicitly asks to be grilled, stress-tested, questioned before action, or to save or resume a Grill discussion; do not use for ordinary clarification, settled trade-offs, mechanical details, negative intent, quoted examples, or maintenance.
Use when a failure, crash, flake, regression, or unexpected result has an unknown cause that prevents a safe fix; do not use when the cause and narrow fix are already clear, for general fact finding or design, or when the user asks only for review.
Use when the user asks to design, architect, choose an approach, or resolve a material product, workflow, API, or system trade-off before implementation and the direction is not yet settled; choose standard or adversarial search from the request and evidence; do not use for discussion-only brainstorming, external fact lookup alone, unknown-cause failures, a plan for an already chosen direction, clear implementation, or review.
Use when the requested result is direct evidence about local code, files, configuration, logs, tests, history, artifacts, or runtime state; do not use for external or current-source research, ordinary local reads needed during implementation, unknown-cause diagnosis, design, or mutation.
Use when the user asks to initialize, audit, repair, migrate, or slim project-local AI instructions, Teamwork context or memory, project routing, or local CodeGraph policy inside a named project; do not use for global skill, agent, policy, notification, plugin, or host installation and refresh.
Use when the user asks for an implementation plan, task breakdown, checklist, roadmap, or handoff for a direction and contract already selected, or a host requires that execution plan; do not use to brainstorm or settle product/architecture choices, research external facts, diagnose failures, review a candidate, or execute changes.
| name | teamwork-goal |
| description | Use when the user explicitly asks the host to keep working until a verifiable result, fix until green, converge without stopping, monitor through completion, or operate within a stated budget; do not use for ordinary one-shot work or infer persistence from task difficulty. |
Apply persistence around the user's actual task. Goal is a modifier, not a separate research, design, planning, debugging, implementation, or review stage. It never broadens scope or effect authority. Ordinary natural discussion or brainstorming does not activate Goal unless the user asks for persistence.
Record objective, direct success signal, scope, protected boundaries, invariants,
supplied budget, and hard stops. Inspect discoverable state first; ask only for a
missing user-owned objective, success, scope, or authority value that prevents
safe progress. Root alone asks users through the current host's native surface;
leaf roles return proposed questions or blockers to Root. Answers do not expand
authority. Do not invent iteration, time, or token budget.
If the user says no files, off-record, read-only, no writes, or equivalent
and no host-native durable state satisfies it, Goal fails closed before promising
persistence; deliver no continuity claim.
Create durable Goal state at entry, before attempt one, through the host-native
mechanism or, for an initialized project, Writer calling the Goal artifact
transaction. Writer runs discussion-transaction.py goal-inspect --project-root <project> and retains its revision, runs discussion-transaction.py goal-schema <start|attempt|close>, then runs discussion-transaction.py goal-apply --project-root <project> --request <file> with that revision and reads back. The transaction derives
docs/teamwork/reports/YYYY-MM-DD-<slug>-goal.md; never invent or hand-author it.
Writer is disposable compute and only the caller; the transaction is the sole
filesystem writer and owns destination, compare-and-swap, journal recovery,
atomic apply, and readback. Record objective, success signal, invariants, scope,
budget, hard stops, status, and attempts. If interrupted before apply begins or
state is otherwise unavailable, stop and report the continuity gap without a
durable claim. Recover only from surviving workflow evidence. Preserve an exact
user-supplied token budget; never invent one.
For each attempt, identify the single current unmet claim and use only the role whose method matches that blocker:
Do not repeat an unchanged command, hypothesis, fix, or review loop. A new attempt needs a strategy delta grounded in new evidence or relevant change. Use planning only when scope or criteria change; use review only when requested or required by a named risk gate.
Mark the durable goal complete only when the real success signal passes and every named protected boundary is satisfied. Continue after an ordinary failure while a safe, evidence-backed different action remains. Stop for missing authority or required input, destructive or security risk, exhausted user budget, protected-boundary conflict, unavailable resources, or genuine no-progress. Follow the host's status semantics when recording completion or blockage, and never report success from a proxy check. Goal completion notifications are available only on Codex (hooks) and Claude Code; on Cursor the user polls manually.
Every durable Goal entry, attempt, or standalone report uses a bounded brief/packet: purpose/audience, facts/sources, frozen decision/status, style/structure, exact path/consumer, preserve/forbid, objective, attempts, evidence, blocker, and next strategy. Writer handles standalone prose and may only call the native mechanism or Goal transaction for managed artifacts. Missing Writer, brief, authority, path, consumer, or registration blocks; no Root, Worker, or other role fallback writes it.
