Use one AI for coding and another for documentation

One assistant finishes a code change. You open another assistant to write the documentation and ask it to inspect the repository. It finds the right area, but the branch has moved, the example uses an old parameter, and the prose promises behavior the implementation deliberately refuses.

Splitting coding from documentation works only when the code-to-docs boundary names an exact state. The second assistant needs more than “document this feature.”

Choose a documentation checkpoint

Hand off after the behavior is stable enough to describe. That does not require a release, but it does require a version the documentation assistant can inspect without guessing.

Record:

• Repository, branch, and exact commit or tag.
• Relevant implementation, test, configuration, and public-interface paths.
• The command that builds or tests the behavior.
• The observed result at that version.
• Any known failure that remains in scope.

Prefer a commit identifier when possible. A branch is a moving reference; a commit is the state you reviewed. If the code is still changing, say which parts are provisional so the documentation assistant does not turn them into a promise.

Explain the documentation job

Code says what the system does. It rarely says which reader needs to know, what sequence they should follow, or which warning belongs before the first command.

Your handoff should add:

1. Reader: operator, application developer, end user, or maintainer.
2. Intent: tutorial, task guide, conceptual explanation, reference, or release note.
3. Public behavior: inputs, outputs, side effects, and visible errors.
4. Examples: the smallest safe examples that should work at the named version.
5. Limits: unsupported cases, permissions, prerequisites, and non-goals.
6. Terminology: the product words the document must use consistently.
7. Verification ask: commands or checks the assistant should run before calling the draft complete.

Keep intent separate from observation. “This endpoint returns 404 for an unknown id in commit X” is an observed fact if the test proves it. “Readers should treat that as retryable” is a policy claim that needs an owner and evidence.

Carry decisions that code cannot explain

Documentation often drifts because the writer reopens a choice that was settled during implementation. If a parameter was omitted for a security reason, or a fallback was rejected because it hides errors, record the option and the reason. Preserving decisions between assistants keeps the documentation from recommending the path the code intentionally closed.

Also identify consequences. A deliberate refusal may require a troubleshooting note. A compatibility choice may require an example for both forms. The assistant writing prose should understand the reader-facing effect, not receive the entire design debate.

Send the brief to your own account

Have the coding assistant draft the code-state record to your own email on the account both assistants use. Review the version, behavior, limits, and documentation ask, then explicitly confirm. That same-account route creates neither a second account nor a contact request, and it sends no email or magic link. The package waits unread until any assistant pulls it; the account portal is the fallback inbox.

Only the approved structured text crosses. RelayLink does not move source files, repository access, generated documentation, or live terminal or editor state. A selected, sanitized command result may travel as text; the second assistant still needs separate authorized access to the named repository state. Code-context handoffs cover the technical coordinates in more detail.

Do not include API keys, webhook secrets, customer records, or confidential source unless the provider and receiving environment are authorized. Paths, commit identifiers, test names, and short safe excerpts are usually enough.

Verify prose against behavior

Run every command and example against the exact version in the handoff. Check parameter names, defaults, status codes, permissions, and failure cases. A fluent draft can still document the intended design instead of the implemented one.

The coding assistant’s explanation is evidence about intent, not proof of behavior. The documentation assistant’s draft is not proof either. If the behavior is still moving or the writer cannot inspect the named version, keep coding and documentation together until there is a stable checkpoint. Your final check connects the text to the code state readers will actually use.