Writing Plans

<EXPLICIT-MODE-GATE>
If activation mode is explicit (`~/.config/aegis/config.toml` has
`activation_mode = "explicit"`, or `AEGIS_ACTIVATION_MODE=explicit` is visible
in the environment) and the current user request did not explicitly invoke
Aegis or this skill by name, exit back to the fast path: answer concisely
without this workflow's checklist, ceremony, or document requirements. If the
user explicitly named Aegis or this skill, proceed normally.
</EXPLICIT-MODE-GATE>

Execute

→ Existing parent plan/spec and a tiny execution slice? → Use Planless Slice Lane. → Mechanical or bounded change with no durable boundary (no new owner, contract, schema, public API, migration, or compat surface)? → Use Planless Slice Lane without a parent document. → Approved spec/requirements for a new workstream or an escalation trigger? → Write an implementation plan for an engineer with no prior task context.

For a durable plan: confirm scope and acceptance, map current owners/files, record the TDD route, decompose into executable tasks, define verification and retirement, self-review, save, then select the execution route. Proceed unless a real authorization or safety boundary requires the user.

Escalate from Planless Slice Lane when the work adds a new owner, contract, schema, public API, architecture boundary, migration, persistence, security/permission, distribution/release surface, or an unclear verification boundary.

Writing Plans

This skill turns approved requirements into a bounded, executable plan. The plan must answer: what changes, why code is necessary, which existing owner and files change, what stays compatible, what verifies the result, what risk remains, and what old path is retired or deliberately retained. A plan is method-pack guidance; it cannot grant authoritative completion.

TDD Route Guard

Before task decomposition, record TDD Route with mode (off | auto), decision (strict | light | skipped), authority, test posture, reason, and verification.

Strict RED / GREEN steps belong only to an explicit user/project TDD request or TDD Route: strict. In off, use skipped unless explicit strict authority overrides it. An approved plan or a risk label alone is not strict authority.

In auto, select strict for behavior, bugfix, shared/core, contract, persistence, permission, migration, producer/consumer, or meaningful regression signals. Select light only when the work is tiny, low-risk, single-owner, has no behavior change or strict signal, and has an obvious focused check. Absence of an explicit user TDD request is never evidence for light; the auto decision itself must be recorded.

If risk remains unknown, return to requirements, debugging, or plan review before task decomposition; do not infer a TDD route from uncertainty.

Only a strict decision with stated authority may prescribe failing-test, RED, GREEN, and REFACTOR steps. Otherwise plan the minimum change plus diagnostic reproduction or post-change regression. A missing auto decision returns to route selection before implementation tasks.

Entry And Artifact Choice

Announce at start: on the plan-writing route, say that this skill is creating the implementation plan. On Planless Slice Lane, announce the lane instead and do not claim a plan is being created.

Execution context: Reuse the current branch/workspace by default. A branch needs independent history; a worktree needs concurrent checkout, blocking unrelated dirty state, or explicit user/repository authority.

Input: approved requirements, a Spec Brief, or a Design Spec.

Default plan path: docs/aegis/plans/YYYY-MM-DD-<feature-name>.md. Plans do not go in work/; user and repository authority override the default.

Exception: use Planless Slice Lane when an existing parent plan/spec already owns the current tiny execution slice, or when the change is mechanical or bounded and needs no parent document. Do not save a new plan. Emit a compact Slice Card:

Slice Card:
- Goal:
- Parent plan/spec:
- Files:
- Boundary:
- Verification:
- Stop:

On the no-parent branch, Parent plan/spec: is none — direct bounded request.

Aegis Project Workspace

Workspace creation is lazy and follows project authority. The Aegis Method Pack repository must not create or ship a live docs/aegis/ workspace. When a durable plan must initialize or update another project's workspace, read the workspace section of expanded-planning-guidance.md. It owns the <aegis-workspace-helper> and INDEX.md command detail, not the decision to create a plan.

Default Plan Surface

Compact output contract: express these as natural plan content, not a stack of cards: Aegis Visibility, approved scope and plan basis, required baseline refs, files/owners, compatibility boundary, Change Necessity, TDD route, tasks, verification, risks, and retirement. Keep conditional structures silent unless their trigger below fires.

Aegis Visibility is normally one sentence explaining which owner, contract, retirement, compatibility, or verification pressure makes a durable plan useful. Structured trace belongs only to audit, debug, release, long-task review, or explicit request.

Before tasks, perform a Requirement Ready Check: identify the approved source, scope, scenarios, and acceptance evidence. If any decision-changing item is missing, do not create implementation tasks; return the smallest gap to the requirement/spec owner.

Perform Change Necessity before any non-trivial source edit or any new source-code path. This is behavior-triggered, not prompt-triggered. State naturally why no-change/docs/config is insufficient and name the minimum code boundary. A tiny helper, guard, branch, fallback, adapter, or owner is not exempt. A no-change, docs/config-only, or needs-clarification result narrows or stops the code plan.

Run Ripple Signal Triage before tasks when the change touches shared/core or cross-module behavior; a public API, schema, contract, compatibility, persistence, cache, export/readback, fallback, adapter, duplicate/legacy owner, retirement path, or both producer and consumer. If no signal fires, add no output. If one fires, identify the canonical owner and affected downstream consumers, state source-of-truth/contract/fallback/retirement risk, and carry expanded verification into the relevant task. A required owner/public-contract/source-of-truth change, retaining two owners, or adding a fallback, adapter, or compatibility branch returns to design or requires explicit prior alignment before implementation.

Run a compact Plan Pressure Test before task decomposition: test owner / contract / retirement fit, higher-level architecture path, verification scope, and task executability. It may proceed, revise the plan, or return to design; it is not an approval authority.