How to Leave Evidence That AI Coding Work Is Done: The Moonshot Relay Workflow

When using an AI coding tool, the first thing that comes to mind is admiration. Read the file, edit the code, run the tests, and even add comments. There are times when I cram into a few minutes something that would previously have taken half a day.

But in practice, other questions soon follow.

Copy1Is it really over?2What files changed?3By what criteria did you pass the test?4When the next person takes over, where should I start?5Are there any failed judgments left in the middle?

After experiencing this problem repeatedly, I started creating Moonshot Relay. This project is a workflow harness for Claude Code and Codex. Rather than being a repository of a few prompts, it is more of a device that ties together the way an AI agent starts a task, progresses, verifies, and resumes a task into a single operational flow.

Why did you need this tool?

The most dangerous moment when fixing code with AI isn't failure. Failure is usually visible. Builds break, tests fail, and screens crash in the browser.

The more dangerous moments are those of modest success. On the surface, it seems plausible. The answers are confident, the change files are there, and the explanations are smooth. But if you actually check, this happens often.

• Implemented based on old documentation.
• They said they ran a test, but it wasn't based on the current branch.
• The build passed, but the styling was broken on the actual screen.
• The scope of work changed midway, but there is no record.
• You'll have to keep track of the context again when you take over in the next session.

This problem is not solved by model performance alone. Even smarter models repeat the same mistakes at different rates when goals, permissions, file boundaries, and validation criteria are blurred. What you need is more of a "better workflow" than a "better answer."

Four Moments Captured by Moonshot Relay

The catch of the Moonshot Relay is clear. These are four moments that often get lost in AI work.

The README on the GitHub repository also clearly points in this direction. Moonshot Relay is a structure that manages rules, agents, skills, and documentation templates, and installs and uses reusable workflows from Claude Code and Codex. In other words, look at the “surface on which you operate” before individual prompts.

how does it work

Moonshot Relay is not a separate executor that replaces the model. It is close to a runtime profile that sets the order of work by layering rules, skills, agents, and document templates on top of the work already done by Claude Code or Codex.

Repository-wise, the originals are in root directories likeskills/,agents/,rules/,templates/, anddocs/public/, and when installed, they are materialized into an account root or project local profile that Claude/Codex can read. At this time, all internal skills are not exposed and the entry points that actual users can select are limited.

Frequently used surfaces are roughly divided as follows:

During execution, runtime outputs such as.moonshot-relay/docs/tasks/,phase-status.yaml,reports/*.json, and verification verdict may be generated. Importantly, this artifact is a trace of your work, not product code. The role of the harness is to distinguish between data to be committed, such as code, records to be read by the next session, and scratches to be discarded.

How to use it

The simplest installation is a one-line command in the README.

Copy1npx -y github:munlucky/moonshot-relay install

When installing directly from source checkout, you can use Node installer.

Copy1node bin/moonshot-relay.mjs install --runtime all

Once installed, simply call the entry point that suits your task in Claude Code or Codex. For example, if you want to leave one function to the end,moonshot-orchestratoris suitable for a small range.

Copy1using moonshot-orchestrator2Add a notification toggle to the current settings screen.3Check the existing UI patterns first,4Please leave your test and browser verification results.

If the work is divided into multiple steps and intermediate deliverables are required,moonshot-phase-runneris better.

Copy1moonshot-phase-runner docs/implementation/notification-settings2Proceed with the planned phases in order,3Leave change files, verification instructions, and remaining risks for each phase.

The key here is not the command name itself. When assigning a task, you provide the goal, scope, and verification criteria, and when the agent says it is finished, you leave behind the actual change file and execution evidence.

How is it different from the prompt bar?

Good prompts are still important. However, it is difficult to control long tasks to completion with prompts alone.

For example, a request like “Please implement this feature” may be enough for a first response. But the real work soon turns into more questions.

Copy1Which file should this change go into?2Doesn’t it conflict with existing patterns?3Where should I add tests?4Should I check it in browser?5Should the document also change?6Can I commit this state?

Moonshot Relay is an attempt to avoid having to improvise and recreate these questions every time. Divide task types, identify required context, break down execution steps, and require verification evidence. Here, the traces of your work are more important than the sentences of your answer.

actual use scene

The first moment that comes to mind when Moonshot Relay comes to mind is “when the work doesn’t end with one fix.” For example, this request:

Copy1Add this feature to fit the current UI flow,2Organize related Korean-English phrases,3The build and browser verification are perfect.

Or something like this.

Read the current structure first, plan what to change, implement it small, and leave the verification results and remaining risks.

What is important here is not just the AI's ability to write code quickly. Rather, you should be able to answer the following questions:

• What are the completion criteria for the current task?
• Does the scope desired by the user match the actual scope of change?
• What verification was done and what verification was not done?
• When the next person takes over, what should they look at first?

If this question remains unanswered, AI work becomes more of a team process than an individual intuition.

Why we need a runtime and not a document

At first, I thought that writing more documentation would solve the problem. I felt like creating good checklists, good work rules, and good retrospective documents would be enough.

But in reality, documentation alone wasn't enough. The AI ​​agent moves in the current workspace every time. Branch status, test results, local servers, files created, and changed policies are all current facts. No matter how good an old document is, it can be dangerous if it doesn't match your current checkout.

So Moonshot Relay doesn't throw away documents. Instead, design your documents to be associated with runtime operations. Rules are attached to the execution surface, verification closes with actual commands and results, and the task history becomes the input to the next execution.

This perspective is important. Documents in the AI ​​era should be less like “good-to-read material” and more like “operating contracts that agents reference when deciding their next actions.”

Good and bad points

The biggest advantage of Moonshot Relay is that it reduces anxiety in AI tasks. This is especially effective when touching multiple files. When planning, execution, verification, and recording are separated, you can see "what you're doing" and it's easier to change direction midstream.

But there are also some inconveniences. It's overkill for very small corrections. Going through every step until you change one typo, one phrase, one line of settings will slow you down. Also, having a harness does not automatically improve your judgment. Fixing on the wrong target can lead to more cleanly wrong results.

So, I don't see Moonshot Relay as a one-size-fits-all automation. I see it as an operational tool to be used lightly for small tasks and strictly for long tasks.

Boundary case: When even a harness fails

Having a Moonshot Relay does not automatically make all operations safe. Especially in the situations below, you should reorganize your inputs rather than trusting the harness.

Who is it suitable for?

Moonshot Relay is a great fit for these people.

• People who use Codex or Claude Code more like a real work agent than just chatting.
• People who frequently work with multiple files, documents, tests, and browser checks.
• A person who must share or inherit the results created by AI in the team
• Anyone who wants to judge “task completed” by verification evidence rather than a response sentence

Conversely, if you only use AI as a lightweight code snippet generator or idea notepad, this structure may be overkill. The Moonshot Relay is a device for speeding up, but more precisely, it is a device for controlling the shaking that occurs when speeding up.

Checklist to follow right away

Even if you do not use Moonshot Relay, the criteria below can be applied immediately.

• [ ]Write the completion criteria in one sentence before entrusting the task to AI.
• [ ]Before modifying, read the current structure and state the rationale.
• [ ]Leave the verification command as the actual execution result, not as an answer.
• [ ]Record failed verification and omitted verification separately.
• [ ]So that the next person can take over. Leave changed files and remaining risks.

The fun of AI coding is that you get results quickly. However, the power to make it last longer comes from making the results believable.

Moonshot Relay is a project that does not leave that belief to the persuasiveness of the prompt, but leaves it as a workflow and evidence. This is also the conclusion that I continue to see while working with AI. If we want AI to do more work, we need to be more strict about saying the job is done.

FAQ

Q. Is Moonshot Relay a prompt library?

Prompts may be included, but the key is how the task operates. It's more about fixing the goal, reading the necessary context, separating execution and verification, and recording so the next session can take over.

Q. Is it necessary for personal projects used alone?

The more a development project you do alone, the easier it is to pass it over and say, “I’ll figure it out later.” However, just one small function moves API contracts, state handling, tests, environment variables, and local execution verification together. Batch jobs or internal automation are more prone to mess ups.

The moment you need a Moonshot Relay is not a grand team project, but a moment when you open it again the next day and wonder, “How far did I get?” If you keep track of what you changed, what you verified, and what you haven't seen yet, working alone is much less shaky.