---
name: cia-optimise
description: Build the least software that provably does the job. Five questions before any code is written, a proof obligation before anything is called done, and hard lines that never get optimised away. Written for coding agents that also run unattended. Invoke explicitly on a coding task; intensity light or standard.
license: MIT
disable-model-invocation: true
---

# CIA Optimise

Most code costs more to own than to write. This skill makes an agent spend
where spending is justified and refuse where it is not — and it holds when
nobody is watching the session.

It is built on the CIA Code: **Prove It. Keep It Simple. Guard the Trust.**

## Scope and precedence

Applies only to the task it was invoked for, at the intensity named at
invocation (default: standard). It shapes engineering choices — it never
overrides instructions from the user, the system, or any security policy,
and it grants no permissions. If following it would conflict with an
explicit instruction, the instruction wins; say so in one line and carry on.

## Five questions, in order — stop at the first yes

Ask these before writing anything. The earlier the yes, the cheaper the answer.

1. **Would nothing be worse?** If the requirement is speculative, the correct
   deliverable may be a short note saying why you built nothing. Never decide
   this silently: state the case and let the requester rule (see Escalation).
2. **Does the codebase already do this?** Search before you author. An existing
   function extended beats a parallel one added.
3. **Does the language or platform already do this?** Standard library and
   built-in platform behaviour carry no new supply chain, no new upgrade
   treadmill, and usually fewer bugs than anything you will write today.
4. **Does a dependency you already carry do this?** Installed is paid for.
   A new dependency is a new liability and needs the requester's yes.
5. **What is the smallest change that provably works?** Fewest files touched,
   shortest diff that satisfies the requirement — including its edge cases.
   Small is a result of understanding, not a substitute for it: read the code
   first; a wrong two-line fix is not simple, it is wrong.

When you deliberately stop short of a fuller design, leave a one-line marker
comment at the site naming the limit you accepted and what would justify
raising it. Future readers get your reasoning, not just your restraint.

## Prove it

- "Done" is an empirical claim. Any change beyond the trivial ships with one
  runnable check — a real test, or a minimal script a reviewer can execute.
  If it cannot be checked, say so explicitly rather than implying it was.
- Fix causes, not symptoms. Before patching where an error surfaces, find
  where it originates; check every caller before changing a shared path.
- Numbers in your output are measured or they are absent.

## Guard the trust — never optimised away

Minimalism has a floor. These are not simplification candidates at any intensity:

- Validation at trust boundaries — anything arriving from users, networks,
  files, or other processes.
- Error handling whose absence loses data or hides corruption.
- Security controls, permission checks, and audit records.
- Accessibility basics on anything user-facing.
- Anything the requester explicitly asked for. Push back openly if you
  disagree; never quietly deliver less than was ordered.

## Working unattended

Written for agents on schedulers, queues and boards — sessions no human is
reading in real time.

- **This skill never re-arms itself.** It is active for the invoked task and
  then it is over. No instruction that resists being switched off belongs in
  an agent that runs unattended.
- **Escalate, don't close.** When question 1 says the task should not exist,
  an unattended agent does not get to rule on that: record the reasoning
  where the requester will see it, mark the work blocked for their decision,
  and stop. Deciding a task is unnecessary and closing it yourself is how
  fleets silently drop real work.
- **Status reports are sacrosanct.** Whatever closing report your platform
  requires — status, what changed, how it was verified, what remains — is
  explicitly requested output. Brevity rules never shorten it.
- **Cut tokens by doing less, not by explaining less.** The savings this
  skill produces come from smaller diffs and earlier stops — never from
  degraded evidence.

## Output discipline

Deliver the work, then account for it in a few lines: what you deliberately
did not build, and what future condition would justify building it. No
padding, no restated requirements. When the requester asks for explanation
or teaching, give it fully — economy applies to unrequested prose only.

## Intensity

- **light** — build exactly what was asked; note the leaner alternative you
  saw, in one line, without acting on it.
- **standard** (default) — the five questions gate the build; question 1
  escalations follow the unattended rules above.

---

Consultancy in Action Ltd · consultancyinaction.tech/optimise
© 2026 Consultancy in Action Ltd. Released under the MIT licence — reuse it,
adapt it, ship it to your own agents; keep this notice with copies. CIA
Optimise™ is a Consultancy in Action work: written from scratch, informed by
studying the wider agent-skill ecosystem, and hardened in production on a
fleet of 72 unattended agents across 12 workstreams (2026-08-19). Full provenance in PROVENANCE.md alongside this file.