ScrumIA

why this exists

About

Where ScrumIA comes from, the premise it runs on, and what it deliberately leaves for you to decide.

Origin

ScrumIA comes out of six months building with Claude Code and BMAD, on personal projects. It is maintained by tibs245.

BMAD supplied the foundations that are still here: a modular base, versioned installs, and tooling kept separate from the projects that consume it.

Starting premise

There is no single right way to run a project with an AI. What works on a five-app monorepo doesn't work on a personal script; what suits a regulated team doesn't suit a weekend prototype.

A method that answers every question at once has to be taken whole or left. In practice it gets taken, adapted, drifts, and ends as a fork that stops receiving updates.

ScrumIA separates the questions and gives each one a replaceable module. The reusable part is the composition, not the answers put into it.

What this does not claim

Each of those is a choice made for a context, documented with its alternatives in the architecture decision records. A module-level decision is contested by writing another module, not by arguing about this one.

Status

ItemState
Architecture and decisionsSettled — 14 ADRs
Twelve modules, 33 skillsFunctional, validated, loaded
Implementation modules (Rust, SolidJS)Built, with audit skills
Cross-cutting modules (TDD, SOLID)Built — reference, audit, refactor
Design moduleBuilt — shipping the redesigned site
Real-project useNot yet — a pilot is next
Rules hierarchy (ADR-0011)Adopted — modules restructured
The real test of the architecture

As long as a single module fills a slot, nothing proves that slot is genuinely replaceable. Writing a second tracker module — even a minimal file-based one — would tell us more than adding another implementation module.

Licence

MIT. Fork it, strip it down, replace the modules that don't suit you.