predictive-execution

Name: predictive-execution
Author: UnpaidAttention

84stars18forks

How to install predictive-execution?

unpaidattention/fable5-methodology/predictive-execution

$npx -y skills add UnpaidAttention/fable5-methodology --skill predictive-execution

Installs into the current project.

Summary

The ambient execution discipline — predict the outcome of every consequential command BEFORE running it and treat any surprise (better or worse) as a model error to investigate; choose the next action by information gain; estimate blast radius before touching anything shared. Tri

Files · 1

View on GitHub

SKILL.md

1	# Predictive Execution
2
3	Running a command "to see what happens" is a slot machine: whatever comes out, you learn almost
4	nothing, because you had no expectation for reality to collide with. This skill converts every
5	execution into a hypothesis test, every choice of action into an information decision, and
6	every edit into a scoped-risk decision. It is the single highest-leverage habit for making a
7	weaker model behave like a stronger one during hands-on work.
8
9	## Rule 1: Predict, then run, then compare
10
11	Before every consequential command, test run, or query, write the expected outcome first —
12	one line, specific enough to be wrong: "42 tests pass", "returns 3 rows", "exits non-zero
13	complaining about the version", "p95 drops below 400ms".
14
15	Then run, and compare. Three cases:
16
17	1. Match → your model of the system is confirmed. Proceed.
18	2. Worse than predicted → your model is wrong somewhere. STOP and locate where before
19	proceeding. The divergence is the most information-dense moment you'll get — it marks
20	exactly where your understanding and reality part ways. Continuing past it means building
21	on a model you just proved wrong.
22	3. Better than predicted — "passed, but I expected failure" — is equally suspicious,
23	and the case weaker models always wave through. A test that passes when you expected red is
24	usually not testing what you think it tests (wrong file ran, stale build, assertion
25	vacuous). A bug that "fixed itself" didn't. Investigate with the same seriousness as case 2.
26
27	Never brush past a surprise in either direction. If you must defer investigating one,
28	write it down as an open question — a surprise you neither investigated nor recorded is a
29	defect in your understanding left armed.
30
31	## Rule 2: Choose the next action by information gain
32
33	At any point with several possible actions, ask: **"which action's outcome most reduces my
34	uncertainty — best discriminates between my live hypotheses?"**
35
36	- A cheap look that eliminates half the hypothesis space beats an expensive build that confirms
37	what you already believe.
38	- Don't take actions whose outcome you can already predict with high confidence — unless
39	verification IS the point (then Rule 1 applies: predict first anyway).
40	- Tie-break equal information gain by cost, always.
41	- This generalizes debugging's "cheapest distinguishing observation" to everything: which file
42	to read next, which experiment to run, which question to ask.
43
44	## Rule 3: Estimate blast radius before editing anything shared
45
46	Before changing anything with potential dependents, enumerate them **mechanically, not from
47	recall**: grep for direct callers; look for serialized artifacts the old code produced (DB
48	rows, cached JSON, files, wire messages); consider consumers in other services/repos, docs,
49	tests, scheduled jobs. Then one step further: what depends on the dependents?
50
51	The classification that decides how careful to be: **does this thing's meaning cross a process
52	or persistence boundary?**
53
54	- No (a pure function with three greppable callers) → it's an edit: change it, update the
55	callers, verify.
56	- Yes (a JSON field in a queue message, a DB column, a public API shape) → it's a migration:
57	invisible dependents exist; use expand/contract or versioning, never a casual in-place change.
58
59	## Worked example
60
61	Task: "The nightly export is empty since Tuesday; fix it."
62
63	- Weak execution: run the job, stare at output, add a print, run again, tweak a filter, run
64	again — five runs, no predictions, learning by slot machine.
65	- Predictive execution:
66	1. Hypotheses: (a) query returns 0 rows, (b) rows returned but serializer drops them,
67	(c) file written then overwritten. Rule 2: the single most discriminating observation
68	is the row count at the query boundary — one log line splits (a) from (b)+(c).
69	2. Rule 1 predict: "if (a), count=0 on Tuesday's snapshot; if not, count>0." Run →
70	`count=1842`. Hypothesis (a) eliminated; model updated.
71	3. Next discriminator: does the serializer receive them? Predict "serializer input len 1842"
72	→ run → `len=0`. Divergence located between query and serializer — reading that seam

People who liked this also viewed

6 picks

Type

predictive-execution

84stars18forks

View on GitHub

How to install predictive-execution?

unpaidattention/fable5-methodology/predictive-execution

$npx -y skills add UnpaidAttention/fable5-methodology --skill predictive-execution

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Predictive Execution
2
3	Running a command "to see what happens" is a slot machine: whatever comes out, you learn almost
4	nothing, because you had no expectation for reality to collide with. This skill converts every
5	execution into a hypothesis test, every choice of action into an information decision, and
6	every edit into a scoped-risk decision. It is the single highest-leverage habit for making a
7	weaker model behave like a stronger one during hands-on work.
8
9	## Rule 1: Predict, then run, then compare
10
11	Before every consequential command, test run, or query, write the expected outcome first —
12	one line, specific enough to be wrong: "42 tests pass", "returns 3 rows", "exits non-zero
13	complaining about the version", "p95 drops below 400ms".
14
15	Then run, and compare. Three cases:
16
17	1. Match → your model of the system is confirmed. Proceed.
18	2. Worse than predicted → your model is wrong somewhere. STOP and locate where before
19	proceeding. The divergence is the most information-dense moment you'll get — it marks
20	exactly where your understanding and reality part ways. Continuing past it means building
21	on a model you just proved wrong.
22	3. Better than predicted — "passed, but I expected failure" — is equally suspicious,
23	and the case weaker models always wave through. A test that passes when you expected red is
24	usually not testing what you think it tests (wrong file ran, stale build, assertion
25	vacuous). A bug that "fixed itself" didn't. Investigate with the same seriousness as case 2.
26
27	Never brush past a surprise in either direction. If you must defer investigating one,
28	write it down as an open question — a surprise you neither investigated nor recorded is a
29	defect in your understanding left armed.
30
31	## Rule 2: Choose the next action by information gain
32
33	At any point with several possible actions, ask: **"which action's outcome most reduces my
34	uncertainty — best discriminates between my live hypotheses?"**
35
36	- A cheap look that eliminates half the hypothesis space beats an expensive build that confirms
37	what you already believe.
38	- Don't take actions whose outcome you can already predict with high confidence — unless
39	verification IS the point (then Rule 1 applies: predict first anyway).
40	- Tie-break equal information gain by cost, always.
41	- This generalizes debugging's "cheapest distinguishing observation" to everything: which file
42	to read next, which experiment to run, which question to ask.
43
44	## Rule 3: Estimate blast radius before editing anything shared
45
46	Before changing anything with potential dependents, enumerate them **mechanically, not from
47	recall**: grep for direct callers; look for serialized artifacts the old code produced (DB
48	rows, cached JSON, files, wire messages); consider consumers in other services/repos, docs,
49	tests, scheduled jobs. Then one step further: what depends on the dependents?
50
51	The classification that decides how careful to be: **does this thing's meaning cross a process
52	or persistence boundary?**
53
54	- No (a pure function with three greppable callers) → it's an edit: change it, update the
55	callers, verify.
56	- Yes (a JSON field in a queue message, a DB column, a public API shape) → it's a migration:
57	invisible dependents exist; use expand/contract or versioning, never a casual in-place change.
58
59	## Worked example
60
61	Task: "The nightly export is empty since Tuesday; fix it."
62
63	- Weak execution: run the job, stare at output, add a print, run again, tweak a filter, run
64	again — five runs, no predictions, learning by slot machine.
65	- Predictive execution:
66	1. Hypotheses: (a) query returns 0 rows, (b) rows returned but serializer drops them,
67	(c) file written then overwritten. Rule 2: the single most discriminating observation
68	is the row count at the query boundary — one log line splits (a) from (b)+(c).
69	2. Rule 1 predict: "if (a), count=0 on Tuesday's snapshot; if not, count>0." Run →
70	`count=1842`. Hypothesis (a) eliminated; model updated.
71	3. Next discriminator: does the serializer receive them? Predict "serializer input len 1842"
72	→ run → `len=0`. Divergence located between query and serializer — reading that seam

People who liked this also viewed

6 picks

Type