// Use when picking up a user-gate task OR when a hook demands re-validation. Runs the "do I know HOW?" self-check; if the HOW is clear, executes the verification and posts evidence; if not, hands off to specifying-gates. Kept deliberately separate from executing-plans so that without the opt-in hook, the main flow stays untouched.
| name | checking-gates |
| description | Use when picking up a user-gate task OR when a hook demands re-validation. Runs the "do I know HOW?" self-check; if the HOW is clear, executes the verification and posts evidence; if not, hands off to specifying-gates. Kept deliberately separate from executing-plans so that without the opt-in hook, the main flow stays untouched. |
User-gate enforcement is an opt-in flow. When the opt-in hook is not registered, executing-plans runs unchanged — no extra checks, no extra context, no extra questions. When the hook IS registered, it routes user-gate tasks through this skill. Keeping the decision logic in a separate skill means:
executing-plans stays short and readable.Any one of:
json:metadata has "userGate": true or whose tags contains "user-gate" AND the opt-in hook is active (see the README for how to detect this — if you were invoked via /gate-check, the hook is active by definition)./gate-check <task-id>./gate-check <task-id>.If none of these apply, return to executing-plans without running this skill.
Announce at start: "I'm using the checking-gates skill to verify Task N's acceptance criteria."
TaskGet <task-id> — read the full description.json:metadata fence.requiresUserSpecification: true → go to Step 2 path A.verifyCommand + every acceptanceCriteria names an observable (sensor, HTTP status, file, log line, entity) → go to Step 2 path B.verifyCommand → go to Step 2 path A.Path A — HOW is ambiguous. Invoke specifying-gates (or tell the user to run /specify-gate <task-id>). Stop. Let that skill lock down the mechanics. When it returns, re-enter this skill from Step 1.
Path B — HOW is clear. Continue to Step 3.
Run the verifyCommand (or dispatch the subagent with subagentBrief). Capture exact output.
Map each acceptanceCriteria entry to an observable in the output.
Post one block of text back to the user, using EXACTLY this format (the sibling hooks key off the AC: + PROVEN BY markers):
Gate: <task subject>
AC: <criterion 1> — PROVEN BY <command or excerpt of output>
AC: <criterion 2> — PROVEN BY <...>
...
If every criterion passed → TaskUpdate status=completed.
If any criterion failed → look up failurePolicy:
"stop-plan" → leave the task in_progress, surface the failure to the user, stop."reopen-continue" → leave the task in_progress, move to the next unblocked task."log-continue" → post the failure inline, mark completed anyway, continue.A criterion has a clear HOW when all three hold:
If any of the three is missing for any criterion, HOW is NOT clear → Path A.
Err on the side of Path A. Inventing a HOW silently is the exact failure this flow exists to prevent.
EnterPlanMode or ExitPlanMode./specify-gate — don't walk around it./gate-check slash command.specifying-gates (Path A).executing-plans (or wherever it was invoked from) after TaskUpdate.skills/shared/task-format-reference.md for metadata schema.Use when you have a spec or requirements for a multi-step task, before touching code
Use when you have a written implementation plan to execute in a separate session with review checkpoints
Use when a user-gate task has requiresUserSpecification=true OR the agent's "do I know HOW?" self-check returns no. Locks down verification mechanics through a short AskUserQuestion sequence and writes the answers back into the task's metadata. Does NOT run the verification itself.
Use when executing implementation plans with independent tasks in the current session
Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes
Use when starting any conversation - establishes how to find and use skills, requiring Skill tool invocation before ANY response including clarifying questions