6 CLI Tools To Take Your Agentic Coding to the Next Level

Here is a small collection of bash CLI tools that allow you to automate software development through custom agentic coding workflows. Whether you use Claude, Copilot, or another agent, and whether your tasks live in Jira, GitHub Issues, or a local TODO file, these tools connect everything together and keep it running autonomously.

You can build simple wokflows and watch them eat through your backlog or build a highly regulated workflows with Human in the Loop checkpoints. The tools are designed to be modular and pluggable, so you can swap out components as needed.

task-manager

A pluggable wrapper that exposes a single interface for claim, list, view, assign, comment, and transition. Regardless of whether the backend is Jira, GitHub, or a local TODO.md file, it exposes the same interface. Every other tool from this list talks to task-manager, so swapping backends requires zero changes upstream.

task-manager list --project MYPROJ
task-manager claim --project MYPROJ --account-id <id>
task-manager comment MYPROJ-42 "Starting implementation..."

It also implements a concurrency control mechanism for claim to avoid multiple workers stepping on each other’s toes.

plan

Generates a structured plan for an issue and pushes it to the main branch.

plan <issue-key>

fetches the issue details (using task-manager), instructs the agent to explore the codebase and produce a structured plan, then saves it to plans/<issue-key>.md. It commits and pushes the file, posts a link as a comment on the issue, and transitions it to “Awaiting Plan Review”, which acts as a human checkpoint before any code is written.

implement

implement <issue-key>

clones the repo, builds a structured prompt from the issue details, runs the agent, then pushes the result.

When feature branching is enabled, it creates a feature/<issue-key> branch. This can be also activated by adding the label needs-branch to the issue. If branching is on by default, you can skipt it with no-branch. When branching, the agent will create a PR instead of pushing to main, which allows for code review and CI checks before merging.

If a plan file (plans/<issue-key>.md) exists, it’s appended to the prompt automatically, so planning and implementation are loosely coupled.

Rate-limit errors from the agent trigger an automatic retry with backoff.

loop

loop polls for an available issue, claims it, invokes either plan or implement, then repeats. It has two modes:

• Implementation mode (loop --project MYPROJ): delegates to implement
• Planning mode (loop --project MYPROJ --for-planning): delegates to plan

It handles configurable wait intervals between issues to avoid hitting any rate limits and if there are no issues, it waits before polling again.

The agent itself is fully pluggable — loop just calls whatever agent binary is on $PATH. It comes with two implementations of agent: Claude Code and Copilot CLI, but you can swap in any agent that can read from stdin and write to stdout.

factory

factory starts, scales, monitors, and stops workers that run the loop. It’s stateless: all state lives in Docker (or ECS Fargate for cloud deployments).

factory workers 5 --env-file .env    # spin up 5 implementation workers
factory planners 2 --env-file .env   # spin up 2 planning workers
factory status                       # see what's running
factory logs <worker-id>             # tail logs
factory stop --all                   # shut everything down

By default it will use a nodejs dev environment with preinstalled claude or copilot, but you can specify any Docker image you want, so it’s easy to support different agents and languages.

It also supports different runtimes. You can spawn local docker containers or deploy to AWS ECS. The AWS ESC support is still experimental.

worker-builder

If your project is using devcontainers, you might want to generate the worker images based on your devcontainer.

worker-builder build --devcontainer ./myproject --type claude --push

No need to duplicate environment setup logic in a separate Dockerfile.

Configuration

Since everything is configured via environment variables, I prefer to have an .env file per project, so I can keep different credentials and settings separate. So far I’ve used this on five different projects with different tools and different levels of automations. These are small and simple tools, but they fundamentally change the philosophy of software development, putting the human in an overseer role and letting the agents do the heavy lifting.

Clone the repo, set up your .env file with the necessary variables and watch your backlog dissapear!

https://github.com/jaksa76/ai-coding-factory