break-down-objectives

Files (1)

• SKILL.md

SKILL.md (first lines)

---

## name: break-down-objectives

description: Decompose a compressed goal, one-liner strategy, or multi-clause mandate into a goal-framework-agnostic hierarchy: goals with measurement stories, strategies as bets, measures with leading/lagging tags, and initiatives/briefs born on a need-to-make basis. Produces testable success criteria, option matrices, a chosen solve path, sequencing, and hard constraints — without implementing unless asked.

# Break down objectives

Turn a **dense statement** (one sentence, a triage list, a “build X then Y”) into a **decision-ready decomposition**: testable success, options, pick, order, and what not to do.

The decomposition naturally produces a **goal hierarchy**: goals with measurement
stories, strategies as bets on how to move each goal, measures with leading/lagging
tags, and — when the work actually requires them — initiatives (commitments to move
a specific goal) and briefs (shippable units inside an initiative). **Do not force
all artifacts to exist.** Decompose only as far as is useful. If a goal is clear and
measurable on its own, leave it. If a strategy doesn't need a measure, don't force
one. Initiatives and briefs emerge when the work demands them — not as a checklist.

**Default: analysis only.** Do not implement code or large doc rewrites unless the user explicitly asks after the breakdown.

## When to use

- “Break that down” / “how do we solve each part”
- Strategy one-liners that hide several jobs
- Ranked backlogs that need **objective** acceptance, not taste
- Aligning agents on *what done means* before anyone codes
- Decomposing a goal into measurable strategies when multiple distinct approaches could move it

## Inputs

Accept any of:

1. A single multi-clause sentence
2. A short ordered list (“first A, then B, don’t C”)
3. A disagreement (“you ranked X first; I’d rank Y”)

If the goal is vague, ask **one** clarifying question, then proceed with stated
assumptions labeled as such.

## Process

### 1. Split into claims

Parse the mandate into **atomic clauses**. Prefer:

- **Do** (positive work)
- **Order** (A before B)
- **Don’t** (constraints / anti-goals)

Number them. Quote the source phrase for each so nothing is invented.

Each claim becomes a **goal** in the decomposition — a measurable outcome the
organization is trying to move. If a claim is already clear and measurable on
its own, it stays a single goal. If multiple distinct approaches could move it,
the goal gets **strategies** (each a bet on a path) and **measures** (leading
and lagging indicators). This split is driven by the work, not by a template.

### 2. For each clause, run the card

Use this structure **every time** (same headings, same order):

#### N. “«quoted clause»”

**What this means**
1–3 sentences. Strip metaphor; name the real problem this goal is trying to solve.

**Measurement story**
1–2 sentences: what we're trying to move, how we'll know, and what period rolls up.
If the goal is clear and measurable on its own, state the measurement story and move
on — don't force further decomposition.

**“Solved when” tests → measures**
A table of tests. Each row: id · test · pass if · leading/lagging.
Rules for good tests (these are the qualities of a good measure):

- Observable (metric, event, artifact, behavior, doc signature)
- Binary or clearly graded — not “feels better”
- Prefer external behavior and outcomes over internal elegance
- Tag each test **leading** (early signal) or **lagging** (outcome itself)
- Include **negative** tests when relevant (“does *not* add second system”)

Minimum **3** tests per substantive clause; **2** OK for pure constraints.

**Strategies** (only if the goal is broad enough that multiple distinct approaches
could move it)
List each strategy as a named bet: “We bet that X will move this goal because Y.”
If the goal has one obvious path, skip this section — don't manufacture fake
alternatives.

**How to solve (options)**
Table: approach · pros · cons · objective pick (or Reject).
At least two real options when the space is non-trivial; “do nothing” is valid.
If strategies were listed above, options should address which strategy (or
combination) to commit to.

**Solve path**
One short recommended path: what to build/write/decide first, scope caps, dependencies. Still no implementation unless asked.

**Initiative / Brief** (born on a need-to-make basis — only when the work requires
a commitment layer or a shippable unit)
If the solve path requires a team commitment to move this goal, name it as an
**initiative** (what goal it moves, weight if partial). If the initiative needs a
discoverable shippable unit, name it as a **brief** (what we're building, why, what
success looks like). If neither is needed yet, skip this section entirely.

**Falsify**
If data shows X, then change Y. 1–3 rows. Prevents sticky plans.

### 3. Constraints as first-class cards

Every “don’t” gets the same card type (solved when = constraint still holds;
options = how to meet the need *without* the forbidden thing).

### 4. Reassemble sequence

After all cards, output **one pipeline** (ascii or numbered) that:

- Respects order clauses
- Parks constrained items

From gethamster/skills, MIT.

More from gethamster/skills