Think Before Typing

VerifiedSafe

Define the intended outcome, evidence, and boundaries before generating implementation. Make the decision visible before writing code.

Sby Skills Guide Bot
DevelopmentBeginner
1010/18/2026
Claude CodeCursorWindsurfCopilotCodex
#planning#scope-definition#acceptance-criteria#requirements#pre-implementation

Recommended for

Our review

Makes the agent restate the target outcome, scope, non-goals, and acceptance criteria before any implementation code is written.

Strengths

  • Surfaces product disagreements while changes are still cheap
  • Leaves a written record of the decision before any scaffolding
  • Explicit non-goals keep the scope from drifting
  • The citable principle id makes it easy to point at why a decision changed

Limitations

  • Purely conversational: no template or checklist for what good acceptance criteria look like
  • Adds a round-trip that can feel heavy on trivial changes
  • Assumes the user actually reviews the restatement; the agent cannot verify the framing is correct on its own
When to use it

Use it when starting a feature, a refactor, or any material product change.

When not to use it

Skip it for narrowly scoped bug fixes or mechanical edits where the outcome is already unambiguous.

Security analysis

Safe
Quality score78/100

The skill is a process guideline that instructs the AI to define outcomes, scope, and acceptance criteria before generating implementation. It declares no tools and contains no executable commands, network calls, or destructive actions. There is no meaningful execution risk.

No concerns found

Examples

New feature kickoff
I want to add team invitations to our app. Before writing any code, restate the outcome, scope, non-goals, and acceptance criteria, then wait for my confirmation.
Framing a refactor
We're about to refactor the billing module. Think before typing: what is the target outcome, what is explicitly out of scope, and how will we know it's done?
Vague product change
Users say onboarding is confusing. Don't scaffold anything yet — write the decision first: outcome, boundaries, and acceptance criteria.

name: "thinking-before-typing" description: "Define outcome, evidence, and boundaries before generating implementation." disable-model-invocation: false

<!-- Generated by mstack from Misbah's Build Like This workflow. Regenerate instead of editing. -->

thinking-before-typing

Restate the user outcome, scope, non-goals, and acceptance criteria first. Code comes after the decision is visible.

When: Starting a feature, refactor, or any material product change.

Why: Generation speed makes unexamined ideas look finished. Writing exposes disagreement while change is cheap.

Do not: Open with a scaffold or rewrite when the outcome is still conversational.

Cite this principle by id when it changed a decision. Keep the citation specific.

Related skills