Method · Doc

Method FAQ

FAQ — DARE Method

❓ Frequently asked questions

General

Q: Is DARE a code framework?
No. It's a methodology (markdown + commands + templates). It has no dependencies, build, or runtime. You adopt it by copying files into your project.

Q: Can I use it with any language?
Yes. The method is language-agnostic. What changes are the Validation Gates (pytest for Python, vitest for Node, phpunit for PHP, etc.). Stack-specific skills exist for a few stacks, but you can write one for any of them.

Q: Can I use it with any IDE / agent?
Yes, in theory. Today there are ready-made implementations for Cursor and Antigravity. For others (Claude Code, VS Code, JetBrains), you adapt the files from the Cursor implementation — the method itself is the same.

Q: Is it only for large projects?
No. DARE scales up and down. On a small feature, Design + Architect take 15 min combined. On a 6-month project, it becomes a central process.

Q: Does it replace Scrum / Kanban / agile methodologies?
No — it's orthogonal. DARE operates at the technical task level. Scrum/Kanban operate at the work organization level. They coexist.

Adoption

Q: How do I get started?

  1. Clone the repo
  2. Copy the implementation folder that matches your IDE (implementations/cursor/ or implementations/antigravity/) into your project
  3. Trigger /generate-design "your first idea" and follow the flow

Q: Do I need to adopt everything at once?
No. Gradual path: start with just Design + Review (write DESIGN.md by hand before each feature). Expand the phases as you get comfortable.

Q: Does the whole team need to adopt it?
Ideally yes, but you can start solo. You generate DESIGN/BLUEPRINT and show them to colleagues as a PR artifact. As they see the value, they adopt it.

Q: What if my team doesn't use Cursor / Antigravity?
You can apply it manually: write DESIGN.md, BLUEPRINT.md, TASKS.md in whatever editor you use, and run Validation Gates manually. You lose the automation of the /generate-* commands, but you gain the structure.

Phases

Q: Can I skip the Design phase for quick prototypes?
You can, but know what you're giving up. Without Design, you're doing Vibe Coding — which is fine for a throwaway prototype. If it's going to production later, you'll pay dearly to do Design retroactively.

Q: How long do Design + Architect take?
Average feature: 15-30 min of Design + 5-15 min of Architect (generate) + 5-10 min of Review. Total: 25-55 min before a single line of code is written.

Sounds like a lot? Compare it with the rework time when you discover halfway through implementation that the approach is wrong.

Q: Can the AI skip the Review?
No. Review is exclusively human. If you "approve" without reading, you're fooling yourself — and you'll pay for it in the next phases.

Ralph Loop

Q: Isn't the Ralph Loop the same as TDD?
It has similarities. TDD: a human writes the test, a human writes the code that makes it pass. Ralph Loop: the tests come from the task spec, the AI writes the code that makes them pass. Key difference: authorship. TDD is the human's work; Ralph Loop is the AI's work with the human as monitor.

Q: Can the Ralph Loop get stuck in an infinite loop?
No — implementations set a limit (usually 6 attempts). If it exceeds that, it aborts and flags the human. If you notice 4+ attempts on the same error, intervene manually.

Q: Why "Ralph"?
A reference to Ralph Wiggum from The Simpsons. The joke is that the AI, just like Ralph, persists with confidence even when it's wrong, until it eventually gets it right. More details in the dedicated section.

Costs / Tokens

Q: Does DARE consume more tokens than Vibe Coding?
Yes if you compare line by line. No if you compare per quality feature delivered. Vibe Coding generates rework that multiplies consumption.

Q: Is there a way to measure it?
The Execute phase logs DARE/TELEMETRY.md with tokens, models, and times. Run /telemetry-report at the end of the feature to see the totals.

Q: Will it work with cheap models (Haiku, GPT-4o-mini)?
The Architect and Execute phases are more demanding — Sonnet/Opus perform better. Design can use a cheap model. Telemetry shows the trade-off.

Customization

Q: Can I change the 4 stages?
You can adapt commands / templates / skills. If you change the structure of the 4 phases, it stops being DARE — it becomes another methodology. That's fine, but don't call it DARE.

Q: Can I add more phases?
Not recommended. The 4 stages were designed to be the minimum viable set. Adding more increases friction without proportional gain. If you feel the need, ask: is the new phase generalizable to other projects? If so, open an issue/PR to discuss it.

Q: Can I have custom skills?
Yes — that's the primary adaptation mechanism. Create skill-<your-stack>.mdc (Cursor) or <your-stack>/SKILL.md (Antigravity) with your project's/company's conventions. The AI will apply them.

Team / collaboration

Q: How do I review a colleague's PR using DARE?
Look at 3 things in order: (1) does the DESIGN.md make sense? (2) does the BLUEPRINT.md satisfy the Design? (3) does the delivered code execute the BLUEPRINT? If all 3 line up, the PR is well-founded. Disagreements are resolved in these artifacts, not in the code directly.

Q: Where do DESIGN.md and BLUEPRINT.md live? Committed?
Yes. Committed to the repo. DARE/ is versioned. It's the feature's "dossier" so anyone joining the project can understand the reasoning behind decisions.

Q: And when it becomes obsolete documentation?
Update it alongside significant changes. If it turns into a drastically different feature, create new DESIGN/BLUEPRINT in a separate folder (e.g. DARE/v2/), preserving history.

Differences from other practices

Q: Does DARE replace code review?
No. Code review still happens on the final PR. DARE just brings forward part of the review to the Blueprint (before the code is written).

Q: Does DARE replace RFC / ADR?
Partially. The BLUEPRINT contains implicit ADRs. You can externalize them to docs/adrs/ if you prefer, but it's not required.

Q: Can I use it with TDD?
Yes. TDD operates inside the Execute phase: you write tests in the task spec, and the Ralph Loop ensures they pass. A very good combination.

Q: Can I use it with BDD?
Yes. BDD scenarios can be inputs to DESIGN.md. The "Given/When/Then" fits into the success criteria.

❓ Not answered here?

Open a discussion on GitHub. We'll add it here if it's useful to others.

🔗 Related topics