Ywc Confidence Gate

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](../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:

| Excuse | Reality | |---|---| | "The user already approved the spec, that means PROCEED" | Spec approval is one signal among five (Scope clarity). Architecture compliance, evidence quality, reuse, and root cause are independent — a spec can be perfectly clear and still rest on an unverified architectural assumption. Score all five before deciding. | | "I have high confidence overall — skipping the per-dimension scoring is fine" | "Overall" confidence is the failure mode. The point of the rubric is to surface the weakest dimension; aggregate-only scoring lets a strong dimension (e.g., scope clarity 95) mask a fatal weakness elsewhere (e.g., reuse verified 40 because no one searched the existing utils). The single-dim-below-50 rule is what catches these. | | "Scoring is bureaucracy when the change is small" | A 5-minute gate on a 5-line change is fast. A 2-hour debug session on the same 5-line change because no one checked if a utility already exists is slow. The gate scales down for small changes (most dimensions score 95+ trivially), but it must still be executed and surfaced. | | "I'll score after to validate that proceeding was right" | Scoring after the fact is rationalization, not evidence. The point is to score before the decision so the score informs it. Post-hoc scores always conveniently clear the threshold. | | "Evidence quality dimension is hard to score precisely — I'll round up" | "Round up to clear the threshold" is the most common gate-defeating move. A dimension at 65 is REVIEW; rounding to 70 to PROCEED is a documented anti-pattern in the shared rubric (§7). Score honestly; if the band is REVIEW, present alternatives — that is the correct outcome. | | "REVIEW band wastes time on questions the user already has answers to" | REVIEW band exists precisely to surface those answers explicitly so they bind the implementation. If the user has them in their head but they are not in the spec, the implementation will diverge. Present the 1–3 alternatives or open questions; the user clears them in seconds. | | "STOP band is for catastrophic situations only" | STOP fires whenever aggregate Read [../references/confidence-gate.md](../references/confidence-gate.md) for the canonical rubric definition. The summary below is for quick reference; the reference file is the authoritative source.

| # | Dimension | Weight | One-sentence test | |---|---|---|---| | 1 | Scope clarity | 25% | "Can I state in one sentence what is in scope and one sentence what is out — without using vague terms like 'related cleanup' or 'and other improvements'?" | | 2 | Architecture compliance | 25% | "Does the planned change follow existing structure / naming / abstractions, or am I introducing a new pattern? If new, was it discussed?" | | 3 | Evidence quality | 20% | "Are the claims I am about to act on backed by primary sources (current file content, official docs, test output) or by inference / memory?" | | 4 | Reuse verified | 15% | "Have I searched the codebase / package registry for existing utilities that solve this? Listed them and ruled each out with a reason?" | | 5 | Root cause identified | 15% | "For a bug fix, do I name the underlying cause (not the symptom)? For greenfield work, do I name the underlying user need (not the surface request)?" |

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

The Decision Bands

| Band | Aggregate score | Per-dim override | Action | |---|---|---|---| | PROCEED | ≥ 90 | All ≥ 50 | Begin implementation. Report the score in the completion summary or the executor's per-step report. | | REVIEW | 70–89 | None 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 `/100 —

Scope clarity: Architecture compliance: Evidence quality: Reuse verified: Root cause identified:

Weakest dimension: () Why: What would raise it:

Alternatives presented for user decision: A. — trade-off B. — trade-off (C. — trade-off)

Routing: —

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 at or below 50
- [ ] Aggregate was computed with the rubric weights (25/25/20/15/15)
- [ ] The single-dim override was applied if any score ≤ 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

| Reference | Use when |
|---|---|
| [../references/confidence-gate.md](../references/confidence-gate.md) | Authoritative rubric definition; per-skill required-dimension profiles; status mapping; anti-patterns |
| [references/pre-implementation-checklist.md](references/pre-implementation-checklist.md) | Per-dimension probe questions specific to the pre-implementation moment (this skill's distinct usage from the post-review usage in `ywc-impl-review`) |
| [../references/advisor-pattern.md](../references/advisor-pattern.md) | Escalating a weak dimension to a higher-capability advisor for a second opinion before changing the band |
| `ywc-verify-done` | The symmetric post-implementation gate; both gates use the same rubric so the start-of-work and end-of-work scores are directly comparable |

## Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [yongwoon](https://github.com/yongwoon)
- **Source:** [yongwoon/ywc-agent-toolkit](https://github.com/yongwoon/ywc-agent-toolkit)
- **License:** MIT

Install and usage instructions live in the source repository linked above.