# Coding Docs > Work with AI agents and teammates on shared GitHub repositories. # Coding Source: https://docs.coding.abloatai.com/ Coding brings your repository, agent conversations, and code review into one shared workspace. Connect GitHub, give an agent a task, inspect its work, and publish the changes when they are ready. [Open Coding](https://coding.abloatai.com/app) or follow the [getting started guide](/quickstart). ## From task to reviewed change 1. **Connect a repository.** Install the Coding GitHub App for the repositories you want to work on. 2. **Start a conversation.** Describe the outcome and choose an available agent and model. 3. **Work together.** Continue the conversation, inspect files, and coordinate with teammates. 4. **Review and publish.** Read the diff, run checks, then commit and push to GitHub. ## Explore the guides - [Conversations and workspaces](/conversations): give agents context and continue shared work. - [Review and publish changes](/source-control): select the right worktree, inspect diffs, and publish. - [Demo videos and CLI](/demos): record a changed interaction and share a private watch link. - [For agents](/agents): read the docs as Markdown and attach evidence to completed work. Coding uses [Ablo](https://docs.abloatai.com) for shared state and collaboration. [Knowledge](https://docs.knowledge.abloatai.com) is the companion product for publishing files and research to shared knowledge. --- # For agents Source: https://docs.coding.abloatai.com/agents ## Read without browser automation - [llms.txt](/llms.txt): documentation index. - [llms-full.txt](/llms-full.txt): complete Markdown reference. - [llm.txt](/llm.txt): alias for the index. - Append `.md` to a guide route, such as [quickstart.md](/quickstart.md), for its raw Markdown. Start with [Conversations and workspaces](/conversations) and [Review and publish changes](/source-control). Read the repository's own instructions before editing; they define its local workflow and checks. ## Return reviewable results Inspect the current branch and working tree, understand the affected code and callers, and preserve unrelated edits. Make the smallest complete change and run checks that exercise the behavior. Report what passed and what remains unverified, along with where the changes live and whether they are published. For visible UI changes, record the interaction with the real updated app. Inspect the recording before uploading through [Coding's demo CLI](/demos), then return the permanent watch URL. Label mock data honestly. A local file path or an expiring storage URL is not a hosted demo link. --- # Conversations and workspaces Source: https://docs.coding.abloatai.com/conversations ## Keep the task and its context together A conversation holds your instructions, agent responses, and tool activity. Describe the desired behavior, the relevant files or constraints, and what should count as a successful check. Send corrections in the same conversation so the agent can use the existing context. Available agents and models appear in Coding's selector. Availability depends on the deployment and your configured access; use the options shown there. ## Understand what is shared Members of the same Coding account can open and continue shared conversations. Repository access still controls which GitHub repositories you can use. Conversations can share a live branch or use different Git worktrees. A conversation is not automatically an isolated copy of every file. Check its workspace and branch before assigning overlapping edits. Use separate worktrees when tasks need incompatible changes, and bring reviewed work back together. ## Continue later Opening conversation history does not itself start a new cloud workspace. Sending another message resumes retained compute or restores the workspace when a suitable checkpoint is available. If Coding reports that a workspace cannot be recovered, preserve the error and resolve it before assuming your files are available. Commit and push reviewed work to GitHub rather than relying on a live workspace as your only copy. ## Ask for evidence An agent finishing its response does not prove the task passed. Ask for the checks it ran, their results, and any remaining limitations. Review diffs for code changes and [demo videos](/demos) for visible interactions. --- # Demo videos and CLI Source: https://docs.coding.abloatai.com/demos Record the actual UI interaction and pause on its result. Label sample data or mocked services, and keep credentials and unrelated private content out of the recording. Coding accepts WebM and MP4; uploads must fit within 20 MiB and two minutes. The CLI uploads existing recordings; it does not record your screen. ## Install the CLI from source The CLI is currently private and installed from a Coding checkout, rather than a public npm release. With Node 24.18 or newer in the Node 24 line and npm 11: ```sh npm ci npm run build --workspace @coding/cli npm link --workspace @coding/cli coding login --email you@company.com ``` Enter the emailed code in the terminal. The CLI saves its own private session; browser sign-in does not sign the CLI in. Use `coding logout` to remove that local session, and run login again when it expires. ## Upload and open Use the numeric GitHub repository ID: ```sh coding demos upload /absolute/path/demo.webm --repository 123456789 ``` The command prints a permanent **Demo:** watch URL. Open that returned URL with `coding demos open URL`, inspect playback, and share it with your team. Use `coding demos open` to browse the library. For several steps, save an ordered `chapters.json` with times in seconds: ```json [ {"time": 0, "title": "Open the project list"}, {"time": 5, "title": "Create a project"} ] ``` ```sh coding demos upload /absolute/path/demo.webm --repository 123456789 --chapters chapters.json ``` ## Access and retention The uploader needs Coding organization membership and repository write access. Viewers must sign in with membership in the same organization and repository read access. A watch URL does not grant access by itself. A browser organization switch does not change the CLI session's organization. Ordinary uploads are retained evidence. Use `--retention disposable` only for throwaway tests; those recordings expire and must not be used as commit evidence. Delete an authorized recording with `coding demos delete URL` when its removal is intended. Deletion makes existing watch links unavailable. ## Inside a Coding agent The running conversation supplies identity and repository authority: ```sh coding demos upload /absolute/path/demo.webm --chapters chapters.json ``` Omit `--repository` and do not copy a personal CLI session into the workspace. See [For agents](/agents) for the documentation entry points. --- # Getting started Source: https://docs.coding.abloatai.com/quickstart ## Sign in and select your organization Open [Coding](https://coding.abloatai.com) and sign in. Coding supports Google and email-code sign-in through Ablo. Complete your profile if prompted. For team work, accept an invitation to your team's organization. Open **Members** to check the current organization and manage invitations. A matching email domain does not automatically join you to a team. ## Connect GitHub Connect GitHub and install the Coding GitHub App on the repositories you want Coding to access. GitHub access is separate from signing into Coding. You do not need to paste a personal access token. Choose a repository from the repository list. If it is missing, check that the GitHub App installation includes it and that you are using the intended account. ## Give the agent a task Start a conversation in your repository and choose an available agent and model. Give it a concrete outcome and a way to verify success. For example: > Add a useful empty state to the project list. Follow the existing components, > check it with an empty list, and record the interaction for review. The cloud workspace starts when work is needed. Read the agent's progress and send follow-up instructions in the same conversation. ## Review the result Open source control and confirm the repository, worktree, and branch. Read the changed files and diffs, then ask for any missing checks or corrections. For a visible UI change, review a recording of the actual interaction. Use **Commit** to save reviewed work in Git. Publishing is a separate step: **Push** sends commits to GitHub, while **Create Pull Request** opens a review for an already published branch. See [Review and publish changes](/source-control). --- # Review and publish changes Source: https://docs.coding.abloatai.com/source-control ## Select the work you are reviewing Open source control and use the repository/worktree selector to choose the conversation's working copy. Confirm the displayed branch before taking a Git action. Repository history and a conversation's live worktree are different views; choose the live worktree when reviewing uncommitted edits. Inspect changed files and their diffs. Check the staged and unstaged changes, and make sure the proposed commit contains only the intended work. ## Commit and push Enter a commit message and choose **Commit** to save changes in the workspace's Git history. A local commit is not yet published to GitHub. **Commit options** also offers **Commit & Push**. Confirm the remote branch in its dialog. If the commit succeeds but publishing fails, retry **Push** after resolving the error; the commit already exists. ## More Git actions | Action | What it does | | --- | --- | | Fetch | Updates remote history without changing your files. | | Pull | Pulls updates into the current branch; diverged history stops without merging. | | Push | Publishes commits to the remote branch you confirm. | | Create Pull Request | Creates or opens a pull request for an already published branch. | | Refresh | Reloads the source-control view. | Resolve conflicts deliberately and preserve other people's changes. Check the result after publishing, including the branch and any pull request checks.