Claude Cursor GitHub Copilot opencode Skill

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.

LLM Mart · 0 points · 1 views 0 listing impressions 0 install-command copies
Virus-scanned Reviewed automatically before listing.

Full trust report

Download ganyuanran-aegis-skills_goal-framing-5b16eb9.zip · 2 KB
Part of ganyuanran/aegis — 21 skills

Install

skills CLI npx skills add https://github.com/GanyuanRan/Aegis/tree/main/skills/goal-framing
Claude Code claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install ganyuanran-aegis@llmmart
Git git clone https://github.com/GanyuanRan/Aegis.git

The skills CLI installs just this skill, for any of its supported agents. Claude Code installs the whole ganyuanran/aegis collection as a plugin from our marketplace. Git is the plain clone.

Skill manifest

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.

Files (aegis)
  • SKILL.md 4.5 KB
    ---
    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:
    
    ```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:
    - 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.
    

Comments (0)

Sign in to join the conversation.

No comments yet.

Reviews (0)

No reviews yet.

Related