sbce

Name: sbce
Author: AdamBien

40stars10forks

How to install sbce?

adambien/airails/sbce

$npx -y skills add AdamBien/airails --skill sbce

Installs into the current project.

Summary

Spec-driven BCE workflow where one capability spec equals one business component (same name) and the spec is the boundary contract. Invoked as /sbce new|apply <capability-or-feature> (or by intent), it drives declare → converge; the stack's own test loop is the oracle for "done

Files · 1

View on GitHub

SKILL.md

1	Drive the spec-driven BCE workflow — one skill owns both the rules and the steps. Invoke as
2	`/sbce <mode> <capability>` (`new` or `apply`), or let it trigger from intent. Apply every rule
3	strictly.
4
5	## Guiding principles
6
7	- The spec is the boundary contract — what the boundary promises, never how.
8	- The spec lives in the BC's package doc — `package-info.java` (Java, `///` Markdown) or `package-info.md` (web) — co-located with the code it governs. There is no separate `specs/` tree and no hand-typed package coordinate. In Java the `///` doc renders via `javadoc`, so the same file is source-of-truth and published contract.
9	- One capability spec ≡ one business component, named the same. No translation between "what" and "where".
10	- The task list is the gap, read off `spec` vs `BC` on demand — never a hand-maintained tasks file.
11	- One spec per capability, the single source of truth — never diff or merge two specs.
12	- Split by determinism: tooling runs tests and places the BC; this skill writes the spec, the code, and closes the gap.
13	- "Done" is a green run of the stack's test loop — never your own opinion.
14
15	## Spec ↔ BC mapping
16
17	The BC name is the only identity — a single lowercase token (`checkout`), never a dotted path
18	or a `bc`/`capability` field. The stack skill owns where it lands:
19
20	```
21	checkout # BC name == the only identity
22	spec = package doc, co-located with code:
23	Java: src/main/java/<base>/checkout/package-info.java # `///` Markdown (JEP 467)
24	web: app/src/checkout/package-info.md # Markdown
25	code = same folder, {boundary,control,entity}/ # stack skill places it
26	```
27
28	- `## Boundary` op ↔ one `boundary` entry-point method.
29	- `## Requirements` (EARS) ↔ behaviour and the tests covering it.
30	- `## Entities` ↔ the `entity` layer.
31
32	## System doc (base package)
33
34	An optional doc one altitude up — the base package's `package-info.java` /
35	`app/src/package-info.md` — for concerns that span BCs and have no other home. Add a section
36	only when a real cross-BC concern appears; a one-BC system needs none. Author from
37	`references/system-doc-template.md`.
38
39	- Charter — one sentence for the whole assembly.
40	- Vision (optional) — one aspirational sentence: the outcome the assembly chases. Rationale, not contract — no `Sn`, no test; the single non-verifiable line in the doc, and the deliberate exception to the traceability invariant. May be proposed by `/sbce new` distilling a README seed (human accepts/edits).
41	- Components — this system's concrete wiring: which BC may call which, which integration events cross boundaries (`/bce` owns the generic layering; this owns the concrete dependencies).
42	- System invariants — cross-cutting EARS `shall` statements (id `Sn`) no single BC owns.
43	- Ubiquitous language — shared domain nouns defined once, so each BC's `## Entities` stays terse.
44	- Stack — the composed stack skill + package base, so `apply` reads it instead of re-inferring.
45
46	Never duplicate a BC's one-liner — a hand-typed BC index drifts; the gap is read, not stored. For
47	a BC map, mark it generated and regenerate it from the per-BC docs.
48
49	## Top-level README (optional projection)
50
51	An optional repo-root `README.md` — a human on-ramp that is a **projection of the specs, not a
52	source of truth**. Author from `references/readme-template.md`. Two slices, handled oppositely:
53
54	- Generated (never hand-edited) — the system doc's Charter + Vision, a BC map (each BC name, its `>` one-liner, a link to its `package-info`), and a Mermaid diagram of the declared `## Components` wiring, fenced by `<!-- sbce:generated:start -->` / `<!-- sbce:generated:end -->`.
55	- Hand-maintained (outside the markers, since no spec covers it — so it can't drift): `## Conventions`, build/run/test delegated to the stack skill, plus free-form meta (license, links, motivation).
56
57	- Doubles as the inception seed. The hand-written prose outside the markers is what `/sbce new` (no argument) reads to bootstrap vision + specs (see `new`); SBC

People who liked this also viewed

6 picks

Type

sbce

40stars10forks

View on GitHub

How to install sbce?

adambien/airails/sbce

$npx -y skills add AdamBien/airails --skill sbce

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	Drive the spec-driven BCE workflow — one skill owns both the rules and the steps. Invoke as
2	`/sbce <mode> <capability>` (`new` or `apply`), or let it trigger from intent. Apply every rule
3	strictly.
4
5	## Guiding principles
6
7	- The spec is the boundary contract — what the boundary promises, never how.
8	- The spec lives in the BC's package doc — `package-info.java` (Java, `///` Markdown) or `package-info.md` (web) — co-located with the code it governs. There is no separate `specs/` tree and no hand-typed package coordinate. In Java the `///` doc renders via `javadoc`, so the same file is source-of-truth and published contract.
9	- One capability spec ≡ one business component, named the same. No translation between "what" and "where".
10	- The task list is the gap, read off `spec` vs `BC` on demand — never a hand-maintained tasks file.
11	- One spec per capability, the single source of truth — never diff or merge two specs.
12	- Split by determinism: tooling runs tests and places the BC; this skill writes the spec, the code, and closes the gap.
13	- "Done" is a green run of the stack's test loop — never your own opinion.
14
15	## Spec ↔ BC mapping
16
17	The BC name is the only identity — a single lowercase token (`checkout`), never a dotted path
18	or a `bc`/`capability` field. The stack skill owns where it lands:
19
20	```
21	checkout # BC name == the only identity
22	spec = package doc, co-located with code:
23	Java: src/main/java/<base>/checkout/package-info.java # `///` Markdown (JEP 467)
24	web: app/src/checkout/package-info.md # Markdown
25	code = same folder, {boundary,control,entity}/ # stack skill places it
26	```
27
28	- `## Boundary` op ↔ one `boundary` entry-point method.
29	- `## Requirements` (EARS) ↔ behaviour and the tests covering it.
30	- `## Entities` ↔ the `entity` layer.
31
32	## System doc (base package)
33
34	An optional doc one altitude up — the base package's `package-info.java` /
35	`app/src/package-info.md` — for concerns that span BCs and have no other home. Add a section
36	only when a real cross-BC concern appears; a one-BC system needs none. Author from
37	`references/system-doc-template.md`.
38
39	- Charter — one sentence for the whole assembly.
40	- Vision (optional) — one aspirational sentence: the outcome the assembly chases. Rationale, not contract — no `Sn`, no test; the single non-verifiable line in the doc, and the deliberate exception to the traceability invariant. May be proposed by `/sbce new` distilling a README seed (human accepts/edits).
41	- Components — this system's concrete wiring: which BC may call which, which integration events cross boundaries (`/bce` owns the generic layering; this owns the concrete dependencies).
42	- System invariants — cross-cutting EARS `shall` statements (id `Sn`) no single BC owns.
43	- Ubiquitous language — shared domain nouns defined once, so each BC's `## Entities` stays terse.
44	- Stack — the composed stack skill + package base, so `apply` reads it instead of re-inferring.
45
46	Never duplicate a BC's one-liner — a hand-typed BC index drifts; the gap is read, not stored. For
47	a BC map, mark it generated and regenerate it from the per-BC docs.
48
49	## Top-level README (optional projection)
50
51	An optional repo-root `README.md` — a human on-ramp that is a **projection of the specs, not a
52	source of truth**. Author from `references/readme-template.md`. Two slices, handled oppositely:
53
54	- Generated (never hand-edited) — the system doc's Charter + Vision, a BC map (each BC name, its `>` one-liner, a link to its `package-info`), and a Mermaid diagram of the declared `## Components` wiring, fenced by `<!-- sbce:generated:start -->` / `<!-- sbce:generated:end -->`.
55	- Hand-maintained (outside the markers, since no spec covers it — so it can't drift): `## Conventions`, build/run/test delegated to the stack skill, plus free-form meta (license, links, motivation).
56
57	- Doubles as the inception seed. The hand-written prose outside the markers is what `/sbce new` (no argument) reads to bootstrap vision + specs (see `new`); SBC

People who liked this also viewed

6 picks

Type