SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillsdata-grill

data-grill

Data & analytics

View repository

Updated 10-15 22:11

About this skill

Data Development Design-First

Before starting data development, first get the user and yourself to say the same thing about the same matter: what to do, where the boundaries are, how to choose the key decisions.If the design is not confirmed, do not write DDL, do not build pipelines, do not define interfaces.

What this skill delivers

The user has a data development need but it is still vague, and through one question at a time you converge on:

  1. Design decision record design-decisions.md: scope, expected result, confirmed key decisions (including option letter markers).
  2. Handoff guidance: clarify which executor the next step should go to (table creation→finance-ddl-design, pipeline→finance-pipeline-dev, interface→finance-query-contract, QC→finance-data-qc).

The decision record is theinput prerequisitefor subsequent executors, and does not repeatedly generate formal deliverables.

Differences from the general /grill

  • The general /grill solves "what product to build/when to build it";data-grill solves "how to design the data"—table granularity/primary key/temporality, pipeline incremental method, interface input boundaries, QC acceptance criteria.
  • The decision surface is switched to data development terminology; evidence is verified from the repository's metadata/contracts (not by guessing), and decisions are given to you (not made for the user).
  • One question at a time, A/B/C/D with Recommended:, and no code changes before confirmation—these three iron rules are retained as-is.

Core principles (data version iron rules)

  1. One question at a time. Never throw out multiple questions at once; first ask the one that would change subsequent decisions.
  2. Include a recommendation. Every multiple choice must be marked with A) Recommended: 机制—产出感, give one clear recommendation and explain the reason.
  3. Evidence verification. Things that can be checked (whether a table should be created, existing contracts, repository conventions) are checked from the environment, not asked of you; only decisions are asked of you.
  4. No action before confirmation. If the design is not finalized, do not write DDL/scripts/interface contracts/checks.
  5. Do not recreate deliverables. The decision record only records "decided/undecided/to be checked"; formal contracts are produced by the executor.

Decision surface (specific to data development, reveal one layer at a time)

Proceed in dependency order:

# Decision surface Typical questions Which executor it lands in
1 Scope and main deliverable Build a table/pipeline/interface/QC? Which executor should handle it? Decide this first, then continue
2 Table design Granularity (daily/minute), primary key, temporal columns (event/available/ingestion) finance-ddl-design
3 Incremental and idempotency Update policy, incremental method (watermark/CDC/partition), late-arrival tolerance finance-pipeline-dev
4 Query interface Query surface, input parameters, disambiguation top-1, null semantics finance-query-contract
5 Acceptance criteria Which defect families, evidence levels, PASS/BLOCK criteria finance-data-qc

Strictly in order: first answer the scope, then drill down step by step; earlier answers will change later questions.

Grill loop (data version)

For each node:

  1. Verify: it is "what exists in the environment" (existing tables, contracts, in-database conventions) → look it up, do not ask.
  2. Decision: it is a user decision about "how to design" → ask exactly one.
  3. For multiple choice use A/B/C/D, mark Recommended:, and the options should give both "mechanism + sense of output".
  4. Wait for the answer before moving to the next one.
  5. Challenge vague assumptions: if the requirement says "build a market data table" without mentioning granularity → ask about granularity, do not assume.

Until you can summarize the design into a few key points the user approves (data output + the underlying table/incremental/contract mechanism).

Decision record template

# 数据设计决策记录
## 范围
- 主交付物：<建表/管道/接口/质检/其中几个>
- 数据集/表：<目标表或数据集>
## 期望结果
- <用户要的最终产出，人话>
## 已敲定决策
- <决策面>：选了 <选项字母 + 机制>，因为 <一句话理由>
## 待查 / 待确认
- <未敲定的，留给执行器>
## 下一步
- 进 <finance-xxx>：<该执行器要接的输入前提>

Hard gate → executor

After design confirmation:do not write DDL/scripts yourself; hand the decision record to the corresponding executor for execution. It is the party responsible for producing the formal deliverables (contract.yaml / pipeline.yaml / api-contract.yaml / quality checks). data-grill stops at "design finalized".

Red Flags

  • Throwing multiple questions at once (back to iron rule 1)
  • Options without A/B/C/D letter markers, without Recommended:
  • Options that only give the mechanism and not the sense of output, or vice versa
  • Writing DDL/scripts/interface contracts before user confirmation
  • Asking the user "what is in the database", a fact you can verify yourself
  • Generating formal deliverables such as contract.yaml that only the executor should produce

Checklist

  • Scope decisions first, then drill down into details
  • One question at a time; verify evidence; decisions go to you
  • Each A/B/C/D carries Recommended:
  • Produce a lightweight decision record, do not recreate the contract
  • Hand off to the executor to continue; data-grill stops at design confirmation