goal-framing

Files (1)

• SKILL.md

SKILL.md (first lines)

# Aegis Goal Framing

Use this skill to create a thin goal frame before execution. It is opt-in and
boundary-setting only.

Do not use it for tiny edits, one-command checks, or ordinary fast-path Q&A
unless the user explicitly asks for `/aegis-goal` or `Aegis goal:`.

## Authority Boundary

Current owner:

- Method Pack task framing

Not owned here:

- authoritative `GateDecision`
- final evidence sufficiency
- final completion authority is not owned here
- host daemon / automatic stop enforcement

## Input Forms

Treat these as equivalent:

- `/aegis-goal <task description>`
- `Aegis goal: <task description>`
- "Define the goal / stop condition before we start"

Slash commands are optional host shortcuts. The natural-language form is the
portable fallback.

Example:

```text
Aegis goal: Fix the auth refresh bug without rewriting the auth system.
```

## Output

Produce the smallest useful frame, then continue into the routed workflow in
the same turn.

```text
TaskIntentDraft:
- Requested outcome:
- Goal:
- Success evidence:
- Stop condition:
- Non-goals:
- Constraints:
- Scope:
- Risk hints:
- Aegis Visibility:
- Route:
- Next:
```

Default behavior:

- Do not stop after `TaskIntentDraft`.
- Treat the frame as the start protocol for execution, not as the final answer.
- After the compact frame, immediately take the `Next` action for the selected
  route when the user asked to do the work.
- Keep the visible frame natural and short when the goal is clear; do not emit a
  large internal-looking card unless the user asked for a formal frame.
- Use `Aegis Visibility` to say why the goal frame constrains the route, stop
  condition, or non-goals. Do not add trace ceremony unless the user explicitly
  asks for auditability.

Frame-only behavior:

- Stop at the frame only when the user explicitly asks to only define the goal,
  only define the stop condition, not execute, not implement, not write a plan,
  or wait for confirmation before continuing.
- If required information is missing, state the missing input and stop with
  `blocked` rather than pretending to continue.

Stop condition must distinguish:

State set: `done`, `blocked`, `needs-verification`, `scope-exceeded`.

- `done`: success evidence is satisfied
- `blocked`: required dependency, permission, or information is missing
- `needs-verification`: implementation exists but evidence is insufficient
- `scope-exceeded`: continuing would exceed the goal or non-goals

## Routing

After framing:

- Low-risk single-owner work continues through the normal fast path or TDD
- Ambiguous product / architecture / contract work routes to `brainstorming`
- Approved requirements route to `writing-plans`
- Multi-step, compaction-prone, handoff, or subagent work routes to
  `long-task-continuation`
- Bug diagnosis routes to `systematic-debugging`

### Route Matrix

| Goal signal | Route |
| --- | --- |
| single-owner, low-risk, clear verification | fast path or `test-driven-development` |
| bug, failure, regression, unexpected behavior | `systematic-debugging` |
| ambiguous product, architecture, contract, cross-module behavior | `brainstorming` |
| approved spec, stable requirements, implementation slicing | `writing-plans` |
| multi-step, compaction-prone, handoff, subagent work | `long-task-continuation` |
| completion, release, handoff, "is this done?" | `verification-before-completion` |

Only create `docs/aegis/` records when the routed workflow needs persistent
evidence. Goal framing alone does not create project files.

## Subagent Context Packet

When delegating work, pass a compact packet instead of the full conversation:

```text
SubagentContextPacket:
- Task:

From GanyuanRan/Aegis, MIT.

More from GanyuanRan/Aegis