| name | dtu-creation |
| description | Creates behavioral clones of third-party services for the Digital Twin Universe. Agents build clones from API documentation, OpenAPI specs, and recorded traffic. Clones are packaged as Docker containers for use in testing and holdout evaluation.
|
Delegation Reference: This skill describes work the orchestrator delegates
to specialist agents via the Agent tool. Each step names the target agent.
The orchestrator does NOT execute these steps directly.
DTU Creation: Building Behavioral Clones
Prerequisites
- Architecture
api-surface.md produced (identifies external integration points)
dtu-assessment.md exists with DTU=YES services listed
- API documentation URLs or OpenAPI specs available for each DTU candidate
.factory/specs/architecture/ARCH-INDEX.md exists with integration points section
When This Skill Runs
- Phase 1b (Architecture Design): The architect identifies third-party service
dependencies and flags DTU candidates. This skill creates the clone specifications.
- Phase 3 (Implementation): Before holdout evaluation, DTU clones are built and
started so the SUT can connect to them.
- On demand: When a new third-party integration is added in Feature Mode.
Inputs
- List of DTU candidates from
.factory/specs/architecture/ARCH-INDEX.md (integration points section)
- API documentation URLs or OpenAPI specs for each service
- Optional: recorded HTTP traffic (HAR files, mitmproxy logs) for behavior reference
Workflow
Step 1: Clone Specification
For each DTU candidate, spawn research-agent to:
- Fetch the service's API documentation via Context7 (library docs) or Perplexity deep research (
perplexity_research)
- If an OpenAPI/Swagger spec exists, download it
- Analyze the SUT's code to identify which endpoints are actually used
- Write a clone specification using
templates/dtu-clone-spec-template.md
- Store in
.factory/dtu-specs/[service-name]-clone-spec.md
Step 2: Determine Fidelity Level
Based on how the SUT uses the service:
- Read-only integration (e.g., fetching user profiles): L1 (API Shape) is sufficient
- CRUD operations (e.g., creating Jira tickets): L2 (Stateful) required
- Complex workflows (e.g., OAuth flow, webhook delivery): L3 (Behavioral) required
- Reliability-critical (e.g., payment processing): L4 (Adversarial) required
The architect's integration point classification from Phase 1b drives this decision.
Step 3: Build Clone
Spawn implementer agent to build the clone:
- Read the clone specification
- Generate a simple HTTP server (Node.js Express or Python FastAPI) implementing the spec
- Implement state persistence (in-memory for L1-L2, SQLite for L3-L4)
- Implement error responses and edge cases per the spec
- Package as a Dockerfile
- Write to
.factory/dtu-clones/[service-name]/
Step 4: Validate Clone
Spawn test-writer agent to:
- Write contract tests verifying the clone matches the real service's API shape
- If an OpenAPI spec exists, use Schemathesis to auto-generate API tests
- Run tests against the clone
- Store results in
.factory/dtu-clones/[service-name]/validation-report.md
Step 5: Generate Docker Compose
Generate .factory/dtu-clones/docker-compose.dtu.yml that starts all clones:
version: "3.8"
services:
okta-clone:
build: ./okta-clone
ports:
- "8080:8080"
environment:
- DTU_FIDELITY=L3
- DTU_DETERMINISTIC=true
stripe-clone:
build: ./stripe-clone
ports:
- "8081:8081"
environment:
- DTU_FIDELITY=L2
- DTU_DETERMINISTIC=true
Step 6: Generate SUT Configuration
Generate environment variable overrides that point the SUT to DTU clones:
export OKTA_BASE_URL=http://localhost:8080
export STRIPE_API_URL=http://localhost:8081
export SLACK_WEBHOOK_URL=http://localhost:8082/webhook
Quality Gate
Output Artifacts
.factory/dtu-specs/[service-name]-clone-spec.md (one per service)
.factory/dtu-clones/[service-name]/ (clone implementation + Dockerfile)
.factory/dtu-clones/docker-compose.dtu.yml
.factory/dtu-clones/dtu-env.sh
.factory/dtu-clones/[service-name]/validation-report.md