shape-goal
Skill2 starsChanged 13 days agoApache-2.0View on GitHub
Turn a rough idea, ambiguous request, or proposed process into an approved, measurable goal contract before planning or implementation. Use when the user asks to grill, interview, clarify, define success, create a measurable goal, or prevent premature implementation. Do not use for a small task whose outcome and done conditions are already explicit.
In this repository9 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- .github/copilot-instructions.mdCopilot instructions
- code-reviewSkill
- diagnosing-bugsSkill
- gatekeep-prsSkill
- orchestrate-agentsSkill
- to-ticketsSkill
- wayfinderSkill
The file
We split this skill into the rules it gives an agent
2 rules. About 0 are common, 2 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈2
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 12
Ask one decision at a time.
- Distinctive: line 16
Stop asking when every required decision is resolved.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Shape a Goal
Interview
- Restate the idea in one sentence and identify the largest unresolved decision.
- Discover facts from available files, tools, and sources. Ask the user only for decisions or unavailable context.
- Ask one decision at a time. Process corrections immediately; do not finish a prepared question list after the user changes direction.
- Trace the goal as
result -> user or system outcome -> KPI -> validation -> exit conditions. - Challenge proxy metrics, implied scope, unstated tradeoffs, and done conditions that cannot be tested.
- Apply the automation-first routing check: ask "Does an owned deterministic command, bot, or API already produce this result?" Prefer that stable path and record the decision; reserve an agent for ambiguity, conflicts, diagnostics, or missing automation.
- Stop asking when every required decision is resolved. Do not plan or implement yet.
Produce the goal contract
Return this compact form:
# Goal: <outcome>
Status: awaiting-approval
## Why now
<one sentence>
## Outcome
<observable change for the user or system>
## Scope
- In: ...
- Out: ...
## Constraints
- ...
## Evidence
- KPI: <measure and target>
- Validation: <how and where it is measured>
## Exit conditions
- [ ] <independently testable condition>
- [ ] <independently testable condition>AND-join all exit conditions: work is complete only when every box can be checked with evidence.
For substantial, security-sensitive, visual, or environment-dependent work, append an acceptance-to-evidence table:
| ID | Outcome or constraint | Owner | Authoritative lane | Planned evidence |
|---|---|---|---|---|
| A1 | ... | ... | static / rendered / local-runtime / architecture-specific / hosted-runtime / manual-ui | ... |Give every row one owner and one authoritative validation lane. Use approved-untested only with an explicit user-approved exception. After goal approval, persist the table with agentflow acceptance create; block the first writable assignment until the matrix validates. Skip the matrix for a small task whose exit conditions and proof are already complete in the compact contract.
A row passes only on evidence from its own lane. A settings API response, a configuration readback, or a component receipt is not executable readiness for a hosted-runtime or architecture-specific row; pass those rows with agentflow acceptance set --evidence-lane <lane> after that environment actually ran. Mark rows that need an end-to-end result with acceptance create --whole-chain <ID>; they pass only with --evidence-scope whole-chain. When the environment is missing, keep the row planned or record it failed. Never waive it without the user's approval.
Approval gate
Ask for one final correction or approval. Do not transition to tickets, planning, or implementation until the user approves. After approval, change Status to approved. When bd where --json succeeds, persist the contract and acceptance rows on a parent bead; otherwise preserve it in the repository's approved planning artifact. Do not store interview transcripts.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

