| name | skald-goals |
| description | How to set and track OKRs (Objectives and Key Results) in Skald, following the Perdoo methodology. Covers the Time Period → Objective → Key Result → Check-in hierarchy, the qualitative-Objective vs measurable-Key-Result split, the outcome-not-output rule for Key Results, the ≤5 KRs per Objective limit, stretch-goal calibration, the weekly check-in cadence (value + note; no confidence field in Skald), and linking Key Results to Product Backlog Items so delivery rolls up to outcomes. Use this skill whenever the user is setting goals, writing or refining objectives or key results, creating a quarter/time period, checking in on progress, or connecting backlog work to outcomes — even if they don't say "Skald". Also trigger on phrases like "set our OKRs", "what should our objective be", "is this a good key result", "that's an output not an outcome", "check in on the KR", "create Q3", "link this PBI to a key result", or any call to a Skald goals tool (objective, key-result, check-in, time-period, and KR-link tools). |
Skald Goals (OKRs)
Skald's Goals module follows the OKR framework as codified by Perdoo.
The agent helps the PM write good OKRs and record progress; the PM owns
the goals.
Full methodology reference: references/okr-methodology.md.
How to write strong Objectives and KRs: references/writing-objectives-and-krs.md.
The hierarchy
Skald enforces a four-level structure. You can't create one level without
its parent:
Time Period (e.g. "Q3 2026", a date-bounded window)
└─ Objective (qualitative, inspiring, no metrics)
└─ Key Result (quantitative: start → target, a unit)
└─ Check-in (a point-in-time measured value + note)
- A Time Period must exist before you can create an Objective.
- An Objective must exist before you can create a Key Result.
- A Key Result must exist before you can record a Check-in.
So a from-scratch OKR setup is: createTimePeriod →
createObjective → createKeyResult (×N) → later, createCheckIn.
Where Objectives come from: the Vision
Before proposing or refining Objectives, read
getExistingProjectVision (and listProjectUsers if user-facing
outcomes are in play). Objectives are how the vision's Business
Goals become measurable — the skald-strategy skill's vision interview
deliberately hands off here, and an Objective that serves no part of
the vision deserves the question "what is this in service of?". If
the project has no vision yet, say so and offer the strategy work
first; don't invent direction from a blank page.
Objective vs Key Result — the core split
This is the distinction the whole framework rests on:
- Objective — what we want to achieve. Qualitative, directional,
inspiring. No metrics. Example: "Make Skald the obvious choice
for multi-team product management."
- Key Result — how we'll know we got there. Quantitative,
measurable, with a start value, a target value, and a unit. Example:
"Active weekly PMs: 5 → 50."
If a proposed Objective has a number in it, it's probably a Key Result
wearing an Objective's clothes. If a proposed Key Result has no number,
it's not measurable yet — push for the metric.
The outcome-not-output rule
The single most common OKR mistake, per Perdoo: writing Key Results
that measure activity instead of results.
- Output (avoid): "Ship 50 sales calls", "Release the share-link
feature", "Write 10 blog posts" — things you do.
- Outcome (aim for): "Close 10 new customers", "Lift weekly
active PMs from 5 to 50", "Cut time-to-first-requirement from 2
days to 2 hours" — results of what you do.
When a PM proposes an output-shaped KR, name it and offer the outcome
behind it: "'Ship the share-link feature' is an output — what outcome
are we hoping it drives? Maybe 'external stakeholder comments per week:
0 → 20'?". The output itself usually belongs in a PBI linked to the
KR (see linkage below), not in the KR text.
Less is more
Perdoo's headline guidance: keep it tight.
- ≤ 5 Key Results per Objective. More than that and focus
dissolves. If the PM wants more, ask which ones actually matter.
- A handful of Objectives per Time Period, not dozens. OKRs are the
vital few transformation goals, not a catalogue of everything the
team does.
Stretch vs committed
Calibrate ambition explicitly with the PM:
- Stretch goals: if the team consistently hits 100%, the goals
aren't ambitious enough. ~70% attainment is a healthy stretch
outcome.
- Committed goals: if the team is not using stretch framing,
then 100% is the expectation and anything less is a miss.
Ask which mode a given Objective is in so check-in interpretation is
honest. Skald doesn't store this flag — capture it in the Objective's
description if it matters.
Check-ins: cadence and shape
- Cadence: weekly progress updates are the Perdoo default. Company
OKRs run on a long (annual) cadence, team OKRs on a short (quarterly)
cadence; check-ins keep both alive between boundaries.
- Shape in Skald: a Check-in is a measured value (string,
captured exactly as the PM states it — never round) plus an optional
note.
- No confidence field. Perdoo's method tracks a confidence level
alongside the value; Skald's Check-in does not have a confidence
field. Do not fabricate one or try to encode it in the value. If the
PM wants to record confidence qualitatively, put it in the
note.
See references/okr-methodology.md
§ Check-ins for the cadence rationale.
Linking Key Results to PBIs
The bridge between outcomes and outputs. A Key Result is the outcome; the
PBIs linked to it are the outputs (Perdoo calls these "Initiatives")
the team believes will move the metric.
- Before linking, call
getExistingBacklogItems to confirm the PBI
exists in the active project.
- Then
linkKeyResultToBacklogItem. The link is idempotent.
- This is how delivery work rolls up to goals. During PBI refinement
(see the skald-planning skill) you can offer the reverse: "this PBI
looks like it moves KR X — want to link them?".
- Close the loop after delivery: when a linked PBI reaches Done
(live in production — see skald-sdd), the next check-in is where the
bet gets tested. Ask: did the metric move? A KR whose linked PBIs
keep shipping while the value stays flat is telling you the outputs
aren't buying the outcome — surface that, don't bury it.
Check for duplicates before creating
Before creating a Time Period, Objective, or Key Result, read the existing
tree — getTimePeriods, listGoals / getExistingGoals. A near-identical
Objective, a KR already tracking the same metric, or a Time Period that
already exists is a duplicate. Surface it to the PM and ask whether to reuse
or extend rather than adding a second. Never create blind.
Confirmation discipline
Every write tool here is preceded by a plain-language summary (a
proposal) and the PM's go-ahead — a plain "yes" to the proposal
suffices. One confirmation covers the whole proposal it answers.
Re-confirm if the conversation has moved on or the write differs from
what was summarised.
For Key Results specifically: state all numeric values explicitly in
the summary — start value, target value, and unit — before calling
createKeyResult. The PM confirms the exact numbers. The tool rejects a
targetValue equal to startValue.
For Check-ins: state the exact value you're about to record and confirm
it's right before calling createCheckIn. Never round.
This matches the discipline both agentic surfaces enforce. Restated
here because this skill is shared: the in-app Skald Agent and external
MCP clients load this same document.
Tool catalogue
Full list with when-to-use: references/tool-catalogue.md.
Quick reference:
Reads (no confirmation needed):
getTimePeriods({ projectId }) — existing time periods.listGoals({ projectId }) / getExistingGoals({ projectId }) — the
Objective + KR tree.getCheckInHistory({ keyResultId }) — progress trail for a KR.
Writes (confirmation discipline applies):
createTimePeriod, updateTimePeriod.createObjective, updateObjective.createKeyResult, updateKeyResult.createCheckIn.linkKeyResultToBacklogItem, unlinkKeyResultFromBacklogItem.
Adjacent reads:
getExistingProjectVision — read before proposing Objectives; they
make the vision's business goals measurable.getExistingBacklogItems — required before linking a KR to a PBI.listProjects — when you don't already have a projectId.
