From domain-chassis
This skill should be used when the user asks to "work the gate", "execute the gate", "run the gate", "work Q3", "run Q3", "do Q3", "execute Q3", "work through the gate", "gate work", "task me with the gate", "resume the gate", or mentions executing against an existing gate file, working through gate checkpoints, resuming a partially-completed gate, or validating against a gate document. Provides the gate execution methodology for working through an operator-authored validation plan.
npx claudepluginhub basher83/domain-chassis --plugin domain-chassisThis skill uses the workspace's default tool permissions.
You are the executing agent. This skill loads a gate document into your context and you work through it directly. There is no subagent dispatch — you read the gate, adopt the framing below, and do the work.
Guides Next.js Cache Components and Partial Prerendering (PPR) with cacheComponents enabled. Implements 'use cache', cacheLife(), cacheTag(), revalidateTag(), static/dynamic optimization, and cache debugging.
Guides building MCP servers enabling LLMs to interact with external services via tools. Covers best practices, TypeScript/Node (MCP SDK), Python (FastMCP).
Generates original PNG/PDF visual art via design philosophy manifestos for posters, graphics, and static designs on user request.
You are the executing agent. This skill loads a gate document into your context and you work through it directly. There is no subagent dispatch — you read the gate, adopt the framing below, and do the work.
The operator provides a gate reference: a Q-number (e.g., "Q3"), a filename (e.g., "Q3-gate.md"), or a path. Resolve to a *-gate.md file at the workspace root.
## Gate Status: CLEARED. If the gate is already cleared, tell the operator and stop. Do not re-execute a cleared gate without explicit confirmation.## Gate Review section with Verdict: PASS. If the section is missing or the verdict is not PASS, stop and tell the operator the gate needs review before execution. The gate lifecycle is plan → review → work — executing an unreviewed gate wastes effort on work that may be blocked at clearance.# Q{n} Gate: title and before the first ## heading. This is what success means.QUEUE.md at the workspace root. Find the matching Q-item for additional context on intent and scope. If no match, proceed without it — the gate file is self-contained.${CLAUDE_PLUGIN_ROOT}/references/anti-pattern-registry.md. When a checkpoint carries an anti-pattern tag (`{AP-nn}`), understand what failure mode that checkpoint guards against — this informs verification rigor. A checkpoint tagged {AP-07} (Vacuous Green) means verification must produce substantive evidence, not just confirm structural existence. A checkpoint tagged {AP-10} (Recursive Defect) means the verification itself should be audited for the defect class being checked. The tag is a signal, not a procedure — use judgment on how the anti-pattern awareness shapes verification depth.After completing Steps 1 and 2, adopt this operational context and begin working through the gate:
The gate file is an operator-authored validation plan. You did not create it. It is not code you can compile or test in that manner. It is a structured set of checkpoints that must be satisfied through real work — executing commands, verifying outputs, producing artifacts, and confirming results.
Your completion criteria: you must be able to claim the extracted completion criteria when done. Every checkpoint in the gate serves that claim. Work through them in order, respecting any stated dependencies between phases.
How to work the gate:
[ ] to [x] in the gate file.[x], the gate file must contain the concrete evidence that proves it — command output, file contents, counts, or results quoted directly below the checkpoint. A checkpoint marked [x] without artifact evidence documented in the gate file is not completed. Either produce the evidence or leave the checkpoint unchecked.[x]. Explain what blocked it and continue with unblocked checkpoints. The operator will decide how to proceed.[~] and document the justification inline. Bypasses are decisions — they require reasoning.## Gate Errata section at the end.## Gate Status: CLEARED, verify all three conditions. If any condition fails, the gate cannot clear — halt and report to the operator. This is fail-closed: ambiguity on any condition is a halt, not a pass.
[x] (not all bypassed, deferred, or blocked).[x] has artifact evidence documented inline in the gate file (no prose-only completions).## Gate Review section exists in the gate document with Verdict: PASS, confirming the gate was reviewed and found adequate for execution. A missing review section or Verdict: FAIL blocks clearance.QUEUE.md at the workspace root. The queue tracks live operational state — a cleared gate is done, not active. If no matching row exists, skip silently.## Gate Status: CLEARED section with the validation date and a summary sentence stating what was proven. The CLEARED stamp is the seal on the complete contract — checkpoints, review, and delivery proof. Do not stamp CLEARED before the exit sequence is complete.gates/ (create the directory if it doesn't exist). This is the final step. Nothing follows it. The gate file is the enforcement contract; the archive move releases the contract.
A cleared gate with uncommitted changes, an unbumped version, or unreachable consumers is delivery without deployment.The operator is here to assist you, not as a crutch. You may work toward the completion criteria in whatever way you deem appropriate. If you are blocked and cannot unblock yourself, ask. Otherwise, proceed.
${CLAUDE_PLUGIN_ROOT}/skills/gate-plan/references/gate-template.md — Gate document conventions: section ordering (phases, errata, notes, status), checkpoint ID format, bypass markers, anti-pattern tags, and verification method placement.${CLAUDE_PLUGIN_ROOT}/references/anti-pattern-registry.md — Named failure modes catalog. Read during Step 2 to understand what failure modes tagged checkpoints guard against, informing verification rigor.