Automating Your Dev Workflow with AI: From Issue to Green PR in Minutes

Overview

What if every pull request you pushed was already tested, security scanned, and code reviewed before you even created it? That's exactly what the upgraded /start-issue skill does in my open source gopher-ai repo.

The Problem

AI-assisted development is fast. Maybe too fast. When you're shipping features and fixes at speed, quality gates get skipped. I noticed a few gaps in my own workflow:

• My bug workflow said "write a failing test" but never actually verified the test failed. That's not real TDD.
• No security scanning before PRs. Dependency vulnerabilities, hardcoded secrets, SQL injection — none of it was being caught automatically.
• No independent code review. I was trusting a single AI to write and validate its own work.
• The verification step was vague. "Verify your work" doesn't mean anything specific.

I decided to fix all of this at once by upgrading my /start-issue skill. Issue #15 covers the full scope.

Setting Up Claude Code

Before we dive in, let me share the alias I use every single day. I run Claude Code with permissions bypassed 100% of the time so I don't have to approve every file write and command:

alias clauded='claude --debug --dangerously-skip-permissions'

Add this to your ~/.zshrc or ~/.bashrc:

echo "alias clauded='claude --debug --dangerously-skip-permissions'" >> ~/.zshrc
source ~/.zshrc

Now instead of typing out the full command with flags, you just run clauded and you're off to the races. The --debug flag gives you extra output for troubleshooting, and --dangerously-skip-permissions means Claude won't stop to ask you to approve every file read, write, or command execution.

Kicking Off the Workflow

With clauded running, I start the workflow:

/start-issue 15 --plan

The --plan flag is important. Plan mode forces Claude to read the issue, analyze it, and build a full implementation plan before it writes a single line of code. Without plan mode, Claude tends to jump straight into coding and sometimes misses the bigger picture. Plan mode makes it think first, then execute.

For this issue, I also used a worktree. Worktrees let you spin up multiple Claude Code sessions on different issues at the same time, each in their own isolated branch. When you're working on a bigger issue, worktrees keep everything clean.

The Four Upgrades

Here's what issue #15 asked for, and what Claude built while I narrated the video.

1. TDD Enforcement

Before: The bug workflow said "write a failing test" but never checked that the test actually failed. That's certainly not real TDD.

After: The workflow now runs go test, confirms the test actually fails, and only then moves on to the fix. After the fix, it runs go test again and confirms the test passes. Red-green-refactor, done properly.

The feature workflow gets the same treatment. Tests first, implementation second.

2. Security Scanning

Before any PR gets created, the workflow now runs:

• govulncheck to check for dependency vulnerabilities
• File scanning on all changed files for common issues:
  • Hardcoded secrets
  • SQL injection
  • Path traversal
  • Unsafe exec commands
  • Missing error checks

If the changes touch auth or crypto code, it even suggests running a Codex review with a security focus. This catches vulnerabilities before they ever reach a human reviewer.

3. Pre-PR Code Review

This is something I'm really big on. I always use one LLM to validate the other. If I do work in Claude, I use Codex to review it. If I work in Codex, I use Claude to review it. They catch different things — it's like having a second pair of eyes on every single PR.

The upgraded workflow now suggests running that independent review before creating the pull request. It's optional and won't block the PR, but it's wired right into the flow so you don't forget.

4. Stronger Verification

Before: A vague "verify your work" step that didn't specify what to actually check.

After: An explicit checklist:

Nothing gets pushed until everything is green.

The CI Feedback Loop

One of the things I love about this workflow is what happens after the PR is pushed. Claude runs gh pr checks --watch and monitors the CI pipeline. If the checks don't pass, it pulls down the errors, fixes them, and pushes again automatically. It stays in that feedback loop until the PR is green.

This means by the time I look at the PR, it's already passing. No orphaned red checks, no context switching back to fix trivial CI failures.

The Results

Claude handled the entire thing while I talked through it on camera. You can see the final output in PR #22. One file changed — plugins/go-workflow/commands/start-issue.md — with 113 lines added and 16 removed. All four improvements are implemented and passing CI.

Key Takeaways

1. Plan mode prevents Claude from jumping into code without understanding the full scope of the issue
2. TDD enforcement means tests actually prove something — verified failures before fixes, verified passes after
3. Security scanning catches vulnerabilities before they reach review — govulncheck plus file-level scanning
4. Cross-LLM review provides independent validation — don't let the AI grade its own homework
5. Explicit verification replaces vague "check your work" — specific commands, specific pass/fail criteria
6. The CI watch loop ensures PRs are always green — automated fix-and-push until all checks pass

Get Started

Everything you saw in this video is open source. Clone the gopher-ai repo, fork it, and make it your own.

Drop a comment and tell me what skill you'd like me to build or demo next. Maybe it's a code review workflow, a deployment automation, a testing pipeline — whatever it is, I actually build these based on what people ask for. Your comment might be the next video.