create-data-context

Create Data Context

Create compact, editable context for how the user wants analysis, reports, and dashboards produced. Context can contain a single tool preference, report or dashboard look and feel, analysis practices, data definitions, or a useful combination. Keep guidance for the same audience in one skill and one plugin; data definitions are optional. Establish what the guidance covers separately from who may receive it. Honor draft-only, source-only, package-only, no-install, and already-reviewed instructions.

Principles

• Call metric definitions, source maps, and caveats "data context" in user-facing copy. Preserve actual provider names, URLs, and technical identifiers.
• Reuse answered questions, honor plain-text requests, and ask only currently useful unresolved questions. Group a few related, independently answerable blocking questions when that saves a round trip, such as references/scan direction and personal versus shared use. Explain the shared context above the group and each choice where needed. Separate questions whose answer depends on an earlier decision, and honor a request for one question at a time. Prefer a nonblocking elicitation (request_user_input_async on Codex when callable and supported), following the host contract. Keep pending questions available where the host supports persistence; do not repeatedly recreate answered or unchanged questions. Use each actual answer before dependent work and continue authorized independent work while waiting.
• Put 1–2 short sentences explaining the current choice or useful inputs immediately above the question inside the elicitation. Use its instruction/description field when supported, otherwise put the explanation before the question in its title. Do not leave essential instructions only in commentary that may collapse. Use P1A's audience explanation once; avoid repeating local-install or sharing disclaimers in the intro and each question.
• Whenever a turn ends awaiting user input, the last final response must contain all currently pending questions, their useful choices or reply instructions, and enough context to answer without expanding progress or finding a form. During initial setup, include the P1 introduction in that final response if it has not yet appeared in a completed turn's final response. This applies even when a form was called or an earlier message was labeled as an answer. Text followed by more tool calls or a later final reply does not satisfy this visible handoff. Finish independent reads first, then send the self-contained final response and yield; if work continues after an earlier question, include the necessary introduction and pending questions again in the last response. Never replace them with "answer the questions above" or a skill-requirement explanation.
• Required choices still need an actual reply before dependent work proceeds. Retain the pending elicitation when the host supports it across turns, with the final-response handoff above regardless of form persistence. If a form is unavailable or renders as ordinary text, ask the pending questions directly in the final response. Do not keep a turn alive just to hold a card open or claim persistence the host does not support. Optional preferences may use a safe fallback; they do not resolve required choices.
• Keep one coherent scope and preserve unrelated context. Save only useful, non-obvious information; omit generic policy/background, installed-tool inventories, and visible capability restatements.
• Apply the intended audience established for each draft or update; use P1A when it is unclear. Keep shared working guidance broadly useful and scoped to the relevant data work or deliverable. Treat optional shared style conventions as defaults that leave room for personal preferences; do not let style preferences redefine metrics or override mandatory policies. Preserve explicit workflow requirements and personal exceptions with their actual scope. Split only when different audiences need different guidance or the user explicitly requests it, never merely because definitions and style are different content types.
• Write preferences as direct model instructions, preserving their meaning and scope without quoting answers or labeling them "explicit user input." Prepopulate facts only with very high-confidence support from current, applicable authoritative sources and adjacent citations. Do not infer analytical methods, query budgets, interaction choices, or tool preferences from nearby examples.
• Keep state, accepted answers, skips, and deferrals in task notes, never the generated skill. Load substantial conditional knowledge only when relevant.
• Use personal memories only when authorized. Present their summary for user review before incorporating them into shared drafts or packages. Exclude secrets, personal details, customer-specific records, and private transcripts from shared context; corroborate recollections before treating them as shared standards.