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-registernpx skills add postmelee/hyper-waterfall --skill task-registergit 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.00072 | $0.01399 |
| Opus 5 | $0.00036 | $0.00700 |
| Sonnet 5 | $0.00014 | $0.00280 |
| Haiku 4.5 | $0.00007 | $0.00140 |
Grade A, and why
task-register 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 3d 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 — 129 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Hyper-Waterfall Issue Registration
Trigger
- The task requester explicitly asks to register an Issue, create a new task, or start from an Issue.
- The task requester invokes this SKILL directly.
Preconditions
- The work does not yet have an Issue number.
- Purpose, background, and scope are at least drafted.
ghCLI is authenticated for the current user.- When possible,
.github/ISSUE_TEMPLATE/task.ymlor framework sourcetemplates/.github/ISSUE_TEMPLATE/task.ymlcan be read. - Before creating the Issue, the title, body, milestone, and label draft can be confirmed with the task requester.
Procedure
- Check for duplicate Issues.
gh issue list --repo {REPO_SLUG} --state all \ --search "{work keywords}" \ --limit 20 \ --json number,title,state,milestone,labels,url- If a substantially identical open Issue exists, do not create a new one. Ask whether to use the existing Issue.
- If a closed Issue covered the same topic, link it in the new Issue references.
- Check open milestones.
gh api repos/{REPO_SLUG}/milestones \ --jq '.[] | {number,title,state,description,open_issues,closed_issues}'- Judge from the live
title,state, anddescription. - Do not rely on remembered old milestone lists or version mappings.
- Judge from the live
- Check existing labels.
gh api repos/{REPO_SLUG}/labels --paginate \ --jq '.[] | {name,description,color}'- Judge from live
nameanddescription. - Do not rely on remembered old label lists.
- Judge from live
- Choose milestone candidates.
- Use only open milestones.
- Compare work purpose, scope, component, and release phase with the milestone
titleanddescription. - If one candidate is clear, record its title and reason.
- If 2-3 candidates are possible, present them with reasons and ask the task requester.
- If no open milestone fits or descriptions are insufficient, ask the task requester instead of guessing.
- Choose label candidates.
- Use only existing labels from the live lookup.
- Select a label only when the work clearly matches the label
nameanddescription. - Prefer 1 type label, 1-2 area labels, and 0-1 kind/status label.
- Type labels include
bug,documentation,enhancement,duplicate, orquestion. - Area labels are selected by primary work ownership, not every affected area.
- Kind labels such as
kind:architecture,kind:automation,kind:regression,kind:verification, orkind:follow-upare used only when they meaningfully distinguish handling. - General Issues should usually have 2-4 labels.
- If 5 or more labels are needed, write the exception reason in the draft and confirm it with the task requester.
- If candidates are clear, record label names and reasons.
- If no label fits or the fit is ambiguous, create without labels or ask the task requester.
- Do not create new labels.
- Draft the Issue.
- Title: one sentence that reveals the work unit.
- Body: prefer GitHub Issue Form
.github/ISSUE_TEMPLATE/task.yml.- In a framework repository, use
templates/.github/ISSUE_TEMPLATE/task.ymlwhen checking the source template for applied repositories. - Since
gh issue createdoes not run Issue Form UI, convert form fields to Markdown sections.
- In a framework repository, use
- Issue Form sections:
- Background
- Goals
- Scope - Included
- Scope - Excluded
- Acceptance Criteria
- Verification Criteria
- References
- Milestone and label candidates
- If the Issue Form cannot be read, use the same section list as fallback.
- Milestone: one open milestone chosen from live lookup and the selection reason.
- Labels: approved existing labels and reasons, or none.
- Split label reasons by type/area/kind, and include the exception reason if using 5 or more labels.
- Request approval before creating the Issue.
- Show the task requester the title, body, milestone, labels, and selection reasons.
- Do not run
gh issue createuntil the task requester explicitly approves creation in the same thread.
- After approval, create the Issue.
gh issue create --repo {REPO_SLUG} \ --title "{title}" \ --body "{body}" \ --milestone "{milestone}" \ --label "{label}"- Repeat
--labelfor multiple labels, such as--label documentation --label enhancement. - Omit
--labelwhen creating without labels.
- Repeat
- Confirm the created Issue.
gh issue view {N} --repo {REPO_SLUG} \ --json number,title,state,milestone,labels,url - Report the created Issue number and URL, then request approval to enter
task-start.
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.
- 3d ago First seen · 129 lines · 72 tokens per session scan A 295ada15ff42
task-register is a skill published in the GitHub repository postmelee/hyper-waterfall (78 stars, last pushed 1mo ago), licensed MIT. It adds 72 tokens to every session and 1,399 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
harness-creator
Build, audit, and improve harnesses that make AI coding agents reliable: AGENTS.md/CLAUDE.md instruction files, feature/state tracking, verification gates, scope boundaries, session handoff, memory persistence, context budgets, tool-permission safety, and multi-agent coordination. Use this whenever a coding agent is…
harness
하네스를 구성합니다. 전문 에이전트를 정의하며, 해당 에이전트가 사용할 스킬을 생성하는 메타 스킬. (1) '하네스 구성해줘', '하네스 구축해줘' 요청 시, (2) '하네스 설계', '하네스 엔지니어링' 요청 시, (3) 새로운 도메인/프로젝트에 대한 하네스 기반 자동화 체계를 구축할 때, (4) 하네스 구성을 재구성하거나 확장할 때, (5) '하네스 점검', '하네스 감사', '하네스 현황', '에이전트/스킬 동기화' 등 기존 하네스 운영/유지보수 요청 시 사용.
new-plugin
Factory line for adding a new HAR verification plugin (like playwright or rocketsim) for any framework — research the framework docs, build the template under src/templates/plugins/, register it everywhere, validate on a real repository, and open a PR. Use when asked to add/create a plugin, plugin template, or…
factory-line
Factory line for executing one station of a declared multi-station program — read the installed line bundle (har line status), plan parallel work into isolated HAR slots, run the cumulative gate with har line gate, and hand off for human review. Use when asked to "run a factory line", "run the next station", "execute…
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"…
debug-memory
Reproduce observational-memory bugs (reflection, recall, observer, freshness, eviction) by dumping the live /.duet/memory.db into a fixture and driving an eval against it. Use whenever the agent's memory misbehaves — wrong observations, bad reflections, missing recall, runaway tokens — or whenever the user asks to…