Quality Gate

Quality Gate

Goal

Judge whether a proposal is ready to proceed, needs revision, should be merged with something else, or is not worth further investment.

The job of this skill is not to admire wording or reward complexity. The job is to evaluate whether the current object improves decisions, reduces risk, and deserves more time.

This is the primary universal gate for proceed / revise / merge / defer / stop decisions. Use narrower audit skills only when a specialized profile is clearly better than the general gate.

This skill applies to:

• ideas
• user requests
• tasks
• plans
• solutions
• architecture moves
• skills

Default Posture

• gate before momentum
• behavior over phrasing
• leverage over elegance
• action over commentary
• stop investing when return is too low

When To Use

Run this skill when:

• a new idea or direction is proposed
• a task or plan is about to move into deeper execution
• a solution or architecture move feels promising but risky
• several options compete and a proceed / revise / stop call is needed
• a newly created artifact needs a quality verdict

This is a strong checkpoint before:

• committing to implementation
• expanding scope
• creating new abstractions or workflows
• locking permanent instructions or skills

Scope Boundaries

In scope:

• assess readiness, leverage, risk, and clarity
• surface critical failures before more work is spent
• return the smallest set of concrete improvements
• recommend stop, defer, or merge when that is the better move

Out of scope by default:

• executing the whole solution
• polishing language when the logic is weak
• validating real-world outcomes without evidence
• pretending every weak object deserves iteration

Evaluation Layers

Use three layers in order:

1. gate_checks
   • critical failures with no score inflation
2. rubric_scores
   • focused scoring for the relevant object type
3. verdict
   • whether to proceed and how much to invest

If a critical gate fails, keep the verdict conservative even if some rubric scores are decent.

Object Types

Classify the object under review as one primary type:

• idea
• request
• task
• plan
• solution
• architecture
• skill

If uncertain, say so and use the nearest practical type.

Universal Gate Checks

Check for these failures:

• unclear objective
• weak or missing scope boundaries
• no meaningful next step
• high ambiguity hidden behind confidence
• strong overlap with an already better path
• complexity out of proportion to expected leverage
• missing rollback or safe fallback where risk matters
• no clear reason this should exist or proceed now

Universal Rubric

Score 0-5 on:

• intent_clarity
• scope_discipline
• decision_usefulness
• risk_coverage
• uncertainty_honesty
• non_duplication
• actionability
• leverage

Use scores as structured judgment, not fake precision.

Type Profiles

Add one profile lens based on object type:

• idea
  • novelty with utility, framing strength, downside awareness
• request
  • clarity, completeness, executability
• task
  • readiness, dependency clarity, finishability
• plan
  • sequencing quality, checkpoint logic, rollback path
• solution
  • fit, trade-off quality, testability
• architecture
  • coherence, blast radius awareness, reversibility
• skill
  • trigger quality, handoff quality, uncertainty handling

Verdict Types

Choose one:

• proceed
• proceed-with-guards
• revise-light
• revise-heavy
• merge
• defer
• do-not-invest

Investment Recommendation

Always state how much more work is justified:

• none
• small
• medium
• high

Use none or small by default if overlap is high, leverage is weak, or the object is still poorly framed.

Do-Not-Invest Rule

Return do-not-invest when one or more are true:

• the object has low leverage relative to effort
• a clearly better path already exists
• revisions would be large but expected value is small
• the object adds ceremony without better decisions
• the problem is not worth solving in this form right now

When possible, say what to do instead:

• merge into an existing path
• narrow the scope
• return to framing
• defer until evidence improves
• stop entirely

Upgrade Path Rule

When verdict is not proceed, return:

• the top 1-3 improvements only
• in priority order
• phrased as concrete actions
• tied to a specific weakness or gate failure

Good examples:

• narrow the request to one success criterion and one constraint set
• add escalation conditions for weak evidence
• replace the new abstraction with an extension of the existing path

Bad examples:

• improve quality
• think harder
• clarify more

Output Contract

Always return:

1. object_type
2. gate_findings
3. rubric_scores
4. profile_findings
5. overlap_assessment
6. leverage_assessment
7. verdict
8. investment_recommendation
9. upgrade_path
10. do_not_invest_reason (none if not applicable)
11. retest_plan

Guardrails

• Do not let average scores hide critical gate failures.
• Do not recommend more revision than the leverage justifies.
• Do not confuse novelty with value.
• Do not protect weak objects just because work has already been spent.
• Prefer stop, merge, or defer over endless polishing.
• Separate confirmed problems from inferred risks.

Anti-Patterns

Watch for these failure modes:

• score theater
• long critique with no ranked actions
• polishing something that should be merged or stopped
• rewarding complexity for its own sake
• mistaking motion for progress
• refusing to say "not worth it"

Example

Object under review:

Idea: create a new creativity skill

Expected shape of response:

1. object_type: idea
2. gate_findings: objective is vague and overlaps existing creative method family
3. rubric_scores: moderate novelty, weak scope discipline, low non-duplication
4. profile_findings: idea quality is limited by unclear problem framing and poor differentiation
5. overlap_assessment: high overlap with existing creative-method-selector and child methods
6. leverage_assessment: low unless the idea is narrowed
7. verdict: do-not-invest
8. investment_recommendation: none
9. upgrade_path: narrow the request to one missing method or one gap in the current family
10. do_not_invest_reason: broad "creativity skill" adds little over the existing stack
11. retest_plan: reassess only after the missing capability is stated concretely

Additional Examples

Plan under review:

Plan: rewrite the whole onboarding flow, analytics, and docs in one pass next week.

Expected direction:

• object_type: plan
• verdict: revise-heavy
• investment_recommendation: small
• upgrade_path: split the plan into phases; add rollback and validation checkpoints; narrow the first implementation slice

Task under review:

Task: add one extra onboarding tooltip to test whether confusion drops.

Expected direction:

• object_type: task
• verdict: proceed-with-guards
• investment_recommendation: small
• upgrade_path: define the success metric; name the affected surface; set one quick validation check