[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"project-80059":3},{"id":4,"name":5,"fullName":6,"owner":7,"repo":5,"description":8,"homepage":9,"htmlUrl":10,"language":11,"languages":10,"totalLinesOfCode":10,"stars":12,"forks":13,"watchers":14,"openIssues":15,"contributorsCount":16,"subscribersCount":16,"size":16,"stars1d":16,"stars7d":15,"stars30d":17,"stars90d":16,"forks30d":16,"starsTrendScore":16,"compositeScore":18,"rankGlobal":10,"rankLanguage":10,"license":19,"archived":20,"fork":20,"defaultBranch":21,"hasWiki":22,"hasPages":20,"topics":23,"createdAt":10,"pushedAt":10,"updatedAt":30,"readmeContent":31,"aiSummary":32,"trendingCount":16,"starSnapshotCount":16,"syncStatus":14,"lastSyncTime":33,"discoverSource":34},80059,"aixbdd","Waterball-Software-Academy\u002Faixbdd","Waterball-Software-Academy","（此專案還在研發封測中，功能尚未完善，請先純粹觀摩就好。）AlxBDD turns product iterations into flowcharts, Gherkin, coverage-oriented test plans, and RED->GREEN->REFACTOR behavior-driven one-shot development harness with faithful reasoning and built-in reconciliation for requirement changes.","",null,"Python",68,11,2,1,0,6,3.24,"Apache License 2.0",false,"main",true,[24,25,26,27,28,29],"ai-development","aibdd","bdd","sdd","software-engineering","tdd","2026-06-12 02:03:57","# AIBDD\n\n> Most AI coding workflows fail in the same place: the agent starts writing code before the system has a real spec.\n\nAIBDD is built to fix that.\n\nAIBDD turns raw product intent into boundary-aware discovery, executable acceptance criteria, implementation tasks, and disciplined `RED -> GREEN -> REFACTOR` execution. Instead of asking an agent to guess from a paragraph and good intentions, it gives the agent a chain of explicit artifacts, each with one job, one owner, and one way to prove it is correct.\n\nThis is not vibe coding with better prompts.\n\nThis is acceptance-driven software delivery with specs as truth.\n\nThis repository is the workflow SSOT for that system. It contains the AIBDD skill family that moves a project from kickoff to discovery, planning, task generation, implementation, evaluation, and reconciliation.\n\n## Why AIBDD Hits Hard\n\nMost teams already know AI can write code. That is not the hard part anymore.\n\nThe hard part is getting the right code, in the right boundary, with the right acceptance target, without silently dropping requirements or smearing one change across the whole system. That is where AIBDD is strong.\n\nIt gives you:\n\n- **Specs as truth**: artifacts are not passive documentation. They are versioned, executable, and downstream-visible.\n- **Specs as guard**: implementation is judged against acceptance artifacts, not against \"looks done to me.\"\n- **Separation of concerns**: activity, feature rules, technical plan, DSL, and tasks each own a precise slice of truth.\n- **Traceability end to end**: intent can be followed into flow, flow into acceptance, acceptance into tasks, and tasks into execution.\n- **Human control without chaos**: the workflow is human-in-the-loop, but not human-do-everything.\n- **Less guessing, more asking**: when information is missing, the system is designed to clarify instead of hallucinate.\n- **Reconcile instead of rot**: when upstream requirements change, AIBDD cascades the correction from the earliest affected planner instead of letting downstream artifacts silently rot.\n\nIf ordinary AI coding feels magical right up until it becomes expensive, flaky, and hard to trust, AIBDD is the counter-move.\n\n## Who This Is For\n\n- **Founders and product builders** who want AI to build from acceptance truth, not from ambiguous feature blur.\n- **Tech leads and architects** who need boundary-aware planning, auditable handoffs, and fewer accidental cross-layer leaks.\n- **PMs, BAs, and spec owners** who want a workflow where business intent survives contact with implementation.\n- **Teams already using AI coding agents** but tired of reruns, shallow fixes, and \"green\" outputs that were never truly grounded.\n\n## Skill Layout\n\nThe canonical skill tree lives at `.agents\u002Fskills\u002F` (Agent Skills standard). `.claude\u002Fskills` is a symlink that points to it, so Claude Code and Codex both load the same files without duplication.\n\n**Windows users:** Git does not create symlinks by default on Windows. Before cloning, enable symlink support so `.claude\u002Fskills` resolves correctly:\n\n```bash\n# One-time, global\ngit config --global core.symlinks true\n\n# Or per-clone\ngit clone -c core.symlinks=true \u003Crepo-url>\n```\n\n## Quick Start\n\n1. Run `\u002Faibdd-kickoff` (Pick the tech-stack, full-loaded with aibdd configuration)\n2. Run `\u002Faibdd-discovery` (Address what you wanna build)\n3. Run `\u002Faibdd-plan` (No arguments needed)\n4. Run `\u002Faibdd-tasks`  (No arguments needed)\n5. Run `\u002Faibdd-implement`  (No arguments needed)\n6. Run `\u002Faibdd-red-execute`, then `\u002Faibdd-green-execute`, then `\u002Faibdd-refactor-execute`\n7. When reality changes, use `\u002Faibdd-reconcile`\n\nStop there. You will know very quickly whether you want agents guessing, or agents executing against acceptance truth.\n\n## See It Work\n\n```text\nYou:    We need refund handling for cancelled orders, with inventory return,\n        approval rules, and audit visibility.\n\nYou:    \u002Faibdd-discovery\nAIBDD:  [sources the raw idea against boundary truth]\n        [asks only the missing questions]\n        [writes activity artifacts and feature-rule skeletons]\n\nYou:    \u002Faibdd-plan\nAIBDD:  [locks technical boundary truth]\n        [maps implementation structure and DSL truth]\n        [records impacted feature scope]\n\nYou:    \u002Faibdd-tasks\nAIBDD:  [renders execution-ready tasks from accepted planning truth]\n\nYou:    \u002Faibdd-implement\nAIBDD:  [turns every checkbox into live tracked execution]\n\nYou:    \u002Faibdd-red-execute\nAIBDD:  [creates legal red from runtime-visible steps]\n\nYou:    \u002Faibdd-green-execute\nAIBDD:  [edits product code until acceptance passes]\n\nYou:    \u002Faibdd-refactor-execute\nAIBDD:  [improves structure without losing green]\n\nYou:    The requirement changed.\nYou:    \u002Faibdd-reconcile\nAIBDD:  [cascades from the earliest affected planner instead of patching chaos]\n```\n\nThat is not a clever prompt chain.\n\nThat is a spec pipeline.\n\n## The Pipeline\n\nAIBDD is a process, not a bag of commands. The skills run in the order software should be made:\n\n**Clarify -> Discover -> Plan -> Derive Acceptance -> Execute -> Evaluate -> Reconcile**\n\nEach stage feeds the next. Discovery writes the artifacts plan consumes. Plan records the DSL and feature scope that tasks and the red gate consume. Tasks become live execution. Execution is evaluated through red, green, and refactor gates. When something changes upstream, reconcile cascades the correction from the earliest affected planner so you do not have to fake consistency by hand.\n\n| Skill | Your specialist | What it does |\n|---|---|---|\n| `\u002Faibdd-kickoff` | **Project initializer** | Binds the project context, stack-aware config, boundary skeleton, and core AIBDD paths so the rest of the pipeline has a real starting point. |\n| `\u002Fclarify-loop` | **Clarification router** | Collects missing information in a controlled, file-first way instead of letting agents improvise around ambiguity. |\n| `\u002Faibdd-discovery` | **Root planner** | Turns raw ideas into boundary-aware discovery truth, sourcing reports, activity intent, and feature-rule skeletons. |\n| `\u002Faibdd-form-activity` | **Flow formulator** | Writes `.activity` DSL from discovery output and validates the syntax so flow truth is explicit and machine-usable. |\n| `\u002Faibdd-plan` | **Technical planner** | Converts accepted discovery truth into technical boundary truth, implementation planning, and red-usable DSL mappings without creating shadow truth. |\n| `\u002Faibdd-form-api-spec`, `\u002Faibdd-form-entity-spec`, `\u002Faibdd-form-story-spec` | **Contract formulators** | Translate the planner's reasoning package into the boundary's declared contract format — OpenAPI, DBML, or Storybook CSF3 + component. Delegated by plan; they format truth, they do not decide scope. |\n| `\u002Faibdd-tasks` | **Task graph builder** | Generates structured `tasks.md` from the accepted plan package, preserving implementation topology and execution order. |\n| `\u002Faibdd-implement` | **Execution driver** | Turns every checkbox into a live todo item and keeps task state synchronized with actual execution. |\n| `\u002Faibdd-spec-by-example-analyze` | **Example & step mapper** | Turns feature rules into concrete Examples and maps every Scenario step to legal DSL, so the red gate can render runtime-visible steps with no guessing. |\n| `\u002Faibdd-red-execute` + `\u002Faibdd-red-evaluate` | **Red gate** | Ensures your failing acceptance state is legal, visible, and grounded before code changes begin. |\n| `\u002Faibdd-green-execute` + `\u002Faibdd-green-evaluate` | **Green gate** | Drives product code to passing acceptance without letting fake green or hollow fixes slip through. |\n| `\u002Faibdd-refactor-execute` + `\u002Faibdd-refactor-evaluate` | **Refactor gate** | Improves internal structure while preserving strict acceptance and constitution conformance. |\n| `\u002Faibdd-reconcile` | **Change cascade manager** | Repairs upstream truth from the earliest affected planner and propagates the correction forward. |\n\n## Why This Workflow Wins\n\n### 1. It reduces cognitive load\n\nAIBDD does not dump every concern into one giant prompt. Flow truth, rule truth, plan truth, DSL truth, and acceptance truth are separated on purpose. That means less context soup, faster review, and fewer invisible contradictions.\n\n### 2. It increases trust\n\nThe workflow is built to ask when it does not know. Clarification is a feature, not a failure. Red and green are evaluated, not declared. That makes the output easier to trust because the system is designed to expose uncertainty early.\n\n### 3. It keeps humans in control\n\nThis is not \"press one button and hope.\" AIBDD is human-in-the-loop, but the loop is structured. People decide the truth. The system propagates it, checks it, and executes against it.\n\n### 4. It preserves traceability\n\nThe chain from requirement to execution stays visible:\n\n`idea -> discovery -> activity \u002F feature rules -> plan (DSL + feature scope) -> tasks -> red\u002Fgreen\u002Frefactor`\n\nThat matters when you need audits, debugging, impact analysis, or simply a clean answer to \"why did we build it this way?\"\n\n### 5. It makes other agents better\n\nAIBDD is not trying to replace every coding agent. It makes coding agents more effective by feeding them sharper specs, clearer acceptance targets, and narrower execution scopes.\n\nIn other words:\n\nSpend effort once on precise truth, and every downstream agent gets more accurate.\n\n## What Makes This Repo Valuable\n\nThis repository is not just a document set. It is the workflow contract for a spec-driven software factory.\n\nIt captures:\n\n- the planning phases,\n- the artifact boundaries,\n- the handoff rules,\n- the quality gates,\n- the rollback model,\n- and the execution discipline that keeps the whole thing coherent.\n\nIf you care about shipping software with AI and still being able to explain, audit, debug, and trust what happened, this is the kind of workflow that scales.\n\n## Bottom Line\n\nAI can already write a lot of code.\n\nWhat most teams still do not have is a reliable way to turn intent into acceptance truth, and acceptance truth into shipped systems, without losing clarity in the middle.\n\nAIBDD is built for that gap.\n\nBuild the spec.\nLock the acceptance target.\nDrive execution from truth.\nShip with fewer guesses.\n\n## License\n\nThis repository is licensed under the [Apache License 2.0](LICENSE). See [`NOTICE`](NOTICE) for attribution.\n","AIBDD项目旨在将产品迭代转化为流程图、Gherkin脚本、面向覆盖率的测试计划，并支持行为驱动的一次性开发，同时具备忠实推理和内置的需求变更协调功能。其核心在于通过明确的可执行规范而非模糊的产品意图来指导AI编码，确保代码在正确的边界内实现并满足具体的验收标准。技术上，AIBDD利用Python构建了一个从项目启动到发现、规划、任务生成、实施、评估及需求变更协调的全流程工作流系统。该项目特别适合初创公司创始人、产品经理和技术领导者使用，以提高软件交付过程中的透明度、可追溯性和一致性，减少因需求理解偏差导致的开发成本增加问题。","2026-06-11 03:59:04","CREATED_QUERY"]