Menu

Individual skill

create-data-context

0upvotes

Create, update, or share reusable context for analysis, reports, and dashboards, including tool preferences, look and feel, analysis practices, and data definitions. Use when asked to remember a working instruction for future tasks, save conventions, or maintain existing context.

OpenAI/Codex/plugins/data-analytics/skills/create-data-context/SKILL.md

Read pinned source

Source commit a2d33761e49b98f6ec1b48f12143264eb9b4ff4f

What was checked

Matches the observed repository HEAD
Yes
Scanner rules are current
Yes
Repository scan complete
No
Skill scan complete
No
Observed behavior
Network or broad shell
Last checked
Nov 10, 2026

These are observations at the recorded commit, not a guarantee of safety. Review the source before running it.

Install this skill

Choose an agent in your Stack or copy a command below. Commands fetch the pinned commit and copy only this skill directory. Existing destinations are refused. Copying a command does not install anything.

An install command is unavailable: current rules, complete repository and skill scans, an eligible behavior level and a permitted license are required.

Repository context

Repository stars (not skill ratings)
71,199
Repository last updated
Nov 10, 2026
License
CC0-1.0

Observed agent integration: No specific integration evidence. Standard SKILL.md installation does not imply verified compatibility.

Files and excerpt

File metadata and permitted, redacted excerpts come from the recorded scan. Source links are pinned to that commit.

Browse files
Read excerpt

# 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.
Back to top