Skip to content

/edikt:spec-artifacts

Generate implementable artifacts from an accepted technical specification.

Artifacts are the engineering outputs that bridge spec and implementation: data model, API contracts, migrations, test strategy, event contracts, config spec, fixtures. Each artifact is reviewed by the appropriate domain specialist before being written.

Usage

/edikt:spec-artifacts SPEC-005
/edikt:spec-artifacts path/to/spec-folder/

Pass a SPEC identifier (e.g., SPEC-005) or the path to the spec folder.

Gate

The spec must have status: accepted before artifacts can be generated:

BLOCKED  SPEC-005 status is "draft".
         Specs must be accepted before generating artifacts.
         Review the spec and change status to "accepted" first.

What gets generated

The command scans the spec content and detects which artifacts are relevant:

Based on SPEC-005, these artifacts are relevant:
  INCLUDED  data-model.md       — schema mentions detected
  INCLUDED  contracts/api.md    — API endpoint references
  INCLUDED  test-strategy.md    — testing strategy section
  SKIPPED   migrations.md       — no schema changes
  SKIPPED   contracts/events.md — no messaging patterns
  SKIPPED   config-spec.md      — no config changes

Generate 3 artifacts? (y/n)

Detection is automatic — if the spec mentions databases, models, or schema, data-model.md is triggered. If it mentions API endpoints, contracts/api.md is triggered. Confirm or adjust before generation begins.

Artifact types

ArtifactTriggered byReviewed by
data-model.mddatabase, model, schema, entity, tabledba
contracts/api.mdAPI, endpoint, route, REST, request, responseapi
contracts/proto/gRPC, protobuf, service definitionapi
migrations.mdmigration, schema change, ALTER, CREATE TABLEdba
contracts/events.mdevent, queue, Kafka, pub/sub, webhook deliveryarchitect
test-strategy.mdtest, testing strategy, coverageqa
config-spec.mdconfig, environment variable, feature flagsre
fixtures.mdseed, fixture, test data (also auto-triggers with data-model)qa

What each artifact contains

data-model.md — entity definitions with fields, types, constraints, relationships, indexes, and migration notes.

contracts/api.md — endpoint definitions with method, path, request/response shapes, error codes, and auth requirements.

migrations.md — up and down migrations (rollback is required for every up migration), data backfill plan, risk assessment including lock duration.

test-strategy.md — unit test coverage by component, integration test scenarios, edge cases from the spec and PRD acceptance criteria, coverage target.

contracts/events.md — event schemas, topics/queues, producers, consumers, ordering guarantees, idempotency strategy.

config-spec.md — environment variables with types, defaults, and required flags; feature flags with rollout plans.

fixtures.md — seed data scenarios with rationale. Database-agnostic — implementation generates the appropriate format (SQL, Prisma, factory definitions, etc.).

Output location

All artifacts live in the spec's folder:

docs/product/specs/SPEC-005-webhook-delivery/
├── spec.md
├── data-model.md
├── contracts/
│   └── api.md
├── test-strategy.md
└── fixtures.md

Each artifact gets frontmatter with spec reference, status, and reviewing agent.

After generating

Review each artifact. Accept them individually by changing status: draft to status: accepted in the frontmatter. All artifacts must be accepted before running /edikt:plan.

What's next

  • /edikt:plan — generate phased execution plan with pre-flight specialist review
  • /edikt:drift — verify implementation against these artifacts after building
  • Governance Chain — full chain overview

Released under the Elastic License 2.0. Free to use, not for resale.