Workflows
Trending
Small Feature Ship Workflow A reusable workflow for shipping small product or engineering features with minimal human coordination and clear agent ownership. This workflow is optimized for small, bounded changes where the goal is to avoid process overhead while still protecting product judgment, implementation quality, and release safety. How to Use When a user makes a small feature/change request in chat, treat this workflow as the operating procedure and execute s001 → s004 in the same chat session. Intermediate artifacts (decision brief, adversarial review prompt, Codex verdict) live in the chat context — no external persistence needed. The final deliverable returned to the user in chat is the PR URL . Role Map | Role | Assignee | Responsibility | | | | | | Feature Owner | human | Owns intent, final judgment, and shipping decision. | | Decision Challenger | Claude Code | Challenges whether the feature should be built, whether the proposed solution is the right one, and what the real problem is. | | Builder | Claude Code | Implements the agreed solution, opens the PR. | | Reviewer | Codex (preferred) / Claude Code (fallback) | Adversarially reviews the PR. Codex owns the verdict when available; otherwise Claude Code performs the same adversarial review against its own work. | | Shipper | human | Reviews the PR, merges/releases, and observes early results. | Core Loop Decide → Build → Check → Ship Four steps. Each step has a clear owner, with explicit handoff artifacts so the next owner can proceed without ambiguity. Operating Principle Do not move forward simply because a feature request exists. The first step must pressure test the request — but right size the scrutiny to the change . A variable rename does not deserve a 9 point brief; a behavior change with user impact does. The Decide step defines what "enough scrutiny" looks like for each tier.
This workflow works with any coding agent that supports Skills, file access, shell commands, and GitHub operations. This workflow turns raw bug reports from a Discord channel into a continuous improvement loop for your product. A lightweight bot converts reports into structured GitHub Issues, a triage skill reads each need triage Issue and labels it as auto fix or manual fix, and an auto fix skill takes auto fix Issues, inspects the codebase, applies small focused changes, runs tests, and opens review ready pull requests. Engineers stay in control through labels and normal code review, while the system quietly handles the repetitive work of sorting bugs and drafting fixes, so the product keeps getting better from real user feedback with less manual overhead.
A battle tested 10 step setup for running multi agent Claude Code workflows: from initial CLAUDE.md config through skills, hooks, MCP connections, PM2 orchestration, parallelization, handoff contracts, done criteria, and verification loops. Synthesized from two sources battle tested over 10+ months of daily use: Shorthand Guide: https://x.com/affaanmustafa/status/2012378465664745795 Longform Guide: https://x.com/affaanmustafa/status/2014040193557471352 Preconditions: Claude Code installed and authenticated Node.js + PM2 installed (npm install g pm2) Git initialized in your project Themes covered: CLAUDE.md context design, skill architecture, hook patterns, session memory, MCP strategy, PM2 orchestration, git worktree parallelization, inter agent handoff contracts, done criteria, and verification loops.
This workflow operationalizes Claude Code Agent Teams for repeatable, collaborative work. Instead of one agent doing everything, you run a team lead (orchestrator) plus multiple teammates (fully independent Claude Code sessions) coordinated through a shared task list and direct messaging. The workflow is designed to be reproducible for other users: Clear inputs and outputs per step Guardrails to reduce data exposure Explicit depends on so parallel work is obvious Orchestrate teams of Claude Code sessions
This workflow sets up a read only assistant that analyzes PRs and CI failures and posts actionable notifications to your team chat. Humans remain the only actors who write to the repository (comments, approvals, merges, reruns). The design emphasizes reproducibility, least privilege, and predictable operations. Primary reference: the original OpenClaw PR review automation guide at zenvanriel.nl. This version improves reproducibility by adding: A hardened, isolated runtime baseline from the official OpenClaw security guidance at docs.openclaw.ai Clear access control practices (pairing, mention only in groups) from docs.openclaw.ai Supply chain guardrails informed by recent public incidents around malicious skills and impersonation attempts reported by Tom's Hardware and TechRadar A pragmatic view on limitations for business use cases and team governance as discussed in eesel.ai