菜单
[Dev Data] Use when you need to implement or enhance test data seeders that simulate QC happy-path scenarios via application-layer commands.
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/duc01226/EasyPlatform --skill seed-test-data命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
正在显示 SKILL.md
[Architecture] Use when designing solution architecture across backend, frontend, deployment, monitoring, testing, and code quality.
[Utilities] Use when you need to answer technical and architectural questions.
[Content] Use when you need to brainstorm as a PO/BA — structured ideation for problem-solving, new product creation, or feature enhancement.
基于 SOC 职业分类
| name | seed-test-data |
| version | 2.1.0 |
| description | [Dev Data] Use when you need to implement or enhance test data seeders that simulate QC happy-path scenarios via application-layer commands. |
| allowed-tools | Read, Write, Edit, Bash, Grep, Glob, TaskCreate, Agent |
[BLOCKING] Execute skill steps in declared order. NEVER skip, reorder, or merge steps without explicit user approval. [BLOCKING] Before each step or sub-skill call, update task tracking: set
in_progresswhen step starts, setcompletedwhen step ends. [BLOCKING] Every completed/skipped step MUST include brief evidence or explicit skip reason. [BLOCKING] If Task tools are unavailable, create and maintain an equivalent step-by-step plan tracker with the same status transitions.
Goal: Implement or enhance test data seeders that create realistic, idempotent, valid test data through application-layer commands (NEVER direct DB writes) — simulating QC happy-path scenarios without corrupting domain state.
Summary:
existing_counttarget_countfile:line evidence; read the count multiplier from config and never hardcode it (zero → no-op).docs/project-reference/seed-test-data-reference.md + project-config Data Seeders group, then close with a fresh zero-memory code-reviewer round; re-review fully only after a validated fix.Workflow:
Key Rules:
docs/project-reference/seed-test-data-reference.md and docs/project-config.json (Data Seeders context group) before writing any seeder changesexisting_count to target_count for restart-safetyBefore any other step, classify the request:
| Task Type | Detection | Action |
|---|---|---|
| New seeder | No existing seeder for feature area | Create following discovered base class pattern |
| Enhance existing | Seeder exists, needs new scenarios | Read existing seeder, add without breaking |
| Fix broken | Seeder fails env gate / idempotency / DI scope | Diagnose via Universal Rules, fix at root |
| Unknown | Request ambiguous | Ask user — NEVER assume |
rg "{Feature}Seeder|{Feature}SeedData|{Feature}TestData" {configured-source-roots} -l
Search for project seeder conventions:
# Search configured source roots using the repository's discovered seed-data naming conventions
rg "{configured-seeder-interface-or-base-patterns}|seeder|SeedData|DataSeed" {configured-source-roots} -l
Record with file:line evidence:
Confirm dev config has both env gate key and count key. If absent, add following project's dev config convention. — why: missing keys silently disable the gate or count, producing no-op or unbounded seeding.
Identify before writing any code:
rg "{Feature}.*Command|{configured-command-handler-patterns}" {configured-source-roots} -lrg "{Feature}TestSeeder|{Feature}SeedingHelper|{Feature}TestDataSeeder" {configured-source-roots} -l
Algorithm (language-agnostic):
seeder():
if not is_development_environment(): return
if not seed_enabled_in_config(): return
target = config.get("SeedCount")
if target <= 0: return
existing = count_by_seeder_marker()
if existing >= target: return
for i from existing to target:
call_application_command(build_scenario_input(i))
Seeder marker — stable predicate identifying seeded vs user data:
MUST ATTENTION verify all before complete:
file:line evidence requiredfile:line evidenceexisting_count, not 0 — file:line evidencefile:line evidence| Task | Sub-Agent | When |
|---|---|---|
| Discover seeders + commands across large codebase | general-purpose | Steps 1-2 |
| Review seeder compliance | code-reviewer | Round 1 post-implementation |
| Seeder handles credentials/PII | security-auditor | Security-sensitive patterns |
| Seeder runs 1000+ records | performance-optimizer | Performance-intensive |
All sub-agent prompts MUST include:
Graph DB active. After grep finds key files, run:
python .claude/scripts/code_graph trace <file> --direction both --json
Pattern: grep → trace → grep verify.
| Anti-Pattern | Correct |
|---|---|
| Direct repo insert for domain entities | Call application command |
| Seeder validates business rules | Command owns validation; seeder provides valid inputs |
| No idempotency check | Check count first; seed only remaining |
Hardcoded count (for i in 0..10) | Read count from config key (discovered Step 1) |
| No environment gate | Check project env gate key first |
| Shared DI scope across loop iterations | Use project's scoped DI per iteration (prevents DbContext corruption) |
| Batch-all-then-write sub-agent findings | Persist findings per file; NEVER batch at end |
Round 1: After implementation, spawn fresh code-reviewer sub-agent with zero memory of implementation:
Review seeder at [file:path]. Verify with file:line evidence for each:
1. Environment gate is FIRST check
2. Idempotency: count-before-seed pattern present
3. Loop starts at existing_count not 0
4. Zero application-layer command bypasses (direct repo/DB = FAIL)
5. No hardcoded count — config key read
6. Scoped DI per iteration
Report: PASS or FAIL with file:line for each finding.
Fix loop: If FAIL → validate findings → fix validated findings → restart full review from first phase. When restarted review uses sub-agents, NEVER reuse them across rounds. If same blocker repeats across 3 full invocations with no progress, escalate to user. NEVER fix unvalidated findings. Do not spawn a fresh sub-agent only to re-review known findings before validation/fix.
MUST ATTENTION — NOT IN WORKFLOW YET: Use
AskUserQuestion:
- Activate
workflow-seed-test-data(Recommended) — scout → investigate → seed-test-data → review-changes → code-simplifier → docs-update- Execute
/seed-test-datadirectly — run this skill standalone
MUST ATTENTION after completing: use
AskUserQuestion— do NOT skip:
[IMPORTANT]
TaskCreatefor ALL tasks BEFORE starting. For simple tasks, ask user whether to skip.
Critical Thinking Mindset — Apply critical thinking, sequential thinking. Every claim needs traced proof, confidence >80% to act. Anti-hallucination: Never present guess as fact — cite sources for every claim, admit uncertainty freely, self-check output for errors, cross-reference independently, stay skeptical of own confidence — certainty without evidence root of all hallucination.
Understand Code First — HARD-GATE: Do NOT write, plan, or fix until you READ existing code.
- Search 3+ similar patterns (
grep/glob) — citefile:lineevidence- Read existing files in target area — understand structure, base classes, conventions
- Run
python .claude/scripts/code_graph trace <file> --direction both --jsonwhen.code-graph/graph.dbexists- Map dependencies via
connectionsorcallers_of— know what depends on your target- Write investigation to
.ai/workspace/analysis/for non-trivial tasks (3+ files)- Re-read analysis file before implementing — never work from memory alone. — why: long context drifts from the file; the file is ground truth
- NEVER invent new patterns when existing ones work — match exactly or document deviation. — why: divergent patterns fragment the codebase and slow every future reader
BLOCKED until:
- [ ]Read target files- [ ]Grep 3+ patterns- [ ]Graph trace (if graph.db exists)- [ ]Assumptions verified with evidence
Evidence-Based Reasoning — Speculation is FORBIDDEN. Every claim needs proof.
- Cite
file:line, grep results, or framework docs for EVERY claim- Declare confidence: >80% act freely, 60-80% verify first, <60% DO NOT recommend
- Cross-service validation required for architectural changes
- "I don't have enough evidence" is valid and expected output
BLOCKED until:
- [ ]Evidence file path (file:line)- [ ]Grep search performed- [ ]3+ similar patterns found- [ ]Confidence level statedForbidden without proof: "obviously", "I think", "should be", "probably", "this is because" If incomplete → output:
"Insufficient evidence. Verified: [...]. Not verified: [...]."
AI Mistake Prevention — Failure modes to avoid on every task:
Re-read files after context changes. Context compaction, resume, or long-running work can make memory stale; verify current files before acting. Verify generated content against source evidence. AI hallucinates APIs, names, claims, and document facts. Check the relevant source before documenting or referencing. Check downstream references before deleting or renaming. Removing an artifact can stale docs, generated mirrors, configs, and callers; map references first. Trace the full impact chain after edits. Changing a definition can miss derived outputs and consumers. Follow the affected chain before declaring done. Verify ALL affected outputs, not just the first. One green check is not all green checks; validate every output surface the change can affect. Assume existing values are intentional — ask WHY before changing. Before changing a constant, limit, flag, wording, or pattern, read nearby context and history. Surface ambiguity before acting — don't pick silently. Multiple valid interpretations require an explicit question or stated assumption with risk. Keep shared guidance role-relevant. Universal guidance must help every receiving skill or agent; code-specific obligations belong only in code-specific protocols.
IMPORTANT MUST ATTENTION search 3+ existing patterns and read code BEFORE writing any seeder.
MUST ATTENTION cite file:line for every claim; declare confidence; "I don't have enough evidence" is valid output.
MUST ATTENTION apply critical + sequential thinking — every claim needs appropriate traced evidence (file:line for repo/code claims; source URL or artifact section for research, product, content, and docs claims); confidence >80% to act, <60% DO NOT recommend. Anti-hallucination: never present guess as fact, admit uncertainty freely, cross-reference independently, stay skeptical of own confidence.
MUST ATTENTION apply AI mistake prevention — verify generated content against evidence, trace downstream references before deleting or renaming, verify all affected outputs, re-read files after context loss, and surface ambiguity before acting.
IMPORTANT MUST ATTENTION follow declared step order for this skill; NEVER skip, reorder, or merge steps without explicit user approval
IMPORTANT MUST ATTENTION for every step/sub-skill call: set in_progress before execution, set completed after execution
IMPORTANT MUST ATTENTION every skipped step MUST include explicit reason; every completed step MUST include concise evidence
IMPORTANT MUST ATTENTION if Task tools unavailable, maintain an equivalent step-by-step plan tracker with synchronized statuses
IMPORTANT MUST ATTENTION Goal: Implement/enhance seeders creating realistic, idempotent, valid test data through application-layer commands (NEVER direct DB writes) — simulate QC happy-path scenarios without corrupting domain state.
Protocols in force (concise digest of the SYNC/shared blocks this skill carries):
file:line per claim; declare confidence; "insufficient evidence" valid.IMPORTANT MUST ATTENTION NEVER call repo/DB directly for domain data — use application-layer commands — why: bypassing the command pipeline skips validation, domain logic, and event side-effects, producing invalid state that passes silently
IMPORTANT MUST ATTENTION ALWAYS gate by environment FIRST, then ALWAYS check count before seeding — why: env gate prevents prod corruption; count gate is the idempotency guarantee
IMPORTANT MUST ATTENTION loop from existing_count to target_count — NEVER from 0 — why: looping from 0 re-seeds on every restart and breaks restart-safety
IMPORTANT MUST ATTENTION scoped DI per iteration — shared DI scope = silent DbContext/session corruption
IMPORTANT MUST ATTENTION ALWAYS read count multiplier from the discovered config key — NEVER hardcode (zero → no-op, never unbounded loop)
IMPORTANT MUST ATTENTION NEVER duplicate command logic in the seeder — seeder provides realistic inputs, commands own validation/domain/events
IMPORTANT MUST ATTENTION every seeded scenario MUST stay consistent with the §5 universal invariants; if a seeder encodes a domain rule (precondition, status, default) feed it into the spec — and tests where testable — NEVER a seeder-only fix — why: a hidden rule in a seeder drifts from the spec and breaks future readers
IMPORTANT MUST ATTENTION Evidence gate: cite file:line for the env gate, count gate, loop start, DI scope, and seeder registration — confidence >80% to act, <60% DO NOT recommend; "Insufficient evidence" is valid output
IMPORTANT MUST ATTENTION search 3+ existing seeder patterns and READ them before writing — match the discovered base class / env-gate / count-key conventions exactly; verify the copied pattern shares the same preconditions (base class, scope, lifetime) before reuse
IMPORTANT MUST ATTENTION read docs/project-reference/seed-test-data-reference.md + docs/project-config.json (Data Seeders group) BEFORE any seeder change — project conventions override generic defaults
IMPORTANT MUST ATTENTION TaskCreate — break all work into tasks BEFORE starting; transition one task at a time, evidence per completed step
IMPORTANT MUST ATTENTION close with a fresh zero-memory code-reviewer round; full re-review is required ONLY after a validated fix cycle — a clean review pass ENDS the review; NEVER fix unvalidated findings
Anti-Rationalization:
| Evasion | Rebuttal |
|---|---|
| "Simple seeder, skip review loop" | Idempotency bugs are silent. Run Round 1 always. |
| "Already know the base class" | Show file:line. No proof = no knowledge. |
| "Environment gate is obvious" | Verify it's FIRST check with file:line evidence. |
| "Just hardcode count for now" | NEVER — config key required. Find it in Step 1. |
| "Seeder can validate this quickly" | NEVER duplicate logic — command owns validation; seeder feeds inputs. |
| "Skip the reference docs, I know seeders" | Project conventions override generic patterns. Read them first. |
| "No graph.db, skip trace" | Use grep-only trace. Still run 3+ pattern search. |
| "Existing scenarios look fine, skip enhance" | Read all scenarios; enhancement may conflict — verify first. |
[TASK-PLANNING] Before acting, break task into small todo tasks using TaskCreate.
IMPORTANT MUST ATTENTION NEVER direct repo/DB writes for domain data · ALWAYS env-gate FIRST then count-gate · file:line evidence for every gate (confidence >80%).