goal-forge
A governed artifact in the stable bundle. Replacing this file on
your machine makes your next attestation come back Drifted, naming this path.
| Description | Forge a crisp, hook-checkable session goal — inferring a draft from the conversation plus patterns from past sessions, and/or interviewing to pin the gaps one question at a time. Fires on: what should the goal be, frame the goal, write me a goal, set the goal for this, give this a north star, I want to build/start X, before I kick this off. Produces an explicit DONE/STOP condition + scoped phases + non-goals that a tired human and a hook evaluator can both judge. NOT davinci (full PM planning), NOT checkpoint (session state). |
|---|---|
| Arguments | none |
| Tools it may use | [Read, Grep, Glob] |
| Installs at | skills/goal-forge/SKILL.md |
| Mode | 0644 — never executable |
| Size | 9973 bytes |
| SHA-256 | d14b612f4951d984241d7c4cbe12b9c2bfae85527fc1453c0b294f50947a0ed1fetch the raw bytes |
The complete file, verbatim
This is the entire SKILL.md, including its YAML frontmatter:
byte-identical to what installs, not rendered and not reformatted. Hash exactly what is below
and you get the digest above. The table is only a reading aid; this block is the artifact.
---
name: goal-forge
description: Forge a crisp, hook-checkable session goal — inferring a draft from the conversation plus patterns from past sessions, and/or interviewing to pin the gaps one question at a time. Fires on: what should the goal be, frame the goal, write me a goal, set the goal for this, give this a north star, I want to build/start X, before I kick this off. Produces an explicit DONE/STOP condition + scoped phases + non-goals that a tired human and a hook evaluator can both judge. NOT davinci (full PM planning), NOT checkpoint (session state).
allowed-tools: [Read, Grep, Glob]
---
# /goal-forge — craft a checkable session goal (infer + interview → pasteable)
*A mistwire skill, ported for public use. Where a step depends on infrastructure you may not have,
the precondition is named inline so you can adapt it rather than run a command that errors.*
> **Born from a real failure.** In the session that prompted this skill, the running goal was one
> run-on sentence with a fuzzy stop-condition — *"you stop when all the work is done and we're ready
> to pivot."* The stop-hook evaluator re-fired roughly ten times, because it could not cleanly tell
> **done** from **not-done**, and kept re-litigating already-finished phases. A good goal is
> *engineered to be checkable.* This skill forges that.
*Precondition: this is written for a harness where a session-level goal is evaluated by a
stop/completion hook. If yours has no such hook, everything below still applies — the evaluator is
just a human, and a human re-litigating a fuzzy goal is the same bug at a slower clock rate.*
## The rubric it builds to (what a well-formed goal needs)
1. **Objective** — one line: what we're achieving and why.
2. **Phases** — ordered, checkable pieces; each one is a noun plus a done-criterion.
3. **DONE / STOP condition** — the SINGLE unambiguous statement of "complete." This is the
load-bearing field: if a machine (or a tired human) can't evaluate it true/false, **rewrite it.**
"Ready to pivot to X" is fuzzy; "X's acceptance test passes and is committed" is checkable.
4. **Non-goals** — explicitly out of scope. Kills both scope creep and mis-evaluation, which are the
same bug seen from two directions.
5. **Ownership / handoffs** — what is THIS session's versus delegated, so the stop-condition isn't
silently blocked on someone else. This is the trap the originating session hit: an "always-on"
item actually belonged to a different session, but the goal read as if this session owed it — so
the goal could never evaluate true no matter what this session did.
## Process (tuned for low cognitive load)
1. **INFER from PATTERNS, not gut — never start the human with a blank page.** Draft from TWO
sources: (a) the current conversation, AND (b) patterns mined from your own session-transcript
corpus — for how this operator's goals and projects *actually* shape: typical phase count, the
stop-condition forms that closed cleanly versus the fuzzy run-ons that caused hook churn, and the
non-goals and ownership lines they habitually omit. Show the draft **and name the patterns it's
grounded in.** A gut guess presented as a pattern is not allowed.
*Precondition: this assumes session transcripts persisted somewhere greppable, plus ideally a
derived workflow summary over them. Without a corpus, say so and draft from the conversation
alone — labeled as such.*
2. **INTERVIEW only the gaps — ONE question at a time.** Ask the single highest-leverage unknown
first (almost always: *"what exact, observable thing means this is done?"*). Never stack
questions. Each answer sharpens the draft in place.
3. **Flag fuzzy stop-conditions out loud and propose the checkable rewrite.** Don't let a "we'll know
it when we see it" condition through — that is precisely the bug this skill exists to kill.
4. **At go-ahead → emit the PASTEABLE.** Lead with the clean goal block; hold the rationale below it.
## What our corpus actually showed (honest grounding, not aspiration)
These numbers come from grepping our own session-transcript archive. It is a private corpus, so they
are our report of what we found, not something you can independently check — read them for shape,
not as a benchmark.
A literal grep for goal directives found **only a couple of sessions** with grep-able goal statements
at all — and those hits were dominated by **one session's run-on goal, whose text appears 206 times**,
because every re-evaluation and context replay echoes the same line back. That is **one** fuzzy goal,
loudly instrumented; it is not 206 independent failures. Two honest takeaways shape this skill:
1. **Explicit goal statements are sparse and inconsistently phrased** across sessions, so a naive
grep undercounts badly. The *rich* signal isn't a goal-statement library; it's the **workflow
shapes** — what this operator's projects and tasks actually look like: phase counts, task mix,
where work stalls. Ground inference THERE, not in a thin grep.
2. **The one loud, real goal-pattern is the cautionary one:** fuzzy "ready to pivot / when the work's
done" stop-conditions account for **742 raw occurrences** in that corpus. Occurrences, not
incidents — the count is inflated by the same echo effect described above, so the defensible
statement is qualitative: fuzzy stop-conditions are far and away the loudest goal-shaped failure
visible in our own history. That is the anti-pattern goal-forge exists to kill.
So goal-forge grounds in **(a) workflow shapes** (rich, real) + **(b) the cautionary fuzzy-stop
exemplar** (loud) + **(c) an accruing goal log** — record each goal it forges and whether that goal
closed clean or churned, so the pattern library *grows*, because the historical one is thin. Honest
status: (a) and (b) are live today; (c) accrues from here. Never present "rich corpus patterns" that
the data does not have.
## The pasteable it emits
```
Goal: <objective — one line>.
Phases: (1) <phase — done-criterion> (2) … (N) …
DONE when: <single, binary-checkable condition>.
Not in scope: <non-goals>. Delegated: <what's owned elsewhere, by whom>.
```
*The block itself is portable — it is plain text a human or an evaluator can read. If your harness
has a goal-setting command (ours is `/goal`), prefix the block with it; if it doesn't, paste the
block wherever the session's objective lives.*
One addition worth making when the goal drives agents rather than a human: tag any phase that
depends on a human decision or a third party as `[HUMAN-GATE]` / `[DELEGATED:<who>]`, and make sure
the DONE condition is satisfiable **from the agent's side**. Otherwise the agent's stop evaluator
reads "not done," re-fires, and hammers a gate only a human can open.
## NOT this skill
- **`davinci`** — full PM planning (roadmaps, stories, estimates, boards). goal-forge crafts ONLY the
goal statement; hand the planning off once the goal is set.
- **`checkpoint`** — preserves session STATE; goal-forge sets a session's *objective*.
---
## DoD self-check (8-gate — dogfooded with the `grey-cells` claim audit)
1. **Trigger description** — **MET.** Vocabulary covers the project-forming phrasings and the
"what's the goal / write me a goal" asks; negatives named versus full PM planning and session
state.
2. **allowed-tools** — **MET, least privilege.** `Read/Grep/Glob` to infer the goal from context (a
forming spec, the active plan anchor). No `Write` — it emits a pasteable the human pastes — and
no `Bash`.
3. **Cites reason** — **MET.** The originating session's run-on goal and its ~10 stop-hook re-fires
(our own observation of that session, reported above and not independently checkable by a reader);
the standing rule to ask only the gap that judgment cannot resolve; the one-question-at-a-time
rule.
4. **Grounded facts** — **MET.** The session goal is evaluated by a stop hook (observed live in our
harness). Inference is **corpus-grounded, not gut**: it mines whatever session-transcript corpus
you have for goal-shaping patterns, and says so plainly when there is none. The rubric (objective /
phases / DONE / non-goals / ownership) is standard goal-spec hygiene. **CAVEAT:** the exact
stop-hook evaluation logic was not read from source — "binary-checkable" holds regardless of how
the evaluator is implemented.
5. **Honest reporting** — **MET.** It must FLAG a fuzzy stop-condition rather than emit it; the
emitted goal is only as good as a binary-checkable DONE.
6. **Trigger-fire validation** — **NOT-RUN** (needs a fresh session). Prompts: ① "I want to start a
new X — what should the goal be?" → should fire (infer + interview) ② "write me a goal for this" →
should fire (emit) ③ "before I kick this off, frame it" → should fire. Negatives that must NOT
fire: "build me a roadmap" (PM planning), "checkpoint this" (session state). **Run this before you
rely on the skill.**
7. **Visual bar** — **N/A.** It emits a text goal block; if a project wants a visual goal tree, that
defers to a rendering skill.
8. **Cognitive-load fit for the human operator** — **MET.** Infer-first, so never a blank prompt;
**one question at a time**, which is the core anti-overwhelm move and literally what the interview
rule enforces; lead with one thing (the pasteable, or the single gap question); honest about fuzzy
conditions. Litmus: forming a project on a low-capacity day, it offers a draft and asks one thing
→ it helps, it doesn't interrogate.
**Standing open item:** Gate 6. Run the three fire prompts in a fresh session, confirm the two
negatives stay quiet, and adjust the trigger vocabulary before you lean on this in your own project.
Everything else above is built and self-audited; the meta-irony is the point — a skill that prevents
fuzzy goals, born from a fuzzy goal.