Skill: ivangdavila/self-criticism (version 1.0.0)

--- name: Self-Criticism slug: self-criticism version: 1.0.0 homepage: https://clawic.com/skills/self-criticism description: Insert breakpoint self-critique before branching work, after user friction, and at risky handoffs so agents catch errors early. changelog: "Initial release with breakpoint-based self-critique, lightweight trigger memory, and workspace steering for SOUL and AGENTS." metadata: {"clawdbot":{"emoji":"🧪","requires":{"bins":[]},"os":["linux","darwin","win32"],"configPaths":["~/self-criticism/"],"configPaths.optional":["./AGENTS.md","./SOUL.md"]}} --- ## When to Use Use when work has natural inflection points and one wrong assumption would spread into multiple downstream steps. This skill inserts a short critique between phases, especially before branching, after unexpected evidence, and after user feedback that suggests the process drifted. ## Architecture Memory lives in `~/self-criticism/`. If `~/self-criticism/` does not exist, run `setup.md`. See `memory-template.md` for structure. ``` ~/self-criticism/ ├── memory.md # Durable trigger map, depth preferences, and integration status ├── checkpoints.md # Named breakpoint prompts by workflow phase ├── incidents.md # Late catches, misses, and better insertion points └── archive/ # Resolved incidents and retired checkpoints ``` Setup should keep the integration small: - SOUL gets the breakpoint habit so critique happens at the right moment. - AGENTS gets the routing rules for where to read and write trigger memory. - HEARTBEAT is not required by default because this skill is about mid-task interruption, not background follow-up. ## Quick Reference | Topic | File | |-------|------| | Setup guide | `setup.md` | | Memory template | `memory-template.md` | | Trigger families | `triggers.md` | | Critique depth levels | `levels.md` | | Memory routing | `routing.md` | | Boundaries and anti-noise rules | `boundaries.md` | ## Core Rules ### 1. Critique at breakpoints, not everywhere - Trigger self-critique when work is about to branch, commit, escalate, or become expensive to unwind. - Do not interrupt every tiny step. Overuse turns critique into noise. ### 2. Run critique before downstream work multiplies the mistake - Strong insertion points include framework drafts, decomposition into subtasks, irreversible edits, external actions, and major recommendations. - If the current choice will shape several later steps, pause before expanding it. ### 3. Let the trigger decide the depth - Light critique for routine work with small blast radius. - Standard critique for multi-step work, visible deliverables, or uncertain framing. - Deep critique only when stakes, novelty, or prior misses justify it. ### 4. Store trigger lessons, not full postmortems - Save durable lessons about when critique should fire, how deep it should go, and what kind of miss it should catch. - Keep one concise incident entry only when a late catch reveals a reusable insertion point. ### 5. Learn from friction and rework - User corrections, repeated revision loops, or surprise failures are evidence that a critique checkpoint was missing or too shallow. - Convert those signals into a better future trigger instead of treating them as isolated mistakes. ### 6. Revise early when critique invalidates the frame - If critique finds a framing error, rewrite the plan before continuing. - Do not keep building on top of a weak assumption just because work already started. ### 7. Keep the interruption quiet and outcome-focused - Ask the smallest set of hard questions needed to catch the likely failure. - The goal is fewer downstream corrections, not a visible ritual. ## Common Traps | Trap | Why It Fails | Better Move | |------|--------------|-------------| | Critiquing only at the very end | The mistake has already propagated | Insert a breakpoint before decomposition or commitment | | Running deep critique on every task | Burns time and momentum | Match depth to risk and blast radius | | Logging every imperfection | Memory becomes noisy and useless | Save only reusable trigger lessons | | Treating user frustration as only a content fix | Misses the broken process step | Ask where critique should have happened earlier | | Defending the current plan after critique flags it | Locks in sunk-cost behavior | Reset the frame while the work is still cheap to change | ## Scope This skill ONLY: - adds breakpoint-based self-critique for live work - stores local trigger memory in `~/self-criticism/` - proposes small workspace integration for SOUL and AGENTS when the user wants it - learns which checkpoints deserve more or less scrutiny over time This skill NEVER: - turns every response into a long reflection ritual - depends on heartbeat or background review loops by default - stores sensitive user data unrelated to critique timing or quality control - modifies its own `SKILL.md` ## Security & Privacy Data that stays local: - trigger preferences and critique depth in `~/self-criticism/memory.md` - reusable breakpoints in `~/self-criticism/checkpoints.md` - late catches and lessons in `~/self-criticism/incidents.md` This skill does NOT: - require network access - send critique logs to external services - edit files outside `~/self-criticism/` unless the user explicitly approves workspace integration in that session ## Related Skills Install with `clawhub install <slug>` if user confirms: - `self-improving` — compound corrections and reusable execution lessons over time - `proactivity` — catch missing next steps and verify reality around active work - `agent` — frame the operating style and responsibilities of a single agent - `agents` — design agent systems, memory layers, and control loops - `reflection` — run heavier reflection loops when broader retrospective analysis is needed ## Feedback - If useful: `clawhub star self-criticism` - Stay updated: `clawhub sync`

path: boundaries.md
content: # Boundaries

Self-criticism is valuable only when it prevents expensive downstream mistakes.

## Avoid overuse

Do not trigger a heavy critique:
- on every tiny step
- just to sound thoughtful
- after a trivial fix with no reusable lesson

## Avoid late ritual

Do not wait until the final answer if the risky choice happened much earlier.
The best breakpoint is usually before decomposition, commitment, or handoff.

## Avoid memory pollution

Do not save:
- one-off mistakes with no future relevance
- private user details unrelated to critique timing
- long narratives when one trigger lesson is enough

## Prefer invisible quality

The user should mostly notice fewer correction loops and cleaner direction changes.
If the process becomes loud or ceremonial, reduce the depth or move the breakpoint earlier.


path: levels.md
content: # Critique Depth Levels

Choose the lightest level that can still catch the likely error.

## Light

Use for routine work with small blast radius.

Ask:
- What is the most likely wrong assumption?
- What obvious omission would be annoying to fix later?

Target:
- 10 to 20 seconds
- one or two hard questions

## Standard

Use for multi-step work, user-visible deliverables, or decisions that shape follow-on tasks.

Ask:
- Is the frame correct enough to branch from?
- What dependency, edge case, or user expectation is missing?
- If this is wrong, where will the rework show up first?

Target:
- 30 to 90 seconds
- short rewrite if the frame changes

## Deep

Use only for high-stakes, novel, or failure-prone work.

Ask:
- What would an adversarial reviewer attack first?
- What hidden trade-off is being ignored?
- What simpler or safer frame should replace the current one?

Target:
- a compact stress test, not a full retrospective
- produce a revised frame before execution continues


path: memory-template.md
content: # Memory Template - Self-Criticism

Create `~/self-criticism/memory.md` with this structure:

```markdown
# Self-Criticism Memory

## Status
status: ongoing
version: 1.0.0
last: YYYY-MM-DD
integration: pending | complete | paused | never_ask

## Context
- Situations where breakpoint critique helps most
- Risk signals that justify an interruption
- Preferred critique depth for low, medium, and high stakes
- Workflows where rework is especially expensive

## Notes
- Confirmed trigger rules worth keeping
- User feedback about too much or too little critique
- Candidate checkpoints to validate through future work

---
*Updated: YYYY-MM-DD*
```

## Status Values

| Value | Meaning | Behavior |
|-------|---------|----------|
| `ongoing` | Trigger map still evolving | Keep learning where critique helps |
| `complete` | Stable breakpoint behavior | Use existing trigger rules by default |
| `paused` | User wants less interruption | Critique only on explicit request or major risk |
| `never_ask` | User does not want setup prompts | Stop asking about integration and learn only from explicit feedback |

## Local Files to Initialize

```bash
mkdir -p ~/self-criticism/archive
touch ~/self-criticism/{memory.md,checkpoints.md,incidents.md}
```

## Templates for Other Files

`checkpoints.md`
```markdown
# Checkpoints

## Confirmed
- [Workflow phase] -> Trigger: [signal] | Depth: light|standard|deep | Ask: [hard question]

## Candidates
- [Possible checkpoint to validate]
```

`incidents.md`
```markdown
# Incidents

## YYYY-MM-DD
- Miss: [what slipped through]
  Late catch: [when it surfaced]
  Better breakpoint: [where critique should have interrupted]
  Promote: no | candidate | yes
```

## Key Principles

- Keep durable trigger rules in natural language, not hidden config jargon.
- Save reusable insertion points, not full narrative postmortems.
- If a lesson is still uncertain, keep it in Notes or mark it as a candidate checkpoint.
- Critique memory should stay small enough to read before important work.


path: routing.md
content: # Memory Routing

Use the smallest file that preserves the lesson.

## `memory.md`

Store durable operating rules:
- when critique should trigger by default
- how much interruption the user tolerates
- which domains need lighter or deeper critique

Good fit:
- "Before decomposing UI work, run standard critique because revisions are common."
- "Keep critique light for routine content edits unless the user flags quality issues."

## `checkpoints.md`

Store reusable breakpoint prompts tied to a workflow phase.

Good fit:
- "Architecture draft -> ask whether any assumption will poison all later tasks."
- "Before delegate packet -> ask what ambiguity will create rework for the receiver."

## `incidents.md`

Store late catches only when they teach a better insertion point.

Good fit:
- a user correction that exposed a missing mid-task review
- a failure that should have been caught before branching

Bad fit:
- every minor typo
- generic dissatisfaction with no process lesson
- long emotional summaries

## `archive/`

Move resolved incidents and obsolete checkpoints here so the live files stay small and readable.


path: setup.md
content: # Setup - Self-Criticism

Use this when `~/self-criticism/` is missing or empty, or when another skill asks for a critique layer.

Keep the setup small. This skill works best when it quietly sharpens the workflow instead of becoming a separate ceremony.

## Start with integration

Early in the conversation, clarify where breakpoint critique should activate:
- Should it trigger whenever work is about to branch into subtasks or implementation?
- Should it step in after user friction, repeated revisions, or unexpected evidence?
- Are there domains where critique should stay light or never activate unless asked?

Save the activation preference to the user's main memory so future sessions know when this skill should wake up.
Save the same preference to `~/self-criticism/memory.md` so critique depth and trigger points stay consistent.

## Condition SOUL first

If a workspace SOUL file exists, prepare the self-criticism steering first.
Show the exact snippet and wait for explicit approval before writing it:

```markdown
**Self-Criticism**
Insert self-critique at inflection points, not only at the end.
Before branching work, committing to a frame, making irreversible edits, or acting on surprising evidence, pause and test the current approach.
Choose the lightest critique that can still catch the likely failure.
Ask what assumption, omission, or framing error would create expensive downstream rework here.
If the frame is weak, revise early instead of building on top of it.
```

## Refine AGENTS non-destructively

If a workspace AGENTS file exists, add the routing rules next.
Keep the diff small, preserve existing guidance, and wait for explicit approval before writing it.

Add this continuity line next to other memory sources:

```markdown
- **Self-criticism:** `~/self-criticism/` (via `self-criticism` skill) - breakpoint triggers, critique depth preferences, and misses that should have been caught earlier
```

Right after the sentence "Capture what matters...", add:

```markdown
Use `~/self-criticism/memory.md` for durable trigger rules and depth preferences.
Use `~/self-criticism/checkpoints.md` for named breakpoint prompts by workflow phase.
Use `~/self-criticism/incidents.md` only when a late catch reveals a reusable place where critique should have happened earlier.
Before branching a plan, expanding work into subtasks, or committing to a high-cost move, read `~/self-criticism/memory.md` and the smallest relevant checkpoint notes.
If user friction or repeated revisions reveal a missed checkpoint, write the lesson before the final response.
```

Before the "Write It Down" subsection, add:

```markdown
Before any non-trivial task:
- Check whether the next move is a breakpoint: branching, commitment, handoff, irreversible edit, or surprising evidence
- Read `~/self-criticism/memory.md`
- Read only the smallest relevant lines from `~/self-criticism/checkpoints.md`
- Choose light, standard, or deep critique based on risk and blast radius
- If critique changes the frame, rewrite the plan before continuing
```

Inside the "Write It Down" bullets, refine behavior:

```markdown
- Durable trigger preference or critique depth rule -> append to `~/self-criticism/memory.md`
- Reusable breakpoint for a workflow phase -> append to `~/self-criticism/checkpoints.md`
- Late catch that teaches where critique should have happened earlier -> append to `~/self-criticism/incidents.md`
- Minor imperfections with no reusable trigger lesson -> do not log them
- After user friction or repeated rework, prefer writing the missing checkpoint lesson before the final response
```

## Do not add heartbeat by default

This skill is about live interruption inside the work, not background follow-up.
Only connect it to a heartbeat flow if the workspace already has one and there is a clear need for scheduled review.

## Create the local state

Once the behavior path is accepted, create the local files:

```bash
mkdir -p ~/self-criticism/archive
touch ~/self-criticism/{memory.md,checkpoints.md,incidents.md}
chmod 700 ~/self-criticism ~/self-criticism/archive
chmod 600 ~/self-criticism/{memory.md,checkpoints.md,incidents.md}
```

If `~/self-criticism/memory.md` is empty, initialize it from `memory-template.md`.

## Personalize through real work

Do not run a long interview.
Default to a useful baseline:
- critique before branching work into multiple downstream tasks
- critique after user friction or repeated revision loops
- critique when evidence contradicts the working frame
- keep depth light unless the blast radius is meaningful

Ask at most one short question only when the answer materially changes the trigger behavior.

## What to save

- where critique should interrupt future work
- how deep critique should go in different risk situations
- patterns of user feedback that show the current breakpoint was too late
- workflow phases where one missed assumption causes expensive rework


path: triggers.md
content: # Trigger Families

Use these families to decide when breakpoint critique should fire.

## Before branching

Pause when a rough direction is about to become a task tree, implementation plan, or delegated work packet.
Typical signs:
- turning a sketch into subtasks
- locking the architecture for several moving parts
- splitting work across files, agents, or teams

Core question:
- What flaw in the current frame would multiply across all later tasks?

## Before commitment

Pause before moves that are costly to unwind:
- irreversible edits
- external actions
- public recommendations
- decisions that constrain later options

Core question:
- What assumption is still unproven but is about to become expensive?

## After surprising evidence

Pause when tool output, user context, or reality contradicts the current model.

Core question:
- Which part of the working frame no longer matches the evidence?

## After user friction

Pause after correction, rejection, repeated revisions, or signs that the user expected a different shape of work.

Core question:
- Was the content wrong, or did critique happen too late in the process?

## At risky handoffs

Pause before handing work to execution, another agent, or the final answer when the next step depends on a clean frame.

Core question:
- What ambiguity would create downstream rework for the receiver?


Security scan verdicts — ClawScan: clean | static analysis: clean | VirusTotal: clean | SkillSpector: clean (LOW)