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
54 lines
2.2 KiB
Markdown
54 lines
2.2 KiB
Markdown
{{ 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.
|