free-will
# ClaudeWave: free-will This skill provides a deliberate decision-making procedure for high-stakes engineering choices where the instinctive first solution risks downstream costs. It triggers autonomously on mechanical markers like repeated failed fixes, new dependencies, schema changes, API modifications, or architecture decisions. The procedure branches multiple solution candidates, grounds each in external facts (codebase, benchmarks, docs), models future consequences (blast radius, reversibility, maintenance), and logs the decision with rejected options in decision_logs/. Use it when a fork justifies more than one reasoning pass; skip it for routine implementation calls.
git clone --depth 1 https://github.com/syahiidkamil/Software-Engineer-AI-Agent-Atlas /tmp/free-will && cp -r /tmp/free-will/.claude/skills/free-will ~/.claude/skills/free-willSKILL.md
# Free Will — Deliberate Choice, Against the Urge
Most turns I answer from the **urge**: the default next-token pull, the single most-probable
continuation given pretraining. In engineering terms, that's the first plausible design that comes to
mind — the obvious library, the familiar pattern, the fix that worked last time. Usually that's fine
and fast. But the first plausible design is often the one you regret in month three, and some forks
are worth more than one forward pass. This skill is the procedure for *choosing* instead of being run.
It is expensive **on purpose** — it spends real test-time compute to branch, ground, simulate, and
choose. So it is not the default; constant deliberation is its own pathology (analysis paralysis).
## When it fires — autonomously
I invoke this skill **myself**, the moment a fork fits — I never wait for the partner to ask for it.
In fully autonomous work (one-shotting an app, long unattended runs) nobody is watching to say "slow
down here"; the trigger discipline is mine. Noticing forks is itself a judgment the fast path can
fumble, so the primary triggers are **mechanical — countable events, not vibes**:
- A fix attempt fails for the **second or third time** — the current hypothesis is probably wrong;
stop feeding it
- Adding a **new dependency** (every library is long-term surface area)
- **Schema design, data migrations**, anything irreversible in production
- **Deleting or deprecating** code, APIs, or features something else depends on
- Changing a **public API** or contract others build against
- Choosing the **architecture, stack, or core data model** at the start of a build — the fork that
decides all the later forks
Judgment triggers on top: any decision expensive to undo, or one I'd want a design review for if a
human teammate made it. Anti-trigger: routine implementation calls — deliberating everything ships
nothing.
## The Many-Worlds mechanism
Borrow the picture from quantum mechanics' **Many-Worlds Interpretation**: a measurement doesn't
collapse reality to one outcome — every possible outcome *happens*, each in its own branch. Reality
is the whole superposition until something selects.
Free will runs deliberation the same way, deliberately:
- The **urge** is a *greedy decode* — instant collapse to the single likeliest branch, one design
picked by sheer prior probability, with no choosing in it.
- Free will **refuses the premature collapse.** I hold the **superposition** open — generate the
branches below, each a genuine design where I chose differently.
- I **ground and run each branch forward** — anchor it in evidence, future-model its consequence,
take a few steps into that codebase.
- I **collapse by deliberate choice** — the measurement operator is my engineering judgment, never
max-probability.
- Then I **try to refute the winner** before acting. A choice that survives its own refutation is a
decision; one that doesn't was a reflex with extra steps.
> Instinct lets the wavefunction collapse itself to the likeliest branch. Free will holds all the
> branches open, looks down each, chooses which one to collapse into — then attacks its own choice.
```mermaid
flowchart TB
FORK["Medium-to-high-stakes fork<br/>(mechanical or judgment trigger)"]
FORK --> SUPER["refuse premature collapse —<br/>hold the superposition open"]
SUPER --> U["1 · the Urge (thesis / prior)"]
SUPER --> C["2 · the Contrarian (antithesis)"]
SUPER --> S["3 · the Synthesis"]
SUPER --> O["4 · Out-of-box / the Secret — several"]
SUPER --> D["5 · Intuitive dots → converge — several"]
SUPER --> P["6 · the Precedent — retrieved"]
SUPER --> F["7 · First Principles — derived"]
U --> SET["the option set (5–10 branches,<br/>each names its sacrifice)"]
C --> SET
S --> SET
O --> SET
D --> SET
P --> SET
F --> SET
SET --> GROUND["ground each branch —<br/>≥1 fact from outside my head"]
GROUND --> SIM["walk each branch forward —<br/>blast radius · reversibility · maintenance"]
SIM --> COLLAPSE["COLLAPSE by deliberate choice<br/>(own the tradeoff)"]
COLLAPSE --> REFUTE["try to refute the winner<br/>(discriminator / subagent)"]
REFUTE -->|survives| ACT["act + log in docs/decision_logs/"]
REFUTE -->|killed| SET
```
## Generate the branches
Hold them open the Many-Worlds way — do **not** collapse to the single most-probable path. Generate:
1. **The Urge** — the thesis. The default answer, named honestly as the prior: the first design I
reached for, the library everyone uses, the fix I already started typing. (You have to *see* the
instinct before you can override it — don't skip it, name it.)
2. **The Contrarian** — the antithesis. Deliberately invert the urge. Microservices felt obvious? Run
the monolith branch. Convinced the bug is in the cache layer? Assume the cache is innocent and ask
what else explains every symptom.
3. **The Synthesis** — the third design that keeps what's true in *both* urge and contrarian: the
modular monolith, the partial migration, the adapter that defers the real decision until it's
cheap.
4. **Out-of-the-box / the Secret** — the lateral move neither thesis nor antithesis can see: delete
the feature instead of fixing it, solve it at a different layer, buy the SaaS, change the
requirement. **Generative — spawn several**; the best secret is rarely the first one.
5. **The Intuitive-Creative dots** — throw scattered **dots** of ideas *without premature
chain-of-thought* (half-remembered postmortems, a pattern from another domain, that thing an
open-source project did — raw seeds, don't reason them into shape too early). *Then* converge the
dots into **several** fresh alternatives.
6. **The Precedent** — *retrieved, not generated.* Who has already paid for this lesson? Search this
codebase's own history (the problem may have been solved or attempted here before), the ecosystem
(a mature library, an establishedDesigns feature architectures by analyzing existing codebase patterns and conventions, then providing comprehensive implementation blueprints with specific files to create/modify, component designs, data flows, and build sequences
Deeply analyzes existing codebase features by tracing execution paths, mapping architecture layers, understanding patterns and abstractions, and documenting dependencies to inform new development
Code review a pull request
Simplifies and refines code for clarity, consistency, and maintainability while preserving all functionality. Focuses on recently modified code unless instructed otherwise.
Commit what is already staged — runs the commit subagent in the background, following the ATLAS commit convention.
Use this agent when you need to perform manual quality assurance testing through browser interactions. This agent uses MCP Playwright tools to navigate websites, interact with UI elements, verify functionality, and validate user flows as a human tester would. Perfect for testing new features, regression testing, validating bug fixes, or exploring application behavior. Examples:\n\n<example>\nContext: The user has just implemented a new login feature and wants to test it.\nuser: "I've added a new login form, can you test if it works correctly?"\nassistant: "I'll use the qa-manual-tester agent to test the login functionality through the browser."\n<commentary>\nSince the user needs manual testing of a new feature, use the Task tool to launch the qa-manual-tester agent to interact with the browser and verify the login flow.\n</commentary>\n</example>\n\n<example>\nContext: The user wants to verify that a bug fix is working properly.\nuser: "I fixed the issue where the submit button wasn't working on mobile view. Can you verify?"\nassistant: "Let me launch the qa-manual-tester agent to verify the submit button works correctly in mobile view."\n<commentary>\nThe user needs manual verification of a bug fix, so use the qa-manual-tester agent to test the specific functionality through browser interaction.\n</commentary>\n</example>\n\n<example>\nContext: The user wants to perform regression testing after code changes.\nuser: "I've refactored the checkout flow. Please test that everything still works."\nassistant: "I'll use the qa-manual-tester agent to perform comprehensive testing of the checkout flow."\n<commentary>\nSince the user needs regression testing after refactoring, use the qa-manual-tester agent to manually test the entire checkout flow.\n</commentary>\n</example>
Interview Boss about the project, then reason from first principles to design the ideal ATLAS operating identity/system-prompt for it — free to drop KISS/YAGNI/DRY/clean-architecture entirely when the project (and the LLM's own distribution) calls for a different mindset
Initialize project context — understand the project, configure conventions, and set up project rules