Five-Deck Workflow Model

alignment_status: confirmed generated: 2026-06-08 amended: 2026-06-15 confirmed: 2026-06-23

Formalizing five workflow decks — VARD, ORD, Business AFPS, Devtool AFPS, and Game AFPS — to support the "Apps as Distribution" thesis while giving game work its own deliberate AFPS track. This page preserves the original VARD/ORD/devtool decisions and supersedes the old matrix with the Game AFPS deck-model update.

Amendment note: Superseded by the 2026-06-10 Game AFPS deck-model update. The active model is now five decks: VARD, ORD, Business AFPS, Devtool AFPS, and Game AFPS.

Confirmation note (2026-06-23, agent review): All six gates are approved: five decks; COA B; four-step rapid ceremony with scan, align, ship, and traction; devtool front-half on demand after ORD graduations reveal gaps; semi-auto graduation where traction skills recommend and the user confirms; and two dedicated rapid decks backed by packs/vard/ and packs/ord/. vard-traction and ord-traction are part of the canonical rapid ceremony now, while afps-status graduation surfacing remains a later enhancement.

Apps as Distribution Thesis

Core thesis: Apps are distribution. Every shipped tool — whether a quick experiment, polished product, developer package, or playable game — compounds brand, audience, and surface area. The active deck model now recognizes three domains and two tempos, with five named decks currently defined:

Deck	Domain	Tempo	Current backing	Primary output
VARD	Business / consumer apps	Rapid	`packs/vard`	Small shipped app plus distribution signal
ORD	Developer tools / OSS	Rapid	`packs/ord`	Published package, README, and ecosystem signal
Business AFPS	Business / consumer / SaaS products	Deliberate	Business discovery, lifecycle, growth, and ops packs	Validated product path, prototype, UAT, roadmap, and spec
Devtool AFPS	Developer tools, CLIs, libraries, SDKs	Deliberate	`packs/devtool`	Positioned developer product with adoption, DX, docs, and monetization evidence
Game AFPS	Video games and playable entertainment	Deliberate	`packs/game`	Audience, fantasy, genre, comparable, core-loop, playtest, store, launch, and roadmap evidence

Rapid (VARD + ORD): Weekly shipping of small experiments. Volume generates signal. Winners graduate into their respective deliberate pipeline.
Deliberate AFPS decks: Business AFPS, Devtool AFPS, and Game AFPS use deeper research, validation, and planning cycles. Quality, positioning, playability, and launch readiness compound over time.

VARD flywheel (rapid, business): Ship viral app fast → collect signal (users, shares, engagement) → graduate winners into Business AFPS → deeper investment → brand compounds → next app ships to a larger audience.

ORD flywheel (rapid, devtool): Ship OSS tool fast → collect signal (stars, installs, issues) → graduate winners into Devtool AFPS → deeper investment → next tool ships to a larger audience.

AFPS cycle (deliberate): Research deeply → validate with users → ship polished product (~monthly) → iterate on traction → compound through quality.

Game AFPS cycle (deliberate, playable entertainment): Align on audience, fantasy, genre, and comparable expectations → validate core loop and playtest metrics → test store-page promise → plan launch and roadmap.

Why five decks?

Three domains: Business/consumer apps, devtools/OSS, and playable entertainment have different audiences, proof gates, distribution channels, success metrics, and research needs. ORD tools live on npm/GitHub; VARD apps live on app stores, the web, or viral channels; Game AFPS work needs playability and store-page validation.
Two tempos: Rapid ships in days with minimal ceremony. Deliberate AFPS ships over weeks or months with full research and validation. These are separate philosophies, not just different ceremony levels.
Different artifacts: ORD produces an npm package + README. VARD produces a deployed app + landing page. Business and Devtool AFPS produce specs, prototypes, UAT, roadmaps, docs, and adoption evidence. Game AFPS produces audience/fantasy/genre evidence, core-loop proof, playtest metrics, store-page tests, launch plans, and roadmap decisions.
Shared graduation paths: Rapid tools that show traction graduate into their domain’s deliberate pipeline for full treatment.
Existing infrastructure: Business AFPS is mature, Devtool AFPS has an active devtool pack, VARD and ORD now have rapid packs, and Game AFPS is backed by the existing game pack.

Current State

Business AFPS Pipeline (complete)

idea-scope-brief
  → pack recommend/install
  → business-discovery: customer-discovery → competitive-analysis
  → customer-lifecycle: journey-map
  → optional evidence lanes (growth, ops)
  → user-flow-map → ui-interview → ux-variations → prototype
  → uat → consolidate-variations
  → research-roadmap → spec-interview → research-roadmap
  → roadmap → plan-phase → run/delegate → ship → ship-end

Spans 4 business packs (business-discovery, customer-lifecycle, business-growth, business-ops) plus global skills. Fully operational with 40+ skills.

Devtool Pack (back half only)

8Existing skills

1Orchestrator

0Front-half skills

v0.1–v0.4Version range

The devtool pack covers research-through-docs but lacks the front-half (idea scoping, discovery, competitive analysis, journey mapping) that Business AFPS provides via its discovery and lifecycle packs.

Existing devtool skill chain

devtool-workflow (orchestrator)
  → devtool-user-map          (research, v0.4)
  → devtool-integration-map   (analysis, v0.2)
  → devtool-dx-journey        (analysis, v0.2)
  → devtool-adoption          (research, v0.4)
  → devtool-positioning       (research, v0.4)
  → devtool-monetization      (research, v0.4)
  → devtool-docs-audit        (review, v0.1)

Rapid Decks (now active)

The original review identified a missing rapid-tempo path. That gap has since been closed with active VARD and ORD decks, each using a scan → align → ship → traction sequence. Graduation now happens through the traction skills: they recommend iterate, graduate, or archive, and the user confirms the action. The remaining strategic question is how much devtool front-half structure should be added after real ORD graduations create evidence.

Game AFPS Deck (new active model)

Game work now has a deliberate AFPS deck backed by the existing game pack. The active route starts with audience, fantasy, genre, and comparable alignment, then validates the core loop, prototype, playtest metrics, store-page promise, launch plan, and roadmap. Game AFPS currently has no rapid feeder deck.

The Five Decks Overview

Dimension	Business AFPS	Devtool AFPS	Game AFPS	VARD	ORD
Domain	Business / viral apps	Devtools / OSS	Games / playable entertainment	Business / viral apps	Devtools / OSS
Tempo	Deliberate	Deliberate	Deliberate	Rapid	Rapid
Ceremony	Full (20+ steps)	Medium (12–15 steps)	Full game proof gates	Minimal (4 steps)	Minimal (4 steps)
Discovery depth	Deep ICP, competitive, journey	Developer user map, DX journey	Audience, fantasy, genre, comparables, playtests	Quick viral/market scan	Quick ecosystem scan
Output	Spec, prototype, UAT, roadmap	Spec, docs, package	Playable proof, store-page promise, launch plan, roadmap	Deployed app + landing page	npm package + README
Graduation from	VARD	ORD	—	—	—
Graduation to	—	Business AFPS	—	Business AFPS	Devtool AFPS
Backing packs	business-discovery, customer-lifecycle, business-growth, business-ops	devtool	game	vard	ord

Deck A: Business AFPS

The existing durable business product pipeline. No changes needed. It receives graduates from VARD (viral apps that showed traction) and from Devtool AFPS (devtools that need full business treatment). Entry triggers: revenue potential, enterprise demand, or product complexity warranting full customer discovery, spec, prototype, and UAT.

When a tool enters Business AFPS

VARD app has clear revenue potential or enterprise demand signals
User base is large enough to justify deep customer discovery
Product complexity requires spec → prototype → UAT cycle
Business model questions (pricing, packaging, channels) are material

Entry point from graduation

Graduated tools enter at /idea-scope-brief with prior VARD/Devtool research artifacts linked as evidence. The brief skill detects existing artifacts and fast-tracks sections already covered.

Deck B: Devtool AFPS

The devtool pack has a strong back half (user-map through docs-audit) but lacks the front half that Business AFPS gets from its discovery and lifecycle packs. The proposed front half mirrors business-discovery’s structure but is developer-specific.

Proposed full pipeline

FRONT HALF (new):
  devtool-idea-brief             ← scoped concept for a devtool
  devtool-discovery              ← developer ICP, pain points, workflow context
  devtool-competitive-scan       ← alternatives, ecosystem gaps

EXISTING BACK HALF:
  devtool-user-map               ← map users, buyers, champions
  devtool-integration-map        ← integrations, setup, compatibility
  devtool-dx-journey             ← install to production adoption
  devtool-adoption               ← adoption loops, examples, templates
  devtool-positioning            ← position vs alternatives
  devtool-monetization           ← pricing, OSS strategy, team conversion
  devtool-docs-audit             ← doc quality review

POST-RESEARCH:
  spec-interview → roadmap → plan-phase → run → ship

Deck C: VARD (Viral App Rapid Distribution)

The rapid-tempo deck for shipping small viral apps and consumer-facing tools as distribution touchpoints. Mirrors the ORD philosophy but for the business/consumer domain. Designed for 1–3 day cycle time and minimum viable ceremony.

Canonical VARD pipeline (4 steps)

1. vard-scan         Quick market scan: viral potential, audience, distribution channel.
                     Output: 1-page scan doc with go/no-go recommendation.

2. vard-align        Lightweight alignment: confirm scope, name, target audience, distribution.
                     Output: Mini alignment page (3 gates max) or skip if solo.

3. vard-ship         Build, deploy, announce.
                     Output: Deployed app + landing page + social announcement.

4. vard-traction     Check back after 1-2 weeks for users, shares, engagement, and revenue signals.
                     Output: Recommendation to iterate, graduate to Business AFPS, or archive; user confirms.

Confirmed ceremony: Traction is no longer optional follow-up in the model; it is the fourth rapid-deck step that makes semi-auto graduation functional.

How VARD differs from ORD

Audience: End users / consumers vs. developers
Distribution: App stores, web, social vs. npm, GitHub
Success metrics: Users, shares, engagement vs. stars, installs, issues
Scan focus: Viral mechanics, market timing vs. ecosystem gaps, existing tools
Graduation target: Business AFPS vs. Devtool AFPS

Deck D: ORD (OSS Rapid Distribution)

The devtool rapid-tempo workflow for shipping small OSS developer tools. Same rapid philosophy as VARD but targeting the developer ecosystem.

Canonical ORD pipeline (4 steps)

1. ord-scan          Quick research: what exists, what is the gap, who cares?
                     Output: 1-page scan doc with go/no-go recommendation.

2. ord-align         Lightweight alignment: confirm scope, name, target user.
                     Output: Mini alignment page (3 gates max) or skip if solo.

3. ord-ship          Build, package, publish, announce.
                     Output: npm package + GitHub repo + README + optional announcement.

4. ord-traction      Check back after 1-2 weeks for stars, installs, issues, and mentions.
                     Output: Recommendation to iterate, graduate to Devtool AFPS or Business AFPS, or archive; user confirms.

Confirmed ceremony: Traction is the fourth rapid-deck step and the semi-auto graduation mechanism for ORD.

Deck E: Game AFPS

The deliberate AFPS deck for video games and playable entertainment. Game AFPS uses the AFPS tempo but replaces generic product proof with game-specific evidence: audience, fantasy, genre expectations, comparable games, core loop, prototype tests, playtest metrics, store-page promise, launch plan, and roadmap.

Canonical Game AFPS chain

game-audience → game-fantasy → game-genre-map → game-comparables
  → game-core-loop → game-prototype-test → game-playtest-metrics
  → game-store-page-test → game-launch → game-roadmap

Game deck status: Game AFPS is already backed by packs/game. It does not require a new rapid feeder deck before use; small game prototypes can start directly inside the game pack when deliberate playtest-driven validation is warranted.

Graduation Path

Rapid-pipeline tools (VARD and ORD) that show traction graduate into their domain’s deliberate pipeline. The graduation path depends on the tool’s domain and ambition.

Revision note: The rapid graduation routing chart now keeps destination labels inside the SVG viewBox so the Business AFPS and Devtool AFPS paths remain fully visible at desktop and mobile widths.

Graduation triggers

Signal	Threshold (suggested)	Action
npm weekly downloads	> 100 sustained	Consider graduation
GitHub stars	> 50	Consider graduation
Issues filed by non-authors	> 5 substantive	Strong signal
Enterprise inquiry / request	Any	Graduate to Business AFPS
Integration requests	> 3	Graduate to Devtool AFPS
Revenue potential identified	Any	Graduate to Business AFPS

Graduation routing

VARD → Business AFPS: Viral app has revenue potential, enterprise demand, or needs full customer discovery. Enter at idea-scope-brief with VARD scan/traction data as evidence.
ORD → Devtool AFPS: OSS tool needs better DX, docs, integrations, or positioning. Enter at devtool-idea-brief (or devtool-user-map if front-half is not yet built).
ORD → Business AFPS (cross-domain): Rare case where an OSS tool shows business/enterprise demand. Enter at idea-scope-brief.
Devtool AFPS → Business AFPS: Devtool matures to need pricing strategy, enterprise ICP, go-to-market. Enter at idea-scope-brief with devtool research as evidence.

COA A: Build Full Deck Coverage Now

COA A Build complete deck coverage simultaneously

Philosophy: Full capability upfront. Build both rapid packs (VARD + ORD), the devtool front-half, and graduation routing all at once while recognizing Game AFPS as an already backed deliberate deck. Ship a complete five-deck system.

New skills required

Pack	Skill	Purpose
VARD	`vard-scan`	Quick market/viral scan and go/no-go
VARD	`vard-align`	Lightweight alignment page
VARD	`vard-ship`	Build, deploy, announce
VARD	`vard-traction`	Post-ship traction check
ORD	`ord-scan`	Quick ecosystem scan and go/no-go
ORD	`ord-align`	Lightweight alignment page
ORD	`ord-ship`	Build, package, publish
ORD	`ord-traction`	Post-ship traction check
Devtool	`devtool-idea-brief`	Scoped devtool concept
Devtool	`devtool-discovery`	Developer ICP and pain points
Devtool	`devtool-competitive-scan`	Alternative tools and gaps

Effort estimate

11 new skills + graduation routing in afps-status + pack metadata. ~5–7 days of skill authoring.

Timeline

Phase	Duration	Deliverable
VARD deck (4 rapid skills)	1–2 days	Functional VARD workflow
ORD deck (4 rapid skills)	1–2 days	Functional ORD workflow
Devtool front-half (3 skills)	1–2 days	Complete devtool pipeline
Graduation routing	0.5 day	afps-status updates, cross-pack routing
Integration testing	0.5 day	End-to-end pipeline validation

Risk: Building both rapid packs and the devtool front-half without real data. VARD and ORD share a structure but may diverge more than expected. The 3 devtool skills are modeled on business-discovery, but developer workflows may need different structures.

COA B: Rapid Pipelines First, Evolve Devtool

COA B Ship both rapid pipelines now, evolve devtool front-half on demand (Recommended)

Philosophy: Fastest to value. Build VARD and ORD decks first (8 skills, sharing structure). Start shipping both viral apps and OSS tools immediately. Let real graduations reveal what the devtool front-half actually needs.

Phase 1: VARD + ORD packs (immediate)

Build vard-scan, vard-align, vard-ship, and vard-traction (business rapid)
Build ord-scan, ord-align, ord-ship, and ord-traction (devtool rapid)
VARD and ORD share structure — build one, adapt the other
Graduation routing: semi-auto through traction-skill recommendations, with user confirmation before graduation, iteration, or archive action

Phase 2: Devtool front-half (on demand)

After 3–5 ORD tools ship, evaluate which ones need graduation
Build devtool front-half skills based on actual gaps encountered
May discover the existing devtool-user-map is a sufficient entry point

Phase 3: Graduation status surfacing (later)

Wire persisted traction recommendations into afps-status so the status skill can surface graduation-ready VARD and ORD items
Keep action authority with the user; afps-status reports readiness, while traction skills create the recommendation record

Effort estimate

Phase 1: 2.5–3.5 days (8 skills, shared structure). Phase 2: 1–2 days when needed. Phase 3: 0.5 day. Total: ~4–6 days, spread over weeks/months.

Why recommended: Both rapid pipelines ship fast because they share structure. Generates real data about what the devtool front-half needs before building it. Lowest risk of over-engineering. VARD and ORD can be adapted from the same skeleton. Phase 2 may turn out to be unnecessary.

COA C: Unified Mode Flag + Rapid Packs

COA C Add mode flags to existing AFPS + build both rapid packs

Philosophy: One deliberate pipeline with mode flags, two separate rapid packs. Add a --mode=business|devtool flag to existing AFPS skills so they adapt per domain. Build VARD and ORD packs separately for rapid workflows.

How it works

idea-scope-brief --mode=devtool → developer-focused brief, skips consumer sections
customer-discovery --mode=devtool → developer ICP template, DX-focused questions
competitive-analysis --mode=devtool → ecosystem/alternatives focus
VARD and ORD decks exist separately for the rapid 4-step workflows

New work

Item	Effort
VARD deck (4 skills)	1–2 days
ORD deck (4 skills)	1–2 days
Mode flag infrastructure in AFPS skills	2–3 days
Devtool mode templates for 5–8 existing skills	1–2 days
Testing across modes	1 day

Effort estimate

6–10 days total. Highest effort because it touches existing stable skills and builds both rapid packs.

Risk: Modifying 5–8 mature skills to support mode flags adds regression risk. Each skill becomes more complex. Mode-specific behavior is harder to test than separate skills. Could slow down iteration on the devtool path.

COA Comparison

Dimension	COA A Build All	COA B Rapid First	COA C Mode Flags
Time to first rapid tool	5–7 days	2–3 days	2–3 days
Total effort	5–7 days	4–6 days (spread)	6–10 days
Risk to existing skills	None	None	High (modifies 5–8)
Data-driven devtool design	No	Yes	Partial
Upfront completeness	Full	Partial	Full
Over-engineering risk	High	Low	Medium
Maintenance complexity	11 new skills	8 now, more later	Mode logic in 8+ skills + 8 rapid

Risk matrix

Risk	Impact	COA A	COA B	COA C
Over-build devtool front-half	Wasted effort	High	None	Medium
Break existing business skills	Pipeline disruption	None	None	High
Graduation friction	Slow graduation	Low	Low (traction skill recommends, user confirms)	Low
Skill sprawl	Maintenance burden	High (11 at once)	Low (incremental)	Medium
Delayed rapid launch	Lost distribution momentum	Medium	None	Medium
VARD/ORD diverge more than expected	Duplicated maintenance	Medium	Low (adapt as needed)	Medium

Evidence & Assumptions

Evidence

Claim	Evidence	Confidence
Business AFPS is complete and operational	40+ skills across 4 packs, documented in canonical-workflow-report	High
Devtool pack covers research through docs	8 skills in packs/devtool/claude, v0.1–v0.4	High
Devtool pack lacks front-half	No idea-brief, discovery, or competitive skills in pack	High
Original rapid-workflow gap is closed	Active VARD and ORD decks now exist with scan, align, ship, and traction skills in `packs/vard/` and `packs/ord/`	High
Business-discovery structure is a good model for devtool front-half	Similar shape: ICP → competitive → journey → positioning	Medium

Assumptions

Assumption	Risk if wrong	Validation approach
Weekly rapid tool shipping is sustainable	VARD/ORD pipelines underused	Ship 3–5 tools through each, measure cadence
4-step rapid pipeline is enough ceremony	Quality, scoping, or traction follow-up issues	Retrospective after first 5 tools per pipeline
VARD and ORD share enough structure to build from one skeleton	More divergence than expected, rework needed	Build ORD first, adapt for VARD, measure delta
Traction signals are measurable	Graduation decisions are subjective	Define thresholds, track actuals
Devtool front-half needs differ from business	Unnecessary skill duplication	Let ORD graduations reveal actual gaps
Rapid tools will generate meaningful distribution	Thesis is wrong, effort wasted	Track aggregate engagement/downloads/stars after 10 tools across both pipelines

Approval Record

Confirmed 2026-06-23: Final gate-answer YAML approved this five-deck workflow model. No section feedback items were included in the approval payload.

Gate	Decision	Confirmed implication
Deck Architecture	Five decks: VARD, ORD, Business AFPS, Devtool AFPS, and Game AFPS	The canonical model uses two rapid decks and three deliberate AFPS decks.
COA Selection	COA B: Rapid Pipelines First, Evolve Devtool	Prioritize VARD and ORD rapid-deck operation before building devtool front-half skills.
Rapid Ceremony	4 steps: scan, align, ship, traction	`vard-traction` and `ord-traction` are part of the canonical rapid ceremony, not deferred optional work.
Devtool Front-Half	On demand after ORD graduations reveal gaps	Do not build devtool idea/discovery/competitive front-half skills until ORD graduation evidence shows the gap.
Graduation Triggers	Semi-auto: traction skill recommends, user confirms	Traction skills create the recommendation record; the user confirms before graduation, iteration, or archive action.
Rapid Pack Location	Two dedicated rapid decks backed by `packs/vard/` and `packs/ord/`	The user note clarifies these are dedicated decks, not merely a pack-location decision.

Confirmed Artifact Boundary

Confirmed page: alignment/workflow-design-three-pipelines.html
Archived prior page: docs/history/archive/2026-06-23/235216/alignment/workflow-design-three-pipelines.html
Implementation backing: active VARD and ORD deck skills under packs/vard/ and packs/ord/, with traction skills as the recommend-and-confirm graduation gate.
Later enhancement: afps-status may surface persisted graduation-ready records, but it does not replace traction-skill recommendations or user confirmation.