foyzulkarim

archive-issue

Retire a closed issue's working artifacts out of specs/ into the GitHub wiki. Use only when the user asks to archive a finished issue, empty out specs/ for a done task, or move an issue's requirements/architecture/tasks/review/QA docs to the wiki.

commit

One-shot conventional commit; bundled scripts adaptively gather diff context, draft the message, and stage+commit — pass `ask` to confirm first or add a hint for the title. Use only when the user asks for a commit.

execute-qa

Executes a QA specification (specs/qa/QA-<N>-<slug>.md) written by /plan-qa: drives every step with the plan's drivers, verifies each Expected line mechanically ([assert]) or by evidence-backed judgment against the plan's written criterion ([judge]), pauses at named operator handoffs, and writes the results artifact QA-RESULTS-<N>-<slug>.md. Use only when the user asks to run or execute a QA plan — never trigger automatically.

generate-tasks

Phase 3 of 5 — slices the ARCH doc into verification-ready task specs (tdd/test-after/ui/checklist), emitted as a separate TASKS-<N>-<slug>.md file alongside ARCH for the implement skill. Use only when the user asks to run Phase 3 or generate tasks from an ARCH doc — never trigger automatically.

implement

Phase 4 of 5 — implements tasks from TASKS-<N>-<slug>.md (with ARCH-<N>-<slug>.md as architecture-only context) using mode-appropriate verification (tdd, test-after, ui, checklist); pass 'auto' to run without stepping. Use only when the user asks to run Phase 4 or implement tasks from an ARCH doc — never trigger automatically from a coding request.

move-to-worktree

After /start-task: park the current clean, pushed feature branch in its own issue-numbered nested worktree (.worktrees/<issue#>) and return the primary checkout to current main, so the next parallel lane can start. Use when the user says to move the branch or task to a worktree or open a parallel lane.

plan-architecture

Phase 2 of 5 — collaborative system design plus change-footprint mapping; outputs an ARCH doc for generate-tasks. Use only when the user asks to run Phase 2, plan the architecture, or design the solution — never trigger automatically from a design question.

plan-qa

Post-implementation QA planning — independent of /review (the developer chooses whether to run them sequentially or in parallel), only when the change has a running surface worth driving. Interviews the developer to turn the specs and the diff into an executable QA specification (specs/qa/QA-<N>-<slug>.md) that /execute-qa runs. The agent drives browser and shell; the human steps in only at named handoff points. Use only when the user asks to plan manual QA — never trigger automatically.

Web & Frontend Listed

plan-requirements

Phase 1 of 5 — Socratic interview capturing WHAT and WHY; outputs a sprint-sized REQ doc for plan-architecture. Use only when the user asks to run Phase 1, plan requirements, or start the requirements interview — never trigger automatically from a feature description.

release-notes

Draft a changelog for the next release by summarizing git commits since the last tag. Use only when the user asks to draft release notes, write a changelog entry, or prepare the next version's notes — never trigger automatically.

review

Phase 5 of 5 — triage-first review orchestrator; dispatches up to 17 domain checks in parallel and compiles one report. Use only when the user asks to run Phase 5 or review a PR, branch, or set of changes — never trigger automatically after writing code.

setup-cost-tracking

Install genuine per-session cost tracking for Claude Code by wiring bundled logger scripts into the user's statusline — preserving any existing statusline and hooks. Use when the user asks to set up, install, enable, or repair cost tracking / cost logging / session cost capture. Idempotent; safe to re-run.

start-task

Bootstrap a task into a synced feature branch — one shot, zero confirmations. Detects the source from the args: GitHub issue ('#100', 'issue 100', 'gh issue 100', or bare '100'), Jira key ('PROJ-42'), or a local spec file path; ad-hoc conversation otherwise. Fetches the task, derives {type}/{number}/{slug}, syncs the default branch, creates and pushes the branch, and writes specs/context/<id>.md. Use only when the user explicitly asks to start a task or create a work branch — never trigger automatically.

sync-skills

Copy this repo's skills into another agent harness's skills directory by name — resolves the harness alias to its path via scripts/sync-targets.json and runs sync-skills.sh. Use only when the user asks to copy/sync/push the skills to another harness (oh-my-pi, opencode, kimi, codex, etc.) — never trigger automatically.

session-audit

Audit Claude Code session logs (~/.claude/projects) for token waste and produce a ranked, attributed efficiency report (habit / skill_file / config). Use when the user asks to audit session efficiency, analyze token waste or cost blowups, review Claude Code usage cost, or asks "where are my tokens going".

finish-worktree

After an issue's PR has squash-merged on GitHub and its issue has closed: fast-forward the default branch, remove the issue-numbered nested worktree (.worktrees/<issue#>), and delete the local feature branch. Use when the user says to finish, tear down, or clean up a lane or worktree for a merged issue.

session-stats

Render a dashboard of the current Claude Code session — message counts, token usage, cache read/write, dollar cost, context %, lines changed, cost-per-turn sparkline, and a tool-call histogram — parsed from the session transcript JSONL by a bundled bash script. One bash call, zero analysis, zero confirmation. Optionally pass a session id to inspect a different session. Use when the user asks for session stats, usage, token or cost breakdown, or a session dashboard.