goal-driven-execution

Name: goal-driven-execution
Author: DevelopersGlobal

64stars10forks

How to install goal-driven-execution?

developersglobal/ai-agent-skills/goal-driven-execution

$npx -y skills add DevelopersGlobal/ai-agent-skills --skill goal-driven-execution

Installs into the current project.

Summary

Transforms imperative instructions into declarative goals with verifiable success criteria. Enables autonomous looping until verified completion.

Files · 1

View on GitHub

SKILL.md

1	## Overview
2
3	Andrej Karpathy's key insight: "LLMs are exceptionally good at looping until they meet specific goals. Don't tell it what to do — give it success criteria and watch it go."
4
5	This skill converts vague imperative instructions ("make the login work") into declarative goals with concrete, testable success criteria. Agents with clear goals self-correct autonomously. Agents with vague goals produce vague results and require constant intervention.
6
7	## When to Use
8
9	- Before starting any multi-step task
10	- When a task has been described imperatively ("do X, then Y, then Z")
11	- When you're unsure how you'll know when you're "done"
12	- For long-running or complex implementations
13
14	## Process
15
16	### Step 1: Extract the Underlying Goal
17
18	1. Read the full request.
19	2. Ask: What is the user trying to achieve, not just what they asked for?
20	3. Write the goal as: "The task is complete when [observable, verifiable outcome]."
21
22	Example transformation:
23	- ❌ Imperative: "Add error handling to the API."
24	- ✅ Goal: "The task is complete when: all API endpoints return structured error responses for 4xx/5xx cases, error responses include a `code`, `message`, and `requestId`, and the existing tests pass."
25
26	Verify: The goal statement is observable and testable by a third party.
27
28	### Step 2: Define Success Criteria
29
30	4. List 3–7 specific, binary success criteria:
31	```
32	Success when:
33	- [ ] All existing tests pass
34	- [ ] New behavior X is demonstrated by test Y
35	- [ ] No regressions in file Z
36	- [ ] Manual check: [describe what to look for]
37	```
38	5. Each criterion must be falsifiable — you can clearly state when it passes or fails.
39
40	Verify: Every criterion can be checked without the original author.
41
42	### Step 3: Define the Execution Plan
43
44	6. Break the goal into ordered steps, each with its own verify check:
45	```
46	1. [Step] → verify: [command or check]
47	2. [Step] → verify: [command or check]
48	3. [Step] → verify: [command or check]
49	```
50	7. Identify the first failure mode — what's most likely to go wrong? Plan for it.
51
52	Verify: The plan is readable and each step is independently verifiable.
53
54	### Step 4: Execute and Loop
55
56	8. Follow the plan step-by-step.
57	9. At each verify checkpoint — actually run the check. Do not skip.
58	10. If a check fails: diagnose, fix, re-verify. Do not proceed past a failing check.
59	11. When all checks pass: report completion with evidence.
60
61	## Common Rationalizations (and Rebuttals)
62
63	\| Excuse \| Rebuttal \|
64	\|--------\|----------\|
65	\| "The goal is obvious" \| Obvious goals still need explicit success criteria. What's obvious to you is ambiguous to an agent. \|
66	\| "I'll know when it's done" \| That's not a verifiable criterion. Write it down. \|
67	\| "The tests will tell me" \| Which tests? What do they cover? What don't they cover? \|
68	\| "It's too simple for a plan" \| Simple tasks rarely fail. Complex tasks without a plan always do. \|
69
70	## Red Flags
71
72	- The task is described as a to-do list, not a goal
73	- You don't know how you'll verify completion
74	- You're 80% through and realize the original framing was wrong
75	- "It seems to work" is your verification strategy
76
77	## Verification
78
79	- [ ] Goal is stated as an observable, testable outcome
80	- [ ] Success criteria are listed and binary (pass/fail)
81	- [ ] Execution plan has verify steps for each phase
82	- [ ] All verify checks have been run (not just assumed passing)
83	- [ ] Evidence of completion is documented
84
85	## References
86
87	- [think-before-coding skill](../think-before-coding/SKILL.md)
88	- [task-decomposition skill](../task-decomposition/SKILL.md)

People who liked this also viewed

6 picks

Type

find-skillsHelps users discover and install agent skills when they ask questions like "how do I do X", "find a skill for X", "is there a skill that can...", or express interest in extending capabilities. This skSkillsJul 20262.6M27k
grill-meA relentless interview to sharpen a plan or design.SkillsJul 2026633k182k
vercel-react-best-practicesVercel's official collection of agent skillsSkillsJul 2026573k29k
improve-codebase-architectureScan a codebase for deepening opportunities, present them as a visual HTML report, then grill through whichever one you pick.SkillsJul 2026522k182k
setup-matt-pocock-skillsConfigure this repo for the engineering skills — set up its issue tracker, triage label vocabulary, and domain doc layout. Run once before first use of the other engineering skills.SkillsJul 2026454k182k
triageMove issues and external PRs through a state machine of triage roles — categorise, verify, grill if needed, and write agent-ready briefs.SkillsJul 2026424k182k

goal-driven-execution

64stars10forks

View on GitHub

How to install goal-driven-execution?

developersglobal/ai-agent-skills/goal-driven-execution

$npx -y skills add DevelopersGlobal/ai-agent-skills --skill goal-driven-execution

Installs into the current project.

Summary

Transforms imperative instructions into declarative goals with verifiable success criteria. Enables autonomous looping until verified completion.

Files · 1

View on GitHub

SKILL.md

1	## Overview
2
3	Andrej Karpathy's key insight: "LLMs are exceptionally good at looping until they meet specific goals. Don't tell it what to do — give it success criteria and watch it go."
4
5	This skill converts vague imperative instructions ("make the login work") into declarative goals with concrete, testable success criteria. Agents with clear goals self-correct autonomously. Agents with vague goals produce vague results and require constant intervention.
6
7	## When to Use
8
9	- Before starting any multi-step task
10	- When a task has been described imperatively ("do X, then Y, then Z")
11	- When you're unsure how you'll know when you're "done"
12	- For long-running or complex implementations
13
14	## Process
15
16	### Step 1: Extract the Underlying Goal
17
18	1. Read the full request.
19	2. Ask: What is the user trying to achieve, not just what they asked for?
20	3. Write the goal as: "The task is complete when [observable, verifiable outcome]."
21
22	Example transformation:
23	- ❌ Imperative: "Add error handling to the API."
24	- ✅ Goal: "The task is complete when: all API endpoints return structured error responses for 4xx/5xx cases, error responses include a `code`, `message`, and `requestId`, and the existing tests pass."
25
26	Verify: The goal statement is observable and testable by a third party.
27
28	### Step 2: Define Success Criteria
29
30	4. List 3–7 specific, binary success criteria:
31	```
32	Success when:
33	- [ ] All existing tests pass
34	- [ ] New behavior X is demonstrated by test Y
35	- [ ] No regressions in file Z
36	- [ ] Manual check: [describe what to look for]
37	```
38	5. Each criterion must be falsifiable — you can clearly state when it passes or fails.
39
40	Verify: Every criterion can be checked without the original author.
41
42	### Step 3: Define the Execution Plan
43
44	6. Break the goal into ordered steps, each with its own verify check:
45	```
46	1. [Step] → verify: [command or check]
47	2. [Step] → verify: [command or check]
48	3. [Step] → verify: [command or check]
49	```
50	7. Identify the first failure mode — what's most likely to go wrong? Plan for it.
51
52	Verify: The plan is readable and each step is independently verifiable.
53
54	### Step 4: Execute and Loop
55
56	8. Follow the plan step-by-step.
57	9. At each verify checkpoint — actually run the check. Do not skip.
58	10. If a check fails: diagnose, fix, re-verify. Do not proceed past a failing check.
59	11. When all checks pass: report completion with evidence.
60
61	## Common Rationalizations (and Rebuttals)
62
63	\| Excuse \| Rebuttal \|
64	\|--------\|----------\|
65	\| "The goal is obvious" \| Obvious goals still need explicit success criteria. What's obvious to you is ambiguous to an agent. \|
66	\| "I'll know when it's done" \| That's not a verifiable criterion. Write it down. \|
67	\| "The tests will tell me" \| Which tests? What do they cover? What don't they cover? \|
68	\| "It's too simple for a plan" \| Simple tasks rarely fail. Complex tasks without a plan always do. \|
69
70	## Red Flags
71
72	- The task is described as a to-do list, not a goal
73	- You don't know how you'll verify completion
74	- You're 80% through and realize the original framing was wrong
75	- "It seems to work" is your verification strategy
76
77	## Verification
78
79	- [ ] Goal is stated as an observable, testable outcome
80	- [ ] Success criteria are listed and binary (pass/fail)
81	- [ ] Execution plan has verify steps for each phase
82	- [ ] All verify checks have been run (not just assumed passing)
83	- [ ] Evidence of completion is documented
84
85	## References
86
87	- [think-before-coding skill](../think-before-coding/SKILL.md)
88	- [task-decomposition skill](../task-decomposition/SKILL.md)

People who liked this also viewed

6 picks

Type