Omar SobhandClaude Opus 4.7
7b23f61632
Hand-authored skill catalog anchored to real 2026-07 versions:
- Rust 1.97.1 (stable), edition 2024
- React 19.2.7, Server Components + Actions
- TailwindCSS 4.3.3 (CSS-first config, Oxide engine)
- three.js r185 (WebGPURenderer stable, BatchedMesh matured)
- React Native 0.86 / Expo SDK 54+ (New Architecture default)
- cargo-nextest 0.9.140, gitleaks 8.20+, cargo-audit 0.21+
- Postgres 17 (18 in beta, don't rely on)
- CUDA Blackwell, Metal Apple7+, ROCm CDNA3
Ships 15 skills across the categories:
foundation/ workspace-repo-commit-protocol
small-focused-commits
tdd-red-green-refactor
code-review-checklist
int-xx-marker-protocol
decompose-int-items
rust/ write-rust-current-edition
rust-error-handling
cargo-test-driven-development
rust-async-tokio-idioms
backend/ postgres-migrations-forward-only
postgres-index-selection
api-pagination-day-1
frontend/ react-19-server-components
tailwind-v4-idioms
component-4-state-model
mobile/ expo-managed-vs-bare
rn-flashlist-perf
gpu/ gpu-coalescing-and-occupancy
roofline-model
threejs/ threejs-perf-and-teardown
security/ cargo-audit-workflow
secret-scanning-gitleaks
skills_loader.rs walks skills/**/*.md, parses YAML frontmatter
(name, description, when_to_use, tags), upserts via
skills_catalog::upsert_builtin. Idempotent per boot — bumps version
+ appends skill_versions row ONLY when body changes. Deterministic
sha256-derived ids so builtins are stable across boots.
Dockerfile copies skills/ to /etc/clawmates/skills. Server boot
task spawns loader alongside team_template_loader.
Follow-ups (Slice 3.5c continuation, future PRs):
- 20-30 more skills (duckdb, shadcn composition, a11y, WebGPU
migration, metal frame capture, rocprof, deep gitea forge
integration, semgrep rulepacks)
- Bind skills to team template roles (add [role.skills] refs to
templates/teams/*.toml + wire template_role_skills population
in team_template_loader)
Co-Authored-By: Claude Opus 4.7 <[email protected]>
64 lines
2.1 KiB
Markdown
64 lines
2.1 KiB
Markdown
---
|
||
name: decompose-int-items
|
||
description: How to break a mission's roadmap/research artifact into INT-XX items sized for one coder-turn each.
|
||
when_to_use: You are the planner role, at the start of a coding phase, when the input is a spec/roadmap and the output is a task list.
|
||
tags: [foundation, planning]
|
||
---
|
||
|
||
# Decomposing into INT-XX items
|
||
|
||
Each INT item is one unit of work handed to a coder. The mission loop iterates one INT per iteration by default. Sizing matters — too big and iterations stall, too small and you burn tokens on ceremony.
|
||
|
||
## Sizing heuristic
|
||
|
||
Aim for **1–3 hours of focused coder time** per INT. Practically:
|
||
- Touches ≤ 5 files
|
||
- Adds ≤ 300 LOC net
|
||
- Owns exactly one test story (a `#[test]` or a small `describe` block)
|
||
- Independently mergeable — reverting it doesn't break other INTs
|
||
|
||
If an item exceeds any of these, split.
|
||
|
||
## The output shape
|
||
|
||
Each INT is a block with:
|
||
|
||
```
|
||
INT-05: <short title>
|
||
|
||
**What:** one paragraph, observable behavior only (no implementation
|
||
details unless they're required for correctness).
|
||
|
||
**Files (expected):** src/foo.rs, tests/foo_test.rs
|
||
|
||
**Acceptance:**
|
||
- [ ] `cargo test foo::` passes with the new case
|
||
- [ ] Coverage on src/foo.rs ≥ 90%
|
||
- [ ] No new `unsafe` blocks
|
||
|
||
**Depends on:** INT-04 (must be merged first)
|
||
|
||
**Risk notes:** touches the hot path — bench before/after.
|
||
```
|
||
|
||
Emit each on its own — the task-card parser (Slice 5) UPSERTs one `mission_tasks` row per marker.
|
||
|
||
## Ordering
|
||
|
||
- **Dependencies first.** INT-01 → INT-02 → ... — but leave room for reorders. A coder can emit `REORDER: <rationale>` if a prerequisite blocks them.
|
||
- **De-risk first.** Put the highest-uncertainty item early so failure is cheap to recover from.
|
||
- **Interface before implementation.** If INT-N introduces a new module boundary, land the trait/type in INT-N-a and the impl in INT-N-b.
|
||
|
||
## Emit protocol
|
||
|
||
At the end of the planning turn, emit:
|
||
|
||
```
|
||
TASK: INT-01 — <title>
|
||
TASK: INT-02 — <title>
|
||
...
|
||
PLAN_COMPLETE: INT-01..05
|
||
```
|
||
|
||
The parser creates `mission_tasks` rows for each TASK line. `PLAN_COMPLETE` records that the plan pass finished so the mission's coding phase can begin iterating.
|