跳到正文
cccskills
免费在 GitHub 公开

workflow-seed-test-data

[Workflow] Build or extend idempotent, environment-gated development/QC seeders with realistic data, change review and verified tests.

中文简介正在准备中。当前显示原文说明。

查看安装方法

包含的文件(1)

  • SKILL.md21.0 KB

SKILL.md(原文)

安装前可以查看交给 AI 代理的指令内容。

<!-- WORKFLOW-CALLS:START -->

Workflow Calls and Todo Bootstrap

Read the registry → workflows.workflow-seed-test-data together with this skill. Call /start-workflow workflow-seed-test-data to resolve the selected mode, pre-actions and fingerprint.

Todo FIRST: before triage, analysis or step execution, create one todo per phase of the selected mode, in order, listing every occurrence of that phase as a line, including conditional/optional ones (a mode that declares no phases gets one todo per occurrence); preserve occurrence IDs, roles and barrier groups. Use native todo tools or an equivalent persistent ledger. Then mark the first todo in_progress; close each step line with its run or skip evidence, and complete a phase todo only when every line is closed and its applicable exit gates hold. Mode selection and registry loading prepare tracking; any 'first action' below means the first substantive action after this bootstrap.

Call each step skill: read its linked SKILL.md and execute its protocol through the active host with the registry args. Reading or naming a skill alone is not execution. Required gates and core/optional flex follow the linked start-workflow Step Execution Protocol; keep this skill's quality gates, loops and evidence requirements.

Conditions: load each occurrence's registry applicability.when and skipReason verbatim, and record its run/skip evidence through the linked start-workflow protocol. Do not silently omit a todo or turn a conditional skill into an unconditional call; close, in one batch at triage, the todos whose condition is already false there. Declared parallel groups retain their all-return barrier.

Explicit step-skill calls by mode (registry order; roles and conditions remain owned by the registry):

<!-- workflow-mode:default fingerprint:3e1dcf670f2e0686885f5c9d1d5a96e5beee77a171b518f487153a2dedc1096b -->

Regenerate this block with node .claude/scripts/lib/workflow-skill-contract.cjs --write after registry edits; /sync-codex refreshes it before mirroring.

<!-- WORKFLOW-CALLS:END -->

Quick Summary

Goal: Add or extend idempotent, command-based seeders that create realistic QC happy-path data for a feature area — environment-gated, count-configurable, restart-safe — proven by tests that ran green in this run, a converged review and, when the data is observable, an inspection of the seeded state itself.

Use this for seeders, dev/QC dummy data and realistic first-init data. Use /seed-test-data --mode=review alone for a read-only seeder audit, and workflow-integration-test / workflow-e2e when the deliverable is a test rather than seeded data.

IMPORTANT MANDATORY Steps: /investigate -> /seed-test-data -> /experience-review -> /changes-review --fix-loop -> /test -> /docs-manager --mode=update -> /workflow-end -> /watzup

Step contract: steps follow /start-workflow → Step Execution Protocol — gate steps always run, a step that runs invokes its Skill tool, and every other deviation is logged. NEVER batch-complete validation gates.

[CRITICAL] Read Project Config Gate: before writing any seeder code, read the seeder context group in docs/project-config.json (for example Data Seeders) and seed-test-data-reference.md in the project-reference docs root (default docs/project-reference/; docsRoots.projectReference.path overrides). A seeder written without the project's base class, env-gate key, count key and DI scope pattern is wrong by construction.

Contents

Size & Kind Triage (FIRST action)

Classify before choosing steps and record the result in the run report:

  • Size — XS: enhance one existing seeder (count, one scenario; 1–3 files) · S: new seeder for one feature area · M: several feature areas or seeders · L/XL: seeding across modules/services with a dependency chain of pre-existing data.
  • Kind — new / enhance / fix seeder · observable data (a QC/operator sees it through an app, API, CLI or artifact) · cross-module or cross-service commands · seeder that encodes a domain rule (a required precondition, status or relationship).
  • Risk — escalate on anything that could run outside development, shared or persistent environments, cross-service data ownership, or ambiguous target counts.

The triage selects which recommended skills run and how deep; it never removes a gate.

Required Quality Gates (non-negotiable)

GateEvidence that proves it
Seeder invariantsfile:line proof for each: (1) environment gate is the FIRST check — development or config-enabled only, never production; (2) count read from the configured key, never hardcoded (small default; zero → no-op); (3) idempotent — count existing BEFORE seeding and loop from existing_count to target_count, never from 0 (restart-safe); (4) domain entities written only through application-layer commands, never direct repository/DB writes, never duplicated command logic; (5) the project's scoped DI mechanism per iteration, never one scope across iterations
tests-pass/test ran green in THIS run against the final seeder code, after the review fixes
review-converged/changes-review --fix-loop over the final diff: validated blocking findings fixed, the fixed state re-reviewed and the review receipt issued
Seeded data observed (when observable)/experience-review record over the seeded state: OBSERVED / JUDGED / HUMAN-ACCEPTED / UNVERIFIED / ENVIRONMENT-BLOCKED / NOT-APPLICABLE; a seeder exit code is not evidence
Spec/docs synced (when a seeder encodes a domain rule or changes documented dev-data coverage)The rule lands in the spec (and in tests where testable), never as a seeder-only fix; /docs-manager --mode=update result, or its registry skip reason
run-closed/workflow-end (top-level only) verifies every gate above

Recommended Skills

SkillEarns its cost whenProves / feeds
/investigate (conditional)Size M or larger, cross-module or cross-service, or conventions and command chain not yet evidencedTarget seeder path (or "none — create new"), 3+ sibling seeders, command signatures, required inputs, validation, side effects, pre-existing data chain
/seed-test-dataAlways — it makes the changeSeeder invariants — its self-audit runs the convention checklist; nested here, its own fresh-review loop hands the final review to the gate below
/experience-review (conditional)The seeded data reaches a configured or likely observable surfaceSeeded data observed
/changes-review --fix-loop (gate)Always — converges the final diff and issues the review receiptreview-converged, seeder-invariant and convention compliance
/test (gate)Alwaystests-pass
/docs-manager --mode=update (conditional)Seeder configuration keys, a domain rule or documented seed coverage changedSpec/docs synced
/workflow-end (gate)Always (top-level run); prints the recap when /watzup does not runrun-closed
/watzup (conditional)A session report was requested, or several workflows or prompts need one handoffConsolidated session report

Skipping a recommended skill is fine when triage shows it does no real work; log it as a deviation (intent-skip / when-false) with evidence.

Conditional step note — /investigate runs when (registry, verbatim): The seeder area is size M or larger, cross-module or cross-service, or its conventions and command chain are not already evidenced; the seed-test-data skill still reads three comparable seeders itself. Skip reason (registry, verbatim): A size XS or S seeder in an area whose conventions the seed-test-data skill discovers itself.

Conditional step note — /docs-manager --mode=update runs when (registry, verbatim): Seeder configuration keys, a domain rule or documented seed coverage changed. Skip reason (registry, verbatim): No configuration key, domain rule or documented seed coverage changed.

Conditional step note — /watzup runs when (registry, verbatim): The user asked for a session report or an HTML wrap-up, or the session spanned several workflows or prompts that need one consolidated handoff. Skip reason (registry, verbatim): workflow-end printed the recap, or the short handoff when nothing was built, and every applicable outcome gate passed.

Conditional step note — /experience-review runs when: the seeded data reaches a configured experienceVerification surface whose reviewOn trigger intersects the change, or the seeder creates or changes data a QC/operator actually observes through a running application, API, CLI, or generated artifact; when the latter holds without usable configuration, run the skill and record ENVIRONMENT-BLOCKED — never invent a runner. A relevant surface that cannot be run or inspected is ENVIRONMENT-BLOCKED, never PASS. Skip reason (registry, verbatim): After inspecting docs/project-config.json and the seeder diff, no configured or likely observable surface consumes the seeded data; record NOT-APPLICABLE with evidence citing the inspected paths.

It sits before /changes-review --fix-loop because a seeder's deliverable is observed data: the review proves the seeder obeys the rules, the inspection proves the scenarios are the ones QC needs. No clean-up rewrite follows it, so it observes the final seeder code; a review fix lands under the re-verification rule below. It runs its own bounded remediation loop (--rounds=N, default 3), never rewrites an expectation or acceptance criterion to close a gap, and reports unresolved defects at the cap as NOT-CONVERGED, routed back to /seed-test-data.

Orchestration Freedom

You choose inline vs sub-agent, batching and ordering, optimizing wall-clock and token cost at equal quality. Fixed constraints only: the seeder exists before it is observed, tested or reviewed; convention checks stay in the seeder's self-audit and the /changes-review --fix-loop gate, so no clean-up rewrite runs after the checks that prove the final code; fixes are re-verified after they land; /workflow-end runs last; gates awaiting user approval never run in parallel. Recommended: XS/S inline; M+ one seeder or feature area per batch with one report per batch, ordered by the data dependency chain (prerequisite data first).

Memory & Reporting

  • One phase task per phase, one row per selected step (and per seeder batch for M+) so nothing is lost after compaction.
  • Write the run report under tmp/reports/ FIRST and append per step and batch; re-read it and TaskList after compaction.
  • Sub-agent briefs carry the resolved config/reference paths, make report writing their first deliverable, and return only the summary envelope.

Fix Path & Loop Bounds

Validate each finding (evidence-backed, reproducible) before fixing. A failing test follows the test-investigation protocol before either side changes. Fix at the owning layer: a seeder that violates an invariant is fixed in the seeder; a command that rejects valid inputs or breaks a domain rule is a product defect — trace its root cause and route it, never work around it in the seeder. Re-run the test or reviewer that raised the finding, plus a holistic pass when fixes were non-trivial. Use /plan only when the fix set is large, cross-module or ambiguous.

Review loop: round 1 zero open findings (LOW deferral) converges; round 2 converges on zero CRITICAL/HIGH/MEDIUM with LOWs deferred; cap 3 review rounds; failed checks block and at the three-round cap require explicit user-approved bounded extension; no progress → escalate via ask user question tool.

<!-- PROTOCOL-GUIDES:START -->

Protocol guides — Apply each protocol only when its read-when condition holds. If a protocol's text is not in your context, read its file below before you act on it.

  • incremental-persistence — Persist results per file or section while the work proceeds; a sub-agent or heavy step processes more than three files → .claude/skills/shared/protocols/incremental-persistence.md
  • session-goal-ledger — Keep the original goal and every user prompt of the session; running a long or multi-prompt session → .claude/skills/shared/protocols/session-goal-ledger.md
  • subagent-return-contract — Sub-agents return a structured envelope and a report path, never an inline report; spawning a sub-agent → .claude/skills/shared/protocols/subagent-return-contract.md
  • workflow-registry-binding — Read the workflow registry entry and the workflow skill together, since they must agree; executing or editing a workflow → .claude/skills/shared/protocols/workflow-registry-binding.md
<!-- PROTOCOL-GUIDES:END --> <!-- SYNC:session-goal-ledger:reminder -->
  • MANDATORY Session goal ledger per the Task Planning Rules: pin Original goal:, keep User prompts this session: P1…Pn, and map the result to every prompt before claiming done; full text: .claude/skills/shared/protocols/session-goal-ledger.md.
<!-- /SYNC:session-goal-ledger:reminder -->

Closing Reminders

IMPORTANT MUST ATTENTION Goal: idempotent, command-based QC happy-path seeders for a feature area, proven by green tests, a converged review and — when observable — an inspection of the seeded data.

  • MUST ATTENTION read the project-config seeder context group and seed-test-data-reference.md BEFORE writing any seeder code; match the project's existing seeder convention exactly.
  • MUST ATTENTION environment gate FIRST; count from config; loop from existing_count to target_count, never from 0; scoped DI per iteration.
  • MUST ATTENTION NEVER write domain entities through a repository/DB directly — application-layer commands only; a domain rule a seeder encodes belongs in the spec.
  • MUST ATTENTION a seeder exit code is not evidence — run /experience-review when the data is observable, record ENVIRONMENT-BLOCKED (never PASS) when it cannot be inspected, and skip only with an evidence-backed NOT-APPLICABLE.
  • MUST ATTENTION triage first, write the report under tmp/reports/ first, keep one phase task per phase, one row per selected step; /test and /changes-review always run on the final code and /workflow-end runs last.

评价

还没有评价。欢迎分享你的使用感受。

评论

无需登录即可发表。欢迎分享使用感受、提问,或说明在哪些环境下无法运行。

还没有评论。来写第一条吧。

提交后会立即公开。请勿填写邮箱、电话等个人信息。URL 最多 2 个。

0 / 1000 字

此表单受 reCAPTCHA 保护,适用 Google 的隐私权政策和服务条款。

同一仓库的技能

[Documentation] Use when generating, smart-merging or refactoring the root AI context (CLAUDE.md, AGENTS.md) and its Claude/Codex projections. Config file only: project-config.

中文简介正在准备中。当前显示原文说明。

duc01226/EasyPlatform122026年10月18日 更新

[Code Quality] Use when a workflow step or the user asks for AI code or plan review: LLM calls, prompts, agents, RAG, evals and guardrails. --mode={code|plan}; --report-only is read-only.

中文简介正在准备中。当前显示原文说明。

duc01226/EasyPlatform122026年10月18日 更新

[Architecture] Use when a workflow step or the user asks for architecture design, compliance review, scalability grading or whole-project audit via --mode={design|review|scalability|full}.

中文简介正在准备中。当前显示原文说明。

duc01226/EasyPlatform122026年10月18日 更新

[Content] Use when a workflow step or the user asks for product/feature ideation with ranked opportunities and validation tests. --mode={roadmap|scope}.

中文简介正在准备中。当前显示原文说明。

duc01226/EasyPlatform122026年10月18日 更新

[Content] Use when a workflow step or the user asks for business viability: Business Model Canvas, financials, risks and go-to-market recommendation.

中文简介正在准备中。当前显示原文说明。

duc01226/EasyPlatform122026年10月18日 更新

[Code Quality] Use when a workflow step or the user asks for a focused code-change review: staged, unstaged, branch diff or simple pull request. --fix-loop fixes and re-reviews. Complex pull request: workflow-review-changes; rationale: why-review.

中文简介正在准备中。当前显示原文说明。

duc01226/EasyPlatform122026年10月18日 更新

查看 duc01226 的全部技能

报告此技能的问题