メニュー
Trunk-based development for Grob — short-lived branches, conventional commits, never-on-main rule, merge protocol. Use this skill when starting a branch, naming a branch, deciding when to commit, deciding when a branch should land or when a branch has grown too big.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Syntax, idioms and conventions for writing .grob programs — sample scripts, integration-test fixtures, error examples. Use this skill whenever you create or edit a .grob file, so the language source is idiomatic and valid against the v1 surface. Covers bindings, the three string forms, nullability, control flow, lambdas, collection pipelines, structs, errors, the stdlib surface and numerics.
The single authoritative procedure for allocating a Grob error code — the pre-declared-budget model with an allocate-and-surface fallback for the unanticipated case. Use whenever an increment needs a diagnostic code: to confirm the budget covers it, to make the fold-into-existing versus register-new judgement, or to register a new code in lockstep. Codes are immutable once shipped (ADR-0017), so this keeps the design judgement explicit while making the mechanics deterministic. writing-an-error-test defers to this skill for the code itself.
Use when an increment introduces, resolves or constructs a Grob type — a `type` declaration, a struct construction, an anonymous struct, a new type-annotation position, a new built-in type, or any feature where a value carries a type the checker must resolve and the VM must represent. Encodes the four failure modes that produced the Sprint 5 post-close interludes (type-reference-grammar gaps, conflated cycle walks, non-uniform redeclaration and lifecycle objects escaping through new containers) as a standing pre-flight and a closing checklist. Reuses, does not replace, `adding-an-opcode` and `tdd-cycle`.
The sanctioned procedure for adding a parser production or an AST node to Grob — the parser/AST analogue of adding-an-opcode. Use when an increment genuinely needs a new surface form or a new node that is not already there (a new construction expression, a new literal, a new annotation position). The front end is built incrementally, so this is a real and expected job — not a wall to route around with an improvised gap-fix. It is deliberate and reviewable, never silent.
How to add or update a gold-master error-example pair (_grob.txt + _expected.txt) and register the error code, without breaking the negative-test release gate.
Use during a manual PR review to pull SonarQube Cloud (SonarCloud) findings for the pull request straight from the Web API — issues on new code, the quality-gate verdict and the new-code coverage against the floor — without the Docker-based Sonar MCP server. Produces a compact findings block for the reviewer to fold into its PR comment. It does not post anything; the human composes and posts the comment. Assumes the PR's Sonar scan has already completed (the reviewer is triggered manually after all scans).
| name | trunk-flow |
| description | Trunk-based development for Grob — short-lived branches, conventional commits, never-on-main rule, merge protocol. Use this skill when starting a branch, naming a branch, deciding when to commit, deciding when a branch should land or when a branch has grown too big. |
The discipline: small, frequent merges to main. Branches live hours, not
days. The codebase is always releasable. Chris merges; you never do.
This skill covers the branch lifecycle and the protocol around it. For the work that happens inside a branch, see:
tdd-cycle/SKILL.md — the red/green/refactor procedure that produces
the commits.the /commit-message command — full conventional-commits
rules.tests/CLAUDE.md — coverage taxonomy and the
90% bar that gates every commit.main. First action on any new piece of work is
to create a branch.main must pass tests
and keep every project at or above 90% line coverage. You don't merge
red. You don't merge below the coverage bar. Chris doesn't either.<type>/<scope>-<kebab-name>
feat, fix, refactor, test,
docs, build, ci, chore.core, compiler, vm,
runtime, stdlib, cli, lsp, tests, docs, build.When the type is the scope (build, docs, chore, ci), the scope
is omitted from the slug — build/add-grob-vm-csproj, not
build/build-add-grob-vm-csproj.
Examples:
feat/compiler-string-lexerfix/vm-stack-underflowtest/compiler-coverage-gap-fillrefactor/core-rename-token-kindsbuild/add-grob-vm-csproj1. Confirm on main with clean tree
git status
git branch --show-current # should be main
2. Pull latest
git pull
3. Create branch
git checkout -b feat/compiler-string-lexer
4. Work the TDD cycles
(red / green / refactor / extend coverage / coverage check /
commit, repeating — see tdd-cycle/SKILL.md)
5. Push to remote
git push -u origin feat/compiler-string-lexer
(the -u sets upstream tracking; first push only)
6. Hand off to Chris for review and merge
"Branch feat/compiler-string-lexer is ready. Three commits.
All tests green. Coverage at or above 90% on every affected
project. Ready for your review and merge."
7. After Chris merges and deletes the remote branch
git checkout main
git pull
git branch -d feat/compiler-string-lexer # local cleanup
Every commit message follows:
<type>(<scope>): <subject>
<body>
<footer>
See the /commit-message command for the full rules. The
short version:
feat and fix always include their tests in the same commit. A
feat commit whose diff contains no test files is not a feat. A fix
commit without a regression test is not a fix. Separate test commits
are reserved for genuinely test-only work — regression rows from
property-test discoveries, coverage gap filling on shipped code, test
infrastructure changes.Implements D-300.[ExcludeFromCodeCoverage] added, tested code removed,
percentage dropped. Silent coverage drops are how 90% becomes 70%.Refs: #42 or
Closes: #42.Commit small, commit often. Each TDD cycle produces one commit containing
both the test and the implementation; separate test commits are only
for genuinely test-only work. The shape of a typical branch:
feat(compiler): scan empty input to EOF # test + impl
feat(compiler): scan decimal integer literals # test + impl
feat(compiler): scan hex integer literals # test + impl
refactor(compiler): extract number scanning to helper # no new tests
Four commits, three TDD cycles plus a refactor. All on one branch, landing in a day or less.
Compare with the wrong shape:
test(compiler): add lexer test for empty input # WRONG —
feat(compiler): add Lexer scanning empty input to EOF split feat
The reviewer treats a feat without tests in its diff as a blocker, so
landing this shape would bounce back. Fold the test into the feat.
Symptoms:
When you notice this, surface it:
"This branch has grown beyond what we planned. It now covers the lexer and part of the parser. Should I land the lexer part first and start a new branch for the parser, or do something else?"
Don't wait for Chris to notice. Branch splits are easy when caught early, painful when caught late.
If a branch needs splitting:
1. From the bloated branch, look at the commits
git log --oneline main..HEAD
2. Decide the split point. The commits before the split point belong to
the first branch, the commits after to the second.
3. Reset the current branch to the split point
git checkout feat/compiler-string-lexer
git reset --hard <split-point-commit>
git push --force-with-lease # only if already pushed
4. Create the second branch from the split point with the orphaned commits
git checkout -b feat/compiler-string-interpolation <bloated-tip>
5. The first branch is now clean and ready to hand off. The second branch
continues the work after the first lands.
Force-pushing a branch is fine when only you have been working on it. Use
--force-with-lease not --force — it refuses if someone else has pushed
in the meantime.
You never merge to main. Always Chris.
When the branch is ready:
dotnet test against the whole solution.
Everything green.[ExcludeFromCodeCoverage] with a substantive
Justification — and note it in the relevant commit body before
handing off.main. git fetch && git log origin/main..HEAD — if there are commits on main you don't
have, rebase or merge them in first.git push (or git push -u origin <branch> on the first
push).<name> ready. <N> commits. All
tests green. Coverage at or above 90% on every affected project.
Ready for your review and merge."If Chris asks for changes, fix them on the same branch and push again. Don't create a "fixes" branch.
Once Chris has merged:
git checkout main
git pull
git branch -d <merged-branch>
The -d (lowercase) only deletes if the branch was merged. If it refuses,
something is off — investigate before forcing with -D.
main.main or to a branch someone else is working on.[ExcludeFromCodeCoverage]
with a substantive Justification and a note in the commit body.
Silent coverage drops are not acceptable.feat commit without its tests, or a fix commit
without a regression test. Those land as reviewer blockers; better to
fold them in before push.main.
Make it explicit when handing off: "This is stacked on
feat/compiler-string-lexer. Once that merges, this one can rebase
onto main." If the parent branch gets force-pushed during a split,
the stacked branch needs rebasing onto the new parent tip — surface
this before pushing.main is broken and needs urgent fixing,
the branch is still required — just keep it minimal. fix/vm-crash-on-eof
with one commit containing both the regression test and the fix. Don't
bundle unrelated cleanup with a hotfix.wip: <description> — no scope,
no type-from-the-conventional-list. wip is local-only. WIP commits
must never reach main and must never reach a pushed branch that
Chris is expected to review. Before pushing or handing off, squash
WIP commits into proper conventional commits with git rebase -i.
An alternative for short checkpoints is git stash — no commit
needed.