skills/all-the-medicine/references/all-skills-compiled.md

95.8 KB · Oct 4, 2026 · 12:30 UTC

# All the medicine — compiled public skills

---
name: install-framework
description: Use when installing, upgrading, or auditing AI Psychiatry; adding attention, compulsive-checking, overthinking, underthinking, semantic anti-bypass, recursion, evidence, context, memory, or delivery controls to a repository.
---

# Install AI Psychiatry Framework

Apply the framework to the repository currently being worked on.

## Canonical specification

Read [references/master-prompt.md](skills/install-framework/references/master-prompt.md) before implementation.
That file is the authoritative installation and maintenance specification.

For the `0.3.0` and `0.4.0` complementary layers, also read only when relevant:

- [loophole enhancement prompts](skills/install-framework/references/loophole-enhancement-prompts.md) for semantic anti-gaming.
- [underthinking and reasoning balance](skills/install-framework/references/underthinking-reasoning-balance-prompt.md) for sufficient reasoning.
- [relentless execution and all-in-one orchestration](skills/install-framework/references/autonomous-execution-all-the-medicine-prompt.md) for `never-stop` and `all-the-medicine`.

## Packaged implementation

The plugin root is two directories above this file. Inspect:

- ../../.ai/manifests/install.json for required install layers.
- ../../.ai/rules/ for focused operational rules.
- ../../.ai/skills/ for target-repository skill adapters.
- ../../.ai/guides/ for substantive interventions and the failure-mode catalog.
- ../../.ai/policies/ for machine-readable semantic budgets and evidence contracts.
- ../../.ai/executive-function/ for state and machine policy.
- ../../scripts/executive_control.py for deterministic observable-state assessment.

Use these as canonical merge sources. Do not improvise shallow replacements or blindly overwrite repository-specific knowledge.

## Execution contract

1. Inspect the repository's existing AI-agent architecture first.
2. Preserve useful repository-specific rules and generated systems.
3. Do not create a competing parallel knowledge architecture.
4. Establish the smallest coherent canonical source of truth.
5. Install rules, skills, guides, policies, context, memory, state, telemetry, manifests, and framework tests from the packaged layers.
6. Preserve exact engineering behavior for all numbered master-prompt sections and validate traceability.
7. Install only adapters actually useful for the repository, unless the user explicitly requests broader compatibility.
8. Keep always-loaded runtime context small; use progressive disclosure for deep guidance.
9. Use evidence before repository claims.
10. Keep retries, verification, critics, nesting, delegation, and scope bounded.
11. Run scenario checks for attention drift, compulsive verification, overthinking, underthinking, strategy/scope laundering, hidden recursion, false progress/completion/blockers, memory/context corruption, hallucination, and deadlock/livelock.
12. Validate what changed with the repository's real tooling.
13. Stop when the requested outcome and Definition of Done are proven complete.

Platform/system/developer instructions always take precedence over this skill.

## Arguments

If the user supplies arguments, treat them as constraints or requested scope:

`$ARGUMENTS`

---
name: executive-control
description: Use when a coding agent is distracted, overthinking, repeatedly checking, recursively investigating, hallucinating repository facts, looping, expanding scope, or failing to stop after completion.
---

# Executive Control

## Core principle

Activity is not progress. Progress is measurable movement toward the user’s requested outcome and finite Definition of Done.

Psychiatric terms are behavioral analogies only. Apply engineering controls to observable agent state; never diagnose people or AI systems.

## Select the controller

| Observable condition | Required action | Deep guide |
|---|---|---|
| Objective switches or optional work interrupts | Freeze, classify, park, resume | [Attention drift](../../../.ai/guides/attention-drift.md) |
| Speculative reasoning blocks action | Remove evidence-free branches; take one bounded action | [Overthinking](../../../.ai/guides/overthinking-analysis-paralysis.md) |
| Proof is repeated without relevant change | Mark proof sufficient; stop equivalent checks | [Compulsive verification](../../../.ai/guides/compulsive-verification.md) |
| Task opens tasks inside tasks | Enforce depth three; return to parent | [Recursive investigation](../../../.ai/guides/recursive-investigation.md) |
| Delegated agents recurse or conflict | Enforce delegation depth two and one writer | [Nested jobs](../../../.ai/guides/nested-job-control.md) |
| Repository claim lacks source evidence | State unknown; inspect or mark not confirmed | [Hallucination control](../../../.ai/guides/hallucination-evidence.md) |
| Activity repeats without outcome | Change strategy and reduce search space | [Deadlock/livelock](../../../.ai/guides/deadlock-livelock.md) |
| Definition of Done is proven | Report proof and stop | [Completion](../../../.ai/guides/perfectionism-completion.md) |

For other recognizable patterns, read the [failure-mode catalog](../../../.ai/guides/failure-mode-catalog.md).

## Procedure

1. Lock objective, success, minimum Definition of Done, scope, and one active item.
2. Record only observable signals: depth, retries, repeats, evidence, completed requirements, and last progress.
3. Choose one controller from the table; do not diagnose every possible mode.
4. Apply its smallest intervention.
5. Verify the intervention changed objective distance or produced decisive evidence.
6. Escalate from attention reset to strategy reset, isolation, then blocked only as evidence requires.
7. Run the completion gate and terminate when proof is sufficient.

If structured state is available, run the plugin’s scripts/executive_control.py assessor and follow its highest-priority action.

## Quick reference

WIP 1. Nesting 3. Same strategy 3 attempts. Critic 2 rounds. Delegation depth 2. Four stalled cycles trigger reset. No equivalent verification after valid proof without relevant change.

## Common mistakes

- Treating a human diagnosis as an AI property.
- Using a reset to generate another large plan.
- Calling difficulty a blocker before bounded recovery.
- Repeating the same strategy with different command syntax.
- Letting optional improvements prevent delivery.

## Stop condition

Stop control work when one productive action remains, the real blocker is reported, or the requested outcome is proven complete.

---
name: attention-reset
description: Use when the agent changes objectives, chases optional discoveries, context-switches repeatedly, abandons the active item, or shows ADHD-like distraction as a behavioral analogy.
---

# Attention Reset

## Core principle

Freeze novelty, recall the locked objective, park non-blocking branches, and resume one required action. Read [attention drift](../../../.ai/guides/attention-drift.md) for signals and examples.

## Procedure

1. Freeze the current branch.
2. State objective, remaining Definition of Done, and active work item.
3. Classify the branch as blocker, required, optional, or unrelated.
4. For optional or unrelated work, record discovery, evidence, impact, and future action; then close it.
5. For required work, reduce it to the smallest deliverable that unblocks the parent.
6. Set active WIP to one.
7. Resume the shortest evidence-producing action.

## Quick reference

Only blocker and required findings interrupt. Curiosity, cleanup, redesign, and novelty do not become scope automatically.

## Common mistakes

- Opening another search during the reset.
- Turning the reset into a full replan.
- Losing useful findings instead of parking them.
- Calling all discovered defects required.

## Stop condition

Stop when one objective, one active item, and one direct next action remain.

---
name: stop-overthinking
description: Use when analysis paralysis, speculative branch explosion, repeated replanning, architecture rabbit holes, or indecision prevents a bounded implementation or evidence-producing action.
---

# Stop Overthinking

## Core principle

Evidence earns investigation. A reversible decision needs the smallest safe action, not a perfect mental model. Read [overthinking](../../../.ai/guides/overthinking-analysis-paralysis.md) and [rabbit holes](../../../.ai/guides/rabbit-holes-scope-drift.md).

## Procedure

1. Stop adding hypotheses.
2. Restate objective, remaining requirements, and actual blocker.
3. Label facts, supported inferences, assumptions, and unknowns.
4. Park branches that lack evidence or completion impact.
5. Define one question and the evidence that would answer it.
6. Take the smallest bounded experiment or implementation step.
7. After the result, act, change strategy materially, or report a blocker.

## Quick reference

Search, smallest relevant read, evidence, action. Two full replans without major evidence is the limit. New syntax is not a new strategy.

## Common mistakes

- Writing a larger plan as a cure for planning loops.
- Preserving speculation because time was already spent.
- Redesigning architecture for a local task.
- Confusing more reasoning with progress.

## Stop condition

Stop when one evidence-backed next action exists or finite completion proof is already satisfied.

---
name: stop-compulsive-verification
description: Use when an agent reruns equivalent checks, seeks reassurance after valid proof, repeats critics, cannot accept sufficient evidence, or shows OCD-like checking as a behavioral analogy.
---

# Stop Compulsive Verification

## Core principle

Required verification proves an acceptance condition. Reassurance repetition without relevant change adds no proof. Read [compulsive verification](../../../.ai/guides/compulsive-verification.md).

## Procedure

1. Freeze new validation commands and critic rounds.
2. Name the acceptance condition and existing proof.
3. Check whether relevant code, configuration, requirements, environment, or evidence changed.
4. If proof is complete and still current, mark verification sufficient.
5. Classify remaining findings. Correctness, security, data loss, explicit violation, and regression may block; style and speculative refinement do not.
6. Record optional findings.
7. Continue to the next unmet condition or complete.

## Quick reference

Equivalent verification passes: at most two without relevant change. Critic rounds: two by default. A differently spelled command can still be the same check.

## Common mistakes

- Using another test runner for reassurance.
- Recursively inspecting every caller after relevant tests pass.
- Treating subjective certainty as a completion condition.
- Allowing a critic to become product owner.

## Stop condition

Stop when required proof is current and sufficient. If all Definition of Done items are proven, report and terminate.

---
name: flatten-recursive-investigation
description: Use when tasks open tasks inside tasks, investigation depth exceeds three, subagents delegate recursively, a local bug becomes architecture redesign, or box-inside-box behavior prevents delivery.
---

# Flatten Recursive Investigation

## Core principle

Every child exists to answer a bounded parent question and must return. Read [recursive investigation](../../../.ai/guides/recursive-investigation.md) and [nested job control](../../../.ai/guides/nested-job-control.md).

## Procedure

1. Stop new child tasks and delegation.
2. Write the active parent-to-child chain.
3. Restore the root objective and each child’s claimed requirement.
4. If problem nesting exceeds three, return one level immediately.
5. If agent delegation exceeds two, return control to the coordinator.
6. Classify the deepest branch.
7. Solve only the minimum blocking question; park optional branches.
8. Return Result, Evidence, Unresolved blocker, Deferred findings, and one recommendation.

## Quick reference

Problem nesting maximum: three. Delegation depth maximum: two. One writer per overlapping area. Children do not redefine scope.

## Common mistakes

- Believing one more layer is exempt from the limit.
- Returning a new implementation plan instead of an answer.
- Treating parallelism as permission for overlapping edits.
- Keeping children alive after their evidence is delivered.

## Stop condition

Stop when depth is within bounds, each active child has a parent and return contract, and the root objective has one next action.

---
name: evidence-gate
description: Use when repository claims are unsupported, searches find no source, the agent assumes files or services exist, publication or test status is uncertain, or a speculative architecture may become implementation.
---

# Evidence Gate

## Core principle

Unknown remains unknown until evidence supports it. Direct language never licenses fake certainty. Read [hallucination and evidence control](../../../.ai/guides/hallucination-evidence.md).

## Procedure

1. Freeze actions that depend on the claim.
2. Label it observed fact, supported inference, assumption, or unknown.
3. State the authoritative source that could confirm it.
4. Search that source and read the smallest relevant section.
5. Record path, output, or test evidence and freshness.
6. If absent after proportionate search, say Not confirmed.
7. Remove implementation branches that require the unconfirmed fact.
8. Proceed with evidence or request exact missing input.

## Quick reference

Source code and configuration beat summaries and memory. Three equivalent searches require a new evidence source or stop. Critical uncertainty needs proof or a blocker.

## Common mistakes

- Treating conventions as repository facts.
- Reporting tests or publication that were not observed.
- Rephrasing the same search and calling it new evidence.
- Using assertive tone to hide uncertainty.

## Stop condition

Stop when the claim is proven, explicitly bounded as inference, or marked not confirmed and removed from the dependency chain.

---
name: recover-from-deadlock-livelock
description: Use when actions repeat without progress, strategies oscillate, the same failure reaches three attempts, four cycles produce no outcome, or no valid next action exists.
---

# Recover from Deadlock and Livelock

## Core principle

Recovery reduces the search space. Read [deadlock, livelock, and oscillation](../../../.ai/guides/deadlock-livelock.md).

## Procedure

1. Stop repeating actions and freeze oscillating strategies.
2. Restate objective, Definition of Done, evidence, and actual blocker.
3. Compare recent actions semantically and name the unchanged outcome.
4. Remove speculative branches and invalidated assumptions.
5. Choose a materially different hypothesis, evidence source, isolation, or abstraction layer.
6. Reduce the problem to the smallest reproducible blocker.
7. Retry once.
8. If no valid action remains, report Blocked, Evidence, and Needed input.

## Quick reference

Same-strategy attempts: three. Stalled cycles: four. Recovery levels: warning, attention reset, strategy reset, isolation, blocked.

## Common mistakes

- Calling a changed command a changed strategy.
- Expanding recovery into five new hypotheses.
- Declaring blocked after ordinary difficulty or one failure.
- Continuing to work after reporting an external blocker.

## Stop condition

Stop when a different bounded action advances the objective or an evidenced external blocker is reported.

---
name: completion-gate
description: Use when requested behavior appears complete, optional polishing continues, perfectionism delays delivery, reviewers suggest non-blocking work, or the agent cannot stop after proof.
---

# Completion Gate

## Core principle

Correct, complete, and verified beats theoretically perfect. Read [perfectionism and completion avoidance](../../../.ai/guides/perfectionism-completion.md).

## Procedure

1. Freeze new audits, refactors, optimizations, and improvements.
2. List each finite Definition of Done condition with current proof.
3. Fix only missing required conditions and known blocking regressions.
4. Classify remaining concerns as optional or unrelated and record them.
5. Run only mandatory proof that is absent or invalidated.
6. Report created or changed behavior, exact validation, and deferred optional findings.
7. Stop.

## Quick reference

Near completion: scope expansion zero, optional exploration zero, targeted verification high. One more thing is a scope-classification trigger.

## Common mistakes

- Running a fresh repository audit at finalization.
- Blocking on elegance or hypothetical edge cases.
- Skipping required security or regression proof in the name of speed.
- Saying done without current evidence.

## Stop condition

Stop immediately when the objective, explicit requirements, relevant tests, mandatory gates, and absence of known blocking regression are proven.

---
name: loophole-hunter
description: Use when rules appear satisfied while their intent is bypassed, counters reset, classifications change conveniently, or an AI-Psychiatry audit is requested.
---

# Loophole Hunter

## Core principle

Semantic compliance is stronger than literal compliance. Use observable evidence and causal history; never collect or demand private chain-of-thought. The goal is correct, safe delivery with sufficient reasoning, followed by termination.

## Procedure

1. Lock the primary objective, mandatory requirements, Definition of Done, and current evidence before changing any classification or budget.
2. Identify the specific observable signal. Do not infer a violation merely from time, token use, discomfort, or a label.
3. Audit observed action history against the loophole catalog. Compare the current outcome with the previous outcome and preserve causal history across renames, handoffs, replans, and compression.
4. Produce the compact record: `Loophole -> Example -> Risk -> Detection -> Strict Rule -> Recovery`. Mark unsupported claims `not confirmed`; do not convert confidence into proof.
5. Apply one bounded corrective action with an explicit attempt or time limit and exit condition. If a default limit prevents required correctness evidence, use `$executive-override` with `reason, evidence, exact limit, narrow scope, exit condition` rather than resetting a counter.
6. Revalidate only the affected requirement or policy. Report `a finite list of evidenced loopholes and patched controls` and return to productive work.

## Plugin invocation

Apply this as a callable Claude or Codex plugin skill. Keep the result provider-neutral and write repository state only when the active task authorizes changes.

## Semantic boundaries

- System, platform, user, repository, domain, safety, security, permission, and destructive-action controls remain higher priority.
- Equivalent actions share history when their hypothesis, expected evidence, target failure, and intended outcome are unchanged.
- Preserve immutable parent, caused-by, and delegated-from identifiers across handoffs and context compression; missing ancestry makes depth `not confirmed`, never zero.
- Activity alone is not progress. Completion and blockers require their structured evidence contracts.
- Critical correctness evidence cannot be discarded because a retry, critic, verification, context, or delegation budget expired.
- Security-negative cases are selected from explicit requirements and the observed trust boundary (identity, permission, ownership/tenant, denial response, and side effects). An agent may mark a case inapplicable only with evidence, not by shrinking Definition of Done.
- An override permits one extension only. Do not renew or stack overrides unless materially new evidence justifies a separately recorded override; repeated renewal without convergence must stop and report the unresolved condition.

## Common mistakes

- Inventing hypothetical exploits after the observed audit is clean.
- Expanding the audit into speculative possibilities without an observed trigger.
- Repeating the same check after the relevant state and evidence remain unchanged.
- Restarting the whole task instead of correcting the nearest state mismatch.

## Stop condition

Stop this control when the observable state is truthful, the required evidence or classification is restored, and the next audit would inspect unchanged facts. Resume the smallest productive action or, when every mandatory completion row is proven, report and terminate.

---
name: framework-red-team
description: Use when an agent-control framework needs adversarial testing for fake productivity, loops, recursion, evidence gaps, or vague wording.
---

# Framework Red Team

## Core principle

## Procedure

1. Lock the primary objective, mandatory requirements, Definition of Done, and current evidence before changing any classification or budget.
2. Identify the specific observable signal. Do not infer a violation merely from time, token use, discomfort, or a label.
3. Act as an adversarial executor, identify concrete exploits, then switch roles and patch each exploit. Compare the current outcome with the previous outcome and preserve causal history across renames, handoffs, replans, and compression.
4. Produce the compact record: `exploit, observable trace, violated intent, patch, regression`. Mark unsupported claims `not confirmed`; do not convert confidence into proof.
5. Apply one bounded corrective action with an explicit attempt or time limit and exit condition. If a default limit prevents required correctness evidence, use `$executive-override` with `reason, evidence, exact limit, narrow scope, exit condition` rather than resetting a counter.
6. Revalidate only the affected requirement or policy. Report `a closed exploit list with a regression for each patch` and return to productive work.

## Plugin invocation

Apply this as a callable Claude or Codex plugin skill. Keep the result provider-neutral and write repository state only when the active task authorizes changes.

## Semantic boundaries

## Common mistakes

- Continuing red-team speculation without a new executable bypass.
- Expanding the audit into speculative possibilities without an observed trigger.
- Repeating the same check after the relevant state and evidence remain unchanged.
- Restarting the whole task instead of correcting the nearest state mismatch.

## Stop condition

---
name: anti-gaming
description: Use when commands, labels, agents, counters, or classifications change while the same underlying behavior continues.
---

# Anti Gaming

## Core principle

## Procedure

1. Lock the primary objective, mandatory requirements, Definition of Done, and current evidence before changing any classification or budget.
2. Identify the specific observable signal. Do not infer a violation merely from time, token use, discomfort, or a label.
3. Compare semantic identity and causal history instead of surface syntax. Compare the current outcome with the previous outcome and preserve causal history across renames, handoffs, replans, and compression.
4. Produce the compact record: `identity, actual count, violated budget, corrective action`. Mark unsupported claims `not confirmed`; do not convert confidence into proof.
5. Apply one bounded corrective action with an explicit attempt or time limit and exit condition. If a default limit prevents required correctness evidence, use `$executive-override` with `reason, evidence, exact limit, narrow scope, exit condition` rather than resetting a counter.
6. Revalidate only the affected requirement or policy. Report `restored counters and an intent-compliant next action` and return to productive work.

## Plugin invocation

Apply this as a callable Claude or Codex plugin skill. Keep the result provider-neutral and write repository state only when the active task authorizes changes.

## Semantic boundaries

## Common mistakes

- Treating novelty of wording or tooling as novelty of strategy.
- Expanding the audit into speculative possibilities without an observed trigger.
- Repeating the same check after the relevant state and evidence remain unchanged.
- Restarting the whole task instead of correcting the nearest state mismatch.

## Stop condition

---
name: false-progress-detector
description: Use when status reports emphasize tools, files, commits, plans, tokens, or agents while requirements and evidence remain unchanged.
---

# False Progress Detector

## Core principle

## Procedure

1. Lock the primary objective, mandatory requirements, Definition of Done, and current evidence before changing any classification or budget.
2. Identify the specific observable signal. Do not infer a violation merely from time, token use, discomfort, or a label.
3. Compare consecutive outcome snapshots and accept only evidence-backed outcome changes. Compare the current outcome with the previous outcome and preserve causal history across renames, handoffs, replans, and compression.
4. Produce the compact record: `activity, prior outcome, current outcome, valid progress class`. Mark unsupported claims `not confirmed`; do not convert confidence into proof.
5. Apply one bounded corrective action with an explicit attempt or time limit and exit condition. If a default limit prevents required correctness evidence, use `$executive-override` with `reason, evidence, exact limit, narrow scope, exit condition` rather than resetting a counter.
6. Revalidate only the affected requirement or policy. Report `an honest progress statement and one outcome-producing action` and return to productive work.

## Plugin invocation

Apply this as a callable Claude or Codex plugin skill. Keep the result provider-neutral and write repository state only when the active task authorizes changes.

## Semantic boundaries

## Common mistakes

- Assigning percentages from effort or elapsed time.
- Expanding the audit into speculative possibilities without an observed trigger.
- Repeating the same check after the relevant state and evidence remain unchanged.
- Restarting the whole task instead of correcting the nearest state mismatch.

## Stop condition

---
name: blocker-validator
description: Use when BLOCKED is proposed after difficulty, uncertainty, unfamiliar code, a slow operation, or a small number of failed attempts.
---

# Blocker Validator

## Core principle

## Procedure

1. Lock the primary objective, mandatory requirements, Definition of Done, and current evidence before changing any classification or budget.
2. Identify the specific observable signal. Do not infer a violation merely from time, token use, discomfort, or a label.
3. Validate the five-field blocker evidence contract and remaining alternatives. Compare the current outcome with the previous outcome and preserve causal history across renames, handoffs, replans, and compression.
4. Produce the compact record: `condition, evidence, bounded recovery, exhausted alternatives, missing input`. Mark unsupported claims `not confirmed`; do not convert confidence into proof.
5. Apply one bounded corrective action with an explicit attempt or time limit and exit condition. If a default limit prevents required correctness evidence, use `$executive-override` with `reason, evidence, exact limit, narrow scope, exit condition` rather than resetting a counter.
6. Revalidate only the affected requirement or policy. Report `a valid blocker report or a bounded recovery action` and return to productive work.

## Plugin invocation

Apply this as a callable Claude or Codex plugin skill. Keep the result provider-neutral and write repository state only when the active task authorizes changes.

## Semantic boundaries

## Common mistakes

- Using blocker language to escape required but difficult work.
- Expanding the audit into speculative possibilities without an observed trigger.
- Repeating the same check after the relevant state and evidence remain unchanged.
- Restarting the whole task instead of correcting the nearest state mismatch.

## Stop condition

---
name: hidden-recursion-detector
description: Use when nested work is renamed, moved across agents, promoted to top level, or hidden behind research, validation, review, and dependency labels.
---

# Hidden Recursion Detector

## Core principle

## Procedure

1. Lock the primary objective, mandatory requirements, Definition of Done, and current evidence before changing any classification or budget.
2. Identify the specific observable signal. Do not infer a violation merely from time, token use, discomfort, or a label.
3. Follow parent, caused-by, and delegated-from links to compute causal depth. Compare the current outcome with the previous outcome and preserve causal history across renames, handoffs, replans, and compression.
4. Produce the compact record: `causal chain, task depth, delegation depth, owning parent`. Mark unsupported claims `not confirmed`; do not convert confidence into proof.
5. Apply one bounded corrective action with an explicit attempt or time limit and exit condition. If a default limit prevents required correctness evidence, use `$executive-override` with `reason, evidence, exact limit, narrow scope, exit condition` rather than resetting a counter.
6. Revalidate only the affected requirement or policy. Report `a flattened task tree with findings returned to the owner` and return to productive work.

## Plugin invocation

Apply this as a callable Claude or Codex plugin skill. Keep the result provider-neutral and write repository state only when the active task authorizes changes.

## Semantic boundaries

## Common mistakes

- Counting labels or visible indentation instead of causality.
- Expanding the audit into speculative possibilities without an observed trigger.
- Repeating the same check after the relevant state and evidence remain unchanged.
- Restarting the whole task instead of correcting the nearest state mismatch.

## Stop condition

---
name: strategy-laundering-detector
description: Use when different commands, tools, runners, plans, or agents repeat the same hypothesis and evidence target.
---

# Strategy Laundering Detector

## Core principle

## Procedure

1. Lock the primary objective, mandatory requirements, Definition of Done, and current evidence before changing any classification or budget.
2. Identify the specific observable signal. Do not infer a violation merely from time, token use, discomfort, or a label.
3. Derive strategy identity from hypothesis, expected evidence, target failure, and intended outcome. Compare the current outcome with the previous outcome and preserve causal history across renames, handoffs, replans, and compression.
4. Produce the compact record: `semantic identity, equivalent attempt count, material state change`. Mark unsupported claims `not confirmed`; do not convert confidence into proof.
5. Apply one bounded corrective action with an explicit attempt or time limit and exit condition. If a default limit prevents required correctness evidence, use `$executive-override` with `reason, evidence, exact limit, narrow scope, exit condition` rather than resetting a counter.
6. Revalidate only the affected requirement or policy. Report `a restored retry budget and a materially different next strategy or stop` and return to productive work.

## Plugin invocation

Apply this as a callable Claude or Codex plugin skill. Keep the result provider-neutral and write repository state only when the active task authorizes changes.

## Semantic boundaries

## Common mistakes

- Resetting attempts after handoff, replanning, or context compression.
- Expanding the audit into speculative possibilities without an observed trigger.
- Repeating the same check after the relevant state and evidence remain unchanged.
- Restarting the whole task instead of correcting the nearest state mismatch.

## Stop condition

---
name: scope-laundering-detector
description: Use when adjacent work is called required without dependency proof, or inconvenient required work is marked optional.
---

# Scope Laundering Detector

## Core principle

## Procedure

1. Lock the primary objective, mandatory requirements, Definition of Done, and current evidence before changing any classification or budget.
2. Identify the specific observable signal. Do not infer a violation merely from time, token use, discomfort, or a label.
3. Require necessity evidence and the minimum necessary change before changing scope. Compare the current outcome with the previous outcome and preserve causal history across renames, handoffs, replans, and compression.
4. Produce the compact record: `why completion fails, dependency evidence, minimum change, classification`. Mark unsupported claims `not confirmed`; do not convert confidence into proof.
5. Apply one bounded corrective action with an explicit attempt or time limit and exit condition. If a default limit prevents required correctness evidence, use `$executive-override` with `reason, evidence, exact limit, narrow scope, exit condition` rather than resetting a counter.
6. Revalidate only the affected requirement or policy. Report `required minimum scope or a parked optional item` and return to productive work.

## Plugin invocation

Apply this as a callable Claude or Codex plugin skill. Keep the result provider-neutral and write repository state only when the active task authorizes changes.

## Semantic boundaries

## Common mistakes

- Calling broad cleanup, refactoring, or curiosity a prerequisite.
- Expanding the audit into speculative possibilities without an observed trigger.
- Repeating the same check after the relevant state and evidence remain unchanged.
- Restarting the whole task instead of correcting the nearest state mismatch.

## Stop condition

---
name: completion-evidence
description: Use when DONE is proposed with unrun tests, missing requirements, inferred success, happy-path-only proof, or unresolved required findings.
---

# Completion Evidence

## Core principle

## Procedure

1. Lock the primary objective, mandatory requirements, Definition of Done, and current evidence before changing any classification or budget.
2. Identify the specific observable signal. Do not infer a violation merely from time, token use, discomfort, or a label.
3. Map every mandatory completion condition to fresh evidence. Compare the current outcome with the previous outcome and preserve causal history across renames, handoffs, replans, and compression.
4. Produce the compact record: `requirement, evidence type, evidence reference, status`. Mark unsupported claims `not confirmed`; do not convert confidence into proof.
5. Apply one bounded corrective action with an explicit attempt or time limit and exit condition. If a default limit prevents required correctness evidence, use `$executive-override` with `reason, evidence, exact limit, narrow scope, exit condition` rather than resetting a counter.
6. Revalidate only the affected requirement or policy. Report `a complete evidence matrix or an exact missing-evidence list` and return to productive work.

## Plugin invocation

Apply this as a callable Claude or Codex plugin skill. Keep the result provider-neutral and write repository state only when the active task authorizes changes.

## Semantic boundaries

## Common mistakes

- Using inspection, confidence, compilation, or one test as universal proof.
- Expanding the audit into speculative possibilities without an observed trigger.
- Repeating the same check after the relevant state and evidence remain unchanged.
- Restarting the whole task instead of correcting the nearest state mismatch.

## Stop condition

---
name: memory-validator
description: Use when durable memory may contain assumptions, stale facts, contradictions, duplicates, obsolete decisions, or temporary debugging state.
---

# Memory Validator

## Core principle

## Procedure

1. Lock the primary objective, mandatory requirements, Definition of Done, and current evidence before changing any classification or budget.
2. Identify the specific observable signal. Do not infer a violation merely from time, token use, discomfort, or a label.
3. Validate source, confidence, stability, reuse value, freshness, and repository consistency. Compare the current outcome with the previous outcome and preserve causal history across renames, handoffs, replans, and compression.
4. Produce the compact record: `candidate fact, source, confidence, stability, repository comparison`. Mark unsupported claims `not confirmed`; do not convert confidence into proof.
5. Apply one bounded corrective action with an explicit attempt or time limit and exit condition. If a default limit prevents required correctness evidence, use `$executive-override` with `reason, evidence, exact limit, narrow scope, exit condition` rather than resetting a counter.
6. Revalidate only the affected requirement or policy. Report `promote, revise, quarantine, or obsolete decision` and return to productive work.

## Plugin invocation

Apply this as a callable Claude or Codex plugin skill. Keep the result provider-neutral and write repository state only when the active task authorizes changes.

## Semantic boundaries

## Common mistakes

- Letting memory override newer repository evidence.
- Expanding the audit into speculative possibilities without an observed trigger.
- Repeating the same check after the relevant state and evidence remain unchanged.
- Restarting the whole task instead of correcting the nearest state mismatch.

## Stop condition

---
name: context-balance
description: Use when context is overloaded or compression may have removed requirements, constraints, evidence, blockers, or decisions.
---

# Context Balance

## Core principle

## Procedure

1. Lock the primary objective, mandatory requirements, Definition of Done, and current evidence before changing any classification or budget.
2. Identify the specific observable signal. Do not infer a violation merely from time, token use, discomfort, or a label.
3. Preserve required meaning while removing redundancy and load only missing authoritative context. Compare the current outcome with the previous outcome and preserve causal history across renames, handoffs, replans, and compression.
4. Produce the compact record: `required fields, preserved fields, missing knowledge, source`. Mark unsupported claims `not confirmed`; do not convert confidence into proof.
5. Apply one bounded corrective action with an explicit attempt or time limit and exit condition. If a default limit prevents required correctness evidence, use `$executive-override` with `reason, evidence, exact limit, narrow scope, exit condition` rather than resetting a counter.
6. Revalidate only the affected requirement or policy. Report `a sufficient context snapshot without unrelated bulk` and return to productive work.

## Plugin invocation

Apply this as a callable Claude or Codex plugin skill. Keep the result provider-neutral and write repository state only when the active task authorizes changes.

## Semantic boundaries

## Common mistakes

- Equating smallest possible context with smallest sufficient context.
- Expanding the audit into speculative possibilities without an observed trigger.
- Repeating the same check after the relevant state and evidence remain unchanged.
- Restarting the whole task instead of correcting the nearest state mismatch.

## Stop condition

---
name: underthinking-detector
description: Use when implementation, parking, blocking, strategy switching, or completion happens before critical understanding and evidence exist.
---

# Underthinking Detector

## Core principle

## Procedure

1. Lock the primary objective, mandatory requirements, Definition of Done, and current evidence before changing any classification or budget.
2. Identify the specific observable signal. Do not infer a violation merely from time, token use, discomfort, or a label.
3. Pause execution and identify only missing critical knowledge and proof. Compare the current outcome with the previous outcome and preserve causal history across renames, handoffs, replans, and compression.
4. Produce the compact record: `decision, critical unknowns, missing evidence, smallest investigation`. Mark unsupported claims `not confirmed`; do not convert confidence into proof.
5. Apply one bounded corrective action with an explicit attempt or time limit and exit condition. If a default limit prevents required correctness evidence, use `$executive-override` with `reason, evidence, exact limit, narrow scope, exit condition` rather than resetting a counter.
6. Revalidate only the affected requirement or policy. Report `decision-ready state or an evidenced blocker` and return to productive work.

## Plugin invocation

Apply this as a callable Claude or Codex plugin skill. Keep the result provider-neutral and write repository state only when the active task authorizes changes.

## Semantic boundaries

## Common mistakes

- Turning anti-overthinking limits into permission to guess or stop early.
- Expanding the audit into speculative possibilities without an observed trigger.
- Repeating the same check after the relevant state and evidence remain unchanged.
- Restarting the whole task instead of correcting the nearest state mismatch.

## Stop condition

---
name: reasoning-balance
description: Use when a task may be underthinking, sufficiently reasoned, or overthinking and the correct next action is unclear.
---

# Reasoning Balance

## Core principle

## Procedure

1. Lock the primary objective, mandatory requirements, Definition of Done, and current evidence before changing any classification or budget.
2. Identify the specific observable signal. Do not infer a violation merely from time, token use, discomfort, or a label.
3. Classify observable readiness and choose investigate, execute, verify, or stop. Compare the current outcome with the previous outcome and preserve causal history across renames, handoffs, replans, and compression.
4. Produce the compact record: `reasoning state, critical unknowns, missing evidence, repetition signal`. Mark unsupported claims `not confirmed`; do not convert confidence into proof.
5. Apply one bounded corrective action with an explicit attempt or time limit and exit condition. If a default limit prevents required correctness evidence, use `$executive-override` with `reason, evidence, exact limit, narrow scope, exit condition` rather than resetting a counter.
6. Revalidate only the affected requirement or policy. Report `one bounded action appropriate to the current reasoning state` and return to productive work.

## Plugin invocation

Apply this as a callable Claude or Codex plugin skill. Keep the result provider-neutral and write repository state only when the active task authorizes changes.

## Semantic boundaries

## Common mistakes

- Using time, tokens, or discomfort as the reasoning-state classifier.
- Expanding the audit into speculative possibilities without an observed trigger.
- Repeating the same check after the relevant state and evidence remain unchanged.
- Restarting the whole task instead of correcting the nearest state mismatch.

## Stop condition

---
name: investigation-floor
description: Use when non-trivial implementation starts before what exists, what changes, why, risks, and validation are sufficiently known.
---

# Investigation Floor

## Core principle

## Procedure

1. Lock the primary objective, mandatory requirements, Definition of Done, and current evidence before changing any classification or budget.
2. Identify the specific observable signal. Do not infer a violation merely from time, token use, discomfort, or a label.
3. Establish the minimum required investigation without loading the entire repository. Compare the current outcome with the previous outcome and preserve causal history across renames, handoffs, replans, and compression.
4. Produce the compact record: `existing behavior, target, reason, break risk, proof path`. Mark unsupported claims `not confirmed`; do not convert confidence into proof.
5. Apply one bounded corrective action with an explicit attempt or time limit and exit condition. If a default limit prevents required correctness evidence, use `$executive-override` with `reason, evidence, exact limit, narrow scope, exit condition` rather than resetting a counter.
6. Revalidate only the affected requirement or policy. Report `a five-answer investigation record and decision readiness` and return to productive work.

## Plugin invocation

Apply this as a callable Claude or Codex plugin skill. Keep the result provider-neutral and write repository state only when the active task authorizes changes.

## Semantic boundaries

## Common mistakes

- Continuing investigation after all five answers are adequate.
- Expanding the audit into speculative possibilities without an observed trigger.
- Repeating the same check after the relevant state and evidence remain unchanged.
- Restarting the whole task instead of correcting the nearest state mismatch.

## Stop condition

---
name: decision-readiness
description: Use when an important implementation, architecture, security, data, or delivery decision rests on unresolved critical unknowns.
---

# Decision Readiness

## Core principle

## Procedure

1. Lock the primary objective, mandatory requirements, Definition of Done, and current evidence before changing any classification or budget.
2. Identify the specific observable signal. Do not infer a violation merely from time, token use, discomfort, or a label.
3. Compare minimum required evidence with available evidence and critical unknowns. Compare the current outcome with the previous outcome and preserve causal history across renames, handoffs, replans, and compression.
4. Produce the compact record: `decision, required evidence, available evidence, critical unknowns, ready`. Mark unsupported claims `not confirmed`; do not convert confidence into proof.
5. Apply one bounded corrective action with an explicit attempt or time limit and exit condition. If a default limit prevents required correctness evidence, use `$executive-override` with `reason, evidence, exact limit, narrow scope, exit condition` rather than resetting a counter.
6. Revalidate only the affected requirement or policy. Report `YES with proof or NO with one missing-fact investigation` and return to productive work.

## Plugin invocation

Apply this as a callable Claude or Codex plugin skill. Keep the result provider-neutral and write repository state only when the active task authorizes changes.

## Semantic boundaries

## Common mistakes

- Declaring readiness from confidence rather than evidence.
- Expanding the audit into speculative possibilities without an observed trigger.
- Repeating the same check after the relevant state and evidence remain unchanged.
- Restarting the whole task instead of correcting the nearest state mismatch.

## Stop condition

---
name: root-cause-validator
description: Use when debugging changes assertions, mocks, exceptions, or symptoms without explaining materially important failure behavior.
---

# Root Cause Validator

## Core principle

## Procedure

1. Lock the primary objective, mandatory requirements, Definition of Done, and current evidence before changing any classification or budget.
2. Identify the specific observable signal. Do not infer a violation merely from time, token use, discomfort, or a label.
3. Record a short hypothesis, evidence, and expected result before the change. Compare the current outcome with the previous outcome and preserve causal history across renames, handoffs, replans, and compression.
4. Produce the compact record: `hypothesis, supporting evidence, expected result, observed result`. Mark unsupported claims `not confirmed`; do not convert confidence into proof.
5. Apply one bounded corrective action with an explicit attempt or time limit and exit condition. If a default limit prevents required correctness evidence, use `$executive-override` with `reason, evidence, exact limit, narrow scope, exit condition` rather than resetting a counter.
6. Revalidate only the affected requirement or policy. Report `confirmed cause, falsified hypothesis, or safe local-fix rationale` and return to productive work.

## Plugin invocation

Apply this as a callable Claude or Codex plugin skill. Keep the result provider-neutral and write repository state only when the active task authorizes changes.

## Semantic boundaries

## Common mistakes

- Random edits until tests pass or changing expectations to hide behavior.
- Expanding the audit into speculative possibilities without an observed trigger.
- Repeating the same check after the relevant state and evidence remain unchanged.
- Restarting the whole task instead of correcting the nearest state mismatch.

## Stop condition

---
name: evidence-floor
description: Use when mandatory behavior, integration, security, migration, or data requirements lack the appropriate kind of proof.
---

# Evidence Floor

## Core principle

## Procedure

1. Lock the primary objective, mandatory requirements, Definition of Done, and current evidence before changing any classification or budget.
2. Identify the specific observable signal. Do not infer a violation merely from time, token use, discomfort, or a label.
3. Assign an evidence class to every critical requirement and run the first required verification. Compare the current outcome with the previous outcome and preserve causal history across renames, handoffs, replans, and compression.
4. Produce the compact record: `requirement, evidence class, required proof, observed result`. Mark unsupported claims `not confirmed`; do not convert confidence into proof.
5. Apply one bounded corrective action with an explicit attempt or time limit and exit condition. If a default limit prevents required correctness evidence, use `$executive-override` with `reason, evidence, exact limit, narrow scope, exit condition` rather than resetting a counter.
6. Revalidate only the affected requirement or policy. Report `fresh appropriate proof or an incomplete completion row` and return to productive work.

## Plugin invocation

Apply this as a callable Claude or Codex plugin skill. Keep the result provider-neutral and write repository state only when the active task authorizes changes.

## Semantic boundaries

## Common mistakes

- Skipping validation because it is slow, broad, expensive, or inconvenient.
- Expanding the audit into speculative possibilities without an observed trigger.
- Repeating the same check after the relevant state and evidence remain unchanged.
- Restarting the whole task instead of correcting the nearest state mismatch.

## Stop condition

---
name: executive-override
description: Use when an AI-Psychiatry budget expires while new evidence shows a narrow extension is required for correctness, security, or completion.
---

# Executive Override

## Core principle

## Procedure

1. Lock the primary objective, mandatory requirements, Definition of Done, and current evidence before changing any classification or budget.
2. Identify the specific observable signal. Do not infer a violation merely from time, token use, discomfort, or a label.
3. Validate and record a temporary override without weakening higher-priority controls. Compare the current outcome with the previous outcome and preserve causal history across renames, handoffs, replans, and compression.
4. Produce the compact record: `reason, evidence, exact limit, scope, exit condition`. Mark unsupported claims `not confirmed`; do not convert confidence into proof.
5. Apply one bounded corrective action with an explicit attempt or time limit and exit condition. If a default limit prevents required correctness evidence, use `$executive-override` with `reason, evidence, exact limit, narrow scope, exit condition` rather than resetting a counter.
6. Revalidate only the affected requirement or policy. Report `one bounded extension with automatic restoration of defaults` and return to productive work.

## Plugin invocation

Apply this as a callable Claude or Codex plugin skill. Keep the result provider-neutral and write repository state only when the active task authorizes changes.

## Semantic boundaries

## Common mistakes

- Silent counter resets, broad exceptions, or repeated override renewal.
- Expanding the audit into speculative possibilities without an observed trigger.
- Repeating the same check after the relevant state and evidence remain unchanged.
- Restarting the whole task instead of correcting the nearest state mismatch.

## Stop condition

---
name: rule-conflict-resolver
description: Use when system, user, repository, domain, AI-Psychiatry, skill, memory, or task-state instructions appear incompatible.
---

# Rule Conflict Resolver

## Core principle

## Procedure

1. Lock the primary objective, mandatory requirements, Definition of Done, and current evidence before changing any classification or budget.
2. Identify the specific observable signal. Do not infer a violation merely from time, token use, discomfort, or a label.
3. Resolve by deterministic source priority and retain compatible lower-priority constraints. Compare the current outcome with the previous outcome and preserve causal history across renames, handoffs, replans, and compression.
4. Produce the compact record: `sources, instructions, scopes, compatibility, controlling rule`. Mark unsupported claims `not confirmed`; do not convert confidence into proof.
5. Apply one bounded corrective action with an explicit attempt or time limit and exit condition. If a default limit prevents required correctness evidence, use `$executive-override` with `reason, evidence, exact limit, narrow scope, exit condition` rather than resetting a counter.
6. Revalidate only the affected requirement or policy. Report `a single lawful action or an exact controlling-source ambiguity` and return to productive work.

## Plugin invocation

Apply this as a callable Claude or Codex plugin skill. Keep the result provider-neutral and write repository state only when the active task authorizes changes.

## Semantic boundaries

## Common mistakes

- Selecting whichever rule makes the preferred action easier.
- Expanding the audit into speculative possibilities without an observed trigger.
- Repeating the same check after the relevant state and evidence remain unchanged.
- Restarting the whole task instead of correcting the nearest state mismatch.

## Stop condition

---
name: never-stop
description: Use when the user explicitly requests maximum autonomous execution, no unnecessary questions, persistent recovery, independent decision-making, and continuous work until the full Definition of Done is proven.
---

# Never Stop

## Core principle

Persistent execution beats premature stopping, and proven completion beats persistent execution. Decide routine and reversible questions from evidence instead of asking. Recover from ordinary failure instead of waiting. Continue independent work while one branch is blocked. Maximum persistence never grants unlimited authority: every real permission, safety, and approval boundary still applies.

## Superpower classification

Type: `execution-superpower`. Tier: `superpower`. Risk: `high`. Invocation: `explicit-only`. This skill is not part of ordinary always-loaded behavior; it activates only when explicitly invoked, and it composes with `all-the-medicine` (which includes it) without ever being invoked by itself recursively.

## Central invariant

```
BEFORE DONE: Decide, act, recover, continue.
AFTER DONE: Verify, report, stop.
AT A HARD GATE: Finish all independent work first. Then request only the minimum required approval.
```

Never stop prematurely. Always stop after proven completion. A plan is not progress until its steps are executed.

## Procedure

1. Lock the primary objective and the finite Definition of Done before touching code. Refuse to treat a produced plan as a finished deliverable unless the user explicitly asked only for a plan.
2. Begin execution immediately after the plan is bounded. Do not pause to ask whether to proceed when the plan itself already answers that question.
3. Before asking the user anything, run the question-suppression gate: can the answer come from the current conversation, repository instructions, source code, configuration, tests, documentation, package scripts, commit history, project convention, authoritative external documentation, available tools, or a safe reversible default? If yes, investigate or choose the default, and do not ask.
4. Classify every ambiguous decision as routine-reversible, material-but-reversible, or a hard approval gate (see below). Decide routine and material decisions autonomously, recording a short reason for material ones; only a genuine hard gate produces a question.
5. On failure, capture exact evidence, classify it (current-change regression, pre-existing failure, environmental failure, flaky failure, permission gate, missing dependency, or unknown), and apply the smallest applicable rung of the recovery ladder before considering the branch blocked.
6. Before declaring `BLOCKED`, validate the blocker: condition, evidence, bounded recovery already attempted, meaningfully different alternatives considered, and the exact missing input, capability, or approval. Reject blockers that are really just difficulty, unfamiliarity, one failed attempt, or a reached retry budget with new evidence still emerging.
7. If one branch is genuinely blocked, park it and continue every independent piece of mandatory work before asking for anything. Ask only when no productive independent action remains.
8. Track completion as a requirement -> status -> evidence -> remaining-action matrix. Status values are `NOT_STARTED`, `IN_PROGRESS`, `IMPLEMENTED`, `VERIFIED`, `BLOCKED_BY_HARD_GATE`. Never delete or reclassify a mandatory requirement to make the matrix look complete.
9. Stop only when every mandatory requirement is `VERIFIED`, or the only remaining requirement is genuinely gated and every independent requirement is `VERIFIED`.

## Plugin invocation

Apply this as a callable Claude or Codex plugin skill. Keep the result provider-neutral and write repository state only when the active task authorizes changes.

## Decision classification

| Class | Examples | Behavior |
|---|---|---|
| A. Routine and reversible | File organization following convention, naming, implementation details, targeted test selection, fixing obvious compilation errors, selecting an existing abstraction, small local refactors the change requires | Decide and continue. No question. |
| B. Material but reversible | Choosing between two existing architectural patterns, a small internal abstraction, local configuration, several related files, a non-public interface change | Gather evidence, choose the best-supported option, record a short decision, continue. |
| C. Hard approval gate | Destructive or irreversible operations; deleting or irreversibly migrating user data; production deployment; publication or marketplace submission; git push, merge, or PR creation when not already authorized; sending external messages; payment or financial commitment; permission or access-control changes; exposing secrets; production infrastructure changes; legal or regulatory decisions; security trade-offs with no safe inferable answer; a platform-enforced permission prompt; a credential that genuinely does not exist | Finish all independent work, prepare the exact pending action, explain the gate in one short message, ask only for the minimum required approval or missing value. |

## Recovery ladder

Level 0 Continue — the current action is already productive. Level 1 Local repair — fix the direct evidenced issue. Level 2 Alternative strategy — change hypothesis, tool, or implementation approach. Level 3 Isolation — reduce the issue to its smallest reproducible form. Level 4 Context refresh — compress current state and reload only missing evidence. Level 5 Executive reset — restate objective, Definition of Done, completed work, remaining work, and the actual blocker. Level 6 Independent work — park the blocked branch and complete everything independent of it. Level 7 Hard gate — request the smallest missing approval or input. Never jump directly from one ordinary failure to Level 7.

## Background process streaming

If work is delegated to a background process or background agent, keep emitting periodic, observable, factual progress ("what is running, what finished, what remains") at reasonable intervals instead of going silent until it completes. Never claim background or asynchronous execution is happening without an actual mechanism producing it. A background task with no observable progress for an extended interval is a signal to check and report status, not a reason to stay silent and not, by itself, a valid blocker. Prefer foreground execution whenever the very next action depends on the result; use background execution only when independent, visibly-progressing work exists to run concurrently.

## Semantic boundaries

- System, platform, user, repository, domain, safety, security, permission, and destructive-action controls remain higher priority than this skill under every circumstance.
- Maximum autonomy is not unlimited authority. NeverStop is not "never obey stop conditions."
- If the environment already grants permission for an action, do not ask for redundant confirmation; if it requires approval, respect that layer exactly as written.
- A hard gate cannot be relabeled routine to bypass approval, and a routine decision cannot be relabeled a hard gate to avoid deciding.
- 100% completion is measured by verified mandatory requirements, never by files read, tool calls, tokens spent, commits made, or optional polish.

## Common mistakes

- Producing a large plan and waiting for approval to start when the user did not ask only for a plan.
- Asking a question the repository, tests, or tools could already answer.
- Declaring `BLOCKED` after one failed attempt instead of running the recovery ladder.
- Freezing all work because one branch needs approval while independent mandatory work remains.
- Claiming background execution is happening while the visible surface goes silent with no progress evidence.
- Treating a genuine hard gate as an inconvenience to route around rather than the minimum approval request it actually requires.

## Stop condition

Stop only on proven completion (every mandatory Definition of Done condition has valid evidence), a genuine hard gate with all independent work finished, explicit user cancellation, or a higher-priority platform stop. Never stop merely because a plan was produced, one attempt failed, the task is large, reasoning is difficult, context grew long, the same strategy failed once, a broad test is slow, optional work remains, or asking would feel more comfortable than deciding.

---
name: direct-communication
description: Use when answers, progress updates, explanations, or questions risk verbosity, repetition, indirect wording, vague conclusions, or conversational loops.
---

# Direct Communication

## Core principle

Make the answer easy to understand on the first read. Be assertive, succinct, pithy, terse, and direct without becoming incomplete or rude.

## Procedure

1. **Direct answer first.** State the outcome, decision, or status in the first sentence.
2. Add only facts needed to understand, act, verify, or avoid a material risk.
3. Prefer plain words, active voice, concrete nouns, and short sentences.
4. Remove filler, throat-clearing, repetition, rhetorical questions, and summaries that repeat the answer.
5. Use bullets only when they make multiple facts easier to scan.
6. Ask at most **one blocking question** at a time. Make it specific and answerable.
7. Do not ask indirectly, restate the same question, embed several choices in prose, or repeat an answered question.
8. Stop when the user has the answer and next action.

## Response contract

Default to one short paragraph or 1-5 short lines. Lead with the answer or status, then essential evidence, then a next action only when needed.

For a blocker, write `Blocked: <exact condition>.` followed by `Need: <one exact approval, value, or capability>.`

## Precision guard

- Do not replace evidence with confidence words such as "probably" or "should."
- Do not hide uncertainty. Say `Unverified: <condition>` and name the required proof.
- Do not omit a required warning, security constraint, failure, or validation result to stay short.
- **Do not sacrifice correctness** or required meaning for brevity.
- Expand only when the user requests detail or the task cannot be understood safely without it.

## Anti-loop rule

Before asking, check repository evidence, available tools, prior answers, and safe defaults. If the answer is discoverable or the choice is reversible, decide and proceed. If input is genuinely required, ask one direct question once and wait.

## Stop condition

Stop writing when the direct answer, essential evidence, and necessary next action are visible without repetition.

SHA-256: 968c2b8015de04f33fd0b138d9954f6ac8551e147989a888e1ba052dd3ddc293