task-final-report

A final-step checklist for finishing a Hyper-Waterfall development task and publishing its pull request (PR), a proposed code change for review.

In plain words
What is it for?
Use it to run final checks, write a task report, mark the daily board complete, create the final commit, push the task branch, and open a PR.
Why use it?
It helps ensure the completed work is verified, documented, committed, and sent for review in the required order.

Skill for Claude CodeCodex

Install

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.

agentmods
npx agentmods add skills/postmelee/hyper-waterfall/task-final-report
Any agent
npx skills add postmelee/hyper-waterfall --skill task-final-report
Clone the repo
git clone --depth 1 https://github.com/postmelee/hyper-waterfall

Made for: Claude Code, Codex.

Per session 74 Skills are progressive disclosure: only the name and description are preloaded; the body loads when the skill is used.
When invoked 1,268 The whole file, excluding the scripts and references it only reads on demand.
Security scan A 0 findings. Scan, not verified.
Origin original No closer match found in the catalogue.
Token cost

What 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.

ModelPer sessionOnce 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

Measured 2d ago against content hash bad692f961b6, method: parsed. Prices are Anthropic first-party input rates as of 2026-08-30, from the pricing page.

Security

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.

templates/locales/en/mydocs/skills/task-final-report/SKILL.md · 105 lines

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

  1. Run integrated verification: use the implementation plan's acceptance criteria or the last Stage verification section commands.
  2. 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
  3. Update daily task board: #{N} row in mydocs/orders/{yyyymmdd}.md.
    • Use output format from mydocs/_templates/orders.md.
    • Set status to Done and include Done: HH:mm in notes.
  4. Check changes.
    git status --short
    git diff --check
    git log --oneline {BASE_BRANCH}..local/task{N}
    
  5. 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"
    
  6. Push the remote publication branch.
    git push origin local/task{N}:publish/task{N}
    
  7. 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_SHA pinned 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, and Verification Limitations.
    • Automated verification uses a Topic / Method / Result / Evidence table, summarizing what acceptance criterion was checked and the key output or pass count.
    • Manual/scenario verification uses a Scenario / Check Procedure / Result / Evidence table.
    • CI/remote verification uses an Item / Result / Evidence table with GitHub Check names, run links, or check time.
    • Do not leave unperformed verification in tables. Move it to Verification Limitations or Remaining Risks.
    • Do not paste long logs into the PR body; link the final report or stage reports.
    • Keep Screenshots only for visual changes.
    • Related Issues is for prerequisite, follow-up, Epic, upstream, or reference Issues, not the target task.
  8. Send the PR URL to the task requester and request review/merge approval.

Read the full file on GitHub · 105 lines

Changes

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.

  1. 2d ago First seen · 105 lines · 74 tokens per session scan A bad692f961b6

Subscribe to this mod's changes

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.

Related

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"…

os-factory/har · 110 tokens

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".

dzhng/duet-agent · 65 tokens

evaluator-write-qa

Internal Auto-Harness evaluator skill for sprint QA and QA report writing. Use only inside the Evaluator subagent during qa mode.

redker56/auto-harness · 32 tokens

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.

redker56/auto-harness · 33 tokens

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.

redker56/auto-harness · 37 tokens

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.

redker56/auto-harness · 39 tokens