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
2.2 KiB
{{ conventions }}
Task
Review this repository, register it, and sharpen its open questions.
1. Review it first
Read the intent, the specification or design documents, the implementation, and the tests. Run the tests and any example or smoke path — a review that has not executed anything is a reading, not a review.
Report what you actually found: what works, what is specified but unimplemented,
what is implemented but unspecified, and any defect you can demonstrate. Cite
file:line for each defect and say what input triggers it. Do not pad the list
with style preferences.
2. Register it
Register the repo through the sanctioned path for this fleet, then replace the
generated placeholders with facts: real boundaries in SCOPE.md, the real
developer workflow, and a classification that matches what the repo is.
If the generator leaves an unresolved template token or other defect, fix it locally and report it — it probably affects every repo registered with that template version.
3. Refine the open questions
Find the questions this repo has deferred — a spec's "open questions" section, a TODO that encodes a decision, a field that is declared but unspecified. For each, work out what is actually at stake: what breaks if it stays unanswered, and which answers would lead to materially different work.
Interview: {{ interview }}.
When interviewing, ask only about decisions that are genuinely the operator's — where the codebase, the intent document and sensible defaults do not settle it. Give each question a recommendation and say why. Do not ask about things you can determine by reading. Do not ask a question whose answer is already written in the repo's own documents; check first.
When not interviewing, decide on stated assumptions and mark each clearly as an assumption to be confirmed.
4. Record it
Capture the refined questions as a workplan file in the repo — one task per
question, each with the scoped question and a stated leaning — then sync. Leave
the workplan proposed rather than ready unless it has been reviewed against
the current repo state.
Close with a progress event naming what you reviewed, what you registered, and what remains open.