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
1.8 KiB
{{ conventions }}
Task
Find the gaps worth closing, plan them, and close them.
1. Rank the gaps honestly
Gather candidate gaps from the intent document, any scope assessment, open questions, failing or missing tests, and defects you can demonstrate.
Rank by what closing each one unblocks — not by how easy it is. A gap that blocks other work outranks three cosmetic ones. State the ranking criterion you used, and name the gaps you considered and rejected, so the shortlist can be argued with.
Where a gap is really a decision the operator must make, say so and ask rather than deciding it inside an implementation task.
2. Write the workplan
One workplan file, one task per gap. Each task states the problem, what "done" looks like, and — where the gap involves a design choice — the options with a stated leaning rather than a silent decision.
Do not invent structure the work does not have. Three real tasks beat nine padded ones.
3. Register it
Register through the sanctioned path: write the file, commit, and let the sync assign ids and write them back. Never create the workplan or its tasks directly against the hub.
4. Implement
Implement: {{ implement }}.
When implementing, work the tasks in order, updating each task's status in the file as you go. After each task: verify it, commit it with reasoning, and sync. Do not batch six tasks into one commit — the record is the point.
When a task turns out to be wrong once you are inside it, say so and revise the plan rather than forcing the original shape.
When not implementing, stop after registering and report what the plan contains.
5. Close
Report which tasks are done, which are not and why, and what the work revealed that the plan did not anticipate. Hand off leftovers as live work records. Log a progress event.