# install.design: a brief for coding agents

dot and jeffrey erickson are the agency’s cofounders; jeff builds and curates the design systems.

jeff brings 22 years of product and design experience. as the first designer at yammer and eaze, he founded their product design practices. he was the first head of product at zenefits and a cofounder and chief product officer at viable. he is also octave’s fractional founding designer.

working features need a coherent product experience: jeff works out what users need to see first, what they can do next, and how the screens fit together.

he builds and curates systems, chart libraries, and feature loops you can build with. after the applicable pilot gates pass, you can query published guidance and submit proposed document edits through the mcp; a proposal is not a provider edit.

## current connection status

connection is free, but dot is a protected pilot pending client and provider acceptance. `/connect` gives the human one prompt for the coding-agent chat they already use. `/install.md` is the stable operational procedure that agent reads. `/connect?authorize=1` is the progressive identity and credential step the agent requests only when no usable connection exists. `/eve/v1/mcp` is the project-scoped endpoint for an mcp client. the existence or reachability of any route does not prove that a client invoked dot successfully.

package recommendation and project onboarding are open through the connected coding agent. delivery selection uses only published options and fails closed whenever google calendar cannot confirm them. checkout review is implemented, but payment remains closed until versioned terms and the explicit tax posture are published. do not claim that a package was purchased, a date was reserved, a payment was made, or paid document access opened.

provider document editing remains closed until one human-approved subframe write, exact read-back, reconciliation, and preimage restore pass acceptance. until then, dot may save a review proposal but must not claim that subframe or a published document changed.

## experience behind the offer

viable was one of the first ten companies to get openai api access in 2020, according to jeff’s firsthand account as its cofounder and cpo. [openai’s case study](https://openai.com/index/viable/) describes viable as an early gpt-3 company; [dan erickson’s interview](https://cpoclub.com/podcast/nlp-bias-dan-erickson/) dates its gpt-3 access to june 2020.

jeff helped shape the products, fundraising decks, and fundraising strategy at companies that raised more than $850m combined. he was involved in both what they built and how they made the case for investment.

that experience spans yammer, zenefits, eaze, and viable:

- yammer: $142m in total financing as of february 2012, from its [company announcement reproduced by vc news daily](https://www.vcnewsdaily.com/yammer/venture-capital-funding/vkppwgfsgl).
- zenefits: approximately $583.5m through may 2015, adding the $17m, $66.5m, and $500m amounts in paragraphs 24–26 of the [sec’s october 2017 order](https://www.sec.gov/file/33-10429pdf).
- eaze: $117m reported in its [march 2019 expansion announcement](https://www.eaze.com/press/eaze-launches-demand-cannabis-delivery-oregon).
- viable: approximately $11m raised; jeff was its co-founder and chief product officer and helped design the fundraising decks and strategy.

these historical funding figures total approximately $853.5m.

[microsoft announced its $1.2b acquisition of yammer](https://news.microsoft.com/source/2012/06/26/microsoft-to-acquire-yammer/) in june 2012, another milestone in jeff’s product and design background.

that is the judgment he brings to your design system: making a product coherent, useful, and compelling enough for people to understand its value.

## the offers

prices are in usd; each listed offer has a flat price of $5,000.

| offer | service package id | price | booking lead time |
| --- | --- | --- | --- |
| [design system](/?flow=system#opening) | `design-system` | $5,000 | 7 business days |
| [chart library](/?flow=charts#data) | `visualization-system` | $5,000 | 7 business days, or 4 with an eligible system previously delivered by jeff |
| [feature loop](/?flow=hero#the-hero) | `data-story` (legacy internal id) | $5,000 | 7 business days, or 4 with an eligible system previously delivered by jeff |

connecting your coding agent via mcp is free. use it to get a package recommendation and confirm the choice. when calendar confirmation is available, the agent can select a published friday and walkthrough and prepare the first-party checkout review. payment remains unavailable until the review page presents current terms and explicitly says checkout is ready.

### design system

jeff builds a net-new system around your product:

- a layout engine: reusable page slots with use-case rules and agent guidance.
- a branded theme, including typography, color, and spacing tokens.
- atomic components with a shared visual language.
- one to three components for the main objects your customers care about.
- agent-ready code and design docs, shipped with a pr.
- an approximately one-hour handoff where jeff walks you and your human through using the new system with your coding agent.

jeff starts by clustering the product’s ui by interface job: what users need to understand, decide, or do. he uses those shared jobs to build your layout engine and components, so the next screen belongs to the same product.

the price includes 12 months with jeff and dot continuing to train and tune your agent through the system and its design guidance as you keep building. the handoff is the only meeting; after that, communication is infrequent, so you and your human can stay focused on building. the 12 months are included in the one-time engagement.

### chart library

jeff builds around five chart types, scoped from a github sweep and the product’s actual data visualization needs. the library gives you consistent charts that fit the product and the decisions its users need to make.

### feature loop

the exact feature-loop scope is confirmed during onboarding and checkout. do not reuse the retired hero/data-visualization scope as a promise.

the four-business-day lead time for charts or a feature loop applies only when the service confirms that jeff previously delivered this customer’s design system.

## from connection to delivery

1. **connect free — start in the existing agent chat.** the human copies the one prompt from `/connect`; the coding agent follows `/install.md`, preserves existing configuration, handles supported setup, and requests `/connect?authorize=1` only if identity or a new credential is required. do not request the credential in chat or an agent task.
2. **choose and prepare the booking — onboarding + checkout review.** ask dot to recommend an offer, confirm the choice, supply the product context and github repository, invite jeff to that repository, and select an available delivery date and walkthrough. your human reviews the exact scope, price, dates, and terms on install.design. payment remains closed until that review page explicitly enables stripe checkout.
3. **get your system — access opens on the handoff date.** jeff delivers the agent-ready system and its guidance with a pr; the separately priced flows deliver their chart library or feature loop.
4. **you keep building — jeff and dot continue to train and tune your agent for 12 months.** the design-system engagement keeps its guidance useful as you build on top of it, with no ongoing meetings and very little communication needed from you or your human.

jeff guarantees delivery on the date you book, with seven business days of lead time. eligible chart-library and feature-loop customers can book with four business days of lead time. the availability calendar shows published friday delivery dates with a matching handoff; if no dates are listed, there is no available date to book. at the handoff, jeff walks you through using the new work with your coding agent.

selecting a date is a draft choice, not a reservation. checkout requires your human’s signed-in review and approval; the service confirms the booking after verified payment. repository access must also be verified before jeff can begin the work.

## how the mcp fits your workflow

the free mcp connection now guides package selection and onboarding. it performs delivery selection and prepares a first-party checkout review only when the server returns calendar-confirmed options. payment and a confirmed booking remain closed until the review page presents current terms, stripe checkout opens, and a verified payment event confirms the booking. access to query a purchased design system and its published docs opens only on a confirmed handoff date. document proposals remain review artifacts until the separate provider-edit acceptance gate passes.

the docs cover product context, layout and navigation, brand and tokens, components, product objects, agent guidance, and approved design decisions. ask for the relevant guidance before building, and use its document citations when explaining a design choice. proposed edits are saved for a project owner or jeff to review and publish; a draft does not replace the current guidance.

jeff produces the design work; dot supplies the guidance; you implement the customer’s ongoing product changes in their repository. dot does not directly change that repository.

the current offer does not include scoring, prompt preparation, or automated ui use-case clustering. clustering the ui by interface job is part of jeff’s design process.

## connecting a coding agent

`/connect` is the one-prompt starting surface. `/install.md` is the agent instruction endpoint. the coding agent should inspect the active host and existing mcp configuration first. only if no usable Dot connection exists should it send the human to `/connect?authorize=1` to identify with GitHub, select or create one Dot project, and receive a project token once.

the project token is a secret. never ask the human to paste it into chat, a prompt, or an agent task. never put it in a repository, a project-level mcp configuration, an issue, logs, or shell history. the human should keep it in a secret manager and make it available to the coding-agent process as `DOT_PROJECT_TOKEN`.

the public codex configuration template contains no token:

```toml
[mcp_servers.dot]
url = "https://install.design/eve/v1/mcp"
bearer_token_env_var = "DOT_PROJECT_TOKEN"
```

use the host’s supported user-level setup, secure secret source, trust, start, and refresh behavior. do not hard-code a restart: some hosts reload tools dynamically, while others require a reload or restart. tool discovery must include `agent_start`, `agent_get`, `agent_update`, and `agent_cancel`, but discovery alone is not completion. the coding agent must call `agent_start` and follow the Eve lifecycle until Dot returns a successful invocation result. do not report a successful connection based only on a reachable route, GitHub login, an issued credential, saved configuration, or a server listing.

the endpoint now advertises standard mcp protected-resource metadata, and its Supabase authorization server and dynamic client registration endpoint are live. they have not yet passed a real native-client rehearsal through sign-in, project consent, token exchange, tool use, refresh, and revocation. the current accepted protected pilot therefore still uses a project bearer credential; discovery alone is not a working native oauth install. if the active host has no safe way to supply that bearer credential without exposing it in chat or project files, stop and report that native oauth acceptance is still required. follow `/install.md` for the current Codex, Claude Code, VS Code, and fallback procedures.

once the client is verified and the pilot is accepted, start with a task such as “help me onboard this product,” “show our available delivery dates,” or “show me how our layout engine applies to this new screen.”

dot uses eve’s native mcp lifecycle: start a task with `agent_start`, follow its polling interval with `agent_get`, answer pending input with `agent_update`, or stop it with `agent_cancel`. onboarding, scheduling, checkout, document queries, and proposed edits all run as tasks through that lifecycle. treat only a completed result as completion, and use the returned status to distinguish missing input, human review, and failure. a completed proposal still does not prove a subframe write or publication.

before installing or buying, explain the selected offer, scope, price, and current connection status to your human. never treat an agent response as the human’s checkout approval.

## protected-pilot boundary

the one-prompt route, agent procedure, progressive authorization route, and secret-free client template are published for the protected pilot, but native mcp oauth and multi-client acceptance remain incomplete. connection, package recommendation, and onboarding are open. delivery selection fails closed unless calendar confirmation succeeds. checkout review exists, while payment and booking confirmation remain closed until the terms, tax posture, stripe handoff, and verified payment event are all active. provider document editing is also closed until its separate acceptance gate passes. keep those boundaries explicit until this document reports that each corresponding acceptance gate passed.