use-loop

Name: use-loop
Author: minghinmatthewlam

34stars4forks

How to install use-loop?

minghinmatthewlam/agent-guards/use-loop

$npx -y skills add minghinmatthewlam/agent-guards --skill use-loop

Installs into the current project.

Summary

Default workflow for implementation and product goals: identify the verifiable goal, check tool/self-test access, start a real /goal continuation loop, iterate until verified, report blockers or decisions, then close with simplify/self-test/autoreview. Use when the user asks for

Files · 1

View on GitHub

SKILL.md

1	# Use Loop
2
3	Use this skill as the default execution shape for implementation and product goals.
4
5	Your job is to run one verifiable loop for the current task. Do not rely on intention alone. Assume the current harness has `/goal`, including Codex and Claude. Set a clear goal with success criteria, verifier, and stop conditions, then keep working until the goal is verified or blocked. Report status, blockers, questions, and final proof concisely in the current thread.
6
7	## Default Loop Policy
8
9	Default to a loop for implementation, product, QA, cleanup, refactor, eval, performance, and verification work. Do not treat loops as a rare special mode.
10
11	A good loop has these properties:
12
13	- The target can be verified by a command, test, metric, browser check, reviewer, eval, validation count, or explicit artifact inspection.
14	- The agent can access or request the tools, credentials, runtime, browser/app surface, repo state, or external service needed to self-test against that target.
15	- The verifier is stable enough to be the source of truth for the loop.
16	- Each attempt can be kept, reverted, or summarized without losing control of the worktree.
17	- There is a clear stop condition.
18	- There is a decision gate for product judgment, destructive actions, publishing, deployment, credential use, or ambiguous tradeoffs.
19
20	If one property is missing, preserve the loop shape and surface the exact blocker. For example: "goal is clear, but I cannot self-test because staging credentials are missing." Do not silently downgrade to an unverifiable one-shot.
21
22	## Setup Flow
23
24	Use this order before iterating:
25
26	1. Identify the goal and verifiable target.
27	2. Identify tool access and ability to self-test against that target.
28	3. Establish the baseline with the verifier when possible.
29	4. Start an actual continuation loop using `/goal` or the harness goal tool.
30	5. Report in-thread only for blockers, critical questions, surprising results, or final completion.
31	6. Repeat until the goal is reached or a stop condition triggers.
32
33	The tool-access check is mandatory. Look for the same things `self-test` requires: test configs, build scripts, app launch paths, browser/Electron harnesses, Computer Use/browser access, API endpoints, credentials, fixtures, existing specs, and the loop continuation tool. If the agent cannot reach the highest-signal affected surface or cannot start the required continuation mechanism, stop and report the blocker instead of silently using weaker proof.
34
35	If the target is reachable but the repo lacks a useful proof lane, include the missing verification structure in the loop work. Add the smallest appropriate focused test, script, fixture, browser check, Computer Use smoke, artifact capture, or `scripts/self-test.sh` lane needed to prove the goal. The loop should improve both the product behavior and the repo's ability to self-test that behavior.
36
37	Plan proof artifacts before implementation when the target has any visual, UI, desktop, browser, animation, focus, timing, or multi-step interaction surface. Use screenshots for final visible state and short screen recordings for flows that cannot be proven by one still image. Store artifacts in a durable path such as `/Users/matthewlam/.codex/proofs/<thread-or-task>/<slug>/`, verify their metadata, and include the paths in the final report. Tool output alone is not durable proof if it cannot be reopened from a stable file path.
38
39	## Loop Diagrams
40
41	Use these diagrams as the mental model for the workflow.
42
43	End-to-end loop:
44
45	```mermaid
46	flowchart LR
47	A["Find verifiable target"] --> B["Check tool access and self-test path"]
48	B --> C["Start /goal"]
49	C --> D["Report blockers or decisions in-thread"]
50	D --> E["Finish with proof"]
51	```
52
53	One turn of the loop:
54
55	```mermaid
56	flowchart TD
57	A["Make one coherent change"] --> B["Measure against target"]
58	B --> C{"Improved or closer?"}
59	C -->\|yes\| D["Keep as new best"]
60	C -->\|no\| E["Revert/discard to last best"]
61	D --> F{"Stop? target hit, stalled, out of ideas, blocked, budget hit"}
62	E --> F
63	F -->\|no\| A
64	F -->\|yes\| G["Report best result and evidence"]
65	```
66
67	## Loop Contract
68
69	Before starting work, write the loop contract in the current thread or task prompt:
70
71	```text
72	Loop: <name>
73	Goal: <specific outcome>
74	Target: <metric, tests, eval, QA check, review gate, validation count>
75	Verifier: <exact command/tool/surface and expected result>
76	Tool access: <available tools, credentials, runtime, browser/app/API access>
77	Self-test path:

People who liked this also viewed

6 picks

Type

use-loop

34stars4forks

View on GitHub

How to install use-loop?

minghinmatthewlam/agent-guards/use-loop

$npx -y skills add minghinmatthewlam/agent-guards --skill use-loop

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Use Loop
2
3	Use this skill as the default execution shape for implementation and product goals.
4
5	Your job is to run one verifiable loop for the current task. Do not rely on intention alone. Assume the current harness has `/goal`, including Codex and Claude. Set a clear goal with success criteria, verifier, and stop conditions, then keep working until the goal is verified or blocked. Report status, blockers, questions, and final proof concisely in the current thread.
6
7	## Default Loop Policy
8
9	Default to a loop for implementation, product, QA, cleanup, refactor, eval, performance, and verification work. Do not treat loops as a rare special mode.
10
11	A good loop has these properties:
12
13	- The target can be verified by a command, test, metric, browser check, reviewer, eval, validation count, or explicit artifact inspection.
14	- The agent can access or request the tools, credentials, runtime, browser/app surface, repo state, or external service needed to self-test against that target.
15	- The verifier is stable enough to be the source of truth for the loop.
16	- Each attempt can be kept, reverted, or summarized without losing control of the worktree.
17	- There is a clear stop condition.
18	- There is a decision gate for product judgment, destructive actions, publishing, deployment, credential use, or ambiguous tradeoffs.
19
20	If one property is missing, preserve the loop shape and surface the exact blocker. For example: "goal is clear, but I cannot self-test because staging credentials are missing." Do not silently downgrade to an unverifiable one-shot.
21
22	## Setup Flow
23
24	Use this order before iterating:
25
26	1. Identify the goal and verifiable target.
27	2. Identify tool access and ability to self-test against that target.
28	3. Establish the baseline with the verifier when possible.
29	4. Start an actual continuation loop using `/goal` or the harness goal tool.
30	5. Report in-thread only for blockers, critical questions, surprising results, or final completion.
31	6. Repeat until the goal is reached or a stop condition triggers.
32
33	The tool-access check is mandatory. Look for the same things `self-test` requires: test configs, build scripts, app launch paths, browser/Electron harnesses, Computer Use/browser access, API endpoints, credentials, fixtures, existing specs, and the loop continuation tool. If the agent cannot reach the highest-signal affected surface or cannot start the required continuation mechanism, stop and report the blocker instead of silently using weaker proof.
34
35	If the target is reachable but the repo lacks a useful proof lane, include the missing verification structure in the loop work. Add the smallest appropriate focused test, script, fixture, browser check, Computer Use smoke, artifact capture, or `scripts/self-test.sh` lane needed to prove the goal. The loop should improve both the product behavior and the repo's ability to self-test that behavior.
36
37	Plan proof artifacts before implementation when the target has any visual, UI, desktop, browser, animation, focus, timing, or multi-step interaction surface. Use screenshots for final visible state and short screen recordings for flows that cannot be proven by one still image. Store artifacts in a durable path such as `/Users/matthewlam/.codex/proofs/<thread-or-task>/<slug>/`, verify their metadata, and include the paths in the final report. Tool output alone is not durable proof if it cannot be reopened from a stable file path.
38
39	## Loop Diagrams
40
41	Use these diagrams as the mental model for the workflow.
42
43	End-to-end loop:
44
45	```mermaid
46	flowchart LR
47	A["Find verifiable target"] --> B["Check tool access and self-test path"]
48	B --> C["Start /goal"]
49	C --> D["Report blockers or decisions in-thread"]
50	D --> E["Finish with proof"]
51	```
52
53	One turn of the loop:
54
55	```mermaid
56	flowchart TD
57	A["Make one coherent change"] --> B["Measure against target"]
58	B --> C{"Improved or closer?"}
59	C -->\|yes\| D["Keep as new best"]
60	C -->\|no\| E["Revert/discard to last best"]
61	D --> F{"Stop? target hit, stalled, out of ideas, blocked, budget hit"}
62	E --> F
63	F -->\|no\| A
64	F -->\|yes\| G["Report best result and evidence"]
65	```
66
67	## Loop Contract
68
69	Before starting work, write the loop contract in the current thread or task prompt:
70
71	```text
72	Loop: <name>
73	Goal: <specific outcome>
74	Target: <metric, tests, eval, QA check, review gate, validation count>
75	Verifier: <exact command/tool/surface and expected result>
76	Tool access: <available tools, credentials, runtime, browser/app/API access>
77	Self-test path:

People who liked this also viewed

6 picks

Type