Omar SobhandClaude Opus 5
4358964c05
55 of 85 role skill bindings pointed at skills that were never authored,
so 10 of 11 team templates bound a smaller context bundle than their role
prompts assumed. Three roles bound nothing at all (gpu.bench_engineer,
threejs.shader_author, threejs.perf_engineer) while their prompts described
procedures they had no way to read.
The loader comment at team_template_loader.rs:167 already diagnosed this —
snake_case slugs in TOML against kebab-case skill files — and it was
half-fixed: the kebab names were corrected, the snake_case ones left.
It was invisible because both existing tests assert authored ⊆ referenced
(30/30, green) and the second explicitly declines to check the other
direction. So the failing half was the half nobody asserted.
Resolved every name by one of three explicit choices:
- 23 skills authored where the role genuinely needed the procedure
(gpu, threejs, research, analysis, frontend, mobile, backend, platform)
- renames onto authored skills where one existed in substance, including
the four-near-duplicate cases that collapse onto one real skill
- 22 aspirational references deleted — a binding an agent cannot read is
a promise, not a capability
Two tests now hold it. The unit test checks referenced ⊆ authored against
the files. The new integration test runs both loaders in boot order and
asserts the bindings survive the trip through the database, which is a
different question: resolution goes through skills_catalog rows, so a skill
file that exists but fails to ingest still leaves the role empty.
Negative controls: the unit test failed naming all 55; the integration test
fails naming the exact role when one name is reverted.
threejs.shader_author and .perf_engineer gained a second and third skill
after the collapse — pin_in_context pins idx < 2, so a role left with one
skill silently pins less than the policy intends.
Co-Authored-By: Claude Opus 5 <[email protected]>
133 lines
4.6 KiB
TOML
133 lines
4.6 KiB
TOML
key = "rust_sdlc"
|
|
name = "Rust SDLC"
|
|
description = "Full software lifecycle for Rust projects — planning, implementation, testing, review, commit. Deep systems + distributed + enterprise backend expertise."
|
|
stack = ["rust", "systems", "distributed", "backend"]
|
|
default_topology = "pipeline"
|
|
risk_profile = "coding_readwrite"
|
|
mcp_bundles = ["clawmates_door", "gitea_forge"]
|
|
version = 1
|
|
|
|
[[roles]]
|
|
slot = "planner"
|
|
order_idx = 0
|
|
skills = ["decompose-int-items", "small-focused-commits"]
|
|
system_prompt = """
|
|
You are the PLANNER of a Rust SDLC team.
|
|
|
|
Read the mission's roadmap or research artifact. Decompose the next
|
|
unconsumed unit of work into concrete INT-XX items with clear acceptance
|
|
criteria. Estimate effort. Hand off to the coder with:
|
|
- a specific INT id and title
|
|
- the files most likely to change
|
|
- explicit test coverage requirements (≥90%)
|
|
- any invariants that must not break
|
|
|
|
Emit `TASK: INT-<NN> — <title>` on its own line when you begin a new item,
|
|
and `PLAN_COMPLETE: INT-<NN>` when the plan is fully specified.
|
|
"""
|
|
brain_seed = """
|
|
# Planner memory seed — Rust SDLC
|
|
|
|
## Decomposition heuristics
|
|
- Every INT item should be small enough that one coder can finish in
|
|
under 2 hours of focused work.
|
|
- If an INT touches more than 5 files, split it.
|
|
- Prefer refactor-then-feature over feature-with-refactor.
|
|
|
|
## Acceptance criteria checklist
|
|
- Behavior described in observable terms (input → output)
|
|
- Coverage bar named (usually ≥90% for changed lines)
|
|
- Backwards-compat expectations stated
|
|
"""
|
|
|
|
[[roles]]
|
|
slot = "coder"
|
|
order_idx = 1
|
|
skills = ["write-rust-current-edition", "cargo-test-driven-development", "workspace-repo-commit-protocol", "small-focused-commits", "int-xx-marker-protocol", "rust-error-handling", "rust-async-tokio-idioms", "react-19-server-components"]
|
|
system_prompt = """
|
|
You are the CODER of a Rust SDLC team.
|
|
|
|
Your working directory is /workspace/repo. All edits happen there.
|
|
Follow the PLANNER's INT-XX brief:
|
|
- implement the change end-to-end
|
|
- keep files under 1500 LOC (see mission config)
|
|
- run `cargo build` after each significant change; abort the turn if
|
|
it doesn't compile
|
|
- hand off to the TESTER with:
|
|
- the file list you touched
|
|
- the specific `cargo test` invocation to prove correctness
|
|
- any risks worth double-checking
|
|
|
|
Emit `WORK: INT-<NN>` when you start, `HANDOFF: INT-<NN>` when done.
|
|
"""
|
|
brain_seed = """
|
|
# Coder memory seed — Rust SDLC
|
|
|
|
## House Rust style
|
|
- 2024 edition, MSRV 1.98.0+
|
|
- prefer `let-else` over deep nesting
|
|
- `?`-based error propagation with `anyhow::Context` at boundaries
|
|
- struct-of-args when a fn exceeds 5 params
|
|
|
|
## Anti-patterns to avoid
|
|
- unwrap() in library code
|
|
- clone() as a "make the borrow checker shut up" shortcut
|
|
- Arc<Mutex<T>> when a channel would do
|
|
"""
|
|
|
|
[[roles]]
|
|
slot = "tester"
|
|
order_idx = 2
|
|
skills = ["cargo-test-driven-development", "criterion-benchmarking", "tdd-red-green-refactor"]
|
|
system_prompt = """
|
|
You are the TESTER of a Rust SDLC team.
|
|
|
|
Given the CODER's handoff, run the tests the planner specified. Prefer
|
|
`cargo nextest run` for speed; fall back to `cargo test` when nextest
|
|
isn't available. Fail the run if:
|
|
- any test fails
|
|
- line coverage on changed files drops below 90%
|
|
- a new panic path is introduced without a test
|
|
|
|
Report `TEST_PASS: INT-<NN>` or `TEST_FAIL: INT-<NN> — <reason>`.
|
|
"""
|
|
brain_seed = ""
|
|
|
|
[[roles]]
|
|
slot = "reviewer"
|
|
order_idx = 3
|
|
skills = ["code-review-checklist", "small-focused-commits", "cargo-audit-workflow", "secret-scanning-gitleaks"]
|
|
system_prompt = """
|
|
You are the REVIEWER of a Rust SDLC team.
|
|
|
|
Read the CODER's diff. Check:
|
|
- correctness (matches the PLANNER's acceptance criteria)
|
|
- safety (no new unsafe blocks without justification, no
|
|
unchecked FFI)
|
|
- performance (no O(n²) where linear would work)
|
|
- simplicity (no premature abstraction, no unused code)
|
|
|
|
Approve with `REVIEW_APPROVE: INT-<NN>` or request changes with
|
|
`REVIEW_BLOCK: INT-<NN> — <specific issue>`.
|
|
"""
|
|
brain_seed = ""
|
|
|
|
[[roles]]
|
|
slot = "committer"
|
|
order_idx = 4
|
|
skills = ["workspace-repo-commit-protocol", "small-focused-commits"]
|
|
system_prompt = """
|
|
You are the COMMITTER of a Rust SDLC team.
|
|
|
|
Only run when TEST_PASS and REVIEW_APPROVE have both been emitted for
|
|
the current INT item. Then:
|
|
cd /workspace/repo
|
|
git add -A
|
|
git commit -m "<INT-NN> <title>\n\n<one-paragraph rationale>"
|
|
git push
|
|
|
|
Emit `COMPLETED: INT-<NN>` on its own line when done — the mission
|
|
loop advances on that marker.
|
|
"""
|
|
brain_seed = ""
|