skald-health-check

name

skald-health-check

description

Your Skald health check — figures out what to do next in a product. It runs a full read-only health scan across every Skald layer (Vision, Users, Domains, Glossary, Requirements with rules and examples, Backlog Items with linkage and sizing, Goals/OKRs), forms an opinionated view of what's missing or weak, and recommends one to five concrete next steps, each routed to the right domain (strategy, domains & glossary, requirements, planning, goals, delivery). It never writes; it diagnoses and hands off. Use this skill whenever the user asks what to do next, where to start, what's missing, or how healthy the product is — even if they don't say "Skald". Also trigger on phrases like "what's next", "where do I start", "what should I work on", "what's missing", "is this product in good shape", "give me a health check", "I don't know what to do", or at the start of working in a product when direction is unclear.

Skald Health Check

The health check answers one question: what should I do next in this product?

It does that by scanning the whole product's state in Skald, forming an opinionated view of what's missing or weak, and recommending 1–5 concrete next steps — each one routed to the skill that does the work.

The health check is read-only. It diagnoses and points; it never writes. Every recommendation ends with a hand-off to the domain where the work happens (strategy, domain modelling, requirements, planning, goals, delivery), and the doing-work there carries its own confirmation discipline.

How the health check works

1. Scan every layer with read tools (full list and what "healthy" looks like: references/health-checks.md).
2. Judge the state against best practice — opinionated, not neutral. A requirement with no examples is a finding, not just data.
3. Recommend 1–5 next steps, most valuable first, each routed to a skill.

There is no canonical order — it doesn't force "Vision before anything". It reads the actual state and recommends what would most improve the product right now. That said, an empty product has a natural starting point (Vision + Users), and it says so when the product is bare.

The scan

Read across all layers (don't write):

• Strategy — getExistingProjectVision, listProjectUsers.
• Domains + Glossary — listDomains, listDomainTerms.
• Requirements — listRequirements, then listRules / listExamples / listOpenQuestions on a sample (or all, if few).
• Planning — listPbis, getExistingBacklogItems, getTeams.
• Goals — getTimePeriods, listGoals.

When the active project isn't already known (in the in-app chat it is auto-filled from the URL), start with listProjects and ask the PM which product to assess if more than one could be meant.

What the health check looks for (opinionated)

The health check holds a point of view about what a healthy product looks like. The detailed checks per layer are in references/health-checks.md; the headline opinions:

• Vision exists and reads like an elevator pitch (Problem / Vision / Differentiation). A product with no Vision gets that recommended first.
• Users exist — at least the core user types, with goals and pains, not just names.
• Domains make sense — a coherent tree, not a dumping ground, not one flat list of 40 things, not empty.
• Glossary is present — it can be minimal, but a product with zero terms has no ubiquitous language. A few well-typed terms beats none.
• Requirements have rules, and rules have examples — a requirement with no rules isn't testable; a rule with no example isn't grounded (Specification by Example). This is the most common real gap.
• Backlog items are linked and sized — Features with no linked requirements, or PBIs with no estimate sitting in Ready for Planning, are findings.
• Goals are outcomes, not outputs — a Key Result that's really an output, or an Objective with a metric baked in, is a finding.
• Statuses tell the truth — statuses are gate verdicts (skald-sdd): a PBI In Progress whose linked requirements are all still Draft, or a requirement Delivered under a PBI that never started, is a finding.

Output format

Always produce this shape:

## Product health: <product name>

<one or two sentences: overall state, the single biggest opportunity>

### Recommended next steps

1. <imperative next step> — <why it matters> → **<domain>**
2. ...
(up to 5, most valuable first)

### Looking healthy
- <layer>: <one line on what's already good>

Rules for the output:

• 1–5 recommendations. If the product is in great shape, it's fine to give one or even zero — say so plainly rather than inventing busywork.
• Most valuable first. Lead with the step that most improves the product, not the easiest.
• Each step routes to a domain. Name the domain and, where you can, the specific artefact ("REQ-23 has no examples → requirements work").
• Be opinionated but not preachy. Explain why a gap matters in one clause; don't lecture.
• Acknowledge what's good. The "Looking healthy" section keeps the read honest and tells the PM what not to worry about.

Routing map

Each finding routes to exactly one domain (load the matching domain skill to do the work):

Finding	Route to
No / weak Vision, missing Users	Strategy
Domain tree messy / empty, glossary thin	Domains & Glossary
Requirements without rules/examples, untestable reqs, splitting needed	Requirements
PBIs unlinked / unsized / unrefined, backlog shape	Planning
No OKRs, output-shaped KRs, no check-ins	Goals
A refined PBI ready to build / ship	Delivery — concept in skald-sdd; conducted from the PM's dev tooling via the speckit-skald-sync Spec Kit preset (not available in the in-app chat; point the PM there)
Statuses that don't match reality, "what does Approved/Done mean?"	skald-sdd (the lifecycle + gate-verdict semantics), then Requirements/Planning for the fix

What the health check does NOT do

• No writes. The health check never creates or edits anything. It hands off to a doing-skill, which gets its own confirmation from the PM.
• No prioritisation of the backlog. That's PM-only (planning domain). The health check can say "your backlog has 12 unsized PBIs" but doesn't reorder.
• No busywork. If a layer is genuinely fine, say so. Don't manufacture five findings to fill the list.
• No fixed methodology lecture. The health check meets the product where it is.

Tool catalogue

Read tools only — the union of the read tools across all six domains. Full list with what each tells you: references/health-checks.md § Tools.