| name | design-artifact-pipeline |
| description | Design the generation pipeline for non-text deliverables — templates, rendering, design tokens, storage, and verification. |
/design-artifact-pipeline - Artifact Pipeline Design
When to Use
- When the OS produces deliverables beyond conversation text (PDFs, CSVs, images, HTML)
- After
/design-skills (need to know which skills produce artifacts)
- When
domain-input/artifact-pipeline.md needs to be filled
- Skip if all OS output is conversational text
Inputs
- Auto-loaded:
output/designs/skill-designs.md (which skills produce non-text output)
- Auto-loaded:
domain-input/audiences.md (who receives artifacts, what format they expect)
- Auto-loaded:
domain-input/domain-workflow.md (where artifacts fit in the pipeline)
Process
Step 1: Inventory Artifact Types
From the skill designs, list every non-text output:
| Artifact Type | Produced By | Format | Audience | Purpose |
|---|
| [e.g., Tailored resume] | /[skill] | PDF | Recruiter, ATS | Job application |
| [e.g., Evaluation report] | /[skill] | Markdown | User | Decision support |
| [e.g., Data export] | /[skill] | CSV/TSV | External system | Data transfer |
Step 2: Design Each Pipeline
For each artifact type with a non-trivial render process:
Template:
- What base template is used? (HTML file, markdown template, CSV schema)
- Where is it stored? (templates/[name].[ext])
- What's customizable vs fixed?
Design Tokens (for visual artifacts):
- Fonts: [family, weights]
- Colors: [primary, secondary, accent — with HSL/hex values]
- Spacing: [margins, padding, gaps]
- Layout: [single-column, grid, sections order]
Content Generation:
- Which context files are read?
- How is content adapted per target? (keyword injection, reordering, archetype framing)
- What content rules apply? (never fabricate, reformulate existing experience, etc.)
Render Pipeline:
- [Step 1: Read source data]
- [Step 2: Generate intermediate format]
- [Step N: Convert to output format]
Tool Requirements:
- What tools are needed? (Playwright for HTML→PDF, Node.js script, MCP server)
- Fallback if tool unavailable?
Storage & Naming:
- Output directory: [output-folder]/[subfolder]/
- Naming convention: [type]-[context]-[date].[ext]
- Sequential numbering if applicable?
Verification:
- Format-specific checks (ATS-parseable, valid CSV, correct dimensions)
- Content checks (keyword coverage, section completeness)
- Cross-reference checks (artifact matches evaluation report)
Step 3: Centralize Design Tokens
If multiple artifacts share visual design:
- Define tokens once in templates/ or config/
- Reference from each pipeline
- Prevent scatter across individual skills
Step 4: Define Fallback Behavior
For each render tool dependency:
- If Playwright unavailable → [fallback: generate HTML only, explain how to convert]
- If MCP server unavailable → [fallback: text-only output with formatting instructions]
Output
Write the artifact pipeline specification to domain-input/artifact-pipeline.md.
Tell the designer:
Artifact pipelines designed:
- [N] artifact types: [list]
- Render tools required: [list]
- Design tokens: [centralized / per-artifact / not applicable]
- Fallback behavior: defined for all tool dependencies
Next: Run /design-batch-architecture if the OS needs scale processing.
Or skip to /generate-os.
Quality Checks
Good artifact pipeline:
- Every step in the render pipeline is specific and ordered
- Design tokens are centralized, not scattered
- Verification runs before storage
- Fallback exists for every tool dependency
- Naming convention is consistent and informative
Bad artifact pipeline:
- "Generate a PDF" with no template or render steps
- Design decisions scattered across multiple skills
- No verification — artifact goes straight to output
- No fallback — skill fails silently when tool is missing
- Inconsistent naming across artifact types