Dashboard/Vibe-Coded-Product-Methodology/Framework-Comparison.md
Vibe-Coded-Product-Methodology

Framework-Comparison.md

Framework Comparison — Idea-to-Build vs. The Field

Empirical comparison research that closes Research Direction #1 from Idea-to-Build-Skill-Proposal.md §"Variations + Research Directions". Validates or refutes the differentiation claims asserted in Projects/Vibe-Coded-Product-Methodology/README.md.

Date: 2026-04-30. Author: Research pass commissioned during Crawler Factory follow-on. Method: Direct fetch of canonical sources (GitHub READMEs, raw markdown, GitHub Contents API for tree walks, official docs). Quotes are verbatim. Anything not directly fetched is marked [ESTIMATE]. Frameworks compared: 1. Idea-to-Build (this proposal — Projects/Crawler-Factory/Idea-to-Build-Skill-Proposal.md) 2. Anthropic Superpowers plugin v5.0.7 (obra/superpowers, MIT) 3. BMad Method v6 (bmad-code-org/BMAD-METHOD, MIT) 4. GitHub spec-kit (github/spec-kit, MIT) 5. Cursor rules (.cursor/rules/ and AGENTS.md, included with Cursor)

Note: Aider, Continue, Cline are tool-shaped (CLI editors with agent loops) and explicitly do not orchestrate plan→design→build→test with hard gates. Excluded per the brief.

1. Executive verdict

  1. Idea-to-Build's empirical-research-after-sketch is genuinely differentiated. No competitor ties research to the v0 plan's stated assumptions. BMad has front-loaded research workflows (bmad-market-research, bmad-domain-research, bmad-technical-research) but they fire BEFORE the plan, not against the plan's assumption register. spec-kit's research.md is tech-stack reconnaissance, not assumption validation. Superpowers has zero research phase. Cursor rules have no research at all.
  2. Idea-to-Build's Contract Lock + closed re-verify loop is genuinely differentiated. spec-kit has [P] parallel markers on tasks but no contract artifact. BMad has bmad-check-implementation-readiness (one-shot traceability check) but no re-verify loop and no cross-cluster contract object. Superpowers has fresh-subagent-per-task isolation but no shared contract. None of them have V1→fix→V2→re-verify with hard halt at 0 Critical / 0 Important.
  3. Idea-to-Build is behind on packaging and distribution. It's a vault Markdown proposal; competitors ship as installable plugins (/plugin install superpowers, npx bmad-method install, uv tool install specify-cli). Without an installable harness it cannot be evaluated by anyone but the operator.
  4. Idea-to-Build is behind on operator burden quantification. All four competitors leave operator-burden unmeasured (Variation Research §3 in the proposal flags this honestly). But spec-kit and BMad ship with non-interactive install + opinionated defaults, lowering first-use cost. Idea-to-Build's dossier validation rubric is heavier on entry; that's a real cost the methodology must own.
  5. Idea-to-Build's commercial framing (open-core) is plausible but unproven against incumbents. BMad explicitly rejects paywalls ("100% free and open source. No paywalls. No gated content. No gated Discord."). Superpowers funds via GitHub Sponsors, no commercial tier. spec-kit is GitHub-owned and free. The open-core SaaS thesis has no direct precedent in this space — it would be a category-creating bet, not a follow-on.

2. Per-framework breakdown

2.1 Anthropic Superpowers (obra/superpowers, v5.0.7)

Source: local install at ~/.claude/plugins/cache/claude-plugins-official/superpowers/5.0.7/. README at same path. MIT license. Author Jesse Vincent / Prime Radiant.

Phases / skills (in fire order): 1. brainstorming — Socratic dialogue, 2-3 approaches, design doc, hard gate ("Do NOT invoke any implementation skill ... until ... user has approved"). 2. using-git-worktrees — isolated workspace. 3. writing-plans — bite-sized 2-5 minute tasks, Protocol Read Receipt requirement before any external API call (this is genuinely strong), Validation Risk Surface table. 4. subagent-driven-development OR executing-plans — fresh subagent per task with two-stage review (spec compliance, then code quality). 5. test-driven-development — RED-GREEN-REFACTOR enforced. 6. requesting-code-review — between tasks. 7. finishing-a-development-branch — merge/PR decision.

Citation: ~/.claude/plugins/cache/claude-plugins-official/superpowers/5.0.7/README.md lines 108-124.

Empirical research: None. Plans are written from spec/design — no programmatic assumption extraction, no research-agent dispatch.

Parallel-author drift handling: dispatching-parallel-agents skill exists but is for "2+ independent tasks that can be worked on without shared state" — explicitly says "Don't use when ... need to understand full system state" and "shared state would interfere." There is no contract artifact and no cross-cluster verification. Subagent-driven-development's "fresh subagent per task" prevents context pollution but doesn't prevent type-drift across parallel implementations.

Citation: skills/dispatching-parallel-agents/SKILL.md lines 36-42.

Gates / checkpoints: - <HARD-GATE> in brainstorming/SKILL.md line 12 (no code before design approved). - Two-stage review (spec then quality) per task in subagent-driven-development. - verification-before-completion skill: "NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE." This is the strongest prior-art gate skill in the field.

Citation: skills/verification-before-completion/SKILL.md line 19.

Eval / metrics: None codified.

Distribution: Claude Code plugin marketplace (/plugin install superpowers@claude-plugins-official), Cursor marketplace, Codex, OpenCode, GitHub Copilot CLI, Gemini CLI. Multi-platform.

Commercial model: MIT. No commercial tier. Funded via GitHub Sponsors.

What Idea-to-Build can adopt: The Protocol Read Receipt pattern (writing-plans/SKILL.md lines 22-37) is excellent and Idea-to-Build's Phase 7 spec-generation should require it explicitly, not rely on operator pushback to enforce it. Two-stage review per task (spec compliance, then code quality) is a sharper version of Idea-to-Build's Phase 8 single-axis SOP review.

What Idea-to-Build does that Superpowers doesn't: empirical research phase, contract lock, closed re-verify loop with V versioning.

2.2 BMad Method v6 (bmad-code-org/BMAD-METHOD)

Source: repo bmad-code-org/BMAD-METHOD, npm bmad-method. README + Contents API tree walk. MIT license. Trademark held by BMad Code, LLC.

Phases (4 stages): 1. Analysis (optional) — bmad-agent-analyst, bmad-agent-tech-writer, bmad-document-project, bmad-prfaq, bmad-product-brief, plus research subfolder: bmad-domain-research, bmad-market-research, bmad-technical-research. 2. Planning (required) — bmad-agent-pm, bmad-agent-ux-designer, bmad-create-prd, bmad-create-ux-design, bmad-edit-prd, bmad-validate-prd. 3. Solutioning — bmad-agent-architect, bmad-create-architecture, bmad-create-epics-and-stories, bmad-check-implementation-readiness, bmad-generate-project-context. 4. Implementation — bmad-agent-dev, bmad-checkpoint-preview, bmad-code-review, bmad-correct-course, bmad-create-story, bmad-dev-story, bmad-qa-generate-e2e-tests, bmad-quick-dev, bmad-retrospective, bmad-sprint-planning, bmad-sprint-status.

Citation: gh api repos/bmad-code-org/BMAD-METHOD/contents/src/bmm-skills/{1-analysis,2-plan-workflows,3-solutioning,4-implementation} 2026-04-30 fetch.

Empirical research: Real, but front-loaded. bmad-market-research, bmad-domain-research, bmad-technical-research exist as Phase 1 workflows, all marked optional. Operator must invoke them before the PRD; they don't fire programmatically against PRD assumptions. This is the closest competitor to Idea-to-Build's Phase 4 — but it's not the same shape. Idea-to-Build's research IS the assumption-validation pass against an existing v0 plan; BMad's research IS the input that produces the PRD.

Parallel-author drift handling: Not a primary concern in BMad's design. Implementation is "epic by epic, story by story" — sequential, with one developer agent per story. No cross-cluster contract object. The bmad-check-implementation-readiness workflow is the closest analog — it validates "PRD, UX, Architecture, Epics and Stories are complete and aligned" with "requirements traceability" focus. One-shot, no re-verify loop. If issues are found, operator runs bmad-correct-course ad-hoc.

Citation: src/bmm-skills/3-solutioning/bmad-check-implementation-readiness/SKILL.md lines 6-9.

Gates / checkpoints: - bmad-validate-prd (Phase 2 close). - bmad-check-implementation-readiness (Phase 3 → Phase 4 transition). - bmad-code-review per story. - bmad-retrospective per epic. - Workflow architecture enforces step-by-step JIT loading: "🛑 NEVER load multiple step files simultaneously" and "🚫 NEVER skip steps or optimize the sequence" — this is genuine process discipline.

Citation: src/bmm-skills/2-plan-workflows/bmad-validate-prd/SKILL.md lines 32-41.

Operator burden: Lower than Idea-to-Build at entry (no dossier rubric — operator just invokes bmad-help). Higher across the lifecycle because each story passes through PM → architect → dev → reviewer agents serially.

Eval / metrics: None codified in core. bmad-retrospective is qualitative, not quantitative.

Distribution: npx bmad-method install (npm). Non-interactive install supported (--directory, --modules, --tools, --yes). Modules: BMM (core), BMB (builder), TEA (test architect, separate repo), BMGD (game dev), CIS (creative intelligence). Module ecosystem is real and growing.

Commercial model: MIT. Explicit anti-paywall stance: "100% free and open source. No paywalls. No gated content. No gated Discord. We believe in empowering everyone, not just those who can pay." Funded via Buy-Me-A-Coffee + corporate sponsorship inquiry.

Citation: README.md lines 14-17.

What Idea-to-Build can adopt: The agent-persona model (PM, Architect, Dev) is sharper than Idea-to-Build's "agent" role-naming — it gives operators something concrete to invoke. The step-file architecture pattern (sequential, no skipping, JIT loading) is a strong harness primitive that Idea-to-Build's prose currently leaves implicit. The module ecosystem (TEA, BMGD, CIS) is a precedent for how to extend a methodology without forking the core.

What Idea-to-Build does that BMad doesn't: Assumption-driven research (vs. front-loaded research), contract lock as a first-class artifact, closed re-verify loop with V1→V2→V3 versioning. BMad will catch the same drift class but only if the operator manually re-runs bmad-check-implementation-readiness after each fix.

2.3 GitHub spec-kit (github/spec-kit)

Source: github/spec-kit repo README via WebFetch. MIT license.

Workflow (commands in order): 1. /speckit.constitution → .specify/memory/constitution.md (governing principles). 2. /speckit.specify → specs/[FEATURE]/spec.md (functional requirements). 3. /speckit.clarify (optional) → appends Clarifications section. 4. /speckit.plan → plan.md, data-model.md, contracts/, research.md, quickstart.md. 5. /speckit.tasks → tasks.md with [P] parallel markers. 6. /speckit.implement → source code. 7. Optional gates: /speckit.analyze (cross-artifact consistency, runs after /speckit.tasks before /speckit.implement), /speckit.checklist (validate completeness).

Citation: https://github.com/github/spec-kit README extraction 2026-04-30.

Empirical research: Limited. research.md is tech-stack reconnaissance ("what stack to use"), not assumption validation against a prior plan. Constitution is principles, not empirical data.

Parallel-author drift handling: [P] markers on tasks indicate parallelizability — but the markers are advisory, not enforced by a contract artifact. contracts/ directory exists in the plan output ("api-spec.json" mentioned) but it's per-feature, not cross-cluster, and not a hard gate before parallel work. /speckit.analyze is the closest analog to a re-verify pass — it's an optional one-shot consistency check, not a closed loop.

Operator burden: Lowest of the field at entry. Six commands in order, opinionated defaults, very little operator decision required after the constitution is set.

Eval / metrics: None native. Extensions (spec-kit-retrospective) offer "spec adherence scoring" but it's third-party and not first-party-supported ("no review, audit, endorse, or support [of extension code itself]").

Distribution: uv tool install specify-cli --from git+https://github.com/github/spec-kit.git@vX.Y.Z (no PyPI). Pipx alternative. Enterprise air-gapped option documented.

Commercial model: MIT. GitHub-owned. No commercial tier; community-driven via issues. Extensions independently maintained.

Goals (verbatim): "Build high-quality software faster" by allowing developers to "focus on product scenarios and predictable outcomes instead of vibe coding."

What Idea-to-Build can adopt: The Constitution-as-foundational-doc pattern is strong — it's the closest external analog to the operator's vault Standards. The [P] parallel marker convention is a lightweight serialization of contract intent. Worktree extensions (spec-kit-worktree, spec-kit-worktree-parallel) are a precedent for parallel feature isolation. The single-CLI install (uv tool install) is the cleanest distribution model in the field.

What Idea-to-Build does that spec-kit doesn't: Empirical assumption research, contract LOCK (vs. contract files that are per-feature deliverables), closed re-verify loop. spec-kit is closer to "spec-driven dev with gates"; Idea-to-Build is closer to "spec-driven dev with empirical validation + drift defense."

2.4 Cursor rules (cursor.com)

Source: https://cursor.com/docs/context/rules via WebFetch.

What it is: Rules-as-context. Markdown files with frontmatter that get injected into agent context based on triggers.

Storage: - Project rules: .cursor/rules/ (version-controlled). - User rules: global to Cursor environment. - Team rules: dashboard-managed. - AGENTS.md: simple alternative to .cursor/rules.

Four rule types: 1. Always Apply — every chat session. 2. Apply Intelligently — agent decides relevance based on description. 3. Apply to Specific Files — when file matches globs pattern. 4. Apply Manually — when @-mentioned (@my-rule).

Phases / workflow / gates: None. Rules are declarative context, not orchestrated flow. "Rule contents are included at the start of the model context" — that's the entire mechanism.

Empirical research support: None.

Eval / metrics: None. Documentation only suggests "When you see Agent make a mistake, update the rule" — manual iteration.

Commercial model: Bundled with Cursor (free tier limits, paid tier above). Team Rules require Team or Enterprise plans.

Why this is a different category from the others: Cursor rules are not a methodology. They're a context-injection mechanism. They're useful for codifying coding standards (Idea-to-Build's Standards/CodingSOPs.md could be a Cursor rule), but they don't gate phases, don't dispatch research, don't manage parallel work. Including them in the comparison is mostly to show that the existing Cursor toolchain does NOT solve what Idea-to-Build is solving.

2.5 Idea-to-Build (this proposal)

Source: Projects/Crawler-Factory/Idea-to-Build-Skill-Proposal.md. Status: Proposal v1, no installable plugin yet.

Phases (9): 1. Dossier Intake (operator-supplied dossier validation against rubric). 2. Context Loading + Clarifying Questions. 3. Initial Sketch (superpowers:writing-plans v0). 4. Assumption Surfacing + Empirical Research (programmatic assumption extraction, parallel research dispatch, Reality Catalog). 5. Plan Freeze + SOP Application. 6. Contract Lock (cross-cluster type artifact, hard gate). 7. Spec Generation (parallel agents per cluster). 8. Multi-Axis Verification with Closed Re-Verify Loop (V1→fix→V2→fix→V3, halt at 0 Critical / 0 Important, max 3 iterations). 9. Build Handoff.

Empirical research: Phase 4. Differentiated — programmatic extraction of assumption claims from v0 plan, dispatch of research subagents per assumption, Reality Catalog as artifact, v0→v1 plan revision with citation density check.

Parallel-author drift handling: Phases 6 + 8. Contract Lock is a single artifact (Contracts.ts or equivalent) consumed by all parallel cluster authors as a fixed import. Phase 8 verifies cross-spec interface drift programmatically, not just per-cluster review.

Gates: 7 hard gates (Phases 1, 2, 3, 4, 5, 6, 9) require operator approval. Phase 8 has automated closed-loop halt criterion (0 Critical / 0 Important).

Eval / metrics: Honestly admitted as not-yet-designed (proposal §"Research directions" line 410-414: "how do we measure that the methodology actually reduces rework? Need: a metric (issues caught at verification vs. issues caught at runtime — the lower-the-better ratio)"). This is the right metric to commit to.

Distribution: Currently vault Markdown only. No plugin, no CLI, no install. Behind every competitor on this axis.

Commercial model: Open-core proposed (free GitHub repo + paid team tier + consulting). No precedent in this category (BMad rejects paywalls; Superpowers is sponsorship-funded; spec-kit is GitHub-funded; Cursor rules are bundled with a paid editor).

3. Comparison matrix

Dim Idea-to-Build Superpowers BMad v6 spec-kit Cursor rules
Phases / steps 9 (Dossier → Context → Sketch → Empirical Research → Freeze → Contract Lock → Spec Gen → Multi-Axis Verify → Build Handoff) 7 (brainstorm → worktree → plan → execute → TDD → review → finish) 4 stages (Analysis → Planning → Solutioning → Implementation), 34+ workflows underneath 6 commands (constitution → specify → clarify → plan → tasks → implement) + 2 optional gates None — declarative context only
Empirical research as a phase YES — Phase 4 against v0 plan's assumption register, programmatic NO YES but front-loaded (bmad-market/domain/technical-research), optional, before PRD LIMITED — research.md is tech-stack recon, not assumption validation NO
Parallel-author drift defense Contract Lock artifact (Phase 6) + cross-spec interface verification (Phase 8) + closed re-verify loop Fresh subagent per task isolation; no shared contract artifact; dispatching-parallel-agents only for independent tasks Sequential epic-by-epic implementation; no cross-cluster contract; one-shot bmad-check-implementation-readiness [P] task markers; per-feature contracts/ directory; one-shot /speckit.analyze N/A
Gates / checkpoints 7 operator gates + 1 automated halt criterion (V 0 Critical / 0 Important) Hard gate before code (brainstorming); two-stage review per task (spec then quality); verification-before-completion as cross-cutting skill bmad-validate-prd, bmad-check-implementation-readiness, per-story bmad-code-review, per-epic bmad-retrospective /speckit.analyze, /speckit.checklist (both optional unless extension enforces) None
Eval / metrics None yet (admitted gap; proposed metric: issues-at-verify vs. issues-at-runtime ratio) None None codified None native; extension spec-kit-retrospective adds spec adherence scoring None
Operator burden High at entry (dossier rubric must validate); medium per phase (7 gates) Low–medium (brainstorm dialogue; plan approval; per-task review checkpoints) Low at entry (bmad-help always available); high across lifecycle (multiple agents serially per story) Lowest (6 commands, opinionated defaults) Trivial (write rules once)
Distribution Vault Markdown only /plugin install superpowers (Claude Code, Cursor, Codex, OpenCode, Copilot CLI, Gemini CLI) npx bmad-method install (npm) uv tool install specify-cli --from git+... Built into Cursor
License Not yet declared (open-core proposed) MIT MIT MIT Proprietary (Cursor)
Commercial model Open-core (free repo + paid team tier + consulting) — UNPROVEN in category Sponsorship Anti-paywall stance, sponsorship + corporate inquiry GitHub-funded, free Bundled with paid editor

4. Recommendations for Idea-to-Build v1

Keep (genuinely differentiated)

  1. Phase 4 — Assumption Surfacing + Empirical Research. This is the strongest differentiator. No competitor extracts assumption claims from a v0 plan and validates each programmatically. Keep as-is, but tighten the language: it's not "research" generally — it's "assumption validation against an existing plan." That framing protects the differentiation against BMad's front-loaded research workflows.

  2. Phase 6 — Contract Lock. The cross-cluster contract artifact concept is unique. spec-kit's contracts/ is per-feature; BMad has no such artifact; Superpowers explicitly avoids parallel work that needs shared state. Keep.

  3. Phase 8 — Closed Re-Verify Loop. V1→fix→V2→fix→V3 with hard halt at 0 Critical / 0 Important is unique. BMad's bmad-check-implementation-readiness is one-shot; spec-kit's /speckit.analyze is one-shot. Keep, but specify: re-verify must check that the FIX did not introduce new drift (the B14-from-Crawler-Factory pattern). This is the operational lesson the methodology was built around.

Drop or merge (redundant against competitors)

  1. Drop Phase 5's SOP-application step as a separate phase. Superpowers' brainstorming has a built-in spec self-review with checklist; BMad has bmad-validate-prd. Idea-to-Build's Phase 5 invokes standards-coding/testing/writing against the plan — but this is just the same idea wearing different clothes. Merge into Phase 4 (research is when SOPs become non-negotiable) or Phase 6 (contract lock is when SOPs harden).

  2. Drop Phase 9's "build handoff" as a separate phase. spec-kit's /speckit.implement is a single command; Superpowers' subagent-driven-development is a single skill invocation. The "handoff" is a Claude Code session boundary, not a methodology phase. Document it as a transition note in Phase 8, not a numbered phase.

  3. Reduce dossier rubric's required fields. Idea-to-Build's Phase 1 requires 7 fields (Idea / UX walk-through / Knowledge sources / Constraints / Definition of done / Areas to push hardest / Hard nos). spec-kit requires zero pre-work; BMad requires zero. Reducing to 3 required (Idea + Knowledge sources + Definition of done) and 4 recommended would lower entry cost without losing rigor.

Adopt from competitors

  1. Adopt Superpowers' Protocol Read Receipt requirement (writing-plans/SKILL.md lines 22-37) into Phase 7 spec generation. Currently Idea-to-Build Phase 7 says "each agent invokes writing-plans" — this assumes the underlying skill enforces source verification. Make it explicit in the Phase 7 contract: every external API mentioned in a generated spec MUST have a Protocol Read Receipt.

  2. Adopt BMad's step-file architecture (JIT-loaded sequential step files with stepsCompleted frontmatter) for the orchestrator. Idea-to-Build's 9 phases are currently described in prose; converting to BMad-style step files would make the harness deterministic without losing the operator gates. This is also a precedent for the eventual plugin distribution.

  3. Adopt spec-kit's Constitution pattern as Idea-to-Build's pre-Phase-1 "Standards Pin" step. Currently the operator's Standards/CodingSOPs.md, TestingSOPs.md, WritingSOPs.md are referenced from ~/.claude/CLAUDE.md but their version isn't pinned per project. spec-kit's .specify/memory/constitution.md per-project pinning is the right pattern.

  4. Adopt Superpowers' two-stage review (spec compliance, then code quality) into Phase 8. Currently Phase 8 has 5 axes verified in one pass (plan coverage, interface drift, SOP, research incorporation, hallucinated deps). Splitting into "spec axis" (1+2+4+5) and "quality axis" (3) with quality only after spec passes mirrors the proven Superpowers pattern and reduces wasted re-verify cycles.

Build (gaps in field, not just Idea-to-Build)

  1. Eval harness — issues-at-verify vs. issues-at-runtime ratio. No competitor has this. Implementing it gives Idea-to-Build a defensible metric story for the commercial pitch. Without it, the "methodology reduces rework" claim is faith-based.

  2. Failure-mode catalog. Operator's proposal §"Research Directions" item 5. Each session's Lessons-Learned feeds methodology versions. This is the BMad bmad-retrospective analog at the methodology level, not the project level. None of the competitors have this — it's both differentiator AND moat.

  3. Operator burden study. Quantitative — time-to-dossier, time-to-context-locked, time-to-frozen-plan, time-to-build-handoff, vs. Superpowers brainstorm-to-plan and BMad analysis-to-implementation. Without this, the methodology is one anecdote (Crawler Factory).

5. Positioning recommendation

Recommendation: Contribute to Superpowers, package the differentiating phases as a separate plugin, defer SaaS.

Reasoning

  1. The genuine differentiators (Phase 4 assumption-research, Phase 6 contract-lock, Phase 8 closed re-verify) are missing from Superpowers. Jesse Vincent's Superpowers explicitly does NOT have these. They are skill-shaped (Markdown + frontmatter), distributable as a separate plugin, and would land cleanly as additions to the Superpowers ecosystem. Submitting them as PRs to obra/superpowers OR as a sibling plugin (idea-to-build published via a separate marketplace) is feasible TODAY.

  2. Competing head-on against Superpowers is a losing motion. Superpowers has multi-platform distribution (Claude Code, Cursor, Codex, OpenCode, Copilot CLI, Gemini CLI), MIT license, sponsorship funding, and Jesse's reputation. Trying to be "Superpowers but better" duplicates the bulk of the system to ship 3 differentiating phases. The 80% overlap of brainstorming ≈ Phase 1+2+3, writing-plans ≈ Phase 7, subagent-driven-development ≈ Phase 9 is not a coincidence — that's the canonical surface of the problem. Idea-to-Build's value is the deltas, not the whole.

  3. Competing head-on against BMad is also a losing motion — BMad has the agent-persona vocabulary baked in, the npm install path, the module ecosystem (TEA, BMGD, CIS), the explicit anti-paywall community stance, and the 34+ workflows. BMad will absorb the assumption-research idea faster than Idea-to-Build can ship a competing methodology.

  4. The open-core SaaS thesis has no precedent in this category and is currently unproven. Two open-core paths exist: (a) HashiCorp/GitLab/Mattermost (sell to enterprises that need SOC2/SAML/audit dashboards on top of OSS); (b) ElasticSearch/MongoDB (sell hosted versions). Neither maps cleanly to "AI agent methodology" — the artifact is Markdown skills, not a runtime platform. The first commercial path that DOES exist is consulting (operator's "Algolia would be the first customer"). Lock that down before betting on a SaaS dashboard.

  5. The "Algolia ships the methodology" claim is the most defensible commercial framing. If Idea-to-Build is the engine that ships Algolia's RC3 Phoenix product family (Crawler Factory + Connector Factory + Transformer + Enricher + Indexer + Agent Set), and the Connector Factory ships faster than the Crawler Factory using the methodology, that's the case study. Then commercialization is consulting + custom packaging, not a generic SaaS.

Proposed go-forward

Tier 1 (now, low cost, high signal): Package Phase 4 (assumption-research) + Phase 6 (contract-lock) + Phase 8 (multi-axis re-verify) as three skills in a sibling Superpowers-compatible plugin (idea-to-build). Submit each as a Superpowers PR in parallel; whichever path is accepted faster wins. Use the Crawler Factory case study as the README evidence.

Tier 2 (next 90 days, medium cost): Build the eval harness (issues-at-verify-vs-runtime ratio) and use it to measure Connector Factory delivery against Crawler Factory baseline. This is the single number that justifies any commercial pitch.

Tier 3 (6+ months, only if Tier 2 numbers hold): Consulting offer to enterprises adopting Claude Code in production. NOT a SaaS dashboard. NOT a paid plugin tier. Consulting is the revenue that doesn't require productizing into a multi-tenant platform.

Defer: the 4-module Plan/Design/Build/Test outer methodology as a distributable repo. That's a real product but it's a Tier 4 ambition. Ship the differentiated skills first; if they get adoption, the outer methodology is a follow-on positioning piece, not the lead.

6. Sources

  • Projects/Vibe-Coded-Product-Methodology/README.md (operator's outer vision)
  • Projects/Crawler-Factory/Idea-to-Build-Skill-Proposal.md (operator's Module 1 proposal)
  • Projects/Algolia-Central/RC3-Phoenix-Product-Family-Vision.md (commercial application context)
  • ~/.claude/plugins/cache/claude-plugins-official/superpowers/5.0.7/README.md
  • ~/.claude/plugins/cache/claude-plugins-official/superpowers/5.0.7/skills/brainstorming/SKILL.md
  • ~/.claude/plugins/cache/claude-plugins-official/superpowers/5.0.7/skills/writing-plans/SKILL.md
  • ~/.claude/plugins/cache/claude-plugins-official/superpowers/5.0.7/skills/subagent-driven-development/SKILL.md
  • ~/.claude/plugins/cache/claude-plugins-official/superpowers/5.0.7/skills/dispatching-parallel-agents/SKILL.md
  • ~/.claude/plugins/cache/claude-plugins-official/superpowers/5.0.7/skills/verification-before-completion/SKILL.md
  • https://github.com/bmad-code-org/BMAD-METHOD (README + AGENTS.md + Contents API tree walk of src/bmm-skills/, src/core-skills/)
  • https://raw.githubusercontent.com/bmad-code-org/BMAD-METHOD/main/src/bmm-skills/2-plan-workflows/bmad-validate-prd/SKILL.md
  • https://raw.githubusercontent.com/bmad-code-org/BMAD-METHOD/main/src/bmm-skills/3-solutioning/bmad-check-implementation-readiness/SKILL.md
  • https://docs.bmad-method.org/tutorials/getting-started/ (BMad workflow stages)
  • https://github.com/github/spec-kit (README)
  • https://cursor.com/docs/context/rules (Cursor rules)

All fetches conducted 2026-04-30.