Codexqa Testdata Generator

Test Data Generation

This directory is the skill. It has no baked-in company knowledge. Platforms are adapters; local files work with zero extra infrastructure.

This skill never invents business data. It decides which path to take and extracts parameters the user already supplied; an executor, a published tool, or a generated script is what actually calls the backend. "Construct succeeded" means the backend returned a business ID, not that an ID appeared in the reply.

SKILL_DIR is the folder that contains this SKILL.md. Every command below uses it, so resolve it once:

SKILL_DIR="<directory of this SKILL.md>"

Config lookup: $DATA_BUILD_CONFIG → ./testdata/config.yaml → ~/.testdata/config.yaml.

Four fallback paths, in this order, after the case-material check below:

1. Domain skill — search for a matching data-build skill, install or load it, and delegate
2. Existing tool — reuse a published tool from the tool registry
3. API catalog — discover the APIs that can build the data
4. Generated script — write a construction script from those APIs and run it

Documents (load on demand)

Read this file first; it is the routing contract. Load anything else only when the row below applies, so a single-step construct does not drag the whole tree into context.

Case-material route (check first)

After receiving a data-construction request, first decide whether it is a case-material job.

Trigger phrases (any match enters the sub-skill and stops the generic flow):

• English: case data, case materials, test-data preparation, write back test data, data requirements, data inventory, prepare test data, test material list
• Chinese: 用例数据, 用例物料, 用例数据准备, 为用例准备数据, 用例前置数据, 测试数据回写, 用例数据构造, 测试数据分析, 测试物料, 数据需求分析, 测试数据准备, 数据物料, 需求测试数据, 准备测试数据, 测试物料清单, 数据诉求

On hit: load and follow references/case-data-material-planner/SKILL.md. Run references/case-data-material-planner/scripts/pipeline.ts as the orchestrator (paths below are relative to that sub-skill root) — construction, binding, and writeback are stages inside that script, so do not spawn Agents to do them.

The sub-skill root is <this SKILL.md directory>/references/case-data-material-planner/. All of its scripts/, agents/, templates/ paths are relative to that root.

Decision tree

Handle every other request in this exact order:

user data-construction request
    │
    ▼
[route] case-material scene? (phrases above)
    │
    ├─ yes → load references/case-data-material-planner/SKILL.md  ✓ stop
    │
    └─ no → generic flow
            │
            ▼
        [step 1] search_data_build.ts
                 (semantic proven methods + skill marketplace, in parallel)
            │
            ├─ pinned_matches present AND Agent judges them relevant
            │       → load skillPath (or install) → delegate → report  ✓ stop
            │
            ├─ proven_matches present AND Agent judges them applicable
            │       → run proven_invocation → feedback only  ✓ stop
            │
            ├─ skill_matches: one local clear match
            │       → load → delegate → report  ✓ stop
            │     several / weak / needs install → ask, then same
            │
            └─ none match
                    │
                    ▼
                [step 2] tool_registry.query (two query angles)
                    │
                    ├─ one clear tool (or user already gave an id)
                    │       → query_input_list → fill params → execute → report  ✓ stop
                    │     several / weak → ask, then same
                    │
                    └─ no matching tool
                            │
                            ▼
                        [step 3] api_catalog (in parallel when useful)
                            │
                            ├─ method A: plan change APIs (if planId exists)
                            └─ method B: keyword / service search
                            │
                            ▼
                        [step 4] write script from template
                            │
                            ├─ generate → run locally → report
                            └─ after a successful run, ask whether to publish
                                    ├─ yes → tool_registry.publish  ✓ stop
                                    └─ no  → return the result     ✓ stop

Step 1 — Search matching data-build options

Build the search input

Extract two kinds of input from the user request:

Keywords (skill-name match):

• Take 1–2 nouns that name the domain slot, such as the name in slot.yaml
• Never use verb phrases such as "create a" or "help me construct"
• If keywords miss, the script falls back to a full scan. Do not retry by hand.

Structured query (semantic match):

• registry-key: {entity}::{action}, e.g. catalog-order::create
• query: one natural-language sentence
• entry-type: entity or action
• domain: from workspace context business_line, or infer from the request

Examples and the full command: references/workflow.md.

node "$SKILL_DIR/scripts/search_data_build.ts" \
  --keywords <nouns> \
  --query "<sentence>" \
  --registry-key "<entity>::<action>" \
  --entry-type entity \
  --domain "<domain>" \
  --json

The script runs proven-method search and skill-marketplace search in parallel, then injects pinned favorites. JSON shape:

{
  "pinned_matches": [...],
  "proven_matches": [...],
  "skill_matches": [...]
}

Result priority

Priority 0 — pinned_matches (highest)

Pinned skills are returned unconditionally so retrieval noise cannot drop them.

The Agent judges relevance from each item's description (same idea as proven applicability):

• Relevant → use it first. Prefer skillPath when SKILL.md exists. If available=false or skillPath is missing, install then load.
• Not relevant → ignore and continue to proven / skill matches.

The script does no keyword filter on pinned items. A relevant pinned hit ends step 1; do not evaluate proven/skill after that.

Priority 1 — proven_matches

Reuse only when all three hold:

1. Semantic alignment: registry_key describes the same operation
2. Tool reachable: the bound skill is installed or the bound tool can execute
3. Params available: required proven_invocation.paramMapping values exist in context

All three → execute proven_invocation and keep experience_id for feedback. Any miss → skip that row and continue to skill_matches.

Priority 2 — skill_matches

Asking is for ambiguity, not ceremony. The user already asked to construct data. Drop rows whose description does not cover the request (a catalog-product construct is not a distributor slot, even if both appear in skill_matches).

• One remaining local match (skillPath already has SKILL.md) → load it, say which skill you used, and stop. Do not ask first.
• Needs install (available=false or no skillPath) → ask, because install is a side effect the user did not request.
• Two or more remaining rows that could both be right, or only a weak/partial match → show them and ask: "Which of these skills matches your request, if any?"

None match → go to step 2.

If search is empty and the user wants a reusable domain pack (not a one-off construct), read $SKILL_DIR/slot-scaffolder/SKILL.md and follow it. That is a bundled folder in this skill, not a separately installed skill — do not go looking for it in the host's skill list. One-off work continues at step 2.

Install and load a confirmed skill

SKILLS_DIR="$(dirname "$SKILL_DIR")"
node "$SKILL_DIR/scripts/adapters/cli.ts" skill_marketplace.install '<name>' '$SKILLS_DIR'

If skillPath already points at a directory that contains SKILL.md, load it directly and skip install. After load, follow that skill and stop.

Pin favorites (personal cheat-sheet)

Pinned skills always enter the candidate set first. Relevance is Agent-judged.

Storage: project ./testdata/data-build-favorites.json, user ~/.testdata/favorites.json. add writes the user file unless --scope project. $DATA_BUILD_FAVORITES_PATH overrides both.

Step 2 — Tool registry (only when no skill matched)

Query with natural-language sentences, not space-separated keywords.

Write at least two angles:

node "$SKILL_DIR/scripts/adapters/cli.ts" tool_registry.query "create a catalog test product"

If the user already has a tool id, look it up exactly:

node "$SKILL_DIR/scripts/adapters/cli.ts" tool_registry.get "<resource-id>"

• User already named a tool id, or exactly one result clearly matches → use it. Tell the user which tool you picked.
• Several results or only a weak match → show them and ask: "Is there a tool that matches your request?"

Then:

1. tool_registry.query_input_list(resource_id)
2. Fill params. Order IDs, user IDs, and other core business fields must be confirmed with the user. Do not invent them. Optional fields may use sane defaults.
3. tool_registry.execute(resource_id, params)
4. On success → report (see below)

Step 3 — API catalog

Method A — plan change APIs (preferred when a plan exists)

Use when the request sits inside a test-plan / change scope.

Resolve planId from workspace context testPlan.id or planId. If missing, ask the user.

node "$SKILL_DIR/scripts/adapters/cli.ts" api_catalog.search_plan_changes "<planId>"

Then api_catalog.detail(<operationId>) for key operations.