Skip to main content
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

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 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.