agentleFS
Sign inStart free
adhyayanrathi01adhyayanrathi01/product-manager-os/skills/data/build-query/SKILL.md

build-query

Skill2 starsChanged 2 months agoMITView on GitHub

Translate a product question into a safe, reproducible query using an available database, warehouse, analytics interface, CLI, MCP, API, or local dataset. Use when a PM needs quantified evidence and the required answer is not available from a standard report.

The file

We split this skill into the rules it gives an agent

7 rules. About 0 are common, 6 are distinctive, and 1 is very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈6

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Verify executable source readiness, read authorization, schema authority, identity mappings, exclusions, resource limits, and timezone …

    line 12
  2. Distinctive:

    When access is missing, produce an annotated draft only if confirmed schemas exist.

    line 14
  3. Distinctive:

    Prefer read-only, bounded, and resource-conscious queries.

    line 24
  4. Distinctive:

    Check joins, cardinality, denominators, null handling, time zones, and date boundaries.

    line 26
  5. Distinctive:

    If task-critical merge or split semantics are unresolved, keep execution partial or blocked.

    line 27
  6. Distinctive:

    Run only when access and authorization permit through a currently addressable, agent-observed source.

    line 28
  7. Very specific:

    Every field above must appear as a labeled section in the produced output.

    line 41

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Build Query

<!-- CORE:BEGIN -->

Contract

  • Require the business question, metric definition, entity grain, absolute period, segment, expected output, source ID, and allowed query scope.
  • Verify executable source readiness, read authorization, schema authority, identity mappings, exclusions, resource limits, and timezone before execution. A user-reported prior test alone does not authorize execution.
  • For longitudinal account- or workspace-grain queries, require a confirmed stable cohort identity, cohort-assignment time, and task-critical merge/split treatment.
  • When access is missing, produce an annotated draft only if confirmed schemas exist. Block execution and never invent tables, columns, or joins.
  • Save the query and validation method, then emit the shared evidence handoff for reusable results.
<!-- CORE:END -->

Process

  1. Define the business question, metric, grain, segment, time range, and expected output.
  2. Discover the available data access and inspect relevant schemas or examples.
  3. Resolve metric definitions and entity relationships before writing the query.
  4. Identify test, internal, deleted, duplicate, or otherwise excluded records.
  5. Prefer read-only, bounded, and resource-conscious queries.
  6. Build the query in understandable stages.
  7. Check joins, cardinality, denominators, null handling, time zones, and date boundaries.
  8. If task-critical merge or split semantics are unresolved, keep execution partial or blocked. If the ambiguity is bounded and non-critical, draft an explicit exclusion of ambiguous entities and a sensitivity variant rather than choosing attribution silently.
  9. Run only when access and authorization permit through a currently addressable, agent-observed source.
  10. Validate the result using totals, samples, or a second calculation.
  11. Save the query or reproducible method in the project.

Explain assumptions and unresolved schema ambiguity. Never invent columns or silently change the metric definition.

<!-- CORE:BEGIN -->

Output

Provide the query or reproducible method, parameters, source and schema references, assumptions, safety bounds, validation method and result, unresolved ambiguity, and evidence packet ID when executed.

Required fields: Query or method|Parameters|Source and schema references|Assumptions|Safety bounds|Validation method and result|Unresolved ambiguity

Every field above must appear as a labeled section in the produced output. Verify with evals/check-output.sh build-query <artifact>.

<!-- CORE:END -->

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free