Create, validate, or clear the optional keel-handoff/v1 pointer override when human intent cannot be inferred uniquely.
中文简介正在准备中。当前显示原文说明。
查看安装方法安装前可以查看交给 AI 代理的指令内容。
Use this skill only when keel context is ambiguous or blocked because human intent cannot be inferred, or when the user explicitly asks to set or clear an override. HANDOFF is not session state or a startup summary, and it is not a durable follow-up owner.
The shift note that keel shift ready stores is a different thing: it hands working context to the role's next session and selects no task. HANDOFF overrides which task keel context selects. Neither holds task state; OpenSpec does.
Run keel context --json, then read the returned paths and the intended durable OpenSpec owner under openspec/changes/<change>/.
Write keel/HANDOFF.md with YAML front matter only:
---
schema: keel-handoff/v1
owner: openspec/changes/<change>/tasks.md#<task>
action: task-start
reason: Concise reason automatic inference is insufficient
---
The only fields are schema, owner, action, and reason. The owner must be a durable OpenSpec proposal, design, or tasks pointer. Supported actions are discuss, author, task-start, task-complete, and change-close.
Never copy task progress, expectation state, evidence details, risks, conversation summaries, active-backlog, or head=.... Those belong to OpenSpec, archive evidence, or an explicit discard reason.
Do not rewrite a pre-v1 HANDOFF heuristically. Preserve it byte-for-byte and report the explicit choices: migrate it manually to the v1 contract or run keel context --clear-handoff.
Clearing removes only the override; it does not modify the durable owner. Run keel context --clear-handoff --json, then verify normal inference resumes.
Lite mode does not create HANDOFF for routine cross-session continuity. Use the same optional override contract only when explicit human intent must supersede inference.
Validate the intended owner first, write or clear only the override, run keel context --json, and report the resulting source and next action.
还没有评价。欢迎分享你的使用感受。
无需登录即可发表。欢迎分享使用感受、提问，或说明在哪些环境下无法运行。
还没有评论。来写第一条吧。
Align explicit requirements, implicit expectations, non-goals, observable acceptance, evidence, and decision authority before OpenSpec specs and executable tasks finalize. Use when authoring or updating a proposal, design, specs, or tasks, or when a request hides a material product choice. Do not use for routine implementation of an already-authorized task, unrelated conversation, or facts the repository can answer.
中文简介正在准备中。当前显示原文说明。
Debug Keel agent command or validation failures under Keel's selected OpenSpec task contract. Use when `openspec-apply-change` or a selected task reports failed commands, failing tests, validation errors, stop decisions, or needs an evidence-bound failure report.
中文简介正在准备中。当前显示原文说明。
Export a local Markdown file that contains SVG diagrams to one Word (.docx) document, keeping the SVG as vector images with PNG fallbacks. Use when the user asks to export, convert, or deliver Markdown with SVG as Word or .docx. Do not use for other document formats, for Markdown without a Word request, or for editing an existing Word file.
中文简介正在准备中。当前显示原文说明。
Run the current agent's thin semantic consistency review after shared Keel Core gates and before task completion, sync, archive, or meaningful handoff.
中文简介正在准备中。当前显示原文说明。
Drive Keel agent test-first or evidence-first execution for a selected OpenSpec task. Use when a task needs software tests, hardware testbench, assertions, lint, new behavior proof, regression coverage, or red/green evidence before implementation.
中文简介正在准备中。当前显示原文说明。
Implement tasks from an OpenSpec change. Use when the user wants to start implementing, continue implementation, or work through tasks.
中文简介正在准备中。当前显示原文说明。