Private portfolio

Enter password

This portfolio is shared privately. Enter the password to continue.

Mindstone Rebel

Designing open-source contribution agents for an AI-native desktop

Rebel is Mindstone's AI desktop operating system. After we shipped the first market-ready version, the next design problem was scale: how to let users and contributors create new capability through open source, while keeping the product coherent, transparent, and grounded in good UX.

Role
Senior Product Designer
Team
Embedded in engineering
Tools
CursorAI-native code editor with an in-editor agent, chat, and tab completion.SlackTeam messaging app used for async collaboration and in-flow notifications.PostHogOpen-source product analytics with session replay, funnels, and feature flags.GitHubGit hosting, code review, and collaboration platform for software teams.StorybookBrowsable gallery of shared UI components in every state, used as a preview and review layer for contributors and reviewers.
Frame

Rebel had to become something users could change

After the first market-ready version shipped, the next challenge was letting more people shape what Rebel could do without losing product judgement.

I joined Rebel while we were still building from zero. Once the product was in people’s hands, the question changed. Rebel needed to become extensible and transparent enough for people to build on. Open source turned into a design problem, not a release strategy.

V1 started with the MCP layer, the connectors that let Rebel reach tools beyond the default catalogue. When one was missing, Rebel had to notice the gap, ask the user how to handle it, then build, test, and contribute it back.

The product problem was simple: missing capability already existed, but contribution lived outside the product.

Existing demand

570

Custom MCP connections, built locally.

Initial rollout

19

Connectors moved into beta.

QA pressure

32

Scenarios across build, extend, submit, and notify.

Review layers

2

Design judgement encoded as checks.

That evidence changed the brief. Open source could not sit in GitHub alone. Rebel had to make missing capability feel solvable inside the task, while keeping GitHub as infrastructure rather than the interface.

Contribution

I started where the gap was felt, not where developers usually start

The V1 flow had to begin when Rebel noticed missing capability, not in a settings screen or a developer portal.

OSS MCP contribution flow: detect, route, scaffold, test, submit, publish
Detect the gap, route the user to extend or build, scaffold and test, then submit and track.

The old path depended on users knowing what to do when a connector did not exist. Custom connectors stayed local, and no one else benefited.

I designed V1 around two paths:

  1. Extend an existing connector when Rebel had the service but not the right capability.
  2. Build a new connector when the service did not exist in the catalog.

Both paths kept the same rule: build in context, test before trust, submit without making GitHub the interface.

The user model

I was designing for different levels of technical confidence

The product had to support people who wanted GitHub credit and people who wanted Rebel to handle the contribution path on their behalf.

Rebel asks for the Recraft API key so it can finish the live test and connect the tool.
Rebel asks which name to use when sharing the connector, including Rebel name, GitHub account, and anonymous options.
User-friendly options for contribution recognition
The contribution flow let users choose how much technical ownership they wanted to expose.

This was not only about open-source mechanics. It was about translation. Rebel had to notice a missing tool, explain what was happening, and let the user stay in control without forcing them to think like an engineer.

That changed the interface:

  • Confident builders needed inspectable outputs, GitHub attribution, and control over the contribution.
  • Outcome-focused users needed plain-language choices, question cards, and visible approval checkpoints.
  • Guided adopters needed reassurance, one clear next step, and recovery paths when Rebel could not complete the job alone.

Question cards were the plain-language prompts that gathered missing connector details. Approval checkpoints made test-before-trust visible. Submission status showed where the contribution stood after Rebel handled the repository work.

That is why the principle mattered:

What shipped first

V1 made connector creation the first open-source surface

Open Source MCPs reached beta with 19 connectors migrated. The first version proved that contribution could move into the app before the wider product opened up.

  1. Ask for attribution and test access.
  2. Show the connector tools before submission.
  3. Generate a GitHub PR with summary and checks.
  4. Bring review status back into Rebel.
Rebel connector settings panel for Recraft, showing fifteen enabled tools and tool permission labels.

GitHub could still hold source, attribution, and review. It could not be the surface that explained what to do next.

The beta exposed the next problems: bugs in the flow, QA pressure across both paths, and reliability gaps in community submission.

If Rebel could guide a connector contribution, the next version could guide a dashboard or a workflow. To get there, review judgement had to be built into the product.

GitHub pull request titled feat connector add recraft MCP, open status, checks, and generated summary.
Rebel sent-for-review card with under-review status and buttons to view on GitHub or in Settings.
V1 turned connector creation into a guided contribution loop: Rebel asked for the missing decisions, generated a GitHub PR, and brought review status back into the app.
Review

Open source needed review rules, not taste-based gatekeeping

If agents and contributors were going to change the product, review had to become explicit.

I encoded review as two runnable skills. The Chief Design Agent did product and interface critique. It restated the user problem, checked against encoded principles, named system effects, and returned a clear next move. The Design System Reviewer ran alongside it, checking that new work fit shared atoms, tokens, and accessibility. Visual critique required a screenshot first and failed closed when one was missing. An open-source product cannot rely on context sitting in one designer’s head.

Review

Chief Design Agent

Reviews product and interface changes before they ship.

  • Problem first
  • Principles checked
  • Next move
System fit

Design System Reviewer

Checks new UI against shared atoms, tokens, and accessibility.

  • Tokens
  • States
  • Access
Signal in

UX Auditor

  • Heuristic breaks
  • Severity
Signal in

UX Research Helper

  • Evidence
  • Sources
Judgement out

Product Design Ideation

  • Problem frames
  • Options
Judgement out

UX Copywriter

  • Voice
  • Mental model

Audits surfaced where heuristics broke. Research turned platform signal into evidence. Copy turned decisions into shippable language. The reviewer judged against grounded context, not invented principles.

System

The design system had to become code-first

Contribution only scales if the product has rules that contributors and agents can inspect.

Code rules Chief Designer SKILL.md in Rebel, defining the product design persona, judgement principles, goals, and expected outcome for UI work.
Registry Storybook Registry page showing status labels, scanned components, unique CSS tokens, undefined tokens, and design system families.
Preview states Storybook preview for Settings Rows, showing guidance for usage and row variants such as assistant voice, quality mode, connection health, and desktop notifications.
Code Tokens, atoms, molecules, and skill contracts
Storybook Registry, usage notes, and component states
Chief Designer Review judgement grounded in the same rules
Rebel Shared patterns return to the product
Code became the source of truth, Storybook became the preview layer, and the Chief Designer skill made the same rules inspectable inside Rebel.

I did not want Rebel to start with a heavy design system. In the early product phase, that would have slowed the team down. The app needed room for engineers, designers, and agents to try things and find the right shape.

Once the product existed, the rules had to become explicit. The contract had to live in code so contributors and agents could read it.

  • Code is the source of truth.
  • Storybook is the preview layer.
  • The system is legible to humans and AI through tokens, atoms, molecules, and component states.

I used AI review, screenshots, Storybook, and the codebase to spot drift and duplicate patterns. I pulled shared atoms and molecules into the system, clarified tokens and component states, and moved real app surfaces onto shared patterns. Without that, contributors and agents kept inventing new UI.

Conclusion

Open source became a product experience when the path became visible

Open source became clearer when Rebel gave users a way to notice a missing capability, shape it, test it, and understand where it went next.

The bigger learning was that AI products need visible rules as much as they need new capability.

01

Start where the gap appears

Contribution should begin where the user feels missing capability, not in GitHub or documentation.

Product entry point
02

Make judgement inspectable

Agents and contributors need explicit review rules so decisions can be checked, challenged, and improved.

Review infrastructure
03

Turn the system into a contract

A code-first design system gives people and AI the same source of truth for how Rebel should behave.

Shared product rules