agentsclimarketplace

Task final report

Skill postmelee/hyper-waterfall/templates/locales/en/mydocs/skills/task-final-report

Apply the final report and PR publication procedure for a Hyper-Waterfall task. Write the final report (`_report.md`), mark the daily task board complete, create the final commit, push the remote publish/task{N} branch, and create an Open PR to {BASE_BRANCH}. Invoke only immediately before PR publication after all stages are complete.From its SKILL.md

Install
npx -y skills add postmelee/hyper-waterfall --skill task-final-report

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • runs commandsInstructs the agent to run 8 commands, including `git status --short` and 7 more.

SKILL.md

5.3 KB, ~1.2k tokens by cl100k_base, as published. Nobody here has run it

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.

Verification

  • All stage reports and the final report exist.
  • The final report fills required sections from mydocs/_templates/final_report.md.
  • git status --short is empty.
  • gh pr view shows a non-draft PR with the correct base/head.
  • The PR body Changes Stage summaries link to stage reports and short commit SHA links.
  • Work document links use commit SHA-pinned URLs and [filename](URL) format.
  • Work document links do not contain raw GitHub blob URLs, relative links, or blob/publish/task{N}.
  • The PR body Verification section follows Automated Verification, Manual/Scenario Verification, CI/Remote Verification, and Verification Limitations.
  • The PR body does not keep unperformed verification checklists in tables.
  • The daily task board #{N} row is Done with Done: HH:mm.

Never Do

  • Create a PR when integrated verification is failing.
  • Push local/task{N} directly to remote; always publish as publish/task{N}.
  • Force squash merge options; Stage commit meaning must be preserved.
  • Create a Draft PR or self-merge without explicit task requester instruction.

Invocation

  • Codex: $task-final-report or the /skills menu
  • Claude Code: /task-final-report

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.

Keep looking

Skills are one crate of 325,949. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.