← ClaudeAtlas

consortlisted

Consort, a spec-first, test-driven agent framework for Lakebase-paired projects: a deterministic orchestrator drives role agents through a spec-first design lane (Spec Driven Development) and a Test Driven Development build lane (RED-GREEN-REFACTOR) that runs against a live copy-on-write branch of a real, governed Lakebase database, composed with paired-branch primitives (cheap experiments, parent-aware schema diff, real per-branch databases). The controls are code the agent cannot edit: gates fail closed, tests are immutable within a unit of work, and a green result is a real test run against real data. Spec-first means the spec is drafted, reviewed, and frozen at gates before any build cycle runs; the spec, the architecture, and the database all evolve increment over increment. Use when planning a new feature, running design-spec gates, running TDD cycles, comparing parallel experiments, or detecting build bad smells. Imports software-design-principles canon. Builds on lakebase-scm-workflows.
databricks-solutions/consort · ★ 14 · AI & Automation · score 70
Install: claude install-skill databricks-solutions/consort
# Consort – agent contract Agent-facing contract: hard rules, phase flow, agent prompt index, and concrete code patterns for the substrate primitives. For the human-facing overview (lexicon, roles narrative, how-to-use prompts, project entry points) see [`README.md`](README.md). ## Hard rules The contract every agent (Navigator, Driver, Orchestrator) and every human collaborator must honor. 1. Tests are immutable until the test list itself is renegotiated through the PO. Never delete or weaken a test to make it pass. 2. "Minimal code" means minimal *honest* code that satisfies the current test list, not just the current test. Use the test list as your horizon. 3. After every GREEN, ask: "would a fresh reader infer the right concept from this API now?" If no, request REFACTOR before the next test. 4. Test at the outermost public boundary that maps to the AC. Inner-loop unit tests are reserved for pure logic that can't be exercised through the outer boundary. 5. A correct refactor should not change the outer-boundary tests. A refactor that requires editing tests is suspect. 6. Never make a private method public to test it. 7. Test count is a lagging indicator. The leading indicator is "how cheap is the next test?" Rising cost = design problem. 8. Spike code is throwaway. Promote nothing from a spike branch into a TDD branch except notes. 9. Experiments are scoped to a story (the branch forks from feature HEAD). N=1 is one experiment per story (iterative refinement, no prom