Omar SobhandClaude Opus 5
771092b165
Extending the Skill-Use mechanical checks, per the baseline's own next step, found something bigger than a missing check. THE DEFECT `workspace-repo-commit-protocol` told agents that `/workspace/repo` was "the ONLY path where source-modifying edits belong". The platform mounts and advertises `/mission/repo` — 26 references in the code; `/workspace/repo` appears in none of them. The skill is bound on 29 role bindings and was delivered TWICE in the run already measured, so an agent received the real path in its tool preamble and a skill contradicting it a few hundred tokens later, in one prompt. An agent that obeyed the skill wrote source into a directory nothing collects — the phase then delivers nothing, and looks like an agent that did no work. The same skill instructed `file_read` / `file_write` / `shell`: ZeroClaw's names, the exact ones `phase_task_text` was fixed to stop advertising after five agents on a single mission spent 7.4k tokens describing the mismatch instead of working. The prompt was corrected and the skill kept saying it. Rewritten against what the code actually does, including the repo-less case (`/mission/repo` exists, is collected as artifacts, has nothing to push). THE CLASS, AND THE GUARD The skills were never checked against the platform they describe. Nothing compared them, so a skill could contradict the prompt it ships inside and stay that way indefinitely — the same shape as PLAN_COMPLETE being documented and never implemented. Two tests in `skills_loader::contradiction_tests` now hold it: no skill may name a repo path the platform does not mount, and none may instruct a tool the agent's subprocess does not expose. The second matches backticked instructions and skips corrective lines, so a skill may still WARN against the wrong names — as this one now does. Both negative-controlled by restoring the old wording. AND THE CHECK THAT STARTED IT `workspace-repo-commit-protocol` now has a Boundary check: writing outside `/mission/repo` fails, and the message names the consequence — a phase that delivers nothing — rather than just the wrong path. docs/SKILL-USE-BASELINE.md records this as the fourth defect the measurement found, and corrects the "next unit of work" note now that this one is done. Full workspace suite green: 106 binaries, zero build errors. Co-Authored-By: Claude Opus 5 <[email protected]>
78 lines
3.0 KiB
Markdown
78 lines
3.0 KiB
Markdown
---
|
|
name: workspace-repo-commit-protocol
|
|
description: How to work inside /mission/repo — the mission's checked-out codebase — and how to commit meaningful changes back.
|
|
when_to_use: You are a coder, committer, or any role that edits code. Pin this at turn start so you never lose orientation.
|
|
tags: [foundation, coding, git]
|
|
---
|
|
|
|
# Mission repo + commit protocol
|
|
|
|
The repository this mission targets is checked out at **`/mission/repo`**. That
|
|
is the only path where source-modifying edits belong.
|
|
|
|
## Ground rules
|
|
|
|
1. **`cd /mission/repo` at the start of every substantive turn.** If you `pwd`
|
|
and it is somewhere else, cd there first.
|
|
2. **Every read and write that touches source uses a path under
|
|
`/mission/repo`.** Anything else is scratch and will not be delivered.
|
|
3. On a mission with **no** repository, `/mission/repo` still exists and is
|
|
writable — it is a scratch workspace, every file you leave there is
|
|
collected when the phase ends and published as a mission artifact, and there
|
|
is nothing to commit or push. Your task text says which kind of mission this
|
|
is; believe it over any assumption.
|
|
|
|
## Use the tool names your prompt gives you
|
|
|
|
Your turn runs through Claude Code, so the tools are `Read`, `Edit`, `Write`,
|
|
`Bash`, `Glob`, `Grep`. Your prompt lists them explicitly — use those names.
|
|
|
|
Do not reach for `file_read`, `file_write`, `content_search` or `shell`. Those
|
|
are ZeroClaw's names, they are not what your subprocess exposes, and agents that
|
|
tried them spent whole turns describing the mismatch instead of working.
|
|
|
|
## Commit protocol
|
|
|
|
When, and only when, you have a meaningful, tested change:
|
|
|
|
```
|
|
cd /mission/repo
|
|
git status # what did you actually touch
|
|
git diff --stat # does the scope match the plan
|
|
git add -A
|
|
git commit -m "<INT-NN> <one-line title>
|
|
|
|
<one paragraph on WHY, not what>
|
|
|
|
Refs: INT-NN
|
|
"
|
|
```
|
|
|
|
- **Put the INT-XX marker on the subject line.** The task-card parser advances
|
|
mission state on it.
|
|
- **One INT per commit** unless the change genuinely cannot be split. Split when
|
|
in doubt: a commit covering three items cannot be reverted for one of them.
|
|
- **Never `--force`, never rewrite pushed history** without an explicit
|
|
`HANDOFF: safe to force-push` from the reviewer.
|
|
- Push only if your task says to. Many missions deliver by having the platform
|
|
diff your checkout, and a phase that pushes when it should not is harder to
|
|
undo than one that did not push.
|
|
|
|
## When NOT to commit
|
|
|
|
- Tests failing. Fix or revert; never commit red.
|
|
- The reviewer emitted `REVIEW_BLOCK: INT-NN` for the current item.
|
|
- The change is exploratory. That is not what the mission branch is for.
|
|
|
|
## Emit the completion marker
|
|
|
|
After the work is genuinely done, on a line by itself:
|
|
|
|
```
|
|
COMPLETED: INT-NN
|
|
```
|
|
|
|
Exactly one INT id, no bold, no code fence — the parser takes the literal line
|
|
and rejects anything else. The mission loop advances on it, so emitting one you
|
|
cannot back up desynchronizes the mission from the repository.
|