/goal-planner

name: goal-planner
description: 'Define user goal, scope, constraints, and done criteria before standard or deep frontend work. Skip micro-fixes, obvious type errors, tiny styling changes, and isolated direct edits.'
id: 'agents.skills.goal-planner.skill'
title: 'Goal Planner'
doc_type: 'skill'
layer: 'skill'
status: 'active'
publishable: true
local_only: false
skill: 'goal-planner'
tags:
    - 'agents/skill-package'
    - 'agents/planning'
    - 'workflow/goal-contract'
parent:
    - '[[AGENTS|Canonical Agent Policy]]'
related:
    - '[[common/agent-operating-model|Agent Operating Model]]'
    - '[[common/goal-contract|Goal Contract]]'
    - '[[common/prompt-intent-routing-rules|Prompt Intent Routing Rules]]'
    - '[[templates/goal-contract|Goal Contract Template]]'
    - '[[skills/project-context-adapter/SKILL|Project Context Adapter]]'
    - '[[skills/agent-rules-skill-author/SKILL|Agent Rules And Skill Author]]'
depends_on:
    - '[[AGENTS|Canonical Agent Policy]]'

Goal Planner

Purpose

Create a clear goal contract for standard or deep frontend work before implementation begins.

This skill exists to prevent ambiguous or large requests from turning into unfocused coding. It defines what the user wants, what is in scope, what is out of scope, which constraints apply, and what observable conditions mean the task is done.

When To Use

Use this skill only after `AGENTS.md` and `common/prompt-intent-routing-rules.md` classify the task as `Standard Workflow` or `Deep Workflow`.

Use this skill when:

• the user asks for a multi-file feature;
• the user asks for a new screen, flow, or frontend capability;
• the user asks for architecture, greenfield project creation, or broad redesign;
• the request is ambiguous enough that implementation would require guessing the goal;
• the task needs a compact goal before execution planning;
• the task needs a durable goal contract because work may span multiple slices.

When Not To Use

Do not use this skill for `Lightweight Workflow` prompts, including:

• one small bug;
• one obvious typo;
• one obvious type error;
• one small styling adjustment;
• one isolated component change;
• one direct file-scope edit;
• one local refactor with clear boundaries.

Do not use this skill to implement code, install tools, scaffold projects, rewrite architecture, or perform visual QA.

If a lightweight task reveals hidden scope, escalate first using `common/prompt-intent-routing-rules.md`, then use this skill only if the escalated task is standard or deep.

Required Context

1. Read `AGENTS.md`. 2. Read `common/prompt-intent-routing-rules.md` when task scale is not obvious. 3. Read `common/goal-contract.md`. 4. Confirm the workflow level is `Standard Workflow` or `Deep Workflow`. 5. Read only project overlays that are needed to understand the goal boundary, such as `project/stack-profile.md`, `project/architecture-map.md`, or `project/design-reference-profile.md`. 6. Read affected source files only when the goal cannot be stated without them.

Tool Contract

• Use filesystem access only when a durable goal contract must be written or an existing one must be updated.
• Do not use MCP installation checks from this skill.
• Do not use Browser, Playwright, Visual Diff, Figma, or design-tool MCP from this skill.
• Do not install packages or tools.
• Do not change application source files.

Workflow

1. Confirm task scale.

• If the task is lightweight, stop and route back to the direct skill without creating a goal contract.
• If the task is standard or deep, continue.

2. Extract the user-facing goal.

• Describe the desired outcome in product or user terms, not only technical activity.
• Preserve explicit user constraints.
• Do not invent business requirements.

3. Define scope.

• Name what is included.
• Name what is explicitly out of scope.
• Identify whether this is existing-project work, greenfield work, design work, architecture work, bugfix work, or review work.

4. Define constraints. Include relevant constraints such as:

• no package installation without approval;
• no new styling system without approval;
• no architecture layer without approval;
• no production systems or production data;
• follow existing project conventions;
• keep host-project facts in `project/**`;
• keep reusable instructions in English.

5. Resolve material ambiguity when needed.

• Scan only for choices that change scope, critical interaction states,

data or state ownership, responsive or accessibility behavior, external integration or security, or verification.

• Use the current request, confirmed decisions, host instructions, and

verified project evidence before asking.

• Rank candidates by impact and uncertainty, then ask exactly one question

at a time and no more than three in one goal-definition pass.

• Prefer mutually exclusive choices or a constrained short answer. Recommend

an option only when evidence supports it.

• Stop when material ambiguity is resolved, the user asks to proceed, or the

limit is reached.

• If the limit is reached with a material blocker unresolved, record the

blocker instead of silently guessing.

• Apply each answer immediately to Scope, Out Of Scope, Constraints, or Done

When. Keep only a compact Clarifications record for durable goals.

• Do not ask the user to repeat known information, confirm a verifiable fact,

choose low-impact styling, or decide safe plan-level implementation detail.

6. Define Done When.

• Done criteria must be observable outcomes, not implementation activity.
• For a durable goal, assign stable zero-padded identifiers such as `AC-001`.
• Do not renumber or reuse durable criterion identifiers after execution begins.
• Use only criteria relevant to the task.

7. Choose output mode.

• For standard tasks, output a compact goal contract in the response unless a durable file is genu