| name | simplest-safe-path |
| description | Use when a build, fix, plan, audit, skill, agent, or pipeline has more than one viable design and the agent must choose the simplest safe option or challenge unjustified complexity. |
| activation | Activate when the task presents design alternatives, proposes a new guardrail, stage, retry, fallback, dependency, abstraction, configuration surface, or review of complexity. Do not activate for a predetermined narrow edit unless a design choice appears. |
| required_inputs | Task objective, repository state, applicable APIVR tier, constraints, source-of-truth files, evidence available, rollback boundary, and any proposed alternatives. |
| required_outputs | Simplest-safe decision, rejected simpler alternatives with reasons, complexity budget, guardrail justifications, evidence states, APIVR verdict, and one next action. |
| authority_dependencies | 00_start_here/SOURCE_OF_TRUTH.md; 10_governance/APIVR_EXECUTION_LIFECYCLE.md; 10_governance/source_of_truth/Elite_Build_Goals_v3.md; 20_skills/PORTABLE_SKILL_CONTRACT.md. |
| evidence_requirements | Execute relevant checks or mark every material claim Verified, Likely, Suspected, Unknown, Not Run, or Blocked; never treat confidence or a design document as runtime proof. |
Simplest Safe Path
Use this skill as the kit-wide owner for design minimality. It makes the
simplest design that still satisfies safety, correctness, security, data
integrity, accessibility, and the required outcome the default. It does not
replace APIVR, the Elite Build Goals, TDD, security review, code review, or
release gates.
Do not add a component, layer, stage, retry loop, fallback, dependency,
abstraction, configuration surface, or guardrail without naming the specific
failure mode or required outcome it addresses and the evidence that makes it
real or reasonably likely. “Best practice,” “future-proofing,” “more robust,”
and “defense in depth” are not sufficient by themselves. If the justification
is speculative, choose the simpler safe option and record the decision.
Activation and authority
Activate during APIVR Phase 1 when the design is not predetermined, during
Phase 2 before implementation, and during Phase 4 when reviewing a plan, diff,
skill, agent, pipeline, or audit for overengineering. For security,
authorization, privacy, data integrity, production, or destructive work, the
higher-risk APIVR and security controls remain authoritative. This skill may
escalate a tier but may not lower one.
Load only the relevant files named by 00_start_here/LOAD_ORDER.md. For a
high-stakes skill, audit, plan, or source-file change, also load
skills/20-pass-protocol/SKILL.md. Do not copy APIVR, routing tables, or Elite
Build Goals into a second source of truth.
Decision procedure
- State the required outcome and the hard constraints in one sentence.
- Establish the current baseline and the smallest design that could meet the
outcome. Treat it as the default choice.
- List at least one simpler alternative and one rejected alternative. Reject
an alternative only with a named constraint, failure mode, or required
outcome it cannot satisfy. If no simpler alternative fails, choose it.
- For every element beyond the baseline, record the failure mode or required
outcome, evidence, implementation/testing cost, and what happens if it
misfires.
- Record the complexity budget before implementation. Unjustified moving
parts are removed or deferred.
- Route the chosen design into the normal APIVR plan, test-first
implementation, review, verification, release, and re-audit controls.
Complexity budget
Use a small table in the plan, review, or evidence ledger:
| Added element | Failure mode or required outcome | Evidence | Cost / misfire risk | Decision |
|---|
| name the layer, guardrail, retry, dependency, or state | what it prevents or delivers | observed, likely, or blocked |
