photobombastic

Fully understandable, it's an AI minefield out there! I wrote everything except the technical summary of what I'd updated, just so you know...Claude only helped me there to explain what had changed.

Good question, thanks. PipeStep is specifically for debugging CI pipelines, not general LLM/flow orchestration. The target user is someone staring at a failing GitHub Actions run who's tired of the commit-push-wait-read-logs cycle. You point your existing workflow YAML at it, it spins up the same Docker container, and you step through interactively. It's more like gdb for CI than a pipeline framework — no new DSL, no lock-in, you just debug your existing workflow and push the fix.

Love this idea — just shipped it. PipeStep now records every step you run/skip/shell-into and saves a bash script on quit (pipestep-session-YYYYMMDD-HHMMSS.sh). Should be useful for reproducing debugging sessions and as a starting point for tests.

Thank you so much! Huge bug. Action steps (uses:) were silently skipped, which meant any workflow relying on setup actions would just fail.

This should be fixed in v0.1.3. Action steps now pause instead of auto-skipping, and PipeStep offers to run a local equivalent when one exists. It also parses with: inputs, so setup-node with node-version: 18 actually installs Node 18 in the container. Currently supported: checkout, setup-node, setup-python, setup-go, setup-java, cache, upload/download-artifact. Anything unrecognized gives you a clear pause to run commands manually.

Would genuinely appreciate it if you gave it another shot (pip install --upgrade pipestep) and if you hit anything else, issues on GitHub would be incredibly helpful. The "why did you think I wrote them?" line was exactly the kind of thing I want more of.

I have been experiencing this as a (don't judge) full-time vibe coder without an engineering background. tmux helps a little. I'm leaning towards embracing YOLO mode (in CC) + writing very detailed specs. That way, the attention goes into the specs.

I'm going to assume you meant "would've" hah. Would love to know how I could improve it!

I love this. Would be really valuable to add semantic search on signal type, not just quality. For example if I'm looking for someone who might be good to recruit for my team, or who is building a competitor, etc.

This is a real problem. I've heard similar stories from people running CI pipelines — a retry loop bug burns through your entire monthly Actions minutes budget in hours, and there's no built-in circuit breaker there either.

The approach of tracking usage locally and cutting off before you hit billing overages makes a lot more sense than trying to parse the billing API after the fact. Prevention over detection.

Could be cool to set per-worker limits in addition to the global ones.

The "context rot" framing is spot on. I've seen the same thing discussed a lot in CI/CD tooling circles — agents lose track of what's already been tried and start suggesting the same fixes in loops.

Storing the reasoning as markdown in git is a clever move. It means the context survives not just across sessions but across team members too. Someone can pick up a task and see why certain approaches were rejected, not just the final code.

Curious if you've found that agents actually read the prior context reliably, or if you need to explicitly inject it at the start of each session.

The core git hosting has been solid for me, but Actions has been noticeably flakier in recent months. More random runner timeouts, longer queue times for larger runners, and occasional runs that just silently hang.

The frustrating part isn't the outages themselves — it's that the feedback loop for debugging them is so slow. A step fails, you read logs, make a guess, push, wait 5 minutes for the run to get to the same point, and repeat. There's no way to inspect the state of a runner mid-pipeline or retry a single step without re-running the whole workflow.

Reliability issues hurt more when your only debugging tool is "push and pray" (im a recovering vc)

Building a step-through debugger for GitHub Actions workflows called PipeStep (https://github.com/Photobombastic/pipestep).

The idea came from the commit-push-wait-read-logs cycle that everyone seems to accept as normal when debugging CI. PipeStep parses your workflow YAML, spins up the right Docker container, and lets you pause before each step, inspect the container, shell in, set breakpoints, skip or retry steps. It deliberately doesn't try to replicate the full Actions runtime — no secrets, no matrix builds, no uses: execution. For that, use act. PipeStep is specifically for when something breaks and you want to figure out why without pushing 10 more commits.

Think of it as gdb for your CI pipeline. pip install pipestep, Python 3.11+, MIT, requires Docker.

very cool idea! in my experience most users don't want anything that requires more than 1 prompt (usually to their detriment), but you perhaps you can help them build a better prompt up front via multi-field input?