Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/postmelee/hyper-waterfall/task-final-reportnpx skills add postmelee/hyper-waterfall --skill task-final-reportgit clone --depth 1 https://github.com/postmelee/hyper-waterfallWhat it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00074 | $0.01268 |
| Opus 5 | $0.00037 | $0.00634 |
| Sonnet 5 | $0.00015 | $0.00254 |
| Haiku 4.5 | $0.00007 | $0.00127 |
Grade A, and why
task-final-report scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 105 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Hyper-Waterfall Final Report and PR Publication
Trigger
- The task requester explicitly says "write final report" or "prepare PR."
- This SKILL is invoked directly.
Preconditions
- All implementation plan stages are complete and each stage report has been committed.
- Integrated verification for acceptance criteria has passed.
local/task{N}has no uncommitted changes, or only changes that this procedure will commit.
Procedure
- Run integrated verification: use the implementation plan's acceptance criteria or the last Stage verification section commands.
- Write final report:
mydocs/report/task_m{milestone}_{N}_report.md.- Use central template
mydocs/_templates/final_report.md. - Only if the template cannot be read, use these fallback sections:
- Work summary: Issue link, milestone, Stage count
- Changed files and impact area
- Quantitative before/after comparison when applicable, such as line count, token count, or verification pass count
- Verification results by acceptance criterion
- Residual risks and follow-up work
- Approval request to task requester
- Use central template
- Update daily task board: #{N} row in
mydocs/orders/{yyyymmdd}.md.- Use output format from
mydocs/_templates/orders.md. - Set status to
Doneand includeDone: HH:mmin notes.
- Use output format from
- Check changes.
git status --short git diff --check git log --oneline {BASE_BRANCH}..local/task{N} - Create the final commit. It may bundle the last Stage and final report, or only the report.
git add mydocs/report/task_m{milestone}_{N}_report.md mydocs/orders/{yyyymmdd}.md git commit -m "Task #{N} Stage {last} + final report: {summary}" # or git commit -m "Task #{N}: final report and daily task board completion" - Push the remote publication branch.
git push origin local/task{N}:publish/task{N} - Create an Open PR to
{BASE_BRANCH}.HEAD_SHA=$(git rev-parse HEAD) PR_BODY=/tmp/task{N}-pr-body.md # Start from {PR_TEMPLATE_PATH} and write "$PR_BODY" from the final report and stage reports. gh pr create --base {BASE_BRANCH} --head publish/task{N} \ --title "Task #{N}: {title}" \ --body-file "$PR_BODY"- The PR body uses
{PR_TEMPLATE_PATH}. - Include at most 4 summary bullets: target task, why, what, review focus.
- Include one line per Stage, verification summary, and remaining risks.
- Link each Stage title to the stage report URL and each short commit SHA to the commit URL.
- Link work documents with
HEAD_SHApinned URLs:https://github.com/{REPO_SLUG}/blob/{HEAD_SHA}/mydocs/.... - Use
[filename](URL)instead of raw links. - Do not use relative links or
blob/publish/task{N}/...links. - Use the PR body verification subsections
Automated Verification,Manual/Scenario Verification,CI/Remote Verification, andVerification Limitations. - Automated verification uses a
Topic / Method / Result / Evidencetable, summarizing what acceptance criterion was checked and the key output or pass count. - Manual/scenario verification uses a
Scenario / Check Procedure / Result / Evidencetable. - CI/remote verification uses an
Item / Result / Evidencetable with GitHub Check names, run links, or check time. - Do not leave unperformed verification in tables. Move it to
Verification LimitationsorRemaining Risks. - Do not paste long logs into the PR body; link the final report or stage reports.
- Keep
Screenshotsonly for visual changes. Related Issuesis for prerequisite, follow-up, Epic, upstream, or reference Issues, not the target task.
- The PR body uses
- Send the PR URL to the task requester and request review/merge approval.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 2d ago First seen · 105 lines · 74 tokens per session scan A bad692f961b6
task-final-report is a skill published in the GitHub repository postmelee/hyper-waterfall (78 stars, last pushed 1mo ago), licensed MIT. It adds 74 tokens to every session and 1,268 once invoked, about $0.0004 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
v1-milestone
Factory line for executing one milestone of the HAR v1.0.0 refactor (epic os-factory/har#225) — plan the wave of parallel subagents, implement each issue in its own HAR slot, ship stacked PRs, run the fixture-e2e milestone gate, and hand off for review. Use when asked to "run the next v1 milestone", "work on v1.0.0"…
release
Increment the package version, commit the release, create a matching version tag, and push main plus the tag. Use when releasing this repo, publishing the package, bumping the version, tagging a release, or when the user asks to "release", "bump ver", "tag", or "push tags".
evaluator-write-qa
Internal Auto-Harness evaluator skill for sprint QA and QA report writing. Use only inside the Evaluator subagent during qa mode.
evaluator-review-contract-parallel
Internal Auto-Harness evaluator skill for parallel sprint contract review before implementation. Use only inside the Evaluator subagent during review mode.
evaluator-write-qa-parallel
Internal Auto-Harness evaluator skill for parallel sprint QA and QA report writing. Use only inside the Evaluator subagent during evaluatorqaparallel.
evaluator-write-retest-parallel
Internal Auto-Harness evaluator skill for parallel sprint retest and retest report writing. Use only inside the Evaluator subagent during evaluatorretestparallel.