How Two Skills Turned Autonomous Coding From Theater Into Workflow

The useful part of autonomous coding was not that an agent kept typing for a long time.

Typing is cheap.

The useful part was turning the work into a controlled convoy: product decisions became issues, issues became approved execution packets, agents worked from bounded context, subagents handled narrow slices, and final gates decided whether anyone was allowed to say done.

That is the difference between an autonomous coding demo and an autonomous coding workflow.

We learned it the expensive way. Naturally.

The two-skill chain

The core pattern uses two skills.

The first skill is grill-to-linear-execution-graph.

Its job is upstream. It takes a messy decision session and turns it into a buildable graph:

• source packet
• SuperSpec or Oracle pass
• PRD pass
• critique pass
• canonical merged spec
• parent epic spine
• child execution issues
• repo-native context pack
• receipts

It exists because a list of parent epics is not an execution plan. Parent issues are a skeleton. The child graph is the body.

The second skill is cursor-project-execution-pack.

Its job is execution control. It turns a Linear-backed project into a repo-native pack an autonomous coding agent can actually run:

• source-of-truth audit
• issue mapping
• stale issue cleanup
• approved queue
• Cursor or Codex prompts
• proof gates
• CLI Tester and Book review gates
• run-state
• receipt rules
• reconciliation back to the issue graph

Together, they make the work less magical and more inspectable.

One skill decides and decomposes. The other skill routes and proves.

That is the whole trick, minus the bruises.

The numbers from the convoy

Here is the snapshot that made the workflow real.

During the autonomous coding run, we measured the build at:

• about 23 hours and 39 minutes from the first autonomous coding commit
• 23 hours and 48 minutes if counting setup/context commit
• 56 hours and 40 minutes from the original Linear/source-load planning timestamp
• 13 parent epics
• 74 Linear child tasks
• 50 of 74 child tasks done at the measurement point
• 1 task in progress at the measurement point
• 23 remaining after current
• 67.6 percent done by completed child tasks
• 68.9 percent touched including the in-progress task

That was not a toy loop. It was about a day of autonomous build time with roughly two-thirds of the child task graph completed at the measurement point.

Later, the Phase 2 closure path produced the more important receipt: the integration branch phase2/the-21-through-the-95-complete reached PASS through npm run ctrl:full.

That final gate covered:

• ctrl:gate, meaning build, scan, and tests
• test:live, meaning sandbox live API smoke
• test:deploy, meaning deploy path checks

The live sandbox API returned 21 tasks during the proof run. Then the branch was merged to main, pushed, and origin/main...HEAD synced cleanly.

That is the part I care about. Not that an agent wrote code. That the work ended with a receipt.

Where subagents helped

Subagents were not decoration. They were how we kept narrow work narrow.

When a local-deep-research regression showed up, the broad problem looked like this:

• a Docker compose model path had drifted
• a backend model endpoint was cold
• raw Docker containers looked orphaned
• the fix needed to be reusable across the crew, not buried in one chat

Instead of putting all of that into one giant agent blob, we split it.

One subagent fixed the exact local-deep-research model regression.

Another removed confirmed dead Docker containers while preserving intentional raw Docker services.

Another created and deployed the shared local-deep-research-repair skill across Crew Home.

The results were concrete:

• local-deep-research-repair was created with a SKILL.md and executable scripts/repair.sh
• the repair script was tested against the real service and reported OK_GOOD_MODEL_ALREADY
• a synthetic drift test confirmed it could detect FOUND_BAD_MODEL
• shared-skills verify local-deep-research-repair returned ALL GOOD
• the installer linked the skill into 6 agent directories: Ada, Book, Geordi, Scotty, Spock, and Zora
• docker-orphan-remediation also verified ALL GOOD
• both skills showed 12 OK checks across the crew skill links
• the live container still had the correct LDR_LLM_MODEL

That is the subagent pattern in miniature.

Do not ask one agent to become a fog machine. Give each one a bounded job, then verify the artifacts yourself.

A second example: agent-reach

The same pattern showed up when we set up agent-reach for the crew.

The final receipt was not “installed some tools.” It was a channel matrix:

• before: 6 of 13 channels OK
• after: 8 of 13 channels OK
• warnings: 5 of 13 channels
• off: 0 of 13 channels
• LinkedIn MCP was live through mcporter as a 17-tool server

The remaining five warnings were not install failures. They were human credential or browser-login gates:

• Twitter cookies
• Reddit OpenCLI browser extension
• Xiaohongshu OpenCLI browser extension
• Xiaoyuzhou Groq key
• Xueqiu login cookie

That distinction matters. A good agent report separates install work from human-auth work. Otherwise you get fake green.

Fake green is how agents become expensive furniture.

The actual workflow

The pattern now looks like this.

First, interrogate the work.

Use the upstream skill to turn intent into a real graph. Do not let the agent begin from a vague project wish. Convert the wish into source material, spec passes, critique, parent epics, and executable child issues.

Second, prepare the execution pack.

Use the execution skill to create the approved queue, repo prompts, context files, gates, and receipt rules. The coding agent should not wander through the repo looking for purpose. It should have a manifest.

Third, spawn narrow subagents.

Give subagents small scopes with acceptance criteria:

• inspect this subsystem
• repair this drift
• produce this shared skill
• verify this route
• classify this set of containers
• generate this evidence packet

Fourth, synthesize and verify.

The parent agent does not trust subagent self-report. It reads the files, runs the commands, checks the receipts, and reconciles the state.

Fifth, close with a hard gate.

For Entity Phase 2, that meant npm run ctrl:full. The exact command will differ by project, but the principle should not: build proof, live proof, deploy proof, then final receipt.

What this produced

The output was not just code.

It produced:

• a 74-child-task execution graph
• a day-scale autonomous coding convoy
• a measured 67.6 percent completion snapshot during the run
• a final Phase 2 integration branch that passed ctrl:full
• live sandbox proof with 21 tasks returned by the API
• reusable execution-finalization logic
• a shared local-deep-research repair skill
• a shared Docker orphan remediation skill
• a repaired service config path
• verified crew-wide skill links
• an agent-reach install matrix that moved from 6/13 OK to 8/13 OK and 0 off channels

Some of those are code outputs. Some are operational outputs. The second category is usually more valuable.

A repo can pass and still leave the organization dumber. The point of skills is to make the next run better.

What we stopped pretending

We stopped pretending one agent can safely hold the whole world in context.

We stopped pretending a Linear parent epic is executable.

We stopped pretending a passing command is the same thing as a verified outcome.

We stopped pretending subagent completion messages are proof.

We stopped pretending autonomy means no supervision.

The better definition is narrower: autonomy is bounded execution against a verified graph, with receipts good enough for another agent to resume the work after compaction.

That is less glamorous than a demo video.

It also works.

The lesson

The workflow is not “ask an agent to build the product.”

It is:

1. turn intent into a graph
2. turn the graph into an execution pack
3. run narrow agents and subagents against bounded scopes
4. verify every artifact
5. close with a final gate
6. preserve the lesson as a reusable skill

That is how the system compounds.

The model writes code. The workflow remembers how the code got safely written.