Five-Deck Workflow Model
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.
packs/vard/ + packs/ord/). Agent review found that semi-auto graduation depends on the traction skills COA B deferred to Phase 3, so it could not function. Resolution: pull vard-traction and ord-traction into Phase 1, making the rapid pipelines effectively 4-step and the semi-auto graduation gate functional now. Both traction skills are built (claude + codex, v0.0) and registered in their PACK.md flows. The afps-status graduation-surfacing wiring remains a later (Phase 3) enhancement; the recommend-and-confirm loop lives inside the traction skills.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.
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)
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 packs, each using a scan → align → ship sequence. The remaining strategic question is how those rapid decks graduate into deliberate AFPS work and how much devtool front-half structure should be added before 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 (3 steps) | Minimal (3 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.
Proposed VARD pipeline (3-step core)
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.
vard-traction — check back after 1–2 weeks. Users, shares, engagement, revenue signals. Recommends: iterate, graduate to Business AFPS, or archive (user confirms).
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.
Proposed ORD pipeline (3-step core)
1. ord-scan Quick research: what exists, what’s 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 tweet.
ord-traction — check back after 1–2 weeks. Stars, installs, issues, mentions. Recommends: iterate, graduate to Devtool AFPS (or cross-domain Business AFPS), or archive (user confirms).
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
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.
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-briefwith VARD scan/traction data as evidence. - ORD → Devtool AFPS: OSS tool needs better DX, docs, integrations, or positioning. Enter at
devtool-idea-brief(ordevtool-user-mapif 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-briefwith 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 pack (3 core + 1 optional) | 1–2 days | Functional VARD workflow |
| ORD pack (3 core + 1 optional) | 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 |
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 packs first (6 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(business rapid) - Build
ord-scan,ord-align,ord-ship(devtool rapid) - VARD and ORD share structure — build one, adapt the other
- Graduation routing: manual initially (user runs
/idea-scope-briefor/devtool-workflow)
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 automation (later)
- Add
vard-tractionandord-tractionfor structured traction checking - Wire graduation triggers into
afps-status
Effort estimate
Phase 1: 2–3 days (6 skills, shared structure). Phase 2: 1–2 days when needed. Phase 3: 0.5 day. Total: ~4–5.5 days, spread over weeks/months.
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 sectionscustomer-discovery --mode=devtool→ developer ICP template, DX-focused questionscompetitive-analysis --mode=devtool→ ecosystem/alternatives focus- VARD and ORD packs exist separately for the rapid 3-step workflows
New work
| Item | Effort |
|---|---|
| VARD pack (3 skills) | 1–2 days |
| ORD pack (3 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.
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–5.5 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 | 6 now, more later | Mode logic in 8+ skills + 6 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 | Medium (manual) | 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 |
| No rapid workflow exists | No VARD or ORD pack or rapid-mode skills in repository | 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 |
| 3-step rapid pipeline is enough ceremony | Quality or scoping 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 |
Review Gates
Gate 1: Deck Architecture
Which deck model should be treated as canonical now?
Gate 2: COA Selection
Which course of action should we pursue?
Gate 3: Rapid Pipeline Ceremony Level
How many steps should the VARD and ORD pipelines have? (Same structure for both, different domain content.)
Gate 4: Devtool AFPS Front-Half Approach
When/how should the devtool front-half be built?
Gate 5: Graduation Trigger Mechanism
How should VARD/ORD-to-deliberate-pipeline graduation work?
Gate 6: Rapid Pack Location
Where should the VARD and ORD skills live?
Compile YAML
Use feedback YAML for emphasis requests, concerns, or clarification before answering all gates. Use final answers YAML only when every required gate is answered.