hongyflow

hongyflow is the set of Claude Code skills and workflows I actually use, kept in one repo and symlinked into my agent config so Claude Code picks them up on its own. The links point straight at the working tree, so editing a skill is live — there's no copy step and no cache to clear. None of it is especially clever; it's mostly my opinions about how software should get built, written down in a form an agent can follow without me hovering over its shoulder.

AI coding agents are quick, capable, and completely undisciplined. Left to their own devices they'll skip the research, skip the review, and start typing — and they've got no real instinct for when a change is risky enough to slow down for.

I wanted the opposite: a loop that insists on the unglamorous parts of a real development lifecycle — gather context, plan, build, harden, review, prove it works — with a clear bar to clear before each step counts as done. It also had to stay portable. I move between Claude Code, Codex, Copilot and OpenCode depending on the job, and I didn't want a way of working that only held together in one of them.

The heart of it is a ten-phase loop with a gate on every phase. A gate is just a check that has to come back green before the work moves on — “it compiles and the plan's criteria are met”, “every blocking review finding is fixed or noted”, that sort of thing.

The loop itself doesn't do the work. Each phase hands off to a smaller, focused skill — research, code review, security, validation — or falls back to an inline checklist when that skill isn't installed. Keeping the pieces small means each one is easy to reason about, and the loop degrades gracefully instead of falling over when something's missing.

The decision I went back and forth on most was letting the loop continue without me. Every gate stays mandatory — but for changes it judges low-risk, the loop evaluates the gate in code and carries on by itself, only pausing for a human at the points that actually warrant one: anything outward-facing, like a push, a PR or a merge, and one final review before it closes.

The safety valve is that eligibility fails closed. If the loop can't confidently call a change low-risk, it treats it as high-risk and checks in. So it handles the routine work start to finish, but it never quietly ships something it shouldn't have.

Nothing in the loop hard-depends on a particular tool. Each phase describes a role — “review the diff”, “run it and watch what happens” — then names a preferred way to do that on Claude Code, with documented fallbacks everywhere else. The skill lives in a cross-agent store shared with `npx skills` and is bridged into Claude Code; the optional Workflow accelerators are Claude-Code-only, and the loop runs identically without them.

One rule keeps the whole thing honest: findings from sub-agents are treated as untrusted until I've read the diff myself. An agent sounding confident isn't evidence.