Note: The configuration for the specific tools mentioned is documented in the repository’s Markdown file. If anything is unclear, you can also leave a comment in this thread, and I’ll reply to each one.
Open-source self-recommendation—I’ll start by sharing the link: GitHub - dream-rec/pitayax: personal code workflow. · GitHub
Installation command: npx dream-wf, supporting claude code, cursor, codex, and opencode
Main Content
Lately, I’ve increasingly felt that the biggest problem with code agents isn’t that they “can’t write code,” but that they “start writing code too quickly.”
A lot of the time, the user says only, “Help me optimize this,” and the agent immediately starts modifying files, refactoring logic, and casually adding configuration. It looks proactive, but it’s also dangerous: the requirements haven’t been confirmed, the code hasn’t been fully understood, and external APIs may still be based on outdated knowledge. In the end, the implementation drifts further and further from what was intended.
So these days, I prefer to give an agent a workflow rather than just a task.
The combination is:
This isn’t simply a pile of tools. Each tool fills in one of the parts of an agent workflow that is most prone to problems:
-
Trellishandles the process. Its strength is that its harness engineering is very comprehensive: task status, PRDs, design, implementation plans, checklists, hooks, and spec updates can all be connected. Compared with an ordinary TODO list or “write a plan first,” Trellis is more like laying down an engineering track for the agent. -
grill-mehandles clarification. It doesn’t conduct open-ended brainstorming; instead, it asks one key decision at a time and provides options along with a recommended answer. Compared with common PRD templates, it places less burden on the user and makes it easier to turn vague requirements into actionable decisions. -
fast-contexthandles code reading. Its core strength is precisely retrieving context and code snippets. Compared with relying solely on grep to search for keywords, it is better suited to semantic questions such as “Where is this behavior implemented?” and “Which files are involved in this feature?” This allows the agent to obtain the right context before modifying the code. -
grok-searchhandles checking external facts. Its strengths are precise web searches, webpage fetching, and returning source URLs. Compared with having the model answer from memory, it is better for verifying the latest documentation, APIs, configuration formats, and release status—turning “I remember” into “I’ve checked.”
Together, they solve one problem: making sure the agent knows why it is writing something, where to write it, and what evidence it is relying on before it starts coding.
Trellis: Taking Tasks Out of Chat
Trellis is the backbone of this workflow.
Its value isn’t that it generates a few more documents, but that it records requirements, design, implementation plans, and checklists in the project instead of leaving them scattered across chat logs.
A complex task has clear states and artifacts:
prd.mdrecords the requirements;design.mdrecords the design;implement.mdrecords the implementation plan;check.jsonlrecords checkpoints;- the task status progresses from
planningtoin_progress.
This means the agent no longer works from “memory,” but from facts recorded in the project.
design.mdserves the role of a TRD in the traditional sense, so anyone with product design experience should be quite familiar with this workflow.
My understanding is that Trellis doesn’t make the agent more verbose; it gives the agent context, boundaries, and the ability to hand work over properly.
grill-me: Ask Less, but Ask the Right Questions
When many agents clarify requirements, they either guess without asking or throw a dozen questions at you all at once.
The style of grill-me is more like that of an experienced product colleague:
- Ask only one question at a time;
- provide 2–3 options;
- give a recommended answer;
- don’t ask the user about things that can be found in the code;
- update
prd.mdimmediately after the user responds.
The point isn’t to “ask more questions,” but to make sure that “each question resolves one key decision.”
For example, instead of asking:
How would you like to optimize the login flow?
It asks:
When login fails, should we show a generic error, or display a specific message based on the error type? I recommend the latter because the current project already has a form-error component, so the change is small while the user experience improves significantly.
Questions like this are easier for users to answer, and the agent is less likely to go off course.
fast-context: Understand the Codebase Before Taking Action
A codebase isn’t just a collection of strings.
Often, we don’t know which function name to search for—we only know a behavior:
- Where is the redirect after login handled?
- Where is the MCP configuration written on each platform?
- Where is task-state progression defined?
- Which files are involved in a particular feature?
These kinds of questions are easy to miss with ordinary keyword searches.
The distinguishing feature of fast-context is semantic retrieval. It is better suited to helping an agent build a map of the codebase first: which files are relevant, how the logic connects, and where changes might have an impact.
I generally put it at the very first step before implementation:
First use
fast-contextto find the context, then use precise searches to fill in the details.
This reduces a very common error: the agent sees only a local match and assumes it understands the whole picture.
grok-search: Don’t Write New Code Based on Outdated Knowledge
Another mistake code agents often make is treating knowledge from their training data as today’s facts.
But development environments change too quickly:
- APIs change;
- configuration formats change;
- hook event names are updated;
- packages may move;
- documentation may already be different.
So I have grok-search handle external knowledge verification.
In particular, before confirming the PRD, the agent needs to check technical assumptions that may have become outdated, such as:
- whether the startup command for a particular MCP server is correct;
- whether the hook configurations for Cursor / Codex / Claude Code have changed;
- whether a dependency package is still available;
- whether the official documentation matches the current approach.
After checking, write the results into Knowledge Verification.
The significance of this step is turning “I remember” into “I’ve verified it.”
When Combined, the Order Is What Matters
The most important thing about this workflow isn’t the tools themselves, but the order.
Trellis defines the task boundaries
↓
fast-context understands the codebase
↓
grill-me clarifies key decisions
↓
grok-search verifies external facts
↓
Confirm the PRD
↓
Begin implementation
The Agent I Really Want
I don’t particularly want an “especially proactive” agent.
I’d rather have a reliable employee (I’m finally getting to experience what it’s like to be the boss):
- knows when to ask;
- knows when to investigate;
- knows when not to take action;
- knows that requirements need to be recorded;
- knows that external facts need to be verified;
- knows to implement only after confirmation.
So, essentially, this trellis + grill-me + fast-context + grok-search workflow isn’t meant to make the agent write code faster, but to help it take fewer wrong turns.
Read first, ask first, verify first, confirm first.
Then write the code.
In the end, this is simply the workflow I normally use for development. I’ve been thinking about it for a long time. I also have an account on the neighboring site, but I still wanted to post this on our NL site as a “friendly exchange” with the community. Hahaha, I really like the free atmosphere here.
