Task final report
Skill postmelee/hyper-waterfall/templates/locales/en/mydocs/skills/task-final-report
A human-governed AI coding workflow that distills ephemeral session context into persistent project memory—making work traceable, reviewable, and resumable.
npx -y skills add postmelee/hyper-waterfall --skill task-final-reportAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
What its author says it does
Copied from the file, not written here
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.
SKILL.md
5.3 KB, 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
- 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.
Verification
- All stage reports and the final report exist.
- The final report fills required sections from
mydocs/_templates/final_report.md. git status --shortis empty.gh pr viewshows a non-draft PR with the correct base/head.- The PR body
ChangesStage 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
Verificationsection followsAutomated Verification,Manual/Scenario Verification,CI/Remote Verification, andVerification Limitations. - The PR body does not keep unperformed verification checklists in tables.
- The daily task board #{N} row is
DonewithDone: HH:mm.
Never Do
- Create a PR when integrated verification is failing.
- Push
local/task{N}directly to remote; always publish aspublish/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-reportor the/skillsmenu - Claude Code:
/task-final-report