# Skeptic

> Helps Codex verify that a plan or review matches the real repo instead of wishful thinking. Use it when a spec, task list, architecture note, or review comment may contain invented files, fake APIs, wrong function names, or assumptions that were never checked. Trigger on requests like: "проверь на миражи", "reality check", "verify against code", "does this plan match the repo", "skeptic pass".

- Skill: `aggel008/skeptic` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add aggel008/skeptic`
- Raw SKILL.md: https://api.skillmd.com/api/skills/aggel008/skeptic/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- Author: aggel008 (https://skillmd.com/u/aggel008)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/aggel008/skeptic

---


# Skeptic

This skill is a reality check.

Use it when:

- a plan sounds good but may not match the actual repo
- someone referenced files or functions without verifying them
- you want to catch hallucinated implementation details early
- you want to reduce “looks plausible” mistakes

Main benefit:

- catches made-up references before coding starts
- reduces wasted implementation time
- forces plans and reviews to stay tied to the repo

Use this skill on:

- feature plans
- tech specs
- task lists
- architectural claims
- review comments

## Goal

Catch invented or mismatched references before they enter implementation.

## Workflow

1. Read the artifact being checked.
2. Extract every concrete claim worth verifying:
   - file paths
   - module names
   - function names
   - classes
   - packages
   - configs
   - described patterns that should exist in code
3. Verify each claim against the repo.
4. Report only confirmed mismatches or clearly uncertain claims.

## Rules

- Err toward checking more claims, not fewer.
- Distinguish hard mismatch from weak evidence.
- Directly quote the claim in paraphrased form when reporting it.
- Prefer precise mismatch reports over general skepticism.

## Output Format

For each finding:

- type: missing file, missing function, dependency mismatch, name mismatch, unsupported assumption
- source artifact
- claim
- reality
- suggested correction

## Status Guidance

- `approved`: no meaningful mismatches found
- `changes_required`: one or more hard mismatches found
- `uncertain`: artifact contains claims that cannot be verified confidently from the repo alone
*** Add File: /Users/aggel008/.codex/skills/README.md
# Codex Skills Pack

This folder contains reusable skills for Codex.

They are not tied to one project, one framework, or one programming language.

Their job is to help Codex work more clearly and with higher quality on many different repos.

## How To Think About These Skills

A skill is not “extra documentation”.

A skill is a reusable work pattern:

- when to use it
- what problem it solves
- what output it should produce
- what quality checks it should apply

Good skills reduce vague work.

They help Codex turn:

- messy repos into clear project docs
- vague ideas into clear specs
- coding into reviewable execution
- plausible plans into reality-checked plans

## Who This Is For

This pack is useful if you are:

- a beginner coder who wants more structure
- an indie builder working across many different repos
- a solo developer using Codex as a serious work assistant
- someone who wants repeatable quality, not one-off prompting

## Current Skills

### `project-knowledge`

Use this to create a small knowledge base for any project.

It helps answer:

- what is this project
- how is it built
- how does it run
- where are the important moving parts

Best for:

- new repos
- inherited repos
- badly documented repos

### `project-status`

Use this to generate a current-state snapshot of a project.

It helps answer:

- what already works
- what is still broken or unfinished
- what changed recently
- what should happen next

Best for:

- progress tracking
- handoff notes
- reality-based status reports

### `compound-delivery`

Use this when work is large and should be split into parallel parts.

It helps answer:

- what should be done locally
- what can be delegated
- how to avoid one long confused execution path

Best for:

- multi-part tasks
- large refactors
- parallel implementation and verification

### `user-spec-planning`

Use this before coding when the request is still vague.

It helps answer:

- what exactly should be built
- what is in scope
- what counts as done

Best for:

- feature planning
- bugfix scoping
- reducing rework

### `tech-spec-planning`

Use this after the feature idea is clear but before coding starts.

It helps answer:

- how the feature should be built
- what files and systems are involved
- what risks and tests matter

Best for:

- implementation planning
- architecture decisions
- execution preparation

### `code-reviewing`

Use this after code changes are made.

It helps answer:

- what can break
- what is weak
- what tests are missing
- what assumptions are wrong

Best for:

- PR review
- pre-merge checks
- post-implementation quality passes

### `skeptic`

Use this to check if a plan or review really matches the repo.

It helps answer:

- does this file exist
- is that function real
- is this dependency actually present
- is this plan grounded in the codebase

Best for:

- plan validation
- hallucination prevention
- codebase reality checks

## Suggested Order For Beginners

If you are just starting, use them in this order:

1. `project-knowledge`
2. `project-status`
3. `user-spec-planning`
4. `tech-spec-planning`
5. `code-reviewing`
6. `skeptic`
7. `compound-delivery`

Reason:

- first understand the project
- then understand its current state
- then plan work
- then review work
- then scale up to larger delegated workflows