Four-Pipeline Workflow Design

alignment_status: revision

Formalizing four distinct workflow pipelines — Business AFPS, Devtool AFPS, VARD (Viral App Rapid Distribution), and ORD (OSS Rapid Distribution) — to support the "Apps as Distribution" thesis. Two domains (business, devtool) × two tempos (deliberate, rapid). This page presents the current state, proposed architecture, courses of action, and alignment gates for your review.

Apps as Distribution Thesis

Section feedback

Core thesis: Apps are distribution. Every shipped tool — whether a quick experiment or a polished product — compounds brand, audience, and surface area. Two domains and two tempos produce a 2×2 matrix of four pipelines:

	Deliberate (~monthly)	Rapid (~weekly)
Business / Viral Apps	Business AFPS	VARD (Viral App Rapid Distribution)
Devtools / OSS	Devtool AFPS	ORD (OSS Rapid Distribution)

Rapid (VARD + ORD): Weekly shipping of small experiments. Volume generates signal. Winners graduate into their respective deliberate pipeline.
Deliberate (Business AFPS + Devtool AFPS): ~Monthly shipping of deeper products. Full research and design cycle. Quality and positioning 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.

Why four pipelines?

Two domains: Business/viral apps and devtools/OSS have different audiences, distribution channels, success metrics, and research needs. ORD tools live on npm/GitHub; VARD apps live on app stores, the web, or viral channels.
Two tempos: Rapid ships weekly with minimal ceremony (3–4 steps). Deliberate ships monthly with full research and design (12–20+ steps). These are separate philosophies, not just different ceremony levels.
Different artifacts: ORD produces an npm package + README. VARD produces a deployed app + landing page. AFPS produces specs, prototypes, UAT, roadmaps.
Shared graduation paths: Rapid tools that show traction graduate into their domain’s deliberate pipeline for full treatment.
Existing infrastructure: Business AFPS is mature (40+ skills). Devtool has a strong back half (8 skills). VARD and ORD need to be built.

Current State

Section feedback

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 Pipelines (do not exist yet)

No rapid-tempo workflows exist. Small tools and viral apps currently either go through the full Business AFPS (too heavy) or get built ad-hoc with no structured process. Both VARD (business/viral rapid) and ORD (devtool/OSS rapid) need to be built.

The Four Pipelines Overview

Section feedback

Dimension	Business AFPS	Devtool AFPS	VARD	ORD
Domain	Business / viral apps	Devtools / OSS	Business / viral apps	Devtools / OSS
Tempo	~Monthly (deliberate)	~Monthly (deliberate)	Weekly (rapid)	Weekly (rapid)
Ceremony	Full (20+ steps)	Medium (12–15 steps)	Minimal (3–4 steps)	Minimal (3–4 steps)
Discovery depth	Deep ICP, competitive, journey	Developer user map, DX journey	Quick viral/market scan	Quick ecosystem scan
Output	Spec, prototype, UAT, roadmap	Spec, docs, package	Deployed app + landing page	npm package + README
Graduation from	VARD	ORD	—	—
Graduation to	—	Business AFPS	Business AFPS	Devtool AFPS
Skills needed (new)	0	3–5 front-half	3–4	3–4

Pipeline A: Business AFPS

Section feedback

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.

Pipeline B: Devtool AFPS

Section feedback

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

Pipeline C: VARD (Viral App Rapid Distribution)

Section feedback

A new rapid-tempo workflow 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. 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.

Optional 4th step: vard-traction — check back after 1–2 weeks. Users, shares, engagement, revenue signals. Decide: iterate, graduate to Business AFPS, or archive.

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

Pipeline D: ORD (OSS Rapid Distribution)

Section feedback

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.

Optional 4th step: ord-traction — check back after 1–2 weeks. Stars, installs, issues, mentions. Decide: iterate, graduate to Devtool AFPS, or archive.

Graduation Path

Section feedback

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 All Four Now

Section feedback

COA A Build all four pipelines simultaneously

Philosophy: Full capability upfront. Build both rapid packs (VARD + ORD), the devtool front-half, and graduation routing all at once. Ship a complete four-pipeline 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

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

Section feedback

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-brief or /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-traction and ord-traction for 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.

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

Section feedback

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 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.

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

Section feedback

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

Section feedback

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

Compile YAML

Section feedback

Use feedback YAML for emphasis requests, concerns, or clarification before answering all gates. Use final answers YAML only when every required gate is answered.

Four-Pipeline Workflow Design

Apps as Distribution Thesis

Why four pipelines?

Current State

Business AFPS Pipeline (complete)

Devtool Pack (back half only)

Existing devtool skill chain

Rapid Pipelines (do not exist yet)

The Four Pipelines Overview

Pipeline A: Business AFPS

When a tool enters Business AFPS

Entry point from graduation

Pipeline B: Devtool AFPS

Proposed full pipeline

Pipeline C: VARD (Viral App Rapid Distribution)

Proposed VARD pipeline (3-step core)

How VARD differs from ORD

Pipeline D: ORD (OSS Rapid Distribution)

Proposed ORD pipeline (3-step core)

Graduation Path

Graduation triggers

Graduation routing

COA A: Build All Four Now

COA A Build all four pipelines simultaneously

New skills required

Effort estimate

Timeline

COA B: Rapid Pipelines First, Evolve Devtool

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

Phase 1: VARD + ORD packs (immediate)

Phase 2: Devtool front-half (on demand)

Phase 3: Graduation automation (later)

Effort estimate

COA C: Unified Mode Flag + Rapid Packs

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

How it works

New work

Effort estimate

COA Comparison

Risk matrix

Evidence & Assumptions

Evidence

Assumptions

Review Gates

Gate 1: Pipeline Architecture

Gate 2: COA Selection

Gate 3: Rapid Pipeline Ceremony Level

Gate 4: Devtool AFPS Front-Half Approach

Gate 5: Graduation Trigger Mechanism

Gate 6: Rapid Pack Location

Compile YAML