kpi-contract-builderlisted

Help a human turn a named-but-planned retail KPI into a governed, owner-ready project metric-contract by driving the shipped kpi_contracts engine (spec 124). On first contact, when no approved decisions exist yet, it assesses source answerability, lists the exact Decision Store decisions to get approved via business-knowledge-interview, and renders a preview with per-field provenance -- writing no YAML. Once the approved kpi_definition / policy_ruling decisions, a named eligible owner, and committed source evidence exist, it drives draft_project_metric_contract (a gold-blocked contract) and, after the gold binding is materialized, finalize_project_metric_contract. Use when someone asks to draft, author, or start a metric contract for a planned KPI in the Seshat BI repo. It never invents business meaning, DAX, SQL, gold columns, approvals, owners, a confidence score, or a registry entry; it never promotes a KPI to Seeded and never self-grants an approval.
Kemetra/Seshat-BI · ★ 2 · API & Backend · score 68

Install: claude install-skill Kemetra/Seshat-BI

# kpi-contract-builder This skill is the agent-facing front door to the shipped `kpi_contracts` stage. It does NOT reimplement contract authoring: the shipped `kpi_contracts` engine and its `kpi_answerability` scorecard already exist (spec 124). This skill DRIVES them and adds the first-contact assessment the engine deliberately refuses to do. ## When to use - Someone asks to draft / author / start a metric contract for a KPI that the registry marks `planned` (no seeded contract yet), or for a user-supplied custom KPI. - You are at the `kpi_contracts` flow stage (downstream of `business-knowledge-interview`, upstream of silver/gold model planning). Do NOT use it to define DAX (`retail generate`), to check a PBIP model (`retail semantic-check`), or to run the interview itself (`business-knowledge-interview`). ## The two-trip flow The shipped `draft_project_metric_contract` REQUIRES an approved decision, a named owner, and committed source evidence; without them it raises `ContractDraftRefused`. So the flow has two trips. ### Trip 1 -- Assess & preview (the common first-contact case; writes nothing) 1. Identify the KPI. Registry-known -> resolve its `generic_kpi_ref: KPI-MC-NN` from the `retail-kpi-knowledge` registry (`custom: false`). User-supplied -> `custom: true`, no ref, no suggested id. 2. Read the source-coverage signal (read-only). NOTE: for a `lifecycle: planned` registry entry -- the primary case for this skill -- `derive_answerability` shor