English | 简体中文
After Matt Pocock Skills breaks your work into GitHub tickets, grill-engineering runs Codex to implement and verify them, with less manual coordination between tasks.
Get started · Screenshots · Feishu notifications · Agent guide
Matt's grill-me and grill-with-docs help work through an idea. to-spec and to-tickets
turn it into a spec and tickets on GitHub. During development, two problems remain:
- Someone still has to keep the work moving: start the next ticket, follow up on fixes, and handle PRs and merges.
- An agent can report completion while leaving bugs, missing requirements, or breaking existing behavior. Its work needs to be checked.
The agent-run command runs Codex to implement the tickets in dependency order. A separate Codex agent
checks the results against the requirements and sends any problems back to the development agent.
Implementation, verification, and fixes run in a loop, managed by the program.
Once the requirements, tickets, and environment are ready, run this from any directory:
agent-run run <parent-issue> --repo OWNER/REPORunner develops in an independent clone of the remote and leaves your local checkout unchanged. You can continue the same repository and Parent task from different directories.
The main workflow:
flowchart TD
A[Select a ready ticket] --> B[Codex development agent]
B -->|Submit work| C{Independent Codex verification}
C -->|Send problems back for fixes| B
C -->|Pass| D[Ticket PR, checks, and merge]
D --> E{All tickets completed?}
E -->|No| A
E -->|Yes| F{Independent verification of the whole feature}
F -->|Send problems back for fixes| G[Codex development agent]
G -->|Submit fixes for verification| F
F -->|Pass| H[Final PR, checks, and human approval]
H --> I[Merge into the default branch]
Individual tickets can look correct while the combined feature still fails. After all tickets are integrated, another agent checks the whole feature against the original requirements. Any problems go back to a development agent for fixes and another verification pass.
When human input is needed, the run pauses and saves its work. The final PR is merged into the default branch after the maintainer reviews and approves it. See the run reference for execution and recovery details.
status shows what is running and whether anything needs attention. Here is an example task:
history shows the time spent on each development and verification round, along with PR checks and merges.
View the history of a real test run
The run keeps going after the terminal closes. Use stop to pause it and preserve the work,
and resume to continue later.
Follow progress without keeping a terminal open. Once enabled, Feishu sends you a message when a ticket finishes, your input or approval is needed, or the whole task is complete.
Concise mode is the default, covering key progress and anything that needs your attention. Switch to detailed mode to follow each development, verification, and repair round. Cards include available work summaries and execution times, with links to the relevant issue or PR.
View development, verification, and repair notifications in detailed mode
Detailed mode shows when each development round starts, what it delivers, and how long it takes.
When verification finds problems, it also shows the findings and the automatic fixes that follow.
Feishu notifications are optional and off by default; see the notification guide (Chinese) for setup.
Give your agent the following prompt with your repository path and parent issue URL. The agent guide covers installation, setup, and running tasks.
Read https://github.com/GRD-Chang/grill-engineering/blob/main/docs/agent-guide.en.md.
Install agent-run, check that this repository and its GitHub tickets are ready, then start the run.
Repository path: <local path>
Parent issue: <GitHub issue URL>
Let me know when you need input or approval for the final PR.
The current backend is Codex CLI with GitHub, running on Linux. Your agent can follow the guide to install and configure it. Runs use your Codex account quota; models and repair limits can be adjusted through user settings.
For Matt's workflow, see the upstream guide.
This project draws on ideas from ClawSweeper. Thanks to its contributors for sharing their work.
MIT.