Menu

Individual skill

atlas-commerce-ops-sql

0upvotes

Use this skill whenever a task asks for Atlas Commerce Operations workplace analysis, scorecards, reconciliations, SLA reviews, warehouse or fulfillment metrics, refund/payment exposure, carrier scan corrections, inventory operations, or strict answer.json generation from the task environment SQL APIs. It guides schema discovery, safe SQL, controlled correction transactions, metric construction from payload rules, and exact JSON output validation.

experiments/codex_skill_creator_comparison_gpt5_5_xhigh/reports/skills/task_group_022/fewshot/cc/fewshot_attempt_03/SKILL.md

Read pinned source

Source commit 5082a777379156a048881e94940d640702e5e09a

What was checked

Matches the observed repository HEAD
Yes
Scanner rules are current
No
Repository scan complete
No
Skill scan complete
No
Observed behavior
Not checked yet
Last checked
Nov 6, 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)
121
Repository last updated
Oct 29, 2026
License
Apache-2.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

# Atlas Commerce Ops SQL

Use this skill to solve Atlas Commerce Operations tasks that provide a prompt, request payloads, an `answer_template.json`, and a task environment URL. The expected result is almost always a single strict `answer.json` object.

## Workflow

1. Read the prompt, every file under `input/payloads/`, and the answer template before querying. Treat request payload definitions as the source of truth for cohort, cutoff, ranking, rounding, risk/status rules, and whether mutation is allowed.
2. Load schema context from the task environment: `GET /api/schema` and `GET /api/data-dictionary`. See [API and schema](references/api-and-schema.md) for endpoint usage and schema relationships.
3. Build the SQL around the requested cohort first. Apply production exclusions, account/campaign/warehouse/region filters, inclusive or strict time boundaries, and cutoff-as-of logic exactly as stated.
4. Prefer source-of-truth event history for "at cutoff", "effective", "latest", or active-clock language. Denormalized `current_status` fields are useful for sanity checks, but historical state should come from append-only events or scans when a cutoff is involved.
5. Deduplicate imported source rows before deriving facts when a table has `source_system`, `external_event_id`, and `ingested_at`. Keep the latest ingested copy per source event unless the request explicitly wants raw import attempts.
6. Decompose the metric into auditable CTEs: cohort rows, effective events, per-entity facts, aggregate counts, ranking tables, and final scalar output. Run intermediate count/list queries before trusting the final JSON.
7. Use unrounded values for comparisons and ordering. Round only final reported fields, with the precision from the template or request.
8. If the request is analytical only, use only `POST /api/sql`. If it explicitly approves a correction, use the controlled transaction endpoint and post-change verification; never mutate raw source fields or unrelated rows.
Back to top