/goal-framing
Use when the user explicitly sets an Aegis goal with /aegis-goal, Aegis goal:, or asks to define goal, success evidence, stop condition, or task boundaries before work.
$ npx -y skills add GanyuanRan/Aegis --skill goal-framing --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/goal-framing
Context preview
The summary Claude sees to decide when to auto-load this skill.
Use when the user explicitly sets an Aegis goal with /aegis-goal, Aegis goal:, or asks to define goal, success evidence, stop condition, or task boundaries before work.
SKILL.md
goal-framing.SKILL.mdname: goal-framing
description: "Use when the user explicitly sets an Aegis goal with /aegis-goal, Aegis goal:, or asks to define goal, success evidence, stop condition, or task boundaries before work."
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:
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.
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:
SubagentContextPacket:
- Task:
- Goal:
- Stop condition:
- Relevant baseline refs:
- Relevant files:
- Known facts:
- Unknowns:
- Non-goals:
- Expected output:
- Verification expected:
- Must-read excerpts:
- Unsafe assumptions:
The packet reduces repeated file reading, but it does not replace evidence. Subagents should still read the smallest raw file/log/test excerpt needed to verify critical facts.
Do not paste full chat transcripts, full session history, or unbounded logs into the packet. If a fact matters, include a file ref, line/window hint, or compact must-read excerpt.
Drift Rule
If the goal changes mid-task, do not silently overwrite it. Record old goal, new goal, changed scope, new risks, and route through `DriftCheckDraft` when a long-task record exists.
Read more
name: goal-framing description: "Use when the user explicitly sets an Aegis goal with /aegis-goal, Aegis goal:, or asks to define goal, success evidence, stop condition, or task boundaries before work."
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:
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.
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:
SubagentContextPacket: - Task: - Goal: - Stop condition: - Relevant baseline refs: - Relevant files: - Known facts: - Unknowns: - Non-goals: - Expected output: - Verification expected: - Must-read excerpts: - Unsafe assumptions:
The packet reduces repeated file reading, but it does not replace evidence. Subagents should still read the smallest raw file/log/test excerpt needed to verify critical facts.
Do not paste full chat transcripts, full session history, or unbounded logs into the packet. If a fact matters, include a file ref, line/window hint, or compact must-read excerpt.
Drift Rule
If the goal changes mid-task, do not silently overwrite it. Record old goal, new goal, changed scope, new risks, and route through `DriftCheckDraft` when a long-task record exists.
Aegis Method Pack Make your AI coding agent trustworthy: fewer reworks, safer changes, proof before "done". English · 中文 · Fast-Track Playbook · 速通秘籍 Stop babysitting your agent.
Other skills on aegis.
- /anti-entropy-governance
Use when retiring old logic, collapsing duplicate owners, removing fallbacks, or touching schema, persistence, or source-of-truth boundaries while deciding whether to delete old paths, retain compatibility, or stop for confirmation.
Open skill - /brainstorming
Use when defining ambiguous or high-complexity new features, product behavior, UI/component design, architecture choices, contract changes, or when grilling/pressure-testing a plan or design. Routine small requests stay on the fast path.
Open skill - /communicating-concisely
Use when the user asks for caveman mode, fewer tokens, brief responses, compressed communication, or otherwise explicitly requests a much shorter answer.
Open skill - /dispatching-parallel-agents
Use when facing 2+ independent tasks without a written plan that can be worked on without shared state or sequential dependencies. Planned tasks in the current session use subagent-driven-development.
Open skill - /establishing-project-context
Use when the user asks to establish shared project language, or project work exposes a conflicting, renamed, or deprecated domain term that needs active semantic modeling. Routine small tasks stay on the fast path.
Open skill - /executing-plans
Use when executing a written implementation plan across sessions or with review checkpoints. For same-session execution with independent tasks, use subagent-driven-development instead.
Open skill

