Seshat-BI: Skill for Claude Code

report-intent-interview

The Report Intent Interview is the missing front end of the dashboard intelligence journey (spec 123, US1). It converts a conversational report request into a committed, reviewable report-intent.yaml so every downstream artifact (blueprint, composition, preview, audit, PBIR) traces back to a clear, approved report purpose instead of an unrecorded assumption.

This skill mirrors .claude/skills/business-knowledge-interview/SKILL.md structurally (load-existing-first, batch/critical question grouping, PII masking, record + STOP, never self-grant) but does NOT extend it: the required_inputs and focus differ. Behavior is governed by the contract contracts/interview/report-intent-interview.yaml; the shape of the produced artifact is templates/report-intent.yaml. The static rule DL9 (seshat check) verifies the recorded artifact's SHAPE, not the conversation.

When to use

• Someone describes a report they need in plain language ("I need a weekly report for branch managers to spot underperforming branches").
• Before dashboard-design, the dashboard coordinator, page blueprints, visual specs, or report composition -- those stages trace their business_question back to a question declared here (FR-002a) and are blocked until this intent's own report_intent_approval decision is approved.

Preconditions (stop if unmet)

• Approved metric contracts exist for the subject area (readiness.status: pass). No approved contract for a metric the request needs => record a gap, route upstream to metric-contract definition, and leave the intent blocked on that metric (FR-004) -- never define the metric here.
• The semantic model is ready (semantic_model_ready: pass). Not ready => stop, name the missing readiness, and do not proceed to design.
• Load the existing Report Intent (if any) first. An existing intent is presented for confirmation or supersession -- never silently overwritten.

How it runs

1. Ground every question in the request and the approved contracts. Focus on: audience, purpose, supported decision, review cadence, primary business questions, metric roles by name (outcome/driver/guardrail), comparisons, dimensions and filters, expected actions and exceptions, pages/drill paths, mobile/accessibility/language/RTL needs, and exclusions/non-goals.
2. Refuse to commit a vague request. "Build an executive dashboard" gets focused disambiguating questions; the intent is NOT committed until audience, purpose, and at least one primary business_questions entry are resolved (US1 AC#4).
3. Batch the obvious low-risk items into one owner confirmation (e.g. comparison phrasing, filter defaults). Critical decision types are never in a batch. The owner may exclude any item; the remainder is approved in one action and each excluded item becomes an individual pending question.
4. Ask critical decisions individually. The intent's own approval (report_intent_approval) is a critical decision type, authority class report_owner (contracts/knowledge/approval-authority.yaml); it requires an explicit, per-decision approval from a named human -- the agent never self-grants it (Principle V).
5. Reference metrics by name only. Every outcome_metrics / driver_metrics / guardrail_metrics entry names an approved metric contract (name + store_ref + status_required: pass) -- the same triple shape as dashboard-page-blueprint.yaml's required_metric_contracts. There is no formula/DAX field. A metric with no approved contract is a gap: record it, route it upstream, and leave the intent blocked on that metric -- never invent the metric here.
6. Mask suspected PII by default. Any PII-adjacent dimension/filter follows the shipped masking behavior; unmasking requires an explicit owner instruction, recorded as a pii_handling decision.
7. Record the artifact and the decision. Write mappings/<subject-area>/design/report-intent.yaml per templates/report-intent.yaml, and record the report_intent_approval decision in the project Decision Store once a named human of authority class report_owner approves. Unanswered items stay pending / needs_user_input; a metric gap stays blocked with a matching blocking_reasons entry.