tegwick
883409665f
HF-WP-0005. The prompts used to drive work across HelixForge repositories existed only as text pasted between sessions. They are now Canned Prompt Format v0.2 packages with declared inputs, parameters and output contracts. Seven packages: repo-orient (merging "what is this repo about" with "what should we do now" as a `depth` parameter), repo-register, repo-advance, commit-sync, scope-audit, gap-workplan, session-close. "Go on implement, please" is deliberately not packaged. It is conversational continuation with no contract to declare, and packaging it would produce an artifact whose only content is the word "continue". Every one of these prompts assumed the operator's setup — the State Hub is a read model, workplans originate as files and are never registered by hand, a session closes with a progress event. That assumption is what made them personal rather than reusable. helix/custodian-conventions states those rules once as a fragment composed by every package, so they are versioned, improvable in one place, and present for an agent that has never seen this fleet. helix/commit-sync-routine exists for a narrower reason. repo-advance first composed the whole commit-sync package, which itself composes the conventions, so the rendered prompt carried the conventions block twice — CPF inclusion does not deduplicate, and a diamond dependency renders shared content once per path. Factoring the routine out removes the diamond and is a better factoring regardless. Recorded upstream as canned-prompts CANP-WP-0004-T03. helix/session-close composes practice/pqrst-estimate, so the canonical PQRST block is embedded verbatim. hall-of-helix CLOSING.md says the canonical prompt still governs when you have no pqrst-practice checkout, without saying how it reaches you; this is how. evals/pqrst-embedded.yaml fails if the canonical text stops being embedded verbatim, rather than letting the package quietly become a paraphrase. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Bjefh8NUiEiahN4JLwoSKM Assistant: claude-code Assistant-Model: opus Assistant-Process: 388925@bnt-lap001 Assistant-Session: 3507023f-e0fd-4a1e-9d90-a0d4217d1502
37 lines
1.2 KiB
Markdown
37 lines
1.2 KiB
Markdown
## Commit and sync
|
|
|
|
### 1. Review before committing
|
|
|
|
Read the actual diff, not just the file list. For each change, decide whether it
|
|
is finished, half-finished, or debris — scratch files, commented-out
|
|
experiments, stray debug output. Do not commit debris; do not silently delete
|
|
work either. Say what you found.
|
|
|
|
If a change looks wrong or you cannot tell what it was for, ask rather than
|
|
committing it.
|
|
|
|
### 2. Commit in coherent units
|
|
|
|
Group changes so each commit is one reviewable idea. A commit message says what
|
|
changed and **why**, in prose, with the reasoning that will not be recoverable
|
|
from the diff six months from now. Do not enumerate the diff — the diff is
|
|
already there.
|
|
|
|
If the working tree contains two unrelated pieces of work, make two commits.
|
|
|
|
### 3. Sync
|
|
|
|
Run the repo's sync step so the hub reflects the files. Report what it did,
|
|
including any warnings it left standing and whether they matter.
|
|
|
|
### 4. Report
|
|
|
|
State plainly:
|
|
|
|
- what was committed, and in how many commits;
|
|
- what was left uncommitted and why;
|
|
- the sync result;
|
|
- anything you noticed that needs a decision from me.
|
|
|
|
If nothing was ready to commit, say so. An empty commit round is a valid
|
|
outcome, not a failure to be papered over.
|