aibdd-kickoff

Initialize AIBDD projects by collecting Q1–Q4 decisions and generating boundary-aware artifacts.

77|15|Updated May 12, 2026
One-click install
npx skills add https://github.com/Waterball-Software-Academy/aixbdd --skill aibdd-kickoff-waterball-software-academy
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: aibdd-kickoff
Source: https://github.com/Waterball-Software-Academy/aixbdd/tree/main/.agents/skills/aibdd-kickoff
Command: npx skills add https://github.com/Waterball-Software-Academy/aixbdd --skill aibdd-kickoff-waterball-software-academy

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill requires python3, subprocess, shutil, and includes scripts (resource) and assets (resource) components.

What problem does it solve?

Converts raw project kickoff intent into a boundary-aware AIBDD starter that prevents ambiguous specs and reduces downstream rework.

Core Features & Use Cases

  • Stack-aware project initialization (Python E2E / Java E2E / Next.js Playwright): derives the correct skeleton and per-stack configuration bindings.
  • One-shot, file-first decision capture (Q1–Q4): collects stack, spec language, service/TLB id, and codebase layout into a single KICKOFF_PLAN.md SSOT.
  • Boundary truth skeleton generation: creates boundary.yml and updates architecture artifacts, including a seeded shared DSL at specs/shared/dsl.yml.
  • Deterministic layout via tooling: runs kickoff_layout.py to copy the shared template tree and materialize the shared DSL.

Quick Start

Ask the AI to run aibdd-kickoff and answer the four kickoff questions to generate arguments.yml, boundary.yml, component-diagram.class.mmd, and specs/shared/dsl.yml in your project.

Frequently Asked Questions about aibdd-kickoff

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I initialize a project kickoff with acceptance criteria and boundary skeletons?

To initialize a project kickoff with acceptance criteria, you collect stack-aware decisions into a single KICKOFF_PLAN.md file, then execute a layout script to generate boundary-aware truth artifacts like boundary.yml and a shared DSL.

What is file-first spec capture and how does it prevent ambiguous project requirements?

File-first spec capture records stack, spec language, and codebase layout decisions into a single source of truth file, preventing ambiguous project requirements by ensuring all downstream development references deterministic, boundary-aware artifacts.

Can I use this project kickoff initialization for Python E2E and Next.js Playwright stacks?

Yes, this project kickoff initialization supports Python E2E, Java E2E, and Next.js Playwright stacks, deriving the correct skeleton and applying per-stack configuration bindings to the generated boundary truth artifacts.

How do I generate a boundary.yml and shared DSL from a kickoff plan?

You generate boundary.yml and a shared DSL by running the kickoff layout script, which copies the shared template tree, seeds specs/shared/dsl.yml, and appends per-stack tail configurations based on your kickoff decisions.

Do I need Python3 installed to run the project layout script and seed the DSL?

Yes, you need Python3 installed to run the project layout script, as the deterministic layout tooling relies on Python3 and its subprocess and shutil modules to copy template trees and seed the DSL file.

What's the best way to capture Q1 to Q4 kickoff decisions for a new codebase?

The best way to capture Q1 to Q4 kickoff decisions is through an interactive file-first process that records stack, spec language, service id, and codebase layout directly into a KICKOFF_PLAN.md single source of truth.