Busabase × AWS KiroKnowledge base for Kiro
Kiro can turn an idea into requirements, design, and executable tasks. Busabase keeps the stakeholder decisions around that spec reviewable, owned, and traceable after implementation crosses teams and repositories.
Three spec artifacts
Kiro formalizes implementation. Keep that work in the repository.
A Kiro Feature Spec creates requirements.md, design.md, and tasks.md. Requirements capture user stories and acceptance criteria; design describes architecture; tasks drive implementation. Kiro recommends version-controlling specs beside the code they describe.
requirements.mdBehavior
User stories, constraints, and acceptance criteria
design.mdApproach
Architecture, data flow, errors, and test strategy
tasks.mdExecution
Discrete work, dependencies, and completion state
A separate ownership layer
A product commitment is wider than one repository spec.
A repository should own the technical artifact. Busabase becomes useful when the same requirement affects product planning, customer commitments, compliance, support readiness, or several repositories. Link the spec; do not paste a second editable copy.
| Information | Home | Owner |
|---|---|---|
| Coding standard or project context | .kiro/steering/ or AGENTS.md | Repository |
| Feature requirements, design, tasks | .kiro/specs// | Repository |
| Code change and tests | Commit / Pull Request | Git provider |
| Cross-team requirement and acceptance decision | Structured record + Change Request | Busabase |
Traceability chain
Connect the original need to the evidence that proves it shipped.
The chain should survive refinement. If Kiro changes a design or synchronizes tasks after requirements move, the business record still points to the accepted requirement version, implementation evidence, and final owner.
Change impact
When a spec moves, show who else must make a decision.
Kiro can refine requirements and regenerate design or task files. That does not automatically resolve effects outside the repository. A small impact matrix turns a spec edit into an explicit review queue.
Acceptance register
Store the decision around the spec in fields the next workflow can query.
The record links to Kiro's files and Git evidence. It does not compete with them. These fields are enough to answer what was accepted, which version, by whom, and under which conditions.
| Field | Purpose |
|---|---|
| requirement_id | Stable identifier shared with the Kiro spec |
| spec_url | Versioned link to requirements, design, and tasks |
| accepted_behavior | Business-level outcome that must remain true |
| implementation_ref | Pull Request, commit, build, or deployment |
| verification | Test result and runtime evidence |
| decision | Proposed, accepted, conditional, rejected, or superseded |
| owner | Person accountable for acceptance |
| effective_at | When dependent teams may act on the decision |
Automation has a narrower job
Hooks can enforce checks. They cannot supply stakeholder acceptance.
Kiro Hooks can run shell commands or agent prompts on lifecycle events. PreToolUse and PreTaskExecution can block, while PostFileSave or Agent Stop can collect results. Use them to produce evidence or open a proposal, then keep the business decision in a separate review.
PostFileSaveEvidenceRun lint, type checks, or targeted tests
PreTaskExecutionExecution gateBlock work when required inputs are missing
Agent Stop + confirmProposal triggerAsk whether to submit session results
Busabase reviewCanonical decisionEvaluate scope, evidence, owner, and impact
Refinement without drift
Change the spec once, then update the acceptance link deliberately.
Kiro Specs support continuous refinement and task synchronization. Use versioned Git references so a later record never points ambiguously at moving branch content. If an accepted requirement changes materially, propose a superseding decision rather than overwriting history.
Connection boundary
Let the knowledge page define ownership; let the connection page handle MCP.
Kiro shares .kiro configuration across IDE, CLI, Web, and Mobile, with surface-specific behavior. Its workspace or user MCP configuration can point to Busabase. Follow the maintained connection page for the endpoint, OAuth, scope precedence, and verification steps.
Questions from spec-driven teams
Kiro knowledge base FAQ
Does Busabase replace Kiro Specs?
No. requirements.md, design.md, and tasks.md should stay version-controlled beside the code. Busabase records cross-team requirements, acceptance decisions, owners, and operational state that need a wider system of record.
Should every spec create a Busabase record?
No. Use a record when another team, repository, customer commitment, control, or release process depends on the outcome. Purely local implementation detail can remain in the spec and Git history.
Can a Kiro Hook approve a requirement automatically?
A Hook can run a check, block an action, or trigger a proposal. It cannot establish that a stakeholder accepted the business consequence. Keep that decision with the named owner.
What is the stable link between systems?
Use a requirement_id plus a versioned spec_url or commit SHA. Avoid linking only to a mutable branch view when later reviewers need to know exactly what was accepted.
Can Quick Spec use the same workflow?
Yes, but Kiro describes Quick Spec as generating all artifacts without the standard phase review gates. For high-impact work, add explicit requirement analysis and acceptance review before treating the result as committed scope.
Start at the next acceptance point
Give one Kiro spec an owner outside the repository.
Choose a feature that crosses team boundaries, link its current spec and evidence, and review the first acceptance decision before dependent work moves forward.