- Home
- Claude to GitHub
Save a Claude chat to GitHub beside your code
Commit the discussion as Markdown, put generated files in their proper folders, and give reviewers the excerpt they need.
To save a Claude chat to GitHub, export it as Markdown and commit the reviewed file beside your code. Download generated source files separately with the artifacts ZIP, then restore their folders yourself. For an issue or pull request, paste a focused excerpt from one reply and preview it before posting.
Put the discussion in a Markdown file
Put a design discussion under docs/decisions/, or a debugging transcript beside its reproduction notes. Follow the project’s existing convention so other contributors can find it.
DocMyChat works on claude.ai in Google Chrome on a computer. Its Markdown option downloads the conversation as a .md file.
- Open the conversation you want to keep.
- Click Export beside Share.
- Select Markdown.
- Review the downloaded file in your text editor.
- Save the reviewed copy as
docs/decisions/2026-11-retry-backoff.md. - Commit it on your working branch with a message explaining the decision.
- Push the branch.
The full export has a title, a meta line, and ## You and ## Claude headings. It can also include an artifacts appendix. The date in the meta line is the export date, so add the decision date yourself if they differ. The Markdown export guide covers the file’s layout.
Without a local checkout, follow GitHub’s upload instructions: use Add file → Upload files, upload the reviewed file or folder, enter a commit message, choose a new branch, and click Propose changes.
Make the decision easy to find in the saved chat
Suppose you discussed an HTTP client’s retry behavior. The proposed decision is to allow eligible read requests at most three attempts, with longer waits between attempts. Earlier replies suggested retrying every failure.
Above the transcript, state what you accepted and whether implementation is proposed or complete. For example: “Proposed: limit retries to eligible read requests. Allow three attempts total. Keep authentication failures outside the retry policy.” Keep that status until you’ve reviewed and tested the implementation.
Keep your decision note separate from Claude’s exported suggestions. If you remove unrelated exchanges, label the file as an edited excerpt instead of a complete transcript.
Link the decision file from the pull request that implements it. Give reviewers enough context in the PR itself to assess the change without reading every turn. The developer workflow guide covers the broader handoff between code, notes, and tickets.
Rebuild the folders for generated code
The Markdown appendix is useful for reading, but use Export → Artifacts when you need the files themselves. The ZIP contains the latest version of each artifact or file. It doesn’t contain the earlier drafts from the conversation.
Extract it outside the repository first. The archive is flat: every file is at the top level, and slashes in names become spaces. A file named src/retry.ts becomes src retry.ts. A test named tests/retry.test.ts becomes tests retry.test.ts.
Create the intended directories yourself, then rename and move each reviewed file into place. Use the discussion and your project’s layout to confirm the paths. Don’t replace every space with a slash automatically, because a space can also be part of a legitimate filename. Compare any existing file before replacing it.
Run your project’s relevant checks after restoring the paths, then add only the intended changes to the branch. The artifacts ZIP guide explains the download. If you can’t locate an output, see where Claude artifacts are saved.
Published Claude Docs and decks appear in the conversation export as titled links. Their contents aren’t in the ZIP. Slide HTML and JSON written only to build a published deck are omitted too.
Check what GitHub renders
Open the saved file on GitHub after pushing. Check code indentation, table cells, equations, and diagram labels.
- Headings: the exported
## Youand## Claudelines become second-level headings under GitHub’s Markdown syntax. - Tables: GitHub renders pipe-and-hyphen tables. If you edit one, keep the header separator and a blank line before it.
- Code: keep the opening and closing fences and the language label. GitHub uses that label for syntax highlighting.
- Math: the export keeps LaTeX between dollar signs. GitHub supports inline math with
$…$and display math with$$…$$, including in Markdown files, issues, and pull requests. - Mermaid: GitHub renders source in a fenced block labeled
mermaid. Add the definition if it isn’t in the saved file, and preview it. GitHub’s diagram guide covers syntax and its supported version.
Images need separate handling. The Markdown export uses claude.ai image URLs that open while you’re signed in. Don’t expect those URLs to display images for GitHub readers. Save an image you’re allowed to share, add it to the repository, and use a relative image path. For a note in docs/decisions/ and an image in docs/images/, use ../images/retry-flow.png. Preview that replacement too.
Use one reply in a PR description or issue
Use the export icon under the reply, next to Copy, and choose Markdown. Open the file and copy the useful answer into the PR description or issue comment. A single-reply export has a title and a “Claude reply” meta line, but no turn heading.
To copy a short passage without an extension, select the relevant text in Claude and copy it into the GitHub editor. Restore any code fences and use the preview before posting. You can also write the final explanation yourself from the discussion.
For the retry example, a useful PR draft could read:
## Change
Limit eligible read requests to three attempts total.
Increase the delay between attempts. Do not retry authentication failures.
## Reason
Bound the time spent retrying while keeping temporary failures recoverable.
## Validation still needed
- Confirm the attempt limit.
- Confirm authentication failures stop immediately.
- Confirm cancellation interrupts the wait.
Replace the proposed behavior with what your patch actually does. Record checks as passed only after running them. Remove conversational fragments such as “as shown above,” and link to the decision file for background.
Read the exact files you’re about to commit
Read the chat before committing it, including prompts, logs, code blocks, filenames, and the appendix. Remove credentials, private data, client names, and internal details the repository’s readers shouldn’t receive. Check screenshots separately, since text searches won’t catch their contents.
Review the staged changes for unrelated exports or an unredacted copy added by mistake. Keep required private records in an approved location outside the shared repository.
If a credential has already been exposed, GitHub recommends revoking or rotating it first. Deleting the current file doesn’t erase the earlier commit or other copies. Follow your team’s process for the remaining cleanup.
Use Claude with repository context
Anthropic’s GitHub integration brings selected repository files into Claude as context. It retrieves filenames and contents from a branch, not commit history or pull requests.
As of November 2026, Anthropic’s unified chat experience lists Add from GitHub as unsupported. Follow the integration instructions only where that option is available in your account.
Questions
Can Claude commit to my repository directly?
Claude Code can stage changes, create commits and branches, and open pull requests. That’s a separate coding workflow. DocMyChat downloads a conversation or its files for you to review and add yourself.
Will the saved chat update when I continue the conversation?
No. DocMyChat exports one chat or reply at a time and doesn’t sync with GitHub. Export again when you need a newer snapshot, then review the change before committing it.
Should I commit the artifacts ZIP itself?
Usually, extract it first and commit the reviewed source files. That lets a reviewer read the code alongside the rest of your project. Keep an archive in the repository only when your project deliberately stores downloads that way.
Does a filename such as notes (2).md mean an older version?
No. Numbered names distinguish files that had the same name. The ZIP contains the latest version of each artifact or file, so inspect their contents to decide where each belongs.