speckit-skald-sync

How to model a product's domain in Skald — creating the domain hierarchy and capturing the ubiquitous language as Entities, Processes, and Terms. DDD-inspired but deliberately simpler — the goal is a clear tree of domains, each holding the glossary it owns. Covers the 3-level depth cap, when to nest vs keep flat, the Entity/Process/Term classification, term aliases, per-domain title uniqueness, reparenting (subtree moves), and domain-impact checks before renames or moves. Use this skill whenever the user is creating or organising domains, building a glossary, classifying a term, deciding where a term or requirement belongs, or restructuring the domain tree — even if they don't say "Skald". Also trigger on phrases like "add a domain", "model this area", "what's the ubiquitous language", "is this an entity or a process", "where does this term go", "move this domain", "rename this bounded context", or any call to a Skald domain tool (createDomain, updateDomain, listDomains, getDomainImpact, or the term tools).

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).

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.

How to create, refine, split, estimate, prioritise, and link Product Backlog Items (PBIs) in Skald. Covers PBI types (Feature / Bug / Refactor / Spike) and per-type title shapes, S/M/L/XL relative sizing calibrated for AI-assisted delivery, the variable PBI↔requirement relationship (either direction, linkage optional), backlog refinement (reading linked requirements, surfacing gaps, suggesting splits), the user-perspective splitting heuristic, release bundling, status transitions (the agent proposes; the PM moves), and the PM-only prioritisation rule. Use this skill whenever the user is creating, editing, splitting, sizing, prioritising, releasing, or refining a PBI — even if they don't say "Skald". Also trigger on phrases like "add to the backlog", "refine this PBI", "what should we work on next", "size this", "estimate this", "link this PBI to a requirement", "what release does this belong in", "split this", or any call to a Skald planning tool (createBacklogItems, updateBacklogItem, listPbis, getTeams).

How to write, refine, split, and manage requirements in Skald — the living specs in Spec-Driven Development. Covers user-story and EARS title shapes, the Example Mapping workshop (story → rules → examples → questions; Specification by Example), Gherkin without backgrounds or scenario outlines, MoSCoW prioritization, INVEST-based splitting, the no-solutions guideline, and the Open Questions discipline (the agent never records one on its own). Use whenever the user is creating, editing, splitting, or refining a requirement; running an example-mapping / spec-by-example workshop; writing rules or examples; or surfacing open questions — even if they don't say "Skald". Also trigger on "let's spec this", "write requirements for", "refine this user story", "what are the rules", "give me examples", "map this story", "is this too big", "moscow this", "split this requirement", or any Skald requirements tool call (createRequirements, updateRequirement, splitRequirement, rules / examples / open-question tools).

Spec-Driven Development (SDD) in Skald — how requirements are used as the living specs that drive delivery. The requirement is the spec; one PBI is one change; per-feature spec files are derived at delivery time and disposable. Covers the two-layer truth model, requirement and PBI status lifecycles as gate verdicts (Draft → Approved → Delivered; Done means live in production), the write-back rule (learnings during a build land back in the requirement), advisory vs hard gates, the code-repo constitution, and how coding agents deliver via the speckit-skald-sync preset. Use this skill whenever the user asks how requirements are used, what happens when a PBI gets built, what a status means, why something isn't Done yet, how Skald connects to Spec Kit or coding agents, or anything about spec-driven development — even if they don't say "SDD". Trigger on "what is SDD", "spec-driven", "the spec", "how does delivery work", "what does Approved mean", "write back", "one PBI one change", "hand this to the team".

How to draft and maintain a product's Vision and User list in Skald, using Roman Pichler's Product Vision Board as the interview — Target Group → Needs → Product → Business Goals, distilling the Vision statement last. The stored Vision is a short Markdown body (Problem, Vision, Differentiation, plus an optional Product list of at most five capabilities). Users capture the kinds of users the product is built for (name, description, goals, pains). Business Goals are realised by linking into the Goals/OKR layer, not stored as strategy text. Use this skill whenever the user is writing, editing, or reviewing a Vision or working on the project's Users (personas, user types, segments) — even if they don't say "Skald". Trigger on "let's write the vision", "vision board", "elevator pitch", "what is this product about", "who is this for", "add a user", or any Skald strategy tool call (setProjectVision, getExistingProjectVision, addProjectUser, updateProjectUser, archiveProjectUser, listProjectUsers).