| name | Ship a code change |
| description | The disciplined way to make and land a code change in a Symphonee-managed repo -- branch, implement, verify, show the diff as its own step, then commit. Use for any implement/fix/refactor task that ends in a commit. |
| when | the user asks you to implement, fix, change, or ship code |
| tags | workflow, git, core |
Ship a code change
The repeatable procedure for landing a change correctly and consistently. Follow
every step in order; the order is load-bearing.
Use when
- The user asks you to implement a feature, fix a bug, refactor, or "ship it".
- Any task whose natural end state is a commit in a managed repo.
Do not use when
- The user only wants an explanation, a search, or a read-only answer (no edit).
- The work is a one-line throwaway in a scratch file with no commit.
Steps (primary path)
- Work in the active repo only: read
activeRepoPath from /api/ui/context; do
all file/git operations there. Never ask "which repo?" -- it is already chosen.
- If on the default branch (master/main), create a feature branch first. Never
develop a feature directly on the default branch.
- Implement the change in small, coherent edits that match the surrounding code's
style, naming, and comment density.
- Verify before showing anything:
- JS modules:
node --check <file>.
- Renderer edits (
app/src/shell/*, mind-ui/src/*, or index.html inline
scripts): edit the SOURCE, run npm run build:renderer, and NEVER hand-edit
the generated dashboard/public/js/app.js or mind-ui.js (see the
verify-frontend-edit skill). Commit both source and rebuilt output.
- Run any fast, relevant unit check.
- Show the diff as its OWN step, then PAUSE. Use the built-in diff viewer
(
/api/ui/view-diff, or Show-Diff.ps1 -Repo '<name>' where available) --
never git diff in the terminal, never an external editor. Do NOT bundle the
diff with the commit: the viewer shows only WORKING (uncommitted) changes, so
committing first leaves the user staring at an empty diff.
- Commit only after the diff is shown and (when a human is present) acknowledged.
Write a clear message: a concise subject plus a body explaining the why.
- Push or merge ONLY if the user explicitly asked. Default is commit-locally-only.
Safety
- Never
git diff in the terminal; never open VS Code or external editors -- use
the built-in file/diff viewers.
- Never push, merge, force-push, skip hooks, or do anything outward-facing unless
the user explicitly authorized it this turn.
- On
403 deny / rejected-by-user from a gated operation: stop. Do not retry or
route around.
- Before a gated operation, tell the user in one short sentence what is about to
happen so the approval modal is not a surprise.
Verification
- The change builds / type-checks / passes
node --check (or rebuilds cleanly for
renderer edits).
- The diff was shown in the built-in viewer as its own step.
- The commit exists with a clear message; nothing was pushed/merged unless asked.
- If you said it is done, it is actually done and verified -- no hedging.
