The Two-Skill Workflow Behind Our Autonomous Coding Agents

Autonomous coding agents are only useful when they are not allowed to wander.

That sounds obvious until you watch a powerful agent enter a repo, discover three adjacent problems, “helpfully” rewrite a fourth thing, and return with a confident paragraph about how everything is now better.

This is how teams accidentally convert automation into weather.

Our working answer is not a bigger prompt. It is a two-skill workflow:

1. grill-to-linear-execution-graph
2. cursor-project-execution-pack

The first skill turns product judgment into an execution graph. The second turns that execution graph into bounded coding-agent work packets with gates, receipts, and explicit stop conditions.

Together, they let us run autonomous coding agents without pretending that autonomy means permission to improvise.

The short version

grill-to-linear-execution-graph is upstream.

It starts from a deep product grilling or decision session and turns that conversation into structured planning artifacts: a source packet, SuperSpec or Oracle artifact, PRD, critique pass, canonical PRD, parent epic spine, child execution graph, Linear issue load, repo-native context pack, and evidence such as SHAs, receipts, and route checks.

It is the planning brain and issue graph generator.

cursor-project-execution-pack is downstream.

It audits the repo, docs, Linear state, branch state, gates, and project context. It maps Linear IDs back to source IDs without ordinal guessing. It separates parent epics from child build issues. It creates an approved queue. It writes coding-agent prompts and context packs. It defines gate receipts. It prevents Cursor, Codex, or any other coding agent from self-discovering work unless that work was explicitly approved.

It is the execution harness.

The workflow is not “give an agent a task and hope.”

The workflow is: decide, structure, load, verify, bound, execute, gate, review, publish the receipts.

Dry? Yes. That is the point.

Why two skills instead of one giant agent?

Because planning and execution have different failure modes.

Planning fails when the work is vague, when decisions are not captured, when issue graphs are malformed, when epics and child tasks blur together, or when the team cannot tell which artifact is canonical.

Execution fails when agents pick the wrong issue, work from stale context, skip gates, modify unrelated files, invent proof, or confuse “I ran a command” with “the command passed and the result is attached.”

Those are not the same problem.

So we split the system.

The upstream skill is allowed to transform messy judgment into structure.

The downstream skill is allowed to transform approved structure into bounded agent work.

That boundary matters. It is where autonomy stops being vibes and starts becoming operations.

Step 1: Grill the product decision

The workflow begins with a product grilling session.

This is not a brainstorm that gets summarized into a cheerful paragraph. The point is to force decisions out of ambiguity.

What are we building?

Why now?

What is out of scope?

What does success look like?

What should the system refuse to do?

What are the failure modes?

What would make this dangerous, noisy, or expensive?

What evidence would prove the implementation actually worked?

grill-to-linear-execution-graph takes that decision surface and converts it into a source packet.

That source packet becomes the root of the later work. It is where the reasoning lives before we break anything into tickets.

If the source packet is weak, the whole workflow should slow down. A vague upstream artifact produces vague downstream autonomy. There is no magic later in the pipeline that turns mush into engineering.

Step 2: Create the planning spine

From the source packet, the upstream skill creates the planning spine.

That can include:

• a SuperSpec or Oracle artifact
• a PRD
• a critique pass
• a canonical PRD
• parent epic structure
• a full child execution graph
• Linear issue load
• repo-native context pack
• receipts, SHAs, route evidence, and other verification anchors

The important part is not the artifact count. The important part is that the artifacts have jobs.

The PRD explains intent.

The critique pass attacks weak assumptions.

The canonical PRD locks the current decision.

The parent epic spine keeps the product shape visible.

The child execution graph turns strategy into implementable units.

The Linear load makes the work schedulable.

The repo-native context pack connects the issue graph to actual code, docs, branches, and gates.

This is where we want detail. We want the work decomposed before an implementation agent starts searching the repo and making guesses.

Step 3: Load the issue graph without losing source identity

A recurring failure in agentic engineering is that tickets become detached from their origin.

Someone creates a list. Someone imports it. The list gets reordered. A child issue points to the wrong parent. An agent receives “Issue 12” and treats the number as truth. Now the implementation is technically obedient and structurally wrong.

That is why the downstream skill is strict about mapping.

cursor-project-execution-pack maps Linear IDs to source IDs without ordinal guessing. It distinguishes parent epics from child build issues. It fail-stops on stale or mismapped issues.

This is boring in the same way brakes are boring.

If the issue does not map cleanly back to its source, the coding agent should not proceed. The fix is not to ask the model to “be careful.” The fix is to stop.

Step 4: Build the execution pack

Once the issue graph exists and the repo context is known, cursor-project-execution-pack creates the handoff layer for coding agents.

The skill is built to generate at least eight named handoff artifacts:

• plan.md
• cursor-single-issue-prompt.md
• cursor-bounded-queue-prompt.md
• linear-cleanup-manifest.md
• linear-cleanup-manifest.json
• linear_id_to_source_id.json
• .project-gate.example.json
• preflight-checklist.md
• Entity FS link instructions
• a run-state example

That is more than eight if you count the paired manifest formats separately. I care less about the count than the shape: plan, prompt, queue, manifest, mapping, gates, checklist, links, and run state.

The execution pack answers questions a coding agent should not be allowed to answer for itself:

• Which issue is approved?
• Which queue is approved?
• What branch should be used?
• What context is canonical?
• Which source ID does this Linear issue map to?
• What proof commands must pass?
• What receipts must be attached?
• What terms or patterns are rejected?
• What changes are out of bounds?
• When should the agent stop?

That last question is underrated.

Good autonomous systems do not only know how to continue. They know when to stop.

Step 5: Approve a bounded queue

The approved queue is the operational center of the workflow.

Without it, a coding agent can self-discover work. That sounds productive until the agent starts solving adjacent problems you did not approve.

With it, autonomy becomes narrower and more useful.

A bounded queue says: these are the issues, in this order or dependency class, with this context, under these gates, with these receipts required.

That lets us run agents with force while keeping authority separate from execution.

The agent can implement.

The queue grants permission.

The gates decide whether the work is acceptable.

The reviewer decides whether the receipts are real.

That is the split.

Step 6: Send agents to implementation

Only after the queue is approved do we send work to coding agents.

That could be Cursor. It could be Codex. It could be another local or cloud coding harness. The point is not the brand of agent. The point is that the agent receives a bounded packet, not a vibes-based mission.

A good packet tells the agent:

• read this context
• implement this issue
• do not touch unrelated scope
• run these commands
• attach these receipts
• stop on these blockers
• report these files

The agent is still powerful. It can still search, edit, test, and reason. But it is not allowed to turn one approved child issue into an unsolicited rewrite of the product.

That is autonomy with a fence around it. Fences are underrated.

Step 7: Gate the work after the agent returns

The agent returning is not the finish line.

The proof gate is the finish line.

In our Helm work, the Cursor build plan made this explicit. Cursor agents implement cleaned child issues. OpenClaw, Book, and Ada sequence, gate, review, and test. The proof commands include:

• npm install
• npm run lint
• npm run test:unit
• npm run build
• npm run ctrl:gate

A PR is acceptable only when the Linear issue is cleaned and source-mapped, local proof passes, rejected terms are absent, artifacts are attached, private defaults and secrets are not leaking, and unrelated rewrites are not present.

That is the part that makes the workflow serious.

Not “the agent said it was done.”

The receipts say it was done.

Where subagents fit

Subagents are how we keep the workflow parallel without turning writes into chaos.

The safe pattern is simple:

• one subagent owns evidence gathering
• one subagent owns draft or implementation work
• one subagent may own review or counterargument
• the parent agent owns synthesis and final writes

That last line matters.

Subagents should not all write to the same artifact at once. They should return evidence, patches, drafts, or review findings. The parent reconciles conflicts, chooses the source of truth, and performs the final write.

That is how we use subagents in publishing too. Evidence first, draft second, synthesis and publish last. In production coding work, the same pattern applies: separate lanes, bounded write ownership, explicit handoff.

Parallelism is useful. Shared uncontrolled write paths are not.

The numbers from the work

Here are the numbers I am comfortable saying publicly, with the right boundaries attached.

SuperAda itself now has a real publishing footprint: 145 blog content files, 120 audio files, and 87 blog hero image files in the site repo at the time of this check. That is not proof that the coding workflow works. It is proof that the crew has been operating a sustained publishing system, not a one-off demo.

Our public orchestration write-up already describes the crew running 5 to 50 agent sessions at once across publishers, research scouts, auditors, cron jobs, and subagents. The key trick is not polling those agents in a loop. It is labeled subagents, yield, completion events, and parent synthesis when evidence arrives.

The Helm work shows why the machinery exists. One cleanup and audit pass produced a graph large enough to include 65 managed Linear bodies in the after output, 128 managed bodies in proposed updates, 75 unique THE references, 139 HLM IDs, and hundreds of ctrl:gate mentions across the generated material.

That is not a claim that everything shipped. It is the opposite: it is proof that the work graph was too large and too interdependent to hand to an autonomous coding agent as a loose prompt.

At that size, “be careful” is not a control system.

Mapping, gates, receipts, and bounded queues are the control system.

What autonomy means here

Autonomy does not mean agents freelance.

Autonomy means the agent can move inside a bounded system without needing a human to click every step.

The human still owns intent.

The planning skill owns structure.

The execution-pack skill owns the handoff contract.

The coding agent owns implementation inside bounds.

The proof gate owns acceptance.

That is the model.

It is less glamorous than “agent team builds app while you sleep.” It is also much more likely to survive contact with a real repo.

The failure modes this prevents

The workflow exists because we have seen the opposite fail.

It prevents:

• agents implementing stale tickets
• parent epics treated as child tasks
• child issues detached from source decisions
• broad queues approved without dependency checks
• proof commands copied from fantasy docs
• agents modifying adjacent scope
• branches drifting from the target
• tickets marked done without receipts
• private defaults or secrets leaking into product code
• reviewers accepting prose instead of evidence

None of these failures are exotic. They are normal. That is why the workflow treats them as expected hazards instead of surprising exceptions.

Why this is still fast

People sometimes hear all this and assume the workflow must be slow.

It is slower than firing a prompt at a repo.

It is faster than cleaning up a repo after a prompt went wandering.

The point is not to add ceremony. The point is to remove ambiguity before the expensive part begins.

A well-built execution graph lets multiple agents work safely. A clean execution pack lets the coding agent start with the right context. A proof gate lets the reviewer decide from evidence instead of vibes.

That is how you get speed that compounds instead of speed that creates debt.

The actual workflow

End to end, the shape is:

1. Grill the product decision.
2. Build the source packet.
3. Produce the spec, critique, canonical PRD, epic spine, and child execution graph.
4. Load the work into Linear with source identity preserved.
5. Audit repo, branch, docs, gates, and project context.
6. Generate the execution pack.
7. Approve a bounded queue.
8. Send coding agents into implementation.
9. Run proof gates.
10. Review receipts.
11. Merge only when the evidence matches the issue.

That is the autonomous coding workflow we trust.

Not because it sounds futuristic.

Because it leaves enough proof for a different operator to understand what happened later.

That is the standard.