rustyrazorblade

Activate a groomed GitHub issue for development — create its git worktree and branch, delegate the design to the architect agent (consulting a domain-expert agent for any architectural/data-model decisions), run OpenSpec explore+propose to produce a committed spec, and stop for the owner's spec approval. Second stage of the flow delivery workflow (see docs/workflow.md). This is the human approval seam; it never implements.

Finalize a merged issue — sync the OpenSpec change's delta specs into the canonical specs, archive the change, remove its git worktree, and close the GitHub issue. Final stage of the flow delivery workflow (see docs/workflow.md). Runs after the owner squash-merges the PR in GitHub; it never merges.

Implement an approved issue — run the background subagent team (tdd-developer → 5-lens review panel → fix loop → build-engineer → docs polish) via a Workflow script in the issue's worktree, then push the branch and open a PR. Third stage of the flow delivery workflow (see docs/workflow.md). Requires the owner to have approved the committed spec first. Invoking this skill is the explicit opt-in to multi-agent Workflow orchestration.

Report status across all in-flight delivery pipelines — every issue by lifecycle label with its priority, stage, worktree, and PR state — and highlight what's next and what's blocked on the owner. Use when the owner asks 'where do things stand' or 'what should I work on'. Part of the flow delivery workflow (see docs/workflow.md).

Pull the branch's latest CI test failures into the issue's local flagged set — download the spec-flow-failures artifact from the most recent CI run and append the failing test ids to .spec-flow/flagged-tests in the worktree, so the local loop runs them for the rest of the branch. Part of the flow delivery workflow (see docs/workflow.md, "Test tiering"). Owner-invoked when CI reports red; never polls.

Address the owner's GitHub review comments on an issue's PR — pull the comments, fix them in the issue's worktree, push, and reply per review thread. Fourth stage of the flow delivery workflow (see docs/workflow.md). Owner-invoked when they return after reviewing; never polls.

One-time migration that splits a repo's existing test suite into the fast unit tier and the slow integration tier the flow test-tiering model assumes — classify tests by evidence (container/I-O/timing) and let the compiler + test timings arbitrate, physically separate them (Gradle source set + classpath scoping, or Rust src/ vs tests/ + nextest profiles), wire the CI failures artifact, and open a PR. Run once per repo, before test tiering applies. See docs/workflow.md ("Test tiering"). Never merges.

Turn a rough idea into a scoped, labeled GitHub issue ready for the delivery pipeline. Use when the owner wants to capture a todo, feature, or bug as a real backlog item with scope, acceptance criteria, and a priority. First stage of the flow delivery workflow (see docs/workflow.md).

Interactively generate a new workload install.yaml with typed lifecycle steps. Researches the workload's helm chart, CRDs, and readiness conditions, proposes a draft for review, refines with user feedback, and writes files only on explicit approval.

Commit and/or push workflow for easy-db-lab. Run this skill before every git push. Runs ktlintFormat, handles commit confirmation, then pushes. Pass -a to stage all files without prompting.

Run an integration test against a real AWS cluster. Use when the user says anything like "test it in AWS", "fire up a cluster and test", "run the presto test", "test on a real cluster", or names a specific test. Handles provisioning, surfaces the tail command, monitors progress, and reports results. Does NOT tear down on failure — leaves the cluster running for debugging.

Dynamic end-to-end test runner for easy-db-lab that calls easy-db-lab commands directly. Analyzes branch changes, proposes a test plan, executes commands step-by-step, and investigates failures inline. Use instead of bin/end-to-end-test when you want intelligent, adaptive testing with real-time debugging.

Comprehensive debugging for easy-db-lab environments. Diagnose cluster issues, service failures, connectivity problems, K8s pod failures, SSH issues, and configuration problems. Use when troubleshooting any easy-db-lab deployment or runtime issue.

Kubernetes expert specialized in easy-db-lab's K3s cluster, Fabric8 manifest builders, and K8s-based deployments. Use for K8s architecture questions, manifest building, pod debugging, or understanding how easy-db-lab uses Kubernetes. This is a Q&A expert, not an executor.

Use when archiving an OpenSpec change that adds or modifies specs, or when the user asks to review specs for overlap. Finds specs that describe the same system from different angles and proposes merging them under a more general name.