# Comments
Source: https://docs.tryscott.ai/collaboration/comments
Use inline comments to gather specific team feedback before execution.
Comments let teammates discuss exact parts of a planspace document without derailing the main authoring chat. They are best for questions, objections, missing context, and small changes that should be resolved before a review.
## Create a comment
1. Open a planspace document
2. Select the text you want to discuss
3. Click the comment action
4. Write the comment and submit
Comments appear in the document margin and keep the conversation anchored to the text that prompted it.
## Mention teammates
Type `@` in a comment to mention a teammate. Mentioned users receive a notification in [For You](/collaboration/notifications).
Use mentions when:
* a PM needs to clarify product intent
* a designer needs to check UX assumptions
* an engineer needs to verify architecture or migration details
* a reviewer should look at one specific risk
## Add comments back to chat
Authors can add important comments to the planspace chat so Scott can revise the document with the feedback in context.
This is the main loop:
1. teammates leave comments on the document
2. the author adds important comments to chat
3. Scott revises the proposal
4. the team reviews the updated version
## Resolve comments
Resolve a comment when the discussion is settled or incorporated. Resolved comments stay attached to the document history so the reasoning remains available later.
## Comments vs reviews
Use comments while the design is still moving. Use [reviews](/collaboration/reviews) when the plan is ready for approval.
# For You
Source: https://docs.tryscott.ai/collaboration/notifications
Your inbox for Sync Chat, reviews, mentions, invites, and team activity.
For You is the personal hub inside Scott. It combines notifications, review requests, mentions, invites, and Sync Chat.
## Tabs
| Tab | What it shows |
| -------- | ----------------------------------------- |
| All | Recent notifications across planspaces |
| Reviews | Open review requests assigned to you |
| Mentions | Comments where someone mentioned you |
| Invites | Planspaces you have been invited to join |
| Sync | Sync Chat over recent local agent history |
## Sync tab
The Sync tab is where the Scott plugin sends you after sync. It lets you ask across recent local agent sessions, attach code context, and identify sessions worth turning into planspaces.
Use Sync when:
* you are onboarding Scott
* you want a read across recent agent work
* you need to find promising prototypes or unfinished ideas
* you want Scott to write up a session as a planspace
Learn more in [Sync](/developer-tools/sync).
## Reviews tab
The Reviews tab shows requests where you are the reviewer. Opening a request takes you to the specific document version under review.
From there you can:
* read the document
* inspect comments
* ask review-chat questions
* approve or reject the version
## Mentions and invites
Mentions help teammates pull you into a specific document passage. Invites give you access to planspaces where your feedback or review is needed.
Use For You as the daily triage view: what needs your attention, what needs approval, and which synced sessions are ready to become team context.
# Team pulse
Source: https://docs.tryscott.ai/collaboration/pulse
How teams use Scott to see design intent, review health, and execution drift.
Team pulse is the operating view Scott is building toward: a way to see what is being planned, what has been approved, and how implementation compares to original design intent.
## Why it matters
Agent output makes execution faster, but it also makes misalignment easier to miss. Teams need to know:
* which proposals are waiting on feedback
* which plans have been approved
* which pull requests are linked to approved intent
* where implementation diverged from what the team reviewed
* which areas of the product lack current design context
## Inputs
Scott's team-level view comes from the same daily workflow:
1. [Sync](/developer-tools/sync) keeps recent agent work discoverable
2. [Push](/developer-tools/push) turns useful agent threads into planspaces
3. [comments](/collaboration/comments) and [reviews](/collaboration/reviews) capture team feedback
4. [Scott GitHub App](/developer-tools/github-app) links pull requests to planspace intent
5. landed code feeds execution context back into the document set
## Signals
Useful team signals include:
| Signal | What it answers |
| ----------------- | ------------------------------------------------------- |
| Review queue | Which plans are waiting on decision makers? |
| Approval coverage | Which shipped work had reviewed design intent? |
| PR links | Which pull requests implemented a given planspace? |
| Design drift | Where did implementation differ from the approved plan? |
| Stale plans | Which documents need to be updated after code landed? |
## Document OS
The goal is a continuously updating document OS for teams: not static specs, not disconnected PR comments, and not lost agent chats. Scott keeps the original design intent, team review, implementation record, and future execution context in one place.
# Reviews and approvals
Source: https://docs.tryscott.ai/collaboration/reviews
Request feedback and approval on a specific planspace document version.
Reviews bring an approval workflow to design intent. Instead of waiting for code review to discover misalignment, a team can approve the plan while it is still cheap to change.
Reviews are attached to a specific document version. Reviewers see the exact content they are approving, including comments and relevant context.
## When to request a review
Request a review when:
* the planspace has a clear proposal or prototype direction
* open comments have been answered or intentionally left as decisions for reviewers
* the author wants a formal approval before delegating implementation
* a PR will later need to link back to the approved design intent
## Request a review
1. Open the planspace version you want reviewed
2. Click **Share**
3. Choose **Review**
4. Select one or more reviewers
5. Add a short note about what they should focus on
6. Send the request
Reviewers receive the request in [For You](/collaboration/notifications).
## Reviewer states
| State | Meaning |
| ----------- | -------------------------------------------------- |
| Pending | The reviewer has not engaged yet |
| In progress | The reviewer is reading, commenting, or discussing |
| Approved | The reviewer agrees with this version |
| Rejected | The reviewer requested changes |
Reviewers can approve, reject, or withdraw their decision if they need to reopen the review.
## Agent-assisted design review
Scott can also request review from agent reviewers in supported environments. Agent reviewers are useful for architecture checks, edge cases, security questions, or consistency with connected source context.
Human approvals still matter. Agent review is a way to broaden coverage and catch issues earlier, not a replacement for team ownership.
## Approval and execution
An approved version becomes the trusted reference for execution:
* [Pull](/developer-tools/pull) can load the reviewed context into a fresh agent thread
* [Scott GitHub App](/developer-tools/scott-ci) can link pull requests back to the approved plan
* the team can compare what shipped against what was approved
That is the shift Scott is designed for: review design intent before the diff, then use the diff to verify execution.
# Sharing
Source: https://docs.tryscott.ai/collaboration/sharing
Share planspaces for collaboration, review, or handoff.
Sharing is how a planspace becomes team context. You can invite people to collaborate, request a formal review, send the document to someone, or share a public read-only link.
## Share intents
The share modal supports three common intents:
| Intent | Use it for |
| ----------- | --------------------------------------------------------------------- |
| Collaborate | Add teammates who should edit, comment, or follow the planspace |
| Review | Ask specific people to approve or reject a document version |
| Send to | Send context to someone without changing the core collaboration setup |
## Invite members
1. Open the planspace
2. Click **Share**
3. Choose **Collaborate**
4. Add teammates by name or email
5. Select their role and send the invite
Invited members receive a notification and can access the planspace after accepting.
## Request review from Share
Use **Review** when the plan is ready for approval.
1. Open the document version you want reviewed
2. Click **Share**
3. Choose **Review**
4. Select reviewers
5. Add a focus note
6. Send the request
See [Reviews and approvals](/collaboration/reviews) for reviewer states and approval behavior.
## Share from your agent
The fastest way to create a shareable planspace is to ask the Scott plugin to [push](/developer-tools/push) from the coding-agent thread where the work happened:
`# from claude code, codex, gemini, opencode, etc`
```text theme={null}
Push this conversation to Scott so my teammates can review it.
```
Scott captures the current coding-agent thread, generates a planspace document, and prints the planspace URL. Share that URL in Slack, Linear, a design review, or a pull request.
## Public links
Toggle **Make public** in the Share modal to generate a read-only link.
Public links are read-only. Viewers cannot comment, edit, or see private comments. To collaborate, invite members directly.
## Pulling shared context
When a planspace is ready for execution, start a fresh coding-agent thread and ask it to pull from Scott:
`# from claude code, codex, gemini, opencode, etc`
```text theme={null}
Pull from Scott using this planspace and start building: https://app.tryscott.ai/workspace/...
```
This loads the document, comments, review state, and available implementation context into your coding agent.
# Scott agent plugin
Source: https://docs.tryscott.ai/developer-tools/cli
Use Scott from your coding agent: sync, push, pull, and setup.
The Scott agent plugin is the bridge between local coding-agent work and team context in Scott. It bundles agent skills with local `scott` commands. Install and sync start from your terminal; push and pull happen from Claude Code, Codex, Cursor, OpenCode, Gemini, or another supported agent thread where the work is happening.
Use it for three daily jobs:
| Plugin action | Daily job |
| ----------------------------- | ------------------------------------------------------------------------- |
| [Sync](/developer-tools/sync) | Manually onboard Scott with recent local agent history and open Sync Chat |
| [Push](/developer-tools/push) | Turn the current agent thread into a shareable planspace |
| [Pull](/developer-tools/pull) | Bring reviewed planspace context into a fresh agent session |
## Install
From your development machine, run:
```bash theme={null}
curl -fsSL https://tryscott.ai/install | sh
scott sync
```
The installer signs you in, wires Scott into detected coding agents, and sets up the hosted MCP connection where supported. `scott sync` reads recent local agent history and opens `/sync`.
Install plus `scott sync` is the manual getting-started step. After that, invoke push and pull from your coding agent because they depend on the active thread context.
If you need manual terminal setup, run:
```bash theme={null}
scott setup --claude # or --cursor, --codex, --opencode, --gemini
```
See [Setup](/developer-tools/setup) for agent-specific details.
## The daily loop
1. **Sync** local agent history from your terminal so Scott has useful context.
2. **Push** focused threads when a prototype, proposal, or design direction needs team feedback.
3. **Review** the planspace with comments and approvals in the Scott app.
4. **Pull** the reviewed context into the next agent session when it is time to execute.
5. **Link** the pull request back to one or more planspaces with the [Scott GitHub App](/developer-tools/github-app).
## Agent prompts
After manual install and sync, invoke push and pull from the coding agent session where the work is happening:
`# from claude code, codex, gemini, opencode, etc`
```text theme={null}
Push this conversation to Scott so my team can review the design.
```
`# from claude code, codex, gemini, opencode, etc`
```text theme={null}
Pull the context from this planspace and start implementation: https://app.tryscott.ai/workspace/...
```
## Command reference
Upload recent local agent sessions and start Sync Chat.
Create a shareable planspace from the current agent thread.
Load reviewed planspace context back into execution.
Configure Scott for Claude Code, Cursor, Codex, OpenCode, Gemini, and other agents.
## Terminal maintenance commands
```bash theme={null}
scott login
scott logout
scott remove --claude
scott remove --mcp-only
scott remove --skills-only
```
Use `scott remove` to undo agent integration without deleting your Scott planspaces.
# Scott GitHub App
Source: https://docs.tryscott.ai/developer-tools/github-app
Review pull requests against planspace design intent and keep execution context updated.
The Scott GitHub App connects pull requests to the planspaces that shaped the work. Its main value is PR design review: Scott checks whether implementation matches the linked design intent, flags unexpected drift, and feeds accepted execution decisions back into the document set.
It supports three related workflows:
1. **PR design review** - link pull requests to planspaces and review implementation against original design intent.
2. **Document OS feedback** - update planspace context when code intentionally diverges and lands.
3. **Code context** - make repositories available when Sync Chat or a planspace needs code-aware answers.
## Install paths
There are two common install moments:
* Install the Scott GitHub App from team settings when your organization wants PR linking and design review.
* Click **Connect repo** from Sync Chat or a planspace when you need code context.
In both cases, we recommend granting access to all repositories. Limiting access can cap answer quality when relevant context lives outside one repo.
Scott is SOC 2 compliant. Scott does not persist repository contents. It fetches code only into ephemeral sandboxes when an answer or review needs it. If you remove GitHub access, Scott can no longer fetch that code.
## What the app enables
| Capability | Why it matters |
| --------------------- | ----------------------------------------------------------------------------------- |
| PR linking | Pull requests can point back to one or more planspace URLs |
| Agent-assisted review | Scott can compare implementation against the design intent the team reviewed |
| Execution feedback | Accepted deviations and landed code update the context around what actually shipped |
| Repository context | Sync Chat and planspaces can answer with awareness of your actual codebase |
| Branch selection | Authors can attach the branch relevant to a proposal or implementation plan |
## Recommended organization setup
1. Open team settings in Scott
2. Install the Scott GitHub App for your GitHub organization
3. Grant access to all repositories where Scott should reason about context or review PRs
4. Ask teams to add planspace URLs to PR descriptions or commit messages
5. Use Scott comments and PR links to keep design intent and execution connected
## Where to go next
Link PRs to planspaces and review implementation against approved intent.
Connect repositories for Sync Chat, planspace answers, and stronger PR reviews.
# Pull
Source: https://docs.tryscott.ai/developer-tools/pull
Ask the Scott plugin to bring reviewed planspace context back into execution.
Pull loads a planspace into a fresh coding-agent thread as execution context. Start Claude Code, Codex, Cursor, OpenCode, Gemini, or another supported agent where you want to execute, then paste:
`# from claude code, codex, gemini, opencode, etc`
```text theme={null}
Pull from Scott using this planspace and start building: https://app.tryscott.ai/workspace/9579e73f-8292-42ea-8d2f-5d390a8f867e
```
Use it when a planspace has enough team alignment to guide implementation.
## What pull includes
The default pull output includes:
* the current document
* relevant document versions
* comments and review context
* reviewer turns and approval state
* connected source summaries
* commits and PR context when available
* conversation history needed to understand the plan
When you only need the headline document and review state, ask your agent for a summary-only pull:
`# from claude code, codex, gemini, opencode, etc`
```text theme={null}
Pull a summary from Scott for this planspace: https://app.tryscott.ai/workspace/...
```
## Agent prompt
You can ask your coding agent:
`# from claude code, codex, gemini, opencode, etc`
```text theme={null}
Pull the project requirements from this planspace and start building: https://app.tryscott.ai/workspace/...
```
## Execution workflow
1. Confirm the planspace has the right comments and approvals
2. Pull the planspace into a fresh agent thread
3. Ask the agent to restate the implementation plan before writing code
4. Execute against the pulled context
5. Put the planspace URL in the PR description so the [Scott GitHub App](/developer-tools/scott-ci) can connect code back to design intent
## Listing recent planspaces
`# from claude code, codex, gemini, opencode, etc`
```text theme={null}
List my recent Scott planspaces so I can choose which one to pull.
```
Use this when you know the work exists in Scott but do not have the URL handy.
# Push
Source: https://docs.tryscott.ai/developer-tools/push
Ask the Scott plugin to turn an active agent thread into a shareable planspace.
Push is the fastest way to create a sharing document from work already happening in a coding agent. From the active Claude Code, Codex, Cursor, OpenCode, Gemini, or other supported agent thread, paste:
`# from claude code, codex, gemini, opencode, etc`
```text theme={null}
Push this conversation to Scott so my teammates can review it.
```
Use it when a thread has become a prototype, design direction, investigation, or proposal that deserves team feedback.
## What push creates
The Scott plugin captures the current coding-agent session and creates or updates a matching planspace. Scott generates a document, preserves the conversation context, redacts likely secrets, and prints the planspace URL on its own line.
That URL is the shareable artifact. Send it to teammates, add it to Linear, paste it in Slack, or include it in a PR description.
## Agent prompt
You can ask your coding agent:
`# from claude code, codex, gemini, opencode, etc`
```text theme={null}
Push this conversation to Scott so my teammates can review the design direction.
```
Scott's installed skill asks what kind of feedback you want and who the audience is, then runs the push workflow.
## Daily use
Use push early and often:
1. Prototype or investigate in your agent
2. Push once there is a concrete direction
3. Share the planspace with teammates
4. Collect comments and review decisions
5. Pull the approved context back into execution
## What to share
Good push candidates include:
* a prototype that changes product direction
* an architecture proposal
* an implementation plan that needs senior engineering feedback
* a risky migration or refactor
* a design critique or alternate approach
* a thread that explains why a decision was made
## Push vs direct app creation
Create a planspace in the app when you want to start from a blank prompt. Use the Scott plugin's push action when the most valuable context is already in your coding-agent thread.
# PR design review
Source: https://docs.tryscott.ai/developer-tools/scott-ci
Use the Scott GitHub App to link pull requests to planspaces and review implementation against design intent.
PR design review connects implementation back to the planspaces that shaped it. Instead of treating code review as the first real alignment point, Scott helps teams review design intent earlier and then verify that code matches it.
## Setup
1. Open your team settings in Scott
2. Install the Scott GitHub App for your GitHub organization
3. Select the repositories you want Scott to review and link
4. Add one or more planspace URLs to a pull request description or commit message
5. Open or update the pull request
No repo config file is required. The planspace URL is the contract between design intent and execution.
## How linking works
```text theme={null}
planspace proposal or approved design
|
v
planspace URL in PR description or commit message
|
v
pull request
|
v
Scott GitHub App review
|
v
PR comment + planspace execution feedback
```
When you open or update a PR, Scott looks for planspace URLs in the PR description and commit messages. If it finds one or more links:
1. Scott links the PR to the relevant planspace versions
2. It traces the PR back to the review and approval context
3. It runs an agent-assisted architectural review using planspace context
4. It leaves a GitHub comment with the review and links back to the planspace
5. When the code lands, Scott feeds execution context back into the document set
Paste any Scott URL into your PR description or include it in a commit message on the branch. Scott takes it from there.
## Multiple planspaces
A single pull request can reference more than one planspace. This is useful when a PR implements:
* an approved product proposal
* a technical design
* a migration plan
* a risk review or security review
Add every relevant planspace URL so Scott can reason across the full design record.
## Review output
Scott's PR comment focuses on whether implementation matches design intent:
* architectural alignment
* missing requirements or edge cases
* places where the code diverges from the planspace
* risks introduced during implementation
* links back to the relevant planspaces
## Document OS feedback loop
Traditional code review asks, "Is this diff acceptable?" Scott asks, "Does this implementation match the design intent the team reviewed?"
By default, Scott checks whether the implementation deviates from the linked planspace. That creates two useful outcomes:
* **Unexpected drift** - Scott flags the gap. If the PR is wrong, update the code before merging.
* **Intentional drift** - tell Scott the deviation is expected and the team plans to move forward. When the code lands, Scott loops that direction back into the original document context.
That makes the document set continuously update:
1. [Push](/developer-tools/push) captures proposals and prototypes from agent threads as planspaces
2. teammates comment and approve direction before implementation hardens
3. PRs link back to one or more planspaces
4. Scott reviews the PR against the original intent and flags deviations
5. expected deviations and landed code update the context around what actually shipped
The result is a document OS that preserves original design intent while still reflecting real execution decisions.
## FAQ
Scott only links PRs to planspaces when it can find a URL reference. Add the URL to the PR description or a commit message, then update the PR.
No. Scott leaves review comments and context links. It does not create a required status check by default.
Approval is recommended because it gives Scott a stronger design-intent baseline. You can still link a PR to an unapproved planspace when the work is intentionally exploratory.
# Setup
Source: https://docs.tryscott.ai/developer-tools/setup
Install and configure Scott for your local coding agents.
The installer configures Scott for detected local coding agents:
```bash theme={null}
curl -fsSL https://tryscott.ai/install | sh
```
Then run the manual onboarding sync:
```bash theme={null}
scott sync
```
The installer configures the skills, rules, and hosted MCP connection where supported. `scott sync` reads recent local agent work and opens `/sync`.
## Manual setup
Use `scott setup` from a local terminal when the installer cannot detect an agent automatically or when you want to target a specific tool.
```bash theme={null}
scott setup # auto-detect agents
scott setup --claude # Claude Code
scott setup --cursor # Cursor
scott setup --codex # Codex
scott setup --opencode # OpenCode
scott setup --gemini # Gemini CLI
```
You can target multiple agents in one run:
```bash theme={null}
scott setup --claude --cursor --codex
```
## What setup installs
Setup adds the Scott skill, rule, and hosted MCP entry needed for your coding agent to:
* sync recent local agent history
* push the current conversation to Scott
* pull planspace context into execution
* understand when to ask for feedback before creating a planspace
## Remove setup
```bash theme={null}
scott remove --claude
scott remove --mcp-only
scott remove --skills-only
```
Removing local setup does not delete planspaces or team context from Scott.
## Login and logout
```bash theme={null}
scott login
scott logout
```
`scott login` opens your browser and stores credentials locally. `scott logout` clears the local credentials file.
# Sync
Source: https://docs.tryscott.ai/developer-tools/sync
Run scott sync to onboard Scott with recent local coding-agent history.
`scott sync` is the primary onboarding action for the Scott agent plugin. From your development machine, run:
```bash theme={null}
curl -fsSL https://tryscott.ai/install | sh
scott sync
```
The installer sets up the Scott plugin for detected coding agents. Then `scott sync` reads recent local coding-agent sessions, uploads the relevant context to Scott, starts a Sync Chat review, and opens `/sync`.
Install plus `scott sync` is the exception to the agent-first workflow. Push and pull should stay agent-invoked because they depend on the active thread context.
## What sync does
1. Finds supported local agent session history
2. Uploads recent sessions from the last 14 days
3. Creates unsynthesized planspaces that Scott can reason over
4. Starts a Sync Chat review of recent themes and priorities
5. Prints a URL to `/sync`
Run sync from the development machine where the agent sessions happened. Hosted browser agents cannot read your local history.
## What to ask Sync Chat
After sync finishes, ask questions like:
```text theme={null}
What have I been working on lately?
```
```text theme={null}
Which of these sessions should become team-facing planspaces?
```
```text theme={null}
What patterns or repeated ideas do you see across my recent agent work?
```
```text theme={null}
Write up the strongest prototype as a planspace for team review.
```
## Add code context
Sync Chat works from session history by default. For code-aware answers, connect repositories with the [Scott GitHub App](/planspaces/connected-sources).
## When to run sync again
Run `scott sync` whenever you want Scott to refresh its view of local agent work:
* after a day of active agent sessions
* before planning what to share with the team
* before a design review or sprint planning meeting
* when switching machines or agents
## Sync vs push
Use `scott sync` to onboard broad recent history. Use [Push](/developer-tools/push) when one current thread is ready to become a team-readable planspace.
# Core concepts
Source: https://docs.tryscott.ai/getting-started/concepts
The main ideas behind Scott: sync, planspaces, reviews, approvals, plugin handoff, and GitHub App feedback.
Scott is a context system for teams working with coding agents. It keeps local agent work, team feedback, design approvals, and shipped code connected.
## Sync Chat
**Sync Chat** is your personal starting point after sync. It lets you ask across recent local coding-agent sessions, find recurring themes, and decide which threads deserve team attention.
Use Sync Chat when:
* You are onboarding Scott and want it to understand your recent work
* You need to search across Claude Code, Codex, Cursor, OpenCode, Gemini, and other local agent sessions
* You want Scott to recommend which sessions should become shared planspaces
Learn more in [Sync](/developer-tools/sync).
## Planspaces
**Planspaces** are shared workspaces for design intent. They combine a chat, a living document, source context, comments, reviews, approvals, and team membership.
Use a planspace when:
* a prototype or proposal needs feedback before implementation hardens
* engineers and non-technical teammates need one place to discuss intent
* you want an approved plan that can later be pulled into an agent thread
Learn more in [Planspaces](/planspaces/overview).
## Documents and versions
Every planspace has a document that evolves as you work with Scott. Saved versions let reviewers approve a specific state of the design, not a moving target.
Use document versions to:
* preserve the proposal that teammates reviewed
* compare intent before and after comments
* link pull requests to the exact design version they implement
Learn more in [Documents](/planspaces/documents).
## Comments, reviews, and approvals
Comments are anchored to document text. Reviews turn a document version into an approval workflow with clear reviewer state: pending, in progress, approved, or rejected.
Use reviews when:
* a plan is ready for formal feedback
* you need design approval before an agent starts execution
* you want the Scott GitHub App to compare a pull request against the approved intent
Learn more in [Reviews and approvals](/collaboration/reviews).
## Scott agent plugin
The Scott agent plugin is the bundle of skills and local `scott` commands that moves coding-agent work into and out of Scott. You usually invoke it from the agent session you are already using:
| Action | What the plugin does |
| ------------------------------------------ | ---------------------------------------------------------- |
| `scott sync` from your local terminal | Upload recent local agent history and open Sync Chat |
| "Push this conversation to Scott" | Turn the current agent thread into a shareable planspace |
| "Pull from Scott using this planspace URL" | Load reviewed planspace context into a fresh agent session |
Learn more in [Scott agent plugin](/developer-tools/cli).
## Scott GitHub App
The Scott GitHub App's primary job is to connect pull requests back to design intent. Teams add Scott URLs to PR descriptions or commit messages, then Scott reviews the implementation against the linked planspaces and feeds execution context back into the document set.
The app also provides repository context so Sync Chat and planspaces can answer with awareness of your codebase. That setup is a utility that makes the core workflow better: PR design review, execution feedback, and continuously updated design context.
Learn more in [Scott GitHub App](/developer-tools/github-app).
# Quickstart
Source: https://docs.tryscott.ai/getting-started/quickstart
Install Scott, sync recent agent work, and learn the daily team workflow.
## Get a quick overview
Sync Chat, planspaces, reviews, approvals, the Scott agent plugin, and the GitHub App.
Our philosophy on building with agents: align on intent before delegating execution.
## Start with Sync
`scott sync` is the fastest way to onboard. From your development machine, run:
```bash theme={null}
curl -fsSL https://tryscott.ai/install | sh
scott sync
```
The installer sets up the Scott plugin for detected coding agents. Then `scott sync` reads recent local coding-agent sessions and opens `/sync`. After sync finishes, open the URL Scott prints and ask across recent Claude Code, Codex, Cursor, OpenCode, Gemini, and other supported agent sessions.
Install plus `scott sync` is the manual getting-started step. After that, push and pull should be invoked from your coding agent because they depend on the active thread context.
Learn more in [Sync](/developer-tools/sync).
## Add code context
Sync Chat works immediately from session history. For code-aware answers, connect GitHub from the Sync Chat source picker or the planspace composer.
1. Click **Connect repo**
2. Install the Scott GitHub App for the GitHub account or organization you want Scott to read from
3. We recommend granting access to all repositories; limiting access can cap answer quality when relevant context lives outside one repo
**Security note:** Scott is SOC 2 compliant. We do not persist repository contents. We fetch code only into ephemeral sandboxes when an answer needs it, and if you remove GitHub access Scott can no longer fetch that code.
After installation, the repositories you granted access to appear in Scott's repo picker.
Learn more in [Code context](/planspaces/connected-sources).
## Push early, pull when ready
Ask your coding agent to push to Scott whenever a thread becomes a prototype, design direction, or proposal that needs team feedback.
`# from claude code, codex, gemini, opencode, etc`
```text theme={null}
push this conversation to Scott so my teammates can review it
```
Your agent runs the Scott workflow from the thread that already has the context. Scott creates a planspace with a readable document and a URL you can share in Slack, Linear, a design review, or a PR description. Teammates can comment, request changes, and approve a specific document version.
When the team is aligned, start a fresh agent thread and ask it to pull from Scott:
`# from claude code, codex, gemini, opencode, etc`
```text theme={null}
pull from Scott using this planspace and start building: https://app.tryscott.ai/workspace/...
```
Learn more in [Push](/developer-tools/push), [Pull](/developer-tools/pull), and [Teams](/planspaces/overview).
## Configure PR design review
Set up the Scott GitHub App for your organization when you want pull requests to stay linked to the planspaces that shaped the work.
1. Open your team settings in Scott
2. Install the Scott GitHub App for the GitHub organization
3. Select the repositories where your team wants Scott review and PR linking
4. Add one or more planspace URLs to a pull request description or commit message
When a pull request includes planspace links, Scott connects the PR to the design approvals and review context. The GitHub App can run an agent-assisted architectural review and leave a comment on GitHub. After code lands, the PR link feeds execution context back into Scott.
Learn more in [Scott GitHub App](/developer-tools/github-app) and [PR design review](/developer-tools/scott-ci).
## What to read next
Learn how to use planspaces, documents, comments, reviews, approvals, sharing, and For You.
Learn how sync, push, pull, and setup fit into your daily agent workflow.
Learn how PR design review, execution feedback, and code context connect planspaces to code.
Learn how teams approve design intent before execution.
# Scott AI docs
Source: https://docs.tryscott.ai/index
Sync agent work, share design intent, gather team feedback, and connect planspaces to code.
Scott helps teams move from isolated agent execution to shared design intent. Start by syncing recent local agent work, push focused threads into planspaces for feedback, pull approved context back into execution, and connect PRs to the design decisions that shaped them.
Install the Scott plugin, sync local agent work, connect code context, and learn the daily push/pull loop.
Planspaces, Sync Chat, reviews, approvals, the Scott agent plugin, and the GitHub App.
## Daily workflow
Use planspaces, documents, comments, reviews, approvals, sharing, and For You to align people before agents execute.
Run manual sync, then ask your coding agent to push planspaces and pull approved context.
Review pull requests against planspace intent and feed execution decisions back into Scott.
Add planspace URLs to pull requests so Scott can review implementation against design intent.
## Common paths
Turn a proposal or prototype into a teammate-readable document with comments and reviews.
Ask humans or review agents to approve a specific document version before implementation.
Make repository context available so Scott can answer and review with better code awareness.
Load planspace documents, comments, approvals, and implementation context into a fresh agent thread.
# Code context
Source: https://docs.tryscott.ai/planspaces/connected-sources
Use the Scott GitHub App to make repository context available to Sync Chat and planspaces.
Code context is supporting setup for the Scott GitHub App. It lets Scott answer and review with awareness of your actual repositories instead of only the text in an agent session or planspace.
Use code context when:
* Sync Chat needs to explain a pattern across recent code work
* a planspace needs architecture-aware recommendations
* reviewers need to verify a proposal against the current repo
* a pulled planspace should give an agent context that matches the codebase
## Connect GitHub
1. Click **Connect repo** from Sync Chat or the planspace composer
2. Install the Scott GitHub App for the GitHub account or organization you want Scott to read from
3. We recommend granting access to all repositories; limiting access can cap answer quality when relevant context lives outside one repo
Scott is SOC 2 compliant. We do not persist repository contents. We fetch code only into ephemeral sandboxes when an answer needs it, and if you remove GitHub access Scott can no longer fetch that code.
After installation, the repositories you granted access to appear in Scott's repo picker.
## Select repositories and branches
When you attach a repository, Scott records the repository and branch selection for that Sync Chat turn or planspace. Use the branch that best represents the code your proposal depends on.
For example:
* use `main` for product or architecture context
* use a feature branch when a prototype already exists
* use a migration branch when reviewing rollout or compatibility risk
## Uploaded files
You can also upload files directly, such as PDFs, design specs, architecture docs, or code snippets.
1. Click **Add source** or the source picker
2. Choose **Files**
3. Drag and drop or browse for files
## Access changes
If a repository does not appear, reopen **Connect repo** and update repository access on the Scott GitHub App installation.
If access is removed in GitHub, Scott can no longer fetch that repository. Existing planspace documents and comments remain, but future code-aware answers cannot use removed code.
## Code context vs PR design review
Code context helps Scott answer questions, write better plans, and run stronger PR reviews. [PR design review](/developer-tools/scott-ci) is the primary GitHub App workflow that links implementation work back to planspaces after a pull request is opened or updated.
# Documents and versions
Source: https://docs.tryscott.ai/planspaces/documents
How planspace documents evolve, get reviewed, and become durable design intent.
Every planspace has a document. The document is the team-readable artifact that turns agent conversation into a proposal, design, implementation plan, or reviewable spec.
Documents are useful because they let non-technical teammates participate without reading an entire agent transcript. They can read the current version, comment on exact passages, and approve a direction before engineers delegate execution.
## What belongs in the document
Good Scott documents usually include:
* the problem and desired outcome
* constraints, risks, and open questions
* architecture or product decisions
* prototype notes and screenshots when relevant
* implementation plan and rollout notes
* links to the code, PRs, or follow-up planspaces that matter
## Versions
Scott saves document versions as the plan changes. A version is the stable thing a teammate can review and approve.
Use versions when:
* comments have changed the direction and you need a clean review point
* a reviewer needs to approve a specific plan, not a live draft
* a PR should link to the exact design version it implements
* you want to compare original intent with actual execution later
## Editing
The author can keep iterating with Scott in chat, edit the document directly, or incorporate selected comments back into the conversation. The goal is not to preserve a perfect first draft. The goal is to make team feedback explicit and keep the document aligned with what the team intends to build.
## Review handoff
When the document is ready for sign-off:
1. Save or open the version you want reviewed
2. Use **Share** and choose **Review**
3. Select reviewers and explain what they should focus on
4. Reviewers approve or reject from the review panel
Once approved, that version becomes the strongest reference when your agent [pulls context from Scott](/developer-tools/pull) and when the [Scott GitHub App](/developer-tools/scott-ci) reviews a PR.
## PR feedback
When a pull request links back to a planspace, Scott can connect implementation work to the document that shaped it. This is how the document set keeps updating: original design intent, review feedback, implementation decisions, and shipped code stay connected.
# Planspaces
Source: https://docs.tryscott.ai/planspaces/overview
The shared UI where teams turn agent work into documents, feedback, reviews, and execution context.
A planspace is where a team aligns on what should be built before handing work back to agents. It combines a conversation, a living document, connected sources, comments, reviews, approvals, and sharing controls.
Use planspaces for:
* prototype writeups and design proposals
* engineering plans that need PM, design, or leadership feedback
* implementation context that should survive beyond one agent thread
* approved intent that should later be pulled into execution with the Scott plugin
## How planspaces start
You can create a planspace three ways:
1. **From Sync Chat** - pin or write up a useful synced session after [Sync](/developer-tools/sync)
2. **From your coding agent** - ask the Scott plugin to [push](/developer-tools/push) from a focused thread
3. **From the app** - start a new planspace and describe what you want Scott to draft
For daily team workflows, pushing from your coding agent is usually the fastest path. It turns active agent work into a shareable document while the idea is still fresh.
## The planspace layout
The planspace UI is built for shared review:
* **Chat** is where the author works with Scott and folds feedback back into the proposal.
* **Document** is the readable artifact teammates review, edit, comment on, and approve.
* **Sources** show the GitHub repos or uploaded files Scott can use for grounded answers.
* **Comments** anchor feedback to exact document text.
* **Reviews** create an approval record for a specific saved version.
* **Share** controls who can collaborate, review, or receive the planspace.
## Recommended team flow
1. Start with real work: a prototype, implementation sketch, investigation, or product proposal.
2. Ask your coding agent to [push](/developer-tools/push) it into a planspace.
3. Attach code context with the [Scott GitHub App](/planspaces/connected-sources) when architecture matters.
4. Share the planspace with engineers, PMs, designers, or leadership.
5. Use [comments](/collaboration/comments) for targeted feedback and [reviews](/collaboration/reviews) for approval.
6. Ask a fresh agent thread to [pull](/developer-tools/pull) the reviewed context from Scott.
7. Link the PR back to the planspace with the [Scott GitHub App](/developer-tools/scott-ci).
## Roles
| Role | Send messages | Edit document | Comment | Review | Manage members |
| --------- | :-----------: | :-----------: | :-----: | :----: | :------------: |
| Owner | Yes | Yes | Yes | Yes | Yes |
| Editor | Yes | Yes | Yes | Yes | No |
| Commenter | No | No | Yes | Yes | No |
| Viewer | No | No | No | No | No |
## What good looks like
A strong planspace is not a polished spec dropped at the end of the process. It is a working design record that captures:
* the rough prototype or proposal that started the thread
* what the team questioned or changed
* the version that was approved
* the context an agent needs to execute
* the PRs that implemented the approved design