Benefits Tracking
When to use
Periodic remeasurement with explicit attribution call — not delivery status reporting.
What this skill does not do
- Does not fix at-risk benefits — route AT-RISK/LAPSED to
benefits-recovery.
- Does not default to FULLY ATTRIBUTABLE when data insufficient.
Preconditions
| Input |
If missing |
| Benefits register |
Halt |
| Prior tracking log |
Start new; note first period |
Provisional mode
Attribution per profile convention; UNKNOWN when data insufficient.
Trust spine
Governance-tracking bands; gaming-pattern check on claimed-but-not-remeasured; append-only log.
Workflow
Read the practice profile — ~/.claude/plugins/config/claude-for-strategy/org-profile.md and ~/.claude/plugins/config/claude-for-strategy/value-realisation/CLAUDE.md — for the attribution convention and tracking cadence, the benefits register, and the prior tracking log if one exists — this skill appends, it doesn't restart the log each cycle.
For each benefit due for tracking, get the current measured value against its registered baseline and target. When the value comes from ~~bi analytics, ~~spreadsheet, or ERP MCP connectors, tag [sourced: <connector>, <report/metric>, <as-of>] on the measured figure before attribution.
Run the attribution call, explicitly, before declaring status. Ask whether a known external or market factor could explain some or all of the movement — a price change, unrelated attrition, a seasonal swing, a separate initiative touching the same number. State one of:
- FULLY ATTRIBUTABLE — no material external factor identified; the movement plausibly reflects the initiative's business change.
- PARTIALLY ATTRIBUTABLE — state the estimated discount and why (e.g. "roughly half the improvement; the other half coincides with a seasonal pattern visible in two prior years' data").
- NOT ATTRIBUTABLE — an external factor plausibly explains the movement; this is not evidence of the benefit realising, regardless of which direction the number moved.
- UNKNOWN — DATA INSUFFICIENT — say so rather than defaulting to fully attributable because that's the more flattering answer.
Flag "claimed but not remeasured" — any benefit marked on-track or realised this period with no fresh measurement actually taken. This is the most common way a register goes stale: a number gets carried forward by assumption rather than re-checked, and nobody notices until a review much later finds it was wrong for several cycles running.
Status each benefit: REALISED / ON-TRACK / AT-RISK / LAPSED. A benefit can be ON-TRACK numerically while being FULLY ATTRIBUTABLE, or AT-RISK precisely because this period's movement turned out NOT ATTRIBUTABLE even though the raw number looked fine — state both the number and the attribution call, since either one alone can mislead.
Flag any status transition since last period (e.g. ON-TRACK → AT-RISK, or the reverse) explicitly — a trend matters more than a single snapshot, and a quiet downgrade buried in a long log is easy to miss.
Route AT-RISK and LAPSED benefits to benefits-recovery rather than just logging the number and moving on — this skill's job ends at an honest status and attribution call, not a fix.
Output the full updated log, appending new entries — same append-only discipline as the rest of this repo's persisted logs.
Output format
[Full tracking log, existing entries unchanged]
NEW ENTRIES — period: [date/cycle]
BENEFIT: [name]
Current value: [value] (baseline: [value], target: [value])
Attribution: [FULLY ATTRIBUTABLE | PARTIALLY ATTRIBUTABLE — discount: ... | NOT ATTRIBUTABLE | UNKNOWN]
Status: [REALISED | ON-TRACK | AT-RISK | LAPSED]
Transition: [none] or [changed from [prior status] — flag]
Remeasurement: [fresh this period] or [FLAG — claimed but not remeasured]
[repeat per benefit tracked this round]
ROUTED TO benefits-recovery: [list of AT-RISK/LAPSED benefits, or "none"]
Worked example
Input: Number improved but seasonal pattern explains movement.
Expected output: Attribution: NOT ATTRIBUTABLE; Status may be AT-RISK despite favorable number.
Quality checks before delivering
Propose profile update
When a stable convention surfaces during this run (thresholds, naming, tone, output format, or recurring corrections), propose a profile update: show the exact diff against ~/.claude/plugins/config/claude-for-strategy/value-realisation/CLAUDE.md (org-wide facts go to org-profile.md), ask for confirmation, and write only on yes. Only /value-realisation:practice-setup auto-applies a full profile write.
Outputs
Follows plugin CLAUDE.md § Outputs. Next: benefits-recovery or next tracking period.
1---2name: benefits-tracking3description: This skill should be used when the user asks to "track this period's benefits," "update the register against actuals," "are we actually getting the savings we claimed," or needs a periodic remeasurement against baseline with an explicit attribution call — distinct from a status report, which tracks delivery progress, not realised value.4---5# Benefits Tracking67## When to use89Periodic remeasurement with explicit attribution call — not delivery status reporting.1011## What this skill does not do1213- **Does not fix at-risk benefits** — route AT-RISK/LAPSED to `benefits-recovery`.14- **Does not default to FULLY ATTRIBUTABLE** when data insufficient.1516## Preconditions1718| Input | If missing |19|---|---|20| Benefits register | Halt |21| Prior tracking log | Start new; note first period |2223## Provisional mode2425Attribution per profile convention; UNKNOWN when data insufficient.2627## Trust spine2829Governance-tracking bands; gaming-pattern check on claimed-but-not-remeasured; append-only log.3031## Workflow32331. **Read the practice profile** — `~/.claude/plugins/config/claude-for-strategy/org-profile.md` and `~/.claude/plugins/config/claude-for-strategy/value-realisation/CLAUDE.md` — for the attribution convention and tracking cadence, the benefits register, and the prior tracking log if one exists — this skill appends, it doesn't restart the log each cycle.34352. **For each benefit due for tracking, get the current measured value** against its registered baseline and target. When the value comes from `~~bi analytics`, `~~spreadsheet`, or ERP MCP connectors, tag `[sourced: <connector>, <report/metric>, <as-of>]` on the measured figure before attribution.36373. **Run the attribution call, explicitly, before declaring status.** Ask whether a known external or market factor could explain some or all of the movement — a price change, unrelated attrition, a seasonal swing, a separate initiative touching the same number. State one of:38 - **FULLY ATTRIBUTABLE** — no material external factor identified; the movement plausibly reflects the initiative's business change.39 - **PARTIALLY ATTRIBUTABLE** — state the estimated discount and why (e.g. "roughly half the improvement; the other half coincides with a seasonal pattern visible in two prior years' data").40 - **NOT ATTRIBUTABLE** — an external factor plausibly explains the movement; this is not evidence of the benefit realising, regardless of which direction the number moved.41 - **UNKNOWN — DATA INSUFFICIENT** — say so rather than defaulting to fully attributable because that's the more flattering answer.42434. **Flag "claimed but not remeasured"** — any benefit marked on-track or realised this period with no fresh measurement actually taken. This is the most common way a register goes stale: a number gets carried forward by assumption rather than re-checked, and nobody notices until a review much later finds it was wrong for several cycles running.44455. **Status each benefit**: REALISED / ON-TRACK / AT-RISK / LAPSED. A benefit can be ON-TRACK numerically while being FULLY ATTRIBUTABLE, or AT-RISK precisely because this period's movement turned out NOT ATTRIBUTABLE even though the raw number looked fine — state both the number and the attribution call, since either one alone can mislead.46476. **Flag any status transition since last period** (e.g. ON-TRACK → AT-RISK, or the reverse) explicitly — a trend matters more than a single snapshot, and a quiet downgrade buried in a long log is easy to miss.48497. **Route AT-RISK and LAPSED benefits to `benefits-recovery`** rather than just logging the number and moving on — this skill's job ends at an honest status and attribution call, not a fix.50518. **Output the full updated log**, appending new entries — same append-only discipline as the rest of this repo's persisted logs.5253## Output format5455```56[Full tracking log, existing entries unchanged]57NEW ENTRIES — period: [date/cycle]5859BENEFIT: [name]60 Current value: [value] (baseline: [value], target: [value])61 Attribution: [FULLY ATTRIBUTABLE | PARTIALLY ATTRIBUTABLE — discount: ... | NOT ATTRIBUTABLE | UNKNOWN]62 Status: [REALISED | ON-TRACK | AT-RISK | LAPSED]63 Transition: [none] or [changed from [prior status] — flag]64 Remeasurement: [fresh this period] or [FLAG — claimed but not remeasured]6566[repeat per benefit tracked this round]6768ROUTED TO benefits-recovery: [list of AT-RISK/LAPSED benefits, or "none"]69```7071## Worked example7273**Input:** Number improved but seasonal pattern explains movement.7475**Expected output:** Attribution: NOT ATTRIBUTABLE; Status may be AT-RISK despite favorable number.7677## Quality checks before delivering7879- [ ] Attribution call before status80- [ ] Remeasurement freshness checked81- [ ] Log appended not overwritten82- [ ] AT-RISK/LAPSED routed to recovery8384## Propose profile update8586When a stable convention surfaces during this run (thresholds, naming, tone, output format, or recurring corrections), **propose a profile update**: show the exact diff against `~/.claude/plugins/config/claude-for-strategy/value-realisation/CLAUDE.md` (org-wide facts go to `org-profile.md`), ask for confirmation, and write only on yes. Only `/value-realisation:practice-setup` auto-applies a full profile write.8788## Outputs8990Follows plugin `CLAUDE.md` § Outputs. Next: `benefits-recovery` or next tracking period.
daddia