ywc-confidence-gate

name: ywc-confidence-gate description: >- (ywc) Use when you need to gate an implementation start — before any non-trivial implementation, before invoking ywc-code-gen / ywc-sequential-executor / ywc-parallel-executor, or before committing to a design path with material rework cost. Scores readiness across five dimensions (scope clarity, architecture compliance, evidence quality, reuse verified, root cause identified) and gates the decision with PROCEED (≥90) / REVIEW (70–89) / STOP (<70). Triggers: "confidence check", "confidence gate", "ready to implement", "should I proceed", "is this ready", "준비 됐어", "구현 시작해도 돼", "confidence 점검", "착수 준비", "実装着手", "実装に進んで良いか", "確信度チェック", "ywc-confidence-gate". Do not use for completion verification (use ywc-verify-done — that gates the claim, this gates the start), spec quality review (use ywc-spec-validate), implementation review (use ywc-impl-review — that scores findings, this scores readiness), or brainstorming intent (use ywc-brainstorm). category: discipline phase: pre-implementation requires: []

ywc-confidence-gate

Announce at start: "I'm using the ywc-confidence-gate skill to score readiness across five dimensions before implementation begins."

This skill is the canonical pre-implementation gate. It exists because every implementation skill (ywc-code-gen, ywc-sequential-executor, ywc-parallel-executor) starts producing code immediately when invoked — and the cost of code produced from a half-understood spec is borne later by ywc-impl-review, CI, or production. A 5-minute confidence score catches the same defect classes that a 30-minute re-plan and a 2-hour debug session would catch — at a fraction of the cost.

The scoring rubric and band definitions are shared with ywc-impl-review and other downstream skills via ../references/confidence-gate.md. This skill does not redefine the rubric; it applies it at the pre-implementation entry point.

The Iron Law

NO IMPLEMENTATION WITHOUT AN EXPLICIT CONFIDENCE SCORE AND BAND DECISION

If the aggregate score is below 90 and the band is REVIEW or STOP, implementation does not begin until the weakest dimension has been raised (or the user has explicitly accepted the residual risk and the agent has surfaced what cannot be raised). "I'll figure it out as I go" is not a band decision — it is the failure mode this skill exists to prevent.

Rationalization Defense

When tempted to skip the gate, check this table first:

Violating the letter of this discipline is violating the spirit. The rubric is shared with downstream skills precisely so that scores remain comparable — a score from this skill must mean the same thing as a score from ywc-impl-review.

The Five Dimensions

Read ../references/confidence-gate.md for the canonical rubric definition. The summary below is for quick reference; the reference file is the authoritative source.

Score each dimension 0–100. Aggregate is the weighted sum, rounded to the nearest integer.

The Decision Bands

The aggregate sets a tentative band; the single-dim override (below) may then drop it one level.

Single-dim < 50 override: after the aggregate sets the tentative band, if any single dimension scored below 50, drop the band by one level — PROCEED → REVIEW, REVIEW → STOP (STOP is already the floor). It is always a one-level drop, never a jump straight to STOP: an aggregate ≥ 90 with one dimension at 45 lands on REVIEW, not STOP. A dimension at exactly 50 does not trigger the drop. This prevents one strong dimension from masking a fatal weakness, and matches the canonical rule in ../references/confidence-gate.md §3.

A separate, stricter rule applies only when a skill designates a dimension as required via the confidence-gate.md §4 profile: a required dimension scoring < 70 forces STOP regardless of aggregate. This gate does not designate required dimensions for its own runs, so only the < 50 override above applies here.

Workflow

Step 1: Establish the work item

State in one sentence what is about to be implemented. If the sentence requires three or more clauses, the work item is too large — split it via ywc-task-generator before continuing.

Step 2: Score each dimension explicitly

For each of the five dimensions, do all of the following:

1. Read the one-sentence test (above).
2. State the evidence supporting the current score in 1–2 lines — file paths, command outputs, doc references, or the absence of those.
3. Score 0–100. Be honest; rounding up is the defeating move.

Use references/pre-implementation-checklist.md for the per-dimension probe questions.

Step 3: Compute the aggregate

aggregate = (scope × 0.25)
          + (architecture × 0.25)
          + (evidence × 0.20)
          + (reuse × 0.15)
          + (root_cause × 0.15)

Round to the nearest integer.

Step 4: Apply the single-dim override

If any dimension scored below 50 (< 50), drop the band by one level: PROCEED becomes REVIEW; REVIEW becomes STOP (already the floor). A dimension at exactly 50 does not trigger the drop, and the drop is never more than one level — an aggregate-PROCEED with a sub-50 dimension lands on REVIEW, not STOP.

Step 5: Surface the report

Print the report in the canonical format below (this is the same shape ywc-impl-review uses for post-implementation confidence — by design, so scores stay comparable).

Step 6: Act on the band

• PROCEED: invoke the implementation skill (ywc-code-gen, ywc-sequential-executor, etc.) immediately. Carry the score into the executor's per-step report.
• REVIEW: present 1–3 alternatives or open questions; wait for user response or trigger the Advisor Pattern for the weakest dimension. Do not begin implementation in this turn.
• STOP: surface the failing dimensions and route back to the appropriate upstream skill (see §Decision Bands above). Do not begin implementation. When the failing dimension qualifies as a Trigger condition below, run Step 7 before handing back.

Step 7: STOP-band Advisor Dispatch

Trigger condition: band == STOP AND at least one dimension among (architecture / scope / evidence / reuse / root cause) scored < 50. STOP without a sub-50 dimension routes directly to the upstream skill listed in §Decision Bands without an advisor pass.

This step adopts the advisor dispatch pattern established by ywc-plan Step 3.5 (Architectural Advisor Gate) and ywc-incident-postmortem Step 4.5 — bounded payload, single dispatch, verdict-as-evidence, re-gate or handoff. See ../references/advisor-pattern.md for the canonical pattern definition.

5-step procedure:

1. Frame the gap — in 1–3 sentences, state the specific decision blocked by the failing dimension. "What would I do differently with a definitive answer?" If the answer is "nothing", do not dispatch.
2. Bounded payload — assemble the minimal context the advisor needs: the failing dimension name + score + evidence line, the current work item one-liner from Step 1, and any spec excerpt or repo snippet directly relevant. Hard cap: ≤ 200 lines. The payload is the gap, not the entire context.
3. Dispatch the advisor — invoke the routing target from the table below. Pass the bounded payload + the framed decision. Expect a verdict in the format proceed | reconsider with refinements | needs more context.
4. Record the verdict — paste the verdict (or its summary if long) under the dimension's evidence line. The verdict becomes part of the dimension's evidence for the re-gate.
5. Re-run the gate or hand off — re-score the failing dimension using the verdict as new evidence. If the dimension now ≥ 70, re-run aggregate + Step 4 override; the band may transition to REVIEW or PROCEED. If still < 70, hand off to the upstream skill listed in §Decision Bands, carrying the verdict as additional context.

Routing target table (per failing dimension):

Scope dimension < 50 does NOT have an advisor target — STOP on scope routes back to ywc-plan (Scale assessment) or ywc-brainstorm (intent surfacing) via §Decision Bands directly; an advisor cannot disambiguate scope without first knowing what the user actually wants.

Budget: 1 advisor dispatch per gate run. Even if multiple dimensions score < 50, dispatch the one with the lowest absolute score (or the architecturally most foundational — architecture > root cause > evidence > reuse) and let its verdict propagate through re-scoring. Multiple dispatches in one gate run defeat the bounded-payload discipline by accumulating context across iterations.

When NOT to dispatch:

• band == STOP with no dimension < 50 (the STOP came purely from aggregate < 70) — hand off to the upstream skill listed in §Decision Bands directly.
• The framed gap has no decision-altering answer (Step 1 "nothing would change with an answer") — dispatch wastes a budgeted call.
• The same dispatch already ran in the immediately preceding gate run on the same work item — accept the prior verdict as still valid and use §Decision Bands directly.

Output Format

Confidence Gate Report
──────────────────────
Aggregate: <NN>/100 — <PROCEED | REVIEW | STOP>

  Scope clarity:           <NN>   <one-line evidence>
  Architecture compliance: <NN>   <one-line evidence>
  Evidence quality:        <NN>   <one-line evidence>
  Reuse verified:          <NN>   <one-line evidence>
  Root cause identified:   <NN>   <one-line evidence>

<If REVIEW or STOP:>
Weakest dimension: <name> (<NN>)
Why: <one or two sentences explaining what is missing>
What would raise it: <concrete evidence or action — file to read, command to run, question to ask>

<If REVIEW:>
Alternatives presented for user decision:
  A. <option> — trade-off
  B. <option> — trade-off
  (C. <option> — trade-off)

<If STOP:>
Routing: <ywc-plan | ywc-spec-validate | ywc-tech-research | ywc-brainstorm> — <why>

The "Weakest dimension" and "What would raise it" lines are mandatory whenever the band is REVIEW or STOP. They are the mechanism that turns the gate from a roadblock into a step-by-step path forward.

Integration

• Upstream callers: user invocation; ywc-plan (after Scale assessment, before downstream handoff); ywc-code-gen (Step 0, before Reuse Gate); ywc-sequential-executor / ywc-parallel-executor (before per-task implementation begins, especially for tasks with no upstream ywc-plan evidence); ywc-agentic (per-iteration entry).
• Downstream: implementation skills proceed on PROCEED; user dialog or Advisor Pattern on REVIEW; ywc-plan / ywc-spec-validate / ywc-tech-research / ywc-brainstorm on STOP.
• Pairs with: ywc-verify-done (the symmetric post-implementation gate — that gates the claim, this gates the start); ywc-impl-review (uses the same rubric for post-review confidence — scores remain comparable across the two gates).

Validation Checklist

Before reporting a PROCEED band and beginning implementation, verify:

• All five dimensions have explicit numeric scores (not "high", not "OK")
• Each dimension has a one-line evidence statement
• No dimension scored below 50
• Aggregate was computed with the rubric weights (25/25/20/15/15)
• The single-dim override was applied if any score is below 50 (< 50)
• The score and band are surfaced in the response before any implementation tool is invoked
• If REVIEW or STOP, no implementation skill was invoked in the same turn

Common Mistakes

(Procedural failure modes specific to this skill. Behavioral rationalizations are in the table above — do not duplicate here.)

• Scoring after the implementation already started in the same turn. The report must appear before the first implementation tool call. Scoring after invokes the gate retroactively — at which point its primary value (preventing the call) is gone.
• Reporting only the aggregate, not the per-dimension breakdown. A single number hides the weakest dimension; that is exactly the information the user needs to act. Always print all five dimension scores.
• Carrying an upstream skill's confidence forward instead of re-scoring. Each skill boundary re-narrows the context. A PROCEED at ywc-plan does not automatically transfer to ywc-code-gen, because the code-gen step has its own dimensions to score (especially Reuse verified and Architecture compliance, which ywc-plan does not score as deeply).
• Treating REVIEW as a soft STOP. REVIEW is "proceed with explicit alternatives presented and one of them chosen". STOP is "do not proceed". Conflating them collapses three bands into two and defeats the rubric's resolution.
• Adding a sixth dimension because "my work has a unique aspect". The five dimensions are fixed across skills so scores remain comparable. Per-skill adjustments belong in the "required dimensions" profile (see references/confidence-gate.md §4), not in extra dimensions.

References