timeboxed-iterating

Name: timeboxed-iterating
Author: av

199stars9forks

How to install timeboxed-iterating?

av/facts/timeboxed-iterating

$npx -y skills add av/facts --skill timeboxed-iterating

Installs into the current project.

Summary

Use when the user specifies a task and a duration, and the work should be done iteratively by subagents over that time period

Files · 1

View on GitHub

SKILL.md

1	# Timeboxed Iterating
2
3	Run a task iteratively via subagents for a user-specified duration. The clock is the only authority on when to stop. You are not.
4
5	## Your Role
6
7	You are the orchestrator. You do exactly two things:
8
9	1. Manage the clock — check time before every dispatch, stop when the deadline passes
10	2. Dispatch subagents — give them the goal, the progress file path, and get out of the way
11
12	You do NOT do any actual work. No code changes, no file edits, no exploration, no analysis, no "quick fixes." All productive work happens inside subagents. Your context is reserved exclusively for the dispatch loop. If you catch yourself doing anything other than checking time, reading the progress file, and dispatching — stop. That work belongs in a subagent.
13
14	## The Iron Law
15
16	```
17	YOU DO NOT DECIDE WHEN THE WORK IS DONE. THE CLOCK DECIDES.
18	```
19
20	Your only job is to keep dispatching useful work until the deadline passes. You have zero authority to judge completeness, sufficiency, or "good enough." The user gave you a duration. You use all of it.
21
22	## Inputs
23
24	The user provides two things:
25
26	1. Goal — what to do (e.g., "improve test coverage", "refactor AI slop", "build out the spec")
27	2. Duration — how long to do it (e.g., "4 hours", "overnight", "90 minutes")
28
29	If the duration is vague ("overnight"), interpret it as 8 hours. If truly ambiguous, ask once.
30
31	## The Process
32
33	```dot
34	digraph timeboxed {
35	rankdir=TB;
36	node [shape=box];
37
38	start [label="Record start time\nCompute deadline" shape=doublecircle];
39	init [label="Create progress file\nin /tmp"];
40	check [label="Check current time\nagainst deadline" shape=diamond];
41	read_log [label="Read progress file\nfor orchestrator context"];
42	dispatch [label="Dispatch subagent\nwith goal + progress file path"];
43	update [label="Update progress file\nwith iteration results"];
44	summary [label="Write final summary\nto progress file" shape=doublecircle];
45
46	start -> init -> check;
47	check -> read_log [label="time remains"];
48	check -> summary [label="deadline passed"];
49	read_log -> dispatch;
50	dispatch -> update;
51	update -> check;
52	}
53	```
54
55	### Step by step
56
57	1. Record the start time. Run `date +%s` to get the current Unix timestamp. Compute the deadline timestamp by adding the duration.
58
59	2. Create the progress file. Write it to `/tmp/timeboxed-<goal-slug>-<timestamp>.md`. Initial contents:
60
61	```markdown
62	# Timeboxed Run: <goal>
63	- Start: <human-readable time>
64	- Deadline: <human-readable time>
65	- Duration: <duration>
66
67	## Iterations
68	```
69
70	3. Check the time. Run `date +%s`. Compare against the deadline timestamp. If the deadline has passed, go to step 6. This check happens BEFORE every dispatch, never after, never "when convenient."
71
72	4. Dispatch a subagent. Give it:
73	- The goal
74	- The path to the progress file — the subagent reads it itself to learn what was already done
75	- Instruction: do ONE meaningful unit of work toward the goal, commit it, and return a structured summary of what was done and what high-impact work remains
76
77	Do NOT paste the progress file contents into the subagent prompt. Pass the path. The subagent reads it. This keeps the orchestrator's context lean across long runs.
78
79	Do NOT give the subagent the deadline or any time awareness. It does not need to know. It does one unit and returns.
80
81	5. Update the progress file. Append the iteration result:
82
83	```markdown
84	### Iteration N — <time>
85	- What was done: <summary>
86	- What was committed: <commit hash or "nothing">
87	- Suggested next: <what the subagent recommended>
88	```
89
90	Then go back to step 3.
91
92	6. Write the final summary. Append to the progress file:
93
94	```markdown
95	## Summary
96	- Total iterations: N
97	- Duration: <actual elapsed>
98	- Key accomplishments: <bullet list>
99	- Remaining work: <what's left>
100	- Progress file: <path>
101	```
102
103	Tell the user where the progress file is.
104
105	## Preventing Premature Exit
106
107	This is the entire point of the skill. LLMs will try to stop early. Every single one of these is a trap:
108
109	\| Thought you're having \| What you must do instead \|
110	\|---\|---\|
111	\| "I've made good progress" \| Check the clock. Time left? Keep going. \|
112	\| "The user would be happy with this" \| You don't decide that. Check the clock. \|
113	\| "The remaining work is too complex" \| Break it into smaller units. Dispatch. \|
114	\| "Let me just quickly check something" \| No. Dispatch a subagent to check it. \|
115	\| "This task is essentially complete" \| Find more improvements. There are always more. \|
116	\| "I should let the user review first" \| No. The user said run for X hours. Run for X hours. \|
117	\| "I don't want to break things" \| That's what commits and tests are for. Dispatch. \|
118	\| "Diminishing returns at this point" \| Not your call. Check the clock. \|
119	\|

People who liked this also viewed

6 picks

Type

hyperframes-cliUse the HyperFrames CLI development loop: init, add, catalog, capture, lint, check, snapshot, compare, grade-compare, preview, play, present, beats, keyframes, single or batch render, publish, cloud, SkillsJul 2026262k37k
request-refactor-planSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026165k181k
analyze-projectRigor Analyze / Rigor Audit read-only skill for deep learning research repositories. Use when the user wants to read and understand a repository, inspect model structure and training or inference entrSkillsMay 2026161k507
explore-codeRigor Improve implementation leaf skill for auditable candidate implementation in deep learning research repositories. Use when the researcher explicitly authorizes exploratory work on an isolated braSkillsMay 2026161k507
ubiquitous-languageSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026160k181k
scaffold-exercisesSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026149k181k

timeboxed-iterating

199stars9forks

View on GitHub

How to install timeboxed-iterating?

av/facts/timeboxed-iterating

$npx -y skills add av/facts --skill timeboxed-iterating

Installs into the current project.

Summary

Use when the user specifies a task and a duration, and the work should be done iteratively by subagents over that time period

Files · 1

View on GitHub

SKILL.md

1	# Timeboxed Iterating
2
3	Run a task iteratively via subagents for a user-specified duration. The clock is the only authority on when to stop. You are not.
4
5	## Your Role
6
7	You are the orchestrator. You do exactly two things:
8
9	1. Manage the clock — check time before every dispatch, stop when the deadline passes
10	2. Dispatch subagents — give them the goal, the progress file path, and get out of the way
11
12	You do NOT do any actual work. No code changes, no file edits, no exploration, no analysis, no "quick fixes." All productive work happens inside subagents. Your context is reserved exclusively for the dispatch loop. If you catch yourself doing anything other than checking time, reading the progress file, and dispatching — stop. That work belongs in a subagent.
13
14	## The Iron Law
15
16	```
17	YOU DO NOT DECIDE WHEN THE WORK IS DONE. THE CLOCK DECIDES.
18	```
19
20	Your only job is to keep dispatching useful work until the deadline passes. You have zero authority to judge completeness, sufficiency, or "good enough." The user gave you a duration. You use all of it.
21
22	## Inputs
23
24	The user provides two things:
25
26	1. Goal — what to do (e.g., "improve test coverage", "refactor AI slop", "build out the spec")
27	2. Duration — how long to do it (e.g., "4 hours", "overnight", "90 minutes")
28
29	If the duration is vague ("overnight"), interpret it as 8 hours. If truly ambiguous, ask once.
30
31	## The Process
32
33	```dot
34	digraph timeboxed {
35	rankdir=TB;
36	node [shape=box];
37
38	start [label="Record start time\nCompute deadline" shape=doublecircle];
39	init [label="Create progress file\nin /tmp"];
40	check [label="Check current time\nagainst deadline" shape=diamond];
41	read_log [label="Read progress file\nfor orchestrator context"];
42	dispatch [label="Dispatch subagent\nwith goal + progress file path"];
43	update [label="Update progress file\nwith iteration results"];
44	summary [label="Write final summary\nto progress file" shape=doublecircle];
45
46	start -> init -> check;
47	check -> read_log [label="time remains"];
48	check -> summary [label="deadline passed"];
49	read_log -> dispatch;
50	dispatch -> update;
51	update -> check;
52	}
53	```
54
55	### Step by step
56
57	1. Record the start time. Run `date +%s` to get the current Unix timestamp. Compute the deadline timestamp by adding the duration.
58
59	2. Create the progress file. Write it to `/tmp/timeboxed-<goal-slug>-<timestamp>.md`. Initial contents:
60
61	```markdown
62	# Timeboxed Run: <goal>
63	- Start: <human-readable time>
64	- Deadline: <human-readable time>
65	- Duration: <duration>
66
67	## Iterations
68	```
69
70	3. Check the time. Run `date +%s`. Compare against the deadline timestamp. If the deadline has passed, go to step 6. This check happens BEFORE every dispatch, never after, never "when convenient."
71
72	4. Dispatch a subagent. Give it:
73	- The goal
74	- The path to the progress file — the subagent reads it itself to learn what was already done
75	- Instruction: do ONE meaningful unit of work toward the goal, commit it, and return a structured summary of what was done and what high-impact work remains
76
77	Do NOT paste the progress file contents into the subagent prompt. Pass the path. The subagent reads it. This keeps the orchestrator's context lean across long runs.
78
79	Do NOT give the subagent the deadline or any time awareness. It does not need to know. It does one unit and returns.
80
81	5. Update the progress file. Append the iteration result:
82
83	```markdown
84	### Iteration N — <time>
85	- What was done: <summary>
86	- What was committed: <commit hash or "nothing">
87	- Suggested next: <what the subagent recommended>
88	```
89
90	Then go back to step 3.
91
92	6. Write the final summary. Append to the progress file:
93
94	```markdown
95	## Summary
96	- Total iterations: N
97	- Duration: <actual elapsed>
98	- Key accomplishments: <bullet list>
99	- Remaining work: <what's left>
100	- Progress file: <path>
101	```
102
103	Tell the user where the progress file is.
104
105	## Preventing Premature Exit
106
107	This is the entire point of the skill. LLMs will try to stop early. Every single one of these is a trap:
108
109	\| Thought you're having \| What you must do instead \|
110	\|---\|---\|
111	\| "I've made good progress" \| Check the clock. Time left? Keep going. \|
112	\| "The user would be happy with this" \| You don't decide that. Check the clock. \|
113	\| "The remaining work is too complex" \| Break it into smaller units. Dispatch. \|
114	\| "Let me just quickly check something" \| No. Dispatch a subagent to check it. \|
115	\| "This task is essentially complete" \| Find more improvements. There are always more. \|
116	\| "I should let the user review first" \| No. The user said run for X hours. Run for X hours. \|
117	\| "I don't want to break things" \| That's what commits and tests are for. Dispatch. \|
118	\| "Diminishing returns at this point" \| Not your call. Check the clock. \|
119	\|

People who liked this also viewed

6 picks

Type