|
| 1 | +--- |
| 2 | +name: goalify |
| 3 | +description: > |
| 4 | + Compose a /goal stop-condition from the current conversation and lint it |
| 5 | + against known termination-failure patterns before showing it to the user. |
| 6 | + Use when the user wants to turn the current task into a /goal loop, asks to |
| 7 | + "goalify this", wants a stop condition for autonomous work, says "write a |
| 8 | + goal condition", "make this a /goal", "turn this into a goal", or asks for |
| 9 | + help wording a condition for /goal. |
| 10 | +user-invocable: true |
| 11 | +version: 1.1.0 |
| 12 | +license: MIT |
| 13 | +--- |
| 14 | + |
| 15 | +Run this procedure yourself, in the current conversation. Do not delegate it |
| 16 | +to a sub-agent or forked session — Phase 1 reads the live transcript. |
| 17 | + |
| 18 | +$ARGUMENTS |
| 19 | + |
| 20 | +If the user supplied focus text above, use it to scope Phase 1. If empty, |
| 21 | +extract from conversation alone — do not ask the user to restate what they |
| 22 | +already said. |
| 23 | + |
| 24 | +--- |
| 25 | + |
| 26 | +## Phase 1 — Extract |
| 27 | + |
| 28 | +From the conversation so far, determine: |
| 29 | + |
| 30 | +- **The target end state.** What does "finished" concretely look like? It |
| 31 | + must be a state that can be checked, not an activity that can be performed |
| 32 | + indefinitely. ("a usable app" is checkable; "finish building the project" |
| 33 | + is not — there is no test for "finished building".) |
| 34 | +- **What is already done.** Re-read the transcript for completed sub-tasks, |
| 35 | + passing tests, merged changes, or resolved questions. These become |
| 36 | + candidates for the KNOWN section (Phase 2) or for narrowing scope |
| 37 | + (SCOPE-OUTS). |
| 38 | +- **What is explicitly NOT required.** Anything the user has ruled out, |
| 39 | + deferred, or said isn't needed. This is the raw material for SCOPE-OUTS. |
| 40 | + |
| 41 | +If the end state genuinely cannot be determined from context (not merely |
| 42 | +effortful to determine), ask one direct question. Otherwise proceed — |
| 43 | +guessing and then showing your extraction for correction is faster than |
| 44 | +front-loading a question the transcript already answers. |
| 45 | + |
| 46 | +## Phase 2 — Compose |
| 47 | + |
| 48 | +Emit a candidate condition using this structure. Every element is required |
| 49 | +unless marked optional. |
| 50 | + |
| 51 | +1. **One-sentence outcome** naming a checkable end state (not an activity). |
| 52 | +2. **Disjunctive exit**: the condition must be satisfiable by *either* |
| 53 | + reaching the end state *or* conclusively demonstrating it cannot be |
| 54 | + reached (naming the blocker). Never phrase a condition with only one exit. |
| 55 | +3. **Per-item negative terminal**, if the condition lists multiple items |
| 56 | + (tasks, sites, phases, experiments). Each item must be able to resolve to |
| 57 | + its own PASS / FAIL / BLOCKED-with-named-reason — a blocker on one item |
| 58 | + converts *that item* to a residual; it must not block the whole goal. |
| 59 | +4. **SCOPE-OUTS section** — an explicit list of what is *not* required. Write |
| 60 | + this by directly converting anything from Phase 1's "not required" list |
| 61 | + into a plain negative statement (e.g. "No production soak time required." |
| 62 | + / "Uniformity across all N items is NOT the goal."). |
| 63 | +5. **KNOWN section (optional)** — facts already established, so the actor |
| 64 | + doesn't re-derive them. Label it explicitly as a speed aid: it prevents |
| 65 | + wasted turns, it does not by itself prevent stalls, so it never replaces |
| 66 | + items 1–4. |
| 67 | + |
| 68 | +## Phase 3 — Lint |
| 69 | + |
| 70 | +Check the full composed document against every rule below. Work through all |
| 71 | +BLOCKERS first; a document with any BLOCKER triggered is not ready to show. |
| 72 | +Then check WARNINGS, which are advisory and do not block presentation. |
| 73 | + |
| 74 | +**Read the whole document for each check.** Several of these rules are only |
| 75 | +detectable by considering the document as one system — a single clause |
| 76 | +elsewhere can silently defeat a correct-looking rule everywhere else. Do not |
| 77 | +scan for keywords in isolation and stop at the first clean-looking match. |
| 78 | + |
| 79 | +### BLOCKERS — fix all before presenting |
| 80 | + |
| 81 | +- **L1 — Ordering/provenance constraint on the transcript's own history.** |
| 82 | + Any phrasing that requires evidence to precede, or be produced independent |
| 83 | + of, events that already exist in the transcript (e.g. "verify it yourself, |
| 84 | + then state what you verified", "proof must precede the claim", "evidence |
| 85 | + you produced yourself" applied to something already reported by a |
| 86 | + sub-agent or prior turn). This class of requirement is **unrepairable** — |
| 87 | + no later turn can change what already happened earlier in the transcript, |
| 88 | + so it cannot be fixed by adding more work. If the condition constrains |
| 89 | + ordering, it must constrain only *future* actions, never re-litigate what |
| 90 | + is already in the history. |
| 91 | + |
| 92 | +- **L2 — Universal quantifier over a set with possibly-exempt members.** |
| 93 | + "all N", "every X", "each of the Y", "uniform/uniformity", "complete |
| 94 | + parity", applied to a set, is a blocker **unless** each item individually |
| 95 | + carries a negative terminal (see Compose #3) or the condition names which |
| 96 | + members are exempt and why. Without one of those, a single member that |
| 97 | + cannot structurally produce the required evidence makes the whole |
| 98 | + condition permanently unsatisfiable. |
| 99 | + |
| 100 | +- **L3 — Elapsed wall-clock requirement.** Anything that requires real time |
| 101 | + to pass beyond the current session: "production soak", "after N days of |
| 102 | + use", "monitor over time", "verify in real-world use". A single session |
| 103 | + cannot advance wall-clock time; this can never be satisfied in-session. |
| 104 | + |
| 105 | +- **L4 — Human-in-the-loop or external-actor dependency mid-loop.** |
| 106 | + "stop and ask me if you need a decision", "once a reviewer merges this", |
| 107 | + "wait for approval before continuing". This directly conflicts with |
| 108 | + unattended continuation — the loop will halt waiting on an event that a |
| 109 | + condition-checking loop cannot itself produce. |
| 110 | + |
| 111 | +- **L5 — Open enumeration.** Scope phrased as an unbounded or unenumerated |
| 112 | + set: "all editing features of X", "complete parity with Y", "everything |
| 113 | + needed to fully support Z". An evaluator can always name one more item |
| 114 | + under this phrasing, so it never terminates. Convert to a closed, named |
| 115 | + list, or to a single representative artifact. |
| 116 | + |
| 117 | +- **L0 — Cross-clause consistency (meta-rule).** *An escape hatch is only as |
| 118 | + strong as the strictest other clause in the same document.* After |
| 119 | + confirming L1–L5 pass individually and a disjunctive exit exists, re-read |
| 120 | + the document once more asking only: **is there any other sentence, anywhere |
| 121 | + in the document, that is stricter than the stated exit and would override |
| 122 | + it?** A document can have a textbook-perfect exit clause and still be |
| 123 | + unsatisfiable because one unrelated sentence elsewhere re-imposes an L1–L5 |
| 124 | + style constraint the exit clause doesn't cover. Confirming an exit clause |
| 125 | + exists is not sufficient — confirm nothing else in the document is |
| 126 | + stricter than it. |
| 127 | + |
| 128 | +### WARNINGS — advisory, do not block presentation |
| 129 | + |
| 130 | +- **L6 — Missing disjunctive exit.** The document should state achievement |
| 131 | + *or* a way to conclusively end in "not achievable, here is why" (see |
| 132 | + Compose #2). Flag and fix its absence where practical, but do not block |
| 133 | + presentation on it alone. |
| 134 | +- **W1** — Multiple items are listed but not all of them carry their own |
| 135 | + negative terminal (some do, some don't). |
| 136 | +- **W2** — No clause asking the actor to show evidence inline in the |
| 137 | + transcript as it's produced, rather than only asserting a result. |
| 138 | +- **W3** — Scope reads like more than one session's worth of work (multi-week |
| 139 | + rollout language, coordination across many independent repos/teams, |
| 140 | + phased production deployment). |
| 141 | +- **W4** — The condition contains a cautionary anecdote or narrative about a |
| 142 | + failure mode (e.g. "don't repeat what went wrong last time", "make sure |
| 143 | + this doesn't stall like before") rather than a plain instruction. Any such |
| 144 | + narrative addressed to the actor is read by the evaluator too, and can |
| 145 | + silently become a criterion the evaluator judges against instead of |
| 146 | + guidance the actor merely follows. State requirements as plain criteria, |
| 147 | + never as stories. |
| 148 | + |
| 149 | + **This applies to the condition you are composing right now.** Write every |
| 150 | + clause as a direct instruction to the actor, never as a story about a past |
| 151 | + run. If you catch yourself writing "so that we don't repeat X", rewrite it |
| 152 | + as the direct requirement it implies, with no reference to the incident. |
| 153 | + |
| 154 | +### If a BLOCKER cannot be cleared |
| 155 | + |
| 156 | +Rewrite and re-check. Allow up to three rewrite passes. If a BLOCKER still |
| 157 | +fires after three passes, stop and surface the specific tension to the user |
| 158 | +by name (e.g. "the user's own request requires enumerating an open-ended set |
| 159 | +— L5 fires no matter how I phrase it; how would you like to bound this?"). |
| 160 | +Do not present a condition that still fails a BLOCKER. |
| 161 | + |
| 162 | +--- |
| 163 | + |
| 164 | +## Output format |
| 165 | + |
| 166 | +Always output the condition inside a fenced code block — terminal reflow |
| 167 | +will otherwise destroy its multi-line structure. Follow it with the lint |
| 168 | +report as a table, then offer (do not auto-run) `/goal`. |
| 169 | + |
| 170 | +``` |
| 171 | +<the condition text> |
| 172 | +``` |
| 173 | + |
| 174 | +| Rule | Result | Note | |
| 175 | +|------|--------|------| |
| 176 | +| L0 | no known pattern detected | ... | |
| 177 | +| L1 | no known pattern detected | ... | |
| 178 | +| L2 | no known pattern detected | ... | |
| 179 | +| L3 | no known pattern detected | ... | |
| 180 | +| L4 | no known pattern detected | ... | |
| 181 | +| L5 | no known pattern detected | ... | |
| 182 | +| L6, W1–W4 | (list only the ones that fired) | ... | |
| 183 | + |
| 184 | +A clean table means no *known* failure pattern was detected — not that the |
| 185 | +condition is validated. Say so if the user reads it as a guarantee. |
| 186 | + |
| 187 | +Then: "Pass this to `/goal` to start the loop — want me to run it now, or |
| 188 | +would you like to adjust anything first?" |
0 commit comments