sideline

Selects the next sprint ticket (or a specified one) and opens it in an isolated herdr-managed git worktree — creates the branch, seeds gitignored config (.env.local, .env.preview.local, .claude/settings.local.json), runs direnv allow + pnpm install, and launches a Claude agent inside it. Use this to spin up parallel work on a ticket without disturbing the main checkout.

Diagnose a running Sideline issue — errors, bad behaviour, "why did X happen", or a failed Coolify deployment. Routes read-only investigation to the right source (SigNoz for logs/traces, the Coolify CLI for deploy state, Postgres for data) and includes the full Coolify deploy-failure root-cause procedure (classify transient infra vs real code/migration defect, recommend fix or redeploy). Use when the user says "look into", "check logs", "why did this happen", "deploy/preview failed", "why did Coolify fail", or asks to investigate live behaviour. READ-ONLY; to change deploy config use /update-deploy-config.

Change Sideline deploy configuration — environment variables, secrets, image tags, domains, healthchecks — for dev or prod. All changes go through the majksa-ops GitOps repo (SOPS-encrypted secrets, rendered to env/* branches, applied to Coolify by CI), NOT the read-only Coolify CLI. Use when the user asks to set/rotate an env var or secret, add a deploy config value, or change deployment settings for dev/prod.

Take a reviewed PR all the way to production — merge the feature PR, merge the Changesets "Version Packages" release PR (which publishes and auto-deploys to dev), wait for the dev deploy to succeed, then promote the released apps to prod. Use when the user says "deploy", "ship to prod", "release and deploy", "merge it and deploy", or "merge release, deploy to dev and prod".

Commit, push, open a PR, verify CI, and address code review comments. The delivery loop from local changes to a reviewed PR. Use this whenever the user asks to commit, push, ship, send, or submit changes.

Research, plan, write tests, implement, verify, review, and refactor a story or bug. The full development loop from plan to clean code. Use this whenever the user asks to implement, build, code, fix, or do any development work.

Checks the active sprint for merged PRs and cascades Notion task/story/epic statuses according to the lifecycle rules. Use after merging PRs or to sync stale statuses.

Mark a story or bug as complete after its PR has been merged. Moves stories to Done and bugs to Fixed. Use when the user says a PR was merged or asks to complete/close a work item.

Fetches the next bug or story from the active Notion sprint (bugs always before stories, preferring in-progress work) and implements it task by task. Creates a plan, gets approval, then codes, commits, and updates Notion statuses.

Fetch and implement code review comments on the current PR. Fixes issues, re-runs checks, commits, and pushes. Use when the user asks to address, revise, or fix review comments or PR feedback.

Refactor code with clear before/after explanation. Verifies changes with tests before completion.