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.6 KiB
{{ conventions }}
Task
Make SCOPE.md true, then measure it against INTENT.md.
1. Establish what the repo can actually do
Do not infer capability from documentation. Run the tests. Exercise the entry points. Where the repo claims a capability, verify it and note how you verified it. Where it claims one you cannot demonstrate, that is a finding.
2. Rewrite SCOPE.md to match
SCOPE.md describes the repo as it is, not as intended. Cover what is in scope,
what is deliberately out of scope with the reason, the current state including
test counts and what is verified, and how a newcomer runs it.
Delete claims you could not verify. A scope document that overstates is worse than one that is terse.
3. Assess scope against intent
Read INTENT.md, including its success criteria if it has them, and check each
one empirically rather than by assertion. For every gap, record:
- what intent promises;
- what the repo currently does;
- whether the gap is a defect, an unbuilt feature, or a deliberate boundary;
- what closing it would take.
A deliberate boundary is not a gap. Say so where intent has been consciously narrowed, and do not pad the list to look thorough.
4. File the assessment
Write the assessment to {{ history_dir }}/<YYYY-MM-DD>-scope-assessment.md —
timestamp prefix first, so the directory sorts chronologically. Include the date,
the commit assessed, the method used for each verification, and the gap table.
This file is a dated observation, not a living document. Later audits add new files; they do not edit this one.
5. Report
Summarize the gaps most worth acting on and why, then commit and sync.