From idc
Use to fire IDC's one human gate — requirements admission. Think uses it at the end of Think to gate a new PRD+TRD on the Think PR; the Recirculator reuses it when backflow needs a requirements change. Supports sync-or-async approval and draft-until-merge.
How this skill is triggered — by the user, by Claude, or both
Slash command
/idc:idc-gate-issueThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
The requirements gate. This is the **only** gate in IDC — everything else flows autonomously and
The requirements gate. This is the only gate in IDC — everything else flows autonomously and
automerges when green (WORKFLOW.md §2). It fires when an idea's requirements are admitted: a
PRD change (user-facing what, always gated while gating.prd: on) and/or a TRD change
(the technical how — the spec layer — gated when gating.trd: on). Think fires it at the
end of Think on the Think PR; the Recirculator reuses this identical mechanism when
backflow needs a requirements change. Nothing else in the system asks the operator for permission.
The gate has two coupled parts:
operator-action issue carrying the plain-terms decision,
so the operator can approve from the GitHub web UI on their phone, and so later runs can detect
the approval without anyone watching the PR.Approval is sync or async: the operator may approve in-session (merge now), or leave the Think PR open and approve later (you, a teammate, or a coding agent reviewing on GitHub). A saved-but- unapproved idea is just an open Think PR; nothing downstream proceeds until it merges.
A plain-terms decision an operator (a non-engineer) can make from a phone:
TITLE: [operator-action] Requirements change — <one plain phrase: what the app will do differently>
WHAT YOUR APP WILL DO DIFFERENTLY
<2–5 sentences in plain terms. No code, no file paths, no jargon. The user-facing
behaviour change only — what someone using the product would notice.>
PROPOSED REQUIREMENTS CHANGE (PRD / TRD)
<the proposed PRD/TRD diff: inline fenced diff if short, else a link to the diff in the
Think PR (or the recirculation PR)>
TO APPROVE: merge the Think PR. Merge = admission — the idea enters the pipeline and Plan
decomposes it. (Closing this issue or commenting does NOT admit: the PRD/TRD live in the Think
PR and only merging it lands them.) To reject: comment what to change and leave the PR open.
Gates: <the consideration pointer (at Think) or the affected work issues (at the Recirculator)>
Label it operator-action (the gate label) so it is findable. The body is plain terms +
the diff + a pointer to the Think PR — nothing else.
All tracker ops route through idc:idc-tracker-adapter (createTicket, setField,
link, comment, query) — never hard-code github vs filesystem semantics; the
adapter reads the backend from config and dispatches. An outside or cloud agent runs these
four steps over the plain tracker API.
1 — Open the Think PR + the gate. Open the (draft) Think PR carrying the PRD/TRD diff, then
createTicket the gate issue with the plain-terms body above; setField Status=Todo and the
operator-action label. One gate issue per admission, no matter how much it gates.
2 — Chain what's pending. Block what must wait on admission, via setField Status=Blocked
link kind=blocks from the gate issue:Stage = Consideration): it is pending admission
while the Think PR is open.Todo and
flows.
Record the chained ids in the gate body's Gates: line.3 — Notify the operator. Send one push notification (see below). Never block the run on delivery.
4 — Detect admission + unblock (sync now or on a later run). Admission is the Think PR
merging — the single, durable block-clearing signal. A closed gate issue or an approved
comment is not admission: it records intent, but the PRD/TRD stay draft until the Think PR
merges, so a closed-but-unmerged gate must not unblock anything — else Plan/Autorun would
proceed against requirements that are still only draft in an open PR (the draft-until-merge
contract). /idc:think (in-session), /idc:plan, /idc:recirculate, and /idc:autorun re-check
open gates at the start of a run: query for operator-action issues and confirm the linked
Think PR has merged. Only once it has, for each thing the gate blocked: remove the blocks link
via the adapter and setField Status=Todo. The admitted consideration is now Plan's to
decompose; chained work builders claim on the next cycle. A gate whose Think PR is not yet
merged (still open, even if the issue was closed) → leave the chain Blocked and move on; the
run never waits on the operator.
Use whatever notification surface the environment provides, in this order, and degrade silently — notification being unavailable must never fail the run:
cmux notify CLI, if present on PATH — send a one-line "Requirements approval needed:
(gate issue #<n>)".
PushNotification tool/hook, if available in the harness.The operator merging the Think PR (or approving from the GitHub web UI) is the real mechanism; the push is only a convenience nudge.
/idc:think or
/idc:recirculate) and only referenced here; this skill writes the gate issue, not the PRD/TRD.idc:idc-tracker-adapter; this skill holds no
backend-specific logic.Guides creation, editing, and verification of skills for AI coding agents using test-driven development with subagent scenarios. Use when authoring or debugging skills.
npx claudepluginhub llamallamaredpajama/idc-workflow --plugin idc