BankNatchapol

refining-spec

Use after gstack /office-hours to technically refine a design into docs/superpowers/specs/ for writing-board-tasks. Fork of gstack /spec phases 1–4 — feature-level repo spec, NOT a GitHub issue. Run before Step 17.

super-board

GitHub-Project-driven autonomous pipeline. Five verbs — onboard, lint, status, run, stop — that take a Project board from empty to drained across Build → QA → Review → Done lanes, with graceful shutdown / resume. Use when the user says "super-board", "/super-board", "drain my GitHub project", "set up the autonomous loop", "kick off the headless build/QA pipeline", or "stop super-board".

super-build

Super Build canonical workflow. Headless parallel GitHub Project executor that reads issues whose `Status` field is `Ready`, dispatches each as a headless `claude -p` worker in its own git worktree (max 3 in parallel), merges results back, closes the issue, moves the project card to `Done`, and notifies Telegram on each completion. The project board is the single curation surface — drag a card to `Ready` and Super Build picks it up. Use when the user says "Super Build", "run the build loop", "/super-build", or invokes the skill.

Testing & QA Listed

super-qa

Super QA canonical workflow for functional bug-bash, evidence capture, and fix-ready issue filing. Builds and runs Playwright path specs from `docs/super-qa/queue.md`, records screenshots/logs/HARs, files product-readable issues with clear type/priority/area labels, and continues until traversal is complete or only human-gated blockers remain. Use when the user says "run super-qa", "QA review", "bug bash", "verify and fix", or invokes `/super-qa`.

Code & Development Listed

super-review

Super Review canonical workflow for PR/code/architecture readiness across EricTechOS apps. Use when the user says "Super Review", "review this branch", "review loop", "make sure this is merge-ready", "PR review", or asks for code, architecture, security, QA evidence, or release-readiness judgment. Produces findings and routes fixes to Super Build, Super QA, or Super UX instead of silently pushing changes unless explicitly authorized.

supersaiyan

End-to-end AI development pipeline — idea to merged PR with one command set. Handles brainstorming, spec writing, task decomposition, issue filing, and autonomous Build → QA → Review execution. Use when the user types "/supersaiyan", "supersaiyan", or any supersaiyan verb (new, setup, prepare, run, status, lint, stop).

test-driven-development

Use when implementing any feature or bugfix, before writing implementation code

verification-before-completion

Use when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidence before assertions always

writing-board-tasks

Use when you have a feature design spec and want super-board GitHub issues — decompose the spec into PR-sized board task files with observable acceptance criteria. Run after refining-spec (or Step 16 spec), before tasks-to-issues.sh. Replaces writing-plans in the super-board pipeline.