design-artifact-pipeline

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:

1. [Step 1: Read source data]
2. [Step 2: Generate intermediate format]
3. [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