Development Methodology
Every Buildpad app is built with AI agents following the same engineering loop: discover → specify → plan → implement → review → ship. The loop is not just documentation — it is enforced by the agent skills bundled in every starter, so your AI follows it whether you’re in Kiro, VS Code Copilot, Claude Code, or Antigravity.
This page is the map. The detailed rules for each practice — checklists, red flags, verification gates — live inside the skills themselves in the buildpad-ai/skills repository, where they are versioned together with the agents that execute them.
You rarely need to invoke these skills by name. Agents activate them automatically when your request matches what a skill does; slash commands (type / in chat) are there when you want a stage explicitly.
The Lifecycle
1. Discover & Refine
Turn a vague idea into a concrete, scoped proposal before any planning starts.
| Skill | Role |
|---|---|
| idea-refine | Structured divergent/convergent thinking to turn rough concepts into proposals |
| buildpad-discovery | Decides whether the work needs one spec, several specs, or none at all |
2. Specify
Every non-trivial feature is specified before it is implemented — requirements.md (EARS) → design.md → tasks.md in .kiro/specs/<feature>/, each approved at a review gate. This is the heart of the methodology and has its own page.
| Skill | Role |
|---|---|
| spec-driven-development | The methodology itself: when to spec, DaaS-specific spec rules, review gates |
| buildpad-spec-init → requirements → design → tasks | The staged spec workflow (Kiro users: native Specs instead) |
3. Plan Tasks
Approved specs are decomposed into small, verifiable tasks ordered along DaaS dependency layers — Data → UI → Logic → Relations → Hardening — with acceptance criteria and no task larger than a few hours.
| Skill | Role |
|---|---|
| planning-and-task-breakdown | Decomposition rules, layer ordering, dependency graphs, parallelization |
4. Implement Incrementally
Implementation happens task by task — thin vertical slices that leave the app working after every step, never a big-bang build.
| Skill | Role |
|---|---|
| buildpad-impl | Task-by-task implementation with TDD and per-task review |
| incremental-implementation | Slicing strategy: risk-first delivery aligned to the DaaS layers |
| subagent-delegation | When and how to fan work out to isolated subagents |
| context-engineering | Feeding the agent the right context — specs, skills, MCP, project files |
5. Review & Harden
Nothing merges on the strength of “it seems to work.” Reviews are multi-axis, failures are debugged to root cause, and completion claims require fresh evidence.
| Skill | Role |
|---|---|
| review-code | Multi-axis review: quality, security, performance, a11y, DaaS/Buildpad compliance |
| buildpad-review / buildpad-verify-completion | Per-task spec-conformance review and evidence-based completion checks |
| debugging-and-error-recovery | Root-cause-first debugging when anything fails |
| security-and-hardening | OWASP-aligned boundaries for input, auth, storage, integrations |
| performance-optimization | Core Web Vitals and DaaS/Next.js performance patterns |
| code-simplification | Reducing complexity while preserving behavior |
6. Ship & Document
Work lands through disciplined git flow and leaves documentation behind — both are part of the task, not afterthoughts.
| Skill | Role |
|---|---|
| git-workflow-and-versioning | Feature branches, commit discipline, Amplify CI/CD (pushes to main deploy) |
| create-tests | Playwright E2E and Vitest coverage as first-class tasks |
| generate-docs | API references, component docs, schemas, changelogs |
Principles Behind the Loop
- Specs before code — the cost of fixing a missed requirement in
requirements.mdis a sentence; in deployed code it’s a refactor. - Working software at every step — tasks are small and independently verifiable; the app is never broken for days.
- Buildpad-First — UI is assembled from the Buildpad component catalog before anything custom is written.
- Evidence over claims — “done” means tests pass and behavior is verified, not that the code was written.
- Same loop, every IDE — the artifacts (
.kiro/specs/, skills) are portable across Kiro, Copilot, Claude Code, and Antigravity.
Related
- Specs-Driven Development — the specification workflow in detail
- AI IDE Setup — per-IDE starter setup guides
- buildpad-ai/skills — the canonical skills repository with the full catalog and every practice’s detailed rules