vs-ship-it
Create PR
Step 0: Ensure review ran
Before shipping, check if roast-my-code was already run in this session.
If not run yet: run it now. Wait for both passes to complete (Pass 1 auto-fixes, Pass 2 presents sins — auto-select option b for critical + serious). Apply fixes before proceeding.
If already run: continue to Step 1.
Step 1: Check state
git branch --show-current && git status -s && git diff HEAD --stat
- Detect username:
git config user.nameor extract from branch prefix - If on
master/main/prod: create a feature branch:
git checkout -b <username>/<feature-name>
Branch name from the diff context — short, descriptive, kebab-case.
Step 2: Commit + Push
If uncommitted changes exist:
If staged files exist (respect user's selection):
git commit -m "<msg>" && git push -u origin HEAD
If no staged files (stage everything):
git add . && git commit -m "<msg>" && git push -u origin HEAD
Commit message: conventional format (feat:, fix:, refactor:, etc.), concise.
Step 3: Generate AI Session Context
Generate a privacy-safe summary for reviewers from the current conversation.
You already have full context of:
- What problem was discussed
- What approaches were considered
- What decisions were made and why
- What trade-offs were evaluated
Synthesize directly from your memory of this session.
What to include vs exclude
| Include | Exclude |
|---|---|
| Problem being solved | Exact user prompts |
| Solution approach chosen | Mistakes/failed attempts |
| Key decisions + WHY | Debugging struggles |
| Trade-offs considered | Personal info/credentials |
| Technical rationale | Anything embarrassing |
Format as collapsible block
<details>
<summary>AI Session Context</summary>
**Problem:** [1 sentence - what was broken/needed]
**Approach:** [1 sentence - solution strategy]
**Key Decisions:**
- [Decision]: [Rationale - the WHY]
- [Decision]: [Rationale - the WHY]
**Trade-offs Considered:**
- [Option A vs B]: Chose A because [reason]
</details>
Skip Conditions
Skip AI Session Context if:
- Trivial change (typo, version bump, config)
- No meaningful decisions were made
- User says "no context" or "skip context"
Step 4: Create PR
Format:
<feature_area>: <Title> (80 chars max)
<TLDR> (1-2 sentences)
- bullet 1
- bullet 2
<details>
<summary>AI Session Context</summary>
...
</details>
gh pr create --title "<title>" --body "<body>"
Display the returned PR URL on its own line so it's clickable.
Step 5: Watch CI
Block until CI checks complete. This keeps the agent in context so it can fix failures immediately without the user having to start a new session and re-explain the change.
gh pr checks --watch --fail-fast
If checks pass: "CI green. Ready for review."
If checks fail:
- Read the failure:
gh pr checks --json name,state,description --jq '.[] | select(.state == "FAILURE")' - Get logs:
gh run view <run-id> --log-failed | tail -50 - Fix the issue, commit, push.
- Watch again:
gh pr checks --watch --fail-fast - Max 2 fix attempts. If still failing after 2: report what's broken, stop.
Tip: while this agent watches CI, the user can open a new terminal and
start a separate claude session to keep working on something else in
parallel.
Workflow
Prev: /vs-roast-my-code (review passed) | /vs-autopilot (handoff suggests ship-it)
Next: /vs-fix-pr (address reviewer feedback) | done
More from vltansky/vladstack
vs-fix
Autonomous bug fix pipeline. Investigates root cause, reproduces with a failing test, fixes, verifies, reviews, and hands back a clean branch. Use when the user says 'fix', 'fix this bug', 'fix this', 'something is broken', 'this doesn't work', or describes a bug to fix. Unlike /debug-mode (investigation only), /fix goes end-to-end: find it, prove it, fix it, verify it.
1vs-tdd
Test-driven development loop. Write failing test first, then implement to make it pass. Use when the user says 'tdd', 'test first', 'write the test first', 'failing test', 'red green refactor', or for any bug fix where the fix should be proven by a test. Also use when autopilot or other skills need test-first execution.
1vs-qa
Systematically QA test a web application and fix bugs found. Runs browser-based testing, iteratively fixes bugs in source code, commits each fix atomically, and re-verifies. Use when asked to 'qa', 'QA', 'test this site', 'find bugs', 'test and fix', or 'fix what's broken'. Three tiers: Quick (critical/high only), Standard (+medium, default), Exhaustive (+cosmetic). Produces before/after health scores, fix evidence, and a ship-readiness summary. For report-only mode, use /qa-only.
1vs-debug-mode
Systematic root-cause debugging with optional runtime log server for frontend/UI bugs. Hypothesis-driven investigation. Use when the user says 'debug', 'debug this', 'investigate', 'why is this broken', 'root cause', 'trace this bug', 'figure out why', 'this doesn't work', 'unexpected behavior', 'UI not updating', 'state is wrong', 'value is null/undefined', 'click doesn't work'. Also use instead of adding console.log — this skill collects logs automatically.
1vs-autopilot
Autonomous plan-to-code pipeline. If no plan is provided, auto-generates one via a plan-mode subagent. Stress-tests the plan (using grill-me), fixes issues found, creates a branch, executes step by step with guardrails, runs code review and QA, then hands back a shippable branch. Zero human interaction until the final handoff. Use when the user says 'autopilot', 'just build it', 'auto execute', 'implement this plan', 'take it from here', or wants to go from plan to working code without babysitting.
1vs-grill-me
Structured adversarial review that pushes back on a plan, challenges the premise, compares alternatives, and stress-tests the design until the main risks are explicit. Use when the user asks to "grill me", stress-test a plan, poke holes in an approach, challenge assumptions, pressure-test a design, or validate an early-stage idea before building ("I have an idea", "is this worth building", "grill me on this idea").
1