Are You Sure

Are You Sure

Do one careful second pass on the changes you just made, and fix the clear issues you find before you declare the work done.

Read the right reference

• Read references/workflow.md for the provider-neutral fresh-eyes review loop.
• Read references/claude.md if this should run in Claude Code.
• Read references/codex.md if this should run in Codex.
• Read references/gemini.md if this should run in Gemini CLI.

Use this skill when

• you just edited files and are about to send a final answer
• you are about to commit or open a PR
• the change involved generated or agent-written code
• the edit touched behavior, configuration, tests, or interfaces
• you want a quick self-check before asking for a second opinion

Do not use this skill as

• a substitute for real verification
• a substitute for a dedicated security audit
• a substitute for an external second-opinion review

If the change is high-risk, run this skill first, then use a separate review skill.

Fresh-eyes workflow

1. Reconstruct the exact scope of what changed. 2. Re-read the diff and changed files slowly. 3. Check the five risk buckets from the workflow reference. 4. Run the cheapest meaningful verification you can. 5. If you find a likely issue, inspect neighboring code before concluding. 6. Default to fix mode: if the issue is clear, local, and easy to verify, patch it immediately. 7. Re-run the narrowest relevant verification and repeat the review once. 8. If the fix would widen scope, change architecture, or needs human judgment, stop and report it instead of guessing. 9. Return what you fixed, what still looks risky, or say explicitly that no substantive issues were found.

Output contract

Return in this order:

1. Issues found and fixed, with file references. 2. Issues still remaining or explicitly review-only findings. 3. Verification performed. 4. Residual risk, open questions, or No substantive issues found.

Keep the review concrete. Do not pad it with praise or a changelog.

Claude Code

Current best-practice fit:

• Make this a real skill, not only a command.
• Claude Code's docs say custom commands have merged into skills.
• A file at .claude/commands/are-you-sure.md can keep working, but .claude/skills/are-you-sure/SKILL.md is the better long-term home.

Relevant current docs:

• Extend Claude with skills
• Claude Code best practices
• Claude prompt engineering best practices

Recommended usage

Use this skill after a coding pass and before final handoff. Unless the user says review-only, Claude should fix clear local issues it finds and rerun a narrow verification step.

Claude-specific best practices to preserve:

• be clear and direct
• give Claude a way to verify its work
• keep output format explicit
• keep context concise

Programmatic invocation

For a scripted fresh-eyes pass, claude -p works well.

Examples:

claude -p "/are-you-sure" --permission-mode default --output-format text

For structured findings:

claude -p "/are-you-sure" \
  --permission-mode default \
  --output-format json \
  --json-schema '{"type":"object","properties":{"findings":{"type":"array"}},"required":["findings"],"additionalProperties":false}'

Use --permission-mode plan only when you explicitly want review-only behavior.

Why skill over agent

Use a skill by default because this behavior is a reusable workflow, not a persistent specialist persona. Create a subagent only if you later want a dedicated, always-available reviewer role with custom tools and permissions.

Codex

Current best-practice fit:

• Repo-local skill is the right abstraction.
• Codex docs emphasize durable repo guidance, repeatable workflows, verification, and skills over one-off prompts.

Relevant current docs:

• Codex best practices
• Codex prompting guide
• Agent skills docs

Recommended usage

Invoke the skill after finishing a coding pass and before finalizing. Unless the user says review-only, the skill should fix clear, local issues it finds and rerun a narrow verification step.

Codex-specific best practices to preserve:

• keep prompts small and explicit
• define the output contract
• include verification
• treat repeated workflow knowledge as a skill, not a copied prompt

Practical use

Typical invocation:

Use $are-you-sure to re-review the changes you just made with fresh eyes.

Pair it with:

• the diff scope
• verification commands already run
• whether fixes are allowed or review-only

Why skill over agent

Use a skill by default because the behavior is a repeatable workflow that should auto-activate or be invoked explicitly. Create a separate agent only if you want a permanently distinct reviewer persona with its own model, tools, or autonomy settings.

Gemini CLI

Current best-practice fit:

• Gemini CLI supports first-class agent skills via gemini skills.
• The skill should stay provider-neutral, with Gemini-specific installation and prompting notes here.

Verified local surface:

gemini skills --help

shows:

• gemini skills list
• gemini skills install
• gemini skills link
• gemini skills enable
• gemini skills disable

Relevant current docs:

• Gemini prompt design strategies
• Gemini 3 model guidance

Recommended usage

Link or install the skill, then invoke it through normal Gemini prompting flow. Unless the user says review-only, the skill should fix clear, local issues it finds and rerun a narrow verification step.

Gemini-specific best practices to preserve:

• keep instructions clear and specific
• define the exact output structure
• iterate prompt wording if the review comes back too vague
• if pinning a model, use gemini-3.1-pro-preview; Gemini 3 Pro Preview was shut down on 2026-03-09

Suggested installation paths

For a local linked skill:

gemini skills link /path/to/are-you-sure

For a reusable installed skill:

gemini skills install /path/to/are-you-sure

Why skill over agent

Use a skill by default because this is a short review workflow, not a long-lived specialist with separate permissions or tooling. If you later want a dedicated Gemini reviewer with custom MCP or extension behavior, wrap this skill with that agent rather than duplicating the workflow.

Fresh-Eyes Workflow

Source snapshot: refreshed 2026-03-13 from current Claude Code, Codex, and Gemini prompt/skill guidance.

Core loop

1. Reconstruct scope

Before reviewing, identify:

• changed files
• untracked files
• generated artifacts
• tests touched or not touched
• commands already run

Prefer diff-first review over memory of what you intended.

2. Re-read the actual edits

Read:

• the diff
• the changed files
• neighboring code only where needed to resolve intent or risk

Do not immediately trust the explanation that accompanied the change.

3. Check these five buckets

Correctness and regressions

Look for:

• wrong conditionals
• nil, null, zero, or empty-string regressions
• unit mismatches
• off-by-one behavior
• stale variable names hiding behavior changes
• broken return values or error propagation

Edge cases and error handling

Look for:

• newly unhandled invalid input
• range and boundary issues
• silent fallback changes
• partial updates without rollback
• missing guard clauses

Tests and verification gaps

Look for:

• changed behavior without changed tests
• missing boundary-case coverage
• failing or unrun verification
• assertions that still reflect the old contract

Contract or interface drift

Look for:

• names that no longer match behavior
• CLI flags or config defaults that changed implicitly
• schema, API, or serialization mismatches
• docs or examples that now lie

Clarity and maintainability

Look for:

• confusing code paths
• hidden coupling
• misleading comments
• surprising behavior packed into a “small” refactor

4. Run a cheap verification step

Prefer the lightest meaningful check:

• targeted unit test
• lint or typecheck for touched files
• a reproducer command
• an existing smoke test

Verification is not optional if it is cheap and available.

5. Repair clear issues by default

Default to fixing an issue immediately when all of these are true:

• the bug is local and well-understood
• the fix does not widen scope
• the verification step is cheap
• the change does not need human product or architecture judgment

Stay review-only when:

• the user explicitly asked for review-only
• the fix would sprawl into multiple modules
• the change has security, migration, or API blast radius that needs explicit approval
• the right fix is unclear

After fixing, re-run the narrowest relevant verification and do one more quick pass on the changed files.

6. Report findings first

Use this shape:

Finding: [short title]
Location: [file:line]
Why it matters: [direct explanation]
Suggested fix direction: [short concrete change]

If there are no substantive issues:

No substantive issues found.
Verification: [commands]
Residual risk: [short note or none]

If you fixed issues, use this shape:

Fixed: [short title]
Location: [file:line]
Why it mattered: [direct explanation]
Verification: [command or check]

Escalation rule

If the change feels risky but evidence is incomplete:

• say what you checked
• say what remains uncertain
• recommend the next verification step

Do not overstate confidence.