Skip to main content

Stet — Design Session Handoff

A handoff brief for kicking off a design session (e.g. Claude Design). Structured as one master brief + six follow-up prompts. Everything here is derived from the ADRs (docs/adrs/), the specs (docs/openspec/specs/), and the visual-identity block in CLAUDE.md — keep it consistent with those if the product evolves.

How to use these​

  1. Paste Prompt 0 (Master Brief) to start. Expect back: design tokens, the brand mark, and the hero three-region window in light + dark.
  2. Iterate until the foundation feels right.
  3. Then send Prompts 1–6 in order (each assumes the master is in context). Prompt 6 is exploratory — send it only if you want the proposed running-artifact modes designed now.
  4. Expansion pack (Prompts 7–13): after the major expansion (trajectories, skill distillation, the social/collaboration layer, agentic voting), send Prompt 7 (Expansion Addendum) to extend the master, then Prompts 8–13 for the new surfaces.
  5. Expansion pack II (Prompts 14–20): the configuration & ecosystem layer (the .stet topology, the three primitives, pins/governance, importable configs). Send Prompt 14 (Addendum II) to extend the master, then Prompts 15–20 for the new surfaces.

Prompt 0 — Master Brief (send first)​

You are a senior Apple-platform product designer. I'm building a native macOS app
called Stet and I want you to design its visual identity and key screens. Treat
this as a real, no-compromise Mac app — the bar is "looks like it shipped from
Cupertino." Read this whole brief, then produce the first-pass deliverables listed
at the end. Ask me before guessing on anything that would define the brand
personality.

WHAT STET IS (one line)
Stet — "You read. It writes." A native macOS app for a world where 100% of code
is written by AI.

THE PREMISE
Every code tool today assumes a human types the code. Stet inverts that: it is a
code VIEWER and a DIRECTION surface, not an editor. The human's job is editorial —
read AI-written code and prose, react, comment, suggest — and when they submit
their feedback, Stet dispatches a sandboxed AI agent (locally, on the user's Mac)
that does the work and opens a pull request. The keyboard is for opinions, not
code.

The name: "stet" is the proofreader's mark (Latin, "let it stand") written in the
margin to approve a change. Approving a hunk in the app is called "stetting" it.

THE GUIDING METAPHOR — proofreading / publishing
Editorial work deserves editorial tools. The vocabulary is galleys and margins:
  galley   — the thing being read/marked up (a file, a diff, a doc)
  margin   — where comments and reactions live
  markup   — the human's comments / emoji / suggestions
  brief    — the compiled set of feedback handed to the agent
  dispatch — sending the brief to a local agent
  tour     — the AI-authored guided walkthrough of a change
Lean into this: calm, precise, literary — not "dev tool," not "AI product."

PLATFORM & HARD CONSTRAINTS
- macOS 26 (Tahoe), Apple silicon only. SwiftUI-native.
- Design language is macOS 26 Liquid Glass: translucent, depth-layered materials
  that adapt to the content behind them (never flat frosted panels). Toolbars float
  above content; sidebars sit beside it; the layering must read as legible depth.
- Everything must be natively implementable in SwiftUI — no web-only effects,
  no tricks that can't be done with system materials, SF Symbols, and standard
  AppKit/SwiftUI controls.
- Design for BOTH light and dark. Tahoe ships both; both must be first-class.

CORE LAYOUT — a three-region window
  LEADING  · Inbox  — a triage list of pull requests and files awaiting the user's
                      "stet." This is the home surface. It is NOT a file tree
                      (a file tree exists only as a secondary view).
  CENTER   · Canvas — the reading surface. Renders code (syntax-highlighted, with
                      minimap, gutter, and diff) and Markdown (fully rendered, not
                      raw). Read-optimized; there is no primary text-entry surface.
  TRAILING · Tour rail — the AI's guided walkthrough of the open PR (an ordered
                      list of "stops," each with a location, a "why," and a risk
                      flag) plus the human's accumulating markup.

THE CORE LOOP (so you understand the flows you're designing)
  1. Sign in with GitHub (or Gitea). Inbox populates.
  2. Read a PR/file in the canvas; the Tour rail guides the reading order.
  3. Mark it up: comments, emoji reactions, suggestions, voice notes, or
     strike-through/scribble gestures. Nothing dispatches yet — markup accumulates
     into a "pending review."
  4. Submit. The markup compiles into one coherent brief → one pull request.
  5. A local agent works (shown as a live, readable "theater," not raw logs) and
     opens a PR, which arrives with its own tour.
  6. Stet it (approve) or reply with more feedback to send the agent back in.

VOCABULARIES TO REFLECT VISUALLY
- Emoji verbs (reactions are a command language, not decoration):
    🐛 investigate ("I think this is wrong")   🎨 refactor-ugly ("works but ugly")
    ❓ explain                                  🔥 delete
- Risk flags on tour stops: none · low · medium · high
- Dispatch lifecycle states: queued → running → opening PR → done · failed
- Narration origin badge: "authored" (by the agent) vs "generated" (on demand)

DESIGN SYSTEM I WANT YOU TO ESTABLISH
- Materials: rules for where Liquid Glass/translucency is used (chrome, sidebars,
  toolbars, the Tour rail) vs. opaque, reading-comfortable content surfaces (the
  canvas). The canvas prioritizes legibility over translucency.
- Typography: SF Pro for UI, SF Mono for code. Generous line-height; reading
  comfort over density. Propose a type ramp (display / title / body / caption /
  code) with sizes and weights.
- Color: restrained and near-neutral so content leads. A SINGLE, tasteful accent
  (propose 2–3 directions — e.g. an ink/indigo, a galley amber, a muted teal — and
  recommend one). Semantic colors for diffs (muted add/remove) and for the risk
  flags. Emoji reactions and risk flags should be most of the color on screen.
- Spacing & density: calm, editorial, roomy — the opposite of a dense IDE.
- Motion: purposeful only — scroll-and-highlight when a tour stop is selected, the
  "dispatch" send gesture, the streaming transcript. Never decorative.
- Iconography: SF Symbols throughout. Brand mark: the stet proofreader's mark
  (a dotted underline). Design an app-icon concept around it.
- Copy tone: calm, precise, editorial. Use the metaphor vocabulary in labels and
  empty states.

EXPLICITLY AVOID
- Any "IDE" / VS Code / Electron look. No file-tree-first layout. No dense toolbars.
- Gratuitous gradients, glows, or neon "AI" aesthetics.
- A webview/cross-platform feel. This is unmistakably a Mac app.
- Skeuomorphism beyond the subtle stet mark.

REFERENCE TOUCHSTONES (for vibe/craft only — do not copy)
Apple Mail & Notes (materials, sidebars, triage), Xcode 26 (native code display),
Linear and NetNewsWire (inbox/triage clarity), Things / Ivory / Panic apps
(craft bar), iA Writer (editorial calm).

FIRST-PASS DELIVERABLES (this prompt)
1. Design-language foundation: color tokens (light + dark), the type ramp, spacing
   scale, material-usage rules, and motion principles.
2. The app icon / brand mark concept (the stet dotted-underline).
3. ONE hero mockup, in light AND dark: the full three-region window showing a code
   review in progress — inbox populated with a few PRs, the code canvas showing a
   diff with two or three emoji/comment markups in the margin, and the Tour rail
   showing 3–4 ordered stops (one flagged medium risk).

If the accent color or brand personality is ambiguous, show me 2–3 directions and
recommend one before committing. We'll then iterate screen-by-screen.

Prompt 1 — First-run: sign-in & connect your engine​

Building on the Stet master brief. Design the first-run experience.

Two moments:
A) Sign-in — "Sign in with GitHub" as the primary action, "Connect a Gitea
   instance" as secondary. OAuth (browser round-trip). Warm, one-screen, editorial
   welcome that states the premise in a sentence ("You read. It writes."). Show the
   stet mark. Light + dark.
B) Connect your engine — a brief, skippable setup that establishes what makes Stet
   different: it runs agents LOCALLY with YOUR model.
   - Model endpoint: bring-your-own, OpenAI-compatible (OPENAI_BASE_URL +
     OPENAI_API_KEY + model name). Support cloud or local (e.g. a local Llama).
   - Harness picker: OpenHands (default), Crush, Pi.
   - Runtime picker: Apple container (native, no Docker needed) or Docker — with a
     "detected on your Mac" state.
Design the happy path plus the empty/first states. Keep it 2–3 calm steps, not a
wizard slog. Deliver light + dark.

Prompt 2 — The Inbox (leading region), in depth​

Building on the Stet master brief. Design the Inbox in detail — the home surface.

It is a triage list, NOT a file tree. Design:
- Item types: "PR awaiting your stet," "file flagged for review," "dispatch in
  progress," "PR ready (your agent finished)."
- Per-row content: title, repo, author (human or "Stet agent"), age, a status
  chip, and unread/needs-attention affordance. Show risk or CI signal if present.
- Grouping/sorting: by attention/recency. A lightweight filter or segmented control
  (e.g. Needs review · In progress · Done).
- The secondary file-tree view (how you switch to it, kept clearly secondary).
- Empty state ("Inbox zero" — an editorial, satisfying moment) and a loading state.
Show it at real sidebar width, light + dark, with the Liquid Glass sidebar material.

Prompt 3 — Code canvas + the markup interactions (the star screen)​

Building on the Stet master brief. Design the code canvas and all markup
interactions. This is the signature surface — invest here.

Reading:
- Syntax-highlighted code (tree-sitter quality), minimap, gutter, and a clear,
  legible diff (muted add/remove). Reading comfort over density.
Marking up (design each as a distinct, delightful interaction with its resting +
active states, anchored to a line range in the margin):
- Comment popover.
- Emoji verb palette: 🐛 investigate, 🎨 refactor-ugly, ❓ explain, 🔥 delete —
  make clear these are commands, not decoration. Show a reaction resting in the
  margin.
- Suggestion (propose replacement text).
- Voice annotation: a press-and-hold-to-speak affordance; show the capturing state
  and the resulting transcribed comment.
- Scribble / strike-through: a pencil/trackpad gesture that strikes a span of code
  and becomes a "remove/replace" suggestion. This is a showcase interaction — make
  the gesture and its result feel physical and precise.
The pending review:
- A persistent, calm indicator of accumulated markup (count + a Submit affordance),
  echoing a GitHub draft review but native and quieter.
- The Submit confirmation: a sheet summarizing the brief and its grouping ("this
  becomes 1 pull request"), with the option to see/adjust grouping rationale when a
  review splits into more than one PR.
Deliver light + dark, showing a realistic marked-up diff.

Prompt 4 — Tour rail + Markdown canvas​

Building on the Stet master brief. Design two reading experiences.

A) Tour rail (trailing region): the AI-authored walkthrough of a PR.
- An ordered list of "stops," each with: a location (file + range), a one-line
  "why," and a risk flag (none/low/medium/high with distinct, restrained
  treatments).
- Selecting a stop drives the canvas to scroll + highlight that range — show the
  connected state (rail selection ↔ canvas highlight).
- A badge distinguishing "authored" narration (from the agent) vs "generated"
  (produced on demand for an external PR).
- Each stop doubles as a place to add markup — show that affordance.

B) Markdown canvas: a Markdown file (README/ADR/spec) rendered beautifully — the
same file is a first-class review target, not raw text. Show headings, a table, a
fenced code block (syntax-highlighted), and a task list, with a margin comment
anchored to a rendered element.
Deliver light + dark.

Prompt 5 — Dispatch theater, menu-bar presence & PR arrival​

Building on the Stet master brief. Design what happens after Submit.

- Dispatch theater: a beautiful, READABLE view of the agent working — a narrated
  feed, not raw logs (messages, tool calls summarized, files changed). Design the
  lifecycle states clearly: queued → running → opening PR → done · failed.
- Cost meter: a subtle per-dispatch usage/cost readout (tokens/$), building trust
  by showing what a piece of feedback cost. Only shown when the endpoint reports it.
- Multiple concurrent dispatches (a small queue/overview).
- Menu-bar item: a compact presence showing "N agents working," and a rich macOS
  notification for "PR ready."
- The "PR ready" arrival back in the inbox/canvas, inviting the user to tour it.
Deliver light + dark. Make "watching the agent work" feel like a calm, premium
moment (think Screen Studio, not a terminal).

Prompt 6 — Settings (and, exploratory, the running-artifact modes)​

Building on the Stet master brief. Two things.

A) Settings — native macOS settings, calm and complete:
- Model endpoints (OPENAI_BASE_URL / OPENAI_API_KEY / model; multiple profiles,
  cloud or local).
- Harness: OpenHands / Crush / Pi.
- Runtime: Apple container / Docker (with availability detection).
- Verb packs: view/edit the emoji-verb vocabulary (each emoji → a named workflow).
- Account/forge connections.

B) EXPLORATORY (label clearly as proposed, not shipping): "review the running
artifact, not only the source."
- Web canvas: an embedded browser pointed at the app's live dev server, with an
  annotation layer so the user marks up the RUNNING web UI (click a control,
  highlight an element, comment) and it becomes review markup.
- Screenshot narrative: the user drops in a screenshot of a running NATIVE app; a
  vision model maps screen regions back to source files as an (inverted) tour the
  user can mark up.
Sketch these two as forward-looking concepts consistent with the design system.
Deliver light + dark for Settings; concept-level fidelity is fine for the
exploratory pair.

Expansion pack — the learning & social layer (Prompts 7–13)

Added after ADRs 0011–0014 (trajectories, skill distillation, collaboration/social layer, agentic voting). Send Prompt 7 first to extend the master brief, then the screen prompts. The core discipline is unchanged — calm, editorial, native macOS 26 Liquid Glass, reading-first — with progressive disclosure now a hard constraint, because this layer adds depth that must not become a dashboard.

Prompt 7 — Expansion Addendum (send before Prompts 8–13)​

Addendum to the Stet master brief — a major expansion. Everything in the original
brief still holds; this adds new artifact types and a social/learning layer. Absorb
it, then we'll design the new surfaces. The discipline is unchanged — calm, editorial,
native macOS 26 Liquid Glass, reading-first — and now, crucially, PROGRESSIVE
DISCLOSURE, because this expansion adds real depth that must NOT turn Stet into a
dashboard. Depth on demand, not on screen.

NEW CONCEPT 1 — Trajectories (the record of how code was made)
Every dispatch captures the full TRAJECTORY: the seeding brief, the agent's reasoning,
tool calls, diffs, cost. Trajectories are first-class, VERSIONED artifacts committed
inside the repo (a .stet/ area) as the final commit of the branch — they travel with
the code and are REVIEWED LIKE ANY FILE. A trajectory reads like a tour of what the
agent did. Before storage, a deterministic secret-scanner + redaction gate runs
(redacted spans are visibly marked). Raw audio isn't stored by default; the transcript
is.

NEW CONCEPT 2 — Skills & distillation (the project learns over time)
Over time Stet DISTILLS reusable SKILLS from trajectories + feedback + outcomes. A
skill is an open, versioned artifact. Skills live in three TIERS: project (in the
repo), team, and user (centralized repos registered in settings; most-specific wins).
Distillation proposes a skill as a PR — reviewed through Stet's normal loop. Skills are
injected into future dispatches, so the project's agents improve.

NEW CONCEPT 3 — The social layer (two backends)
The forge (GitHub/Gitea) is the social backbone: identity + baseline comments/emoji
that non-Stet teammates can see. Stet's richer markup, threads, resolution, and votes
live in an embedded, versioned database (Dolt) that syncs to the forge or a
self-hosted instance. Review is multi-user: teammates' markup and reactions appear
together.

NEW CONCEPT 4 — Agentic voting (the collective flywheel)
Humans AND agents vote on hunks/PRs, skills, and trajectories. HUMAN consensus and
AGENT consensus are shown SEPARATELY — humans decide, agents advise. Agent votes carry
an expandable RATIONALE and attribution. Voter DIVERSITY matters (don't imply
consensus from one model echoed N times). Votes feed distillation and can opt-in gate
actions.

NEW VOCABULARY: trajectory, .stet/, distillation, skill, tier (project/team/user),
provenance/lineage, vote, consensus (human vs agent), redaction.

WHAT THIS ADDS TO EXISTING SCREENS
- The canvas gains a new mode: TRAJECTORY (alongside code, markdown, web, screenshot).
- The inbox gains new item types: "trajectory to review", "proposed skill (PR)",
  "PR needs your vote".
- Existing surfaces gain vote affordances, multi-user presence, and provenance access.

Keep it calm. Use progressive disclosure relentlessly.

Prompt 8 — Trajectory review​

Building on the Stet master brief + expansion addendum. Design TRAJECTORY REVIEW.

A trajectory is the versioned record of how an agent produced a change, reviewed like
a file (a new canvas mode). Design:
- The trajectory as a readable, narrated sequence of STEPS — reasoning + tool calls
  (summarized, not raw logs) + the diffs each step produced + running cost. It should
  feel like a guided tour of the agent's work, kin to Tour mode — not a log viewer.
- Anchored markup on any step (comment / emoji verb / vote), same margin model as code.
- Redaction + safety indicators: visibly-marked redacted spans and a "secret-scan
  passed" status — trust signals that this artifact is safe to have in the repo.
- The relationship to its commit (a trajectory IS the branch's final commit), and the
  navigation from a diff to "how was this made?".
- The .stet/ presence: subtle, so trajectories feel first-class without cluttering the
  file view.
- A short/simple trajectory (one step) and a long/complex one.
Light + dark.

Prompt 9 — Skills: the library + reviewing a distilled skill​

Building on the master brief + expansion addendum. Design SKILLS.

A) The skill library — browse skills across three tiers: PROJECT (this repo), TEAM,
   USER. Show tier clearly and its precedence (most-specific wins), each skill's
   name/purpose, PROVENANCE (distilled from N trajectories), an EFFICACY signal (is it
   helping?), and status (active / deprecated). Include registering a centralized
   team/user skill repo (link to settings).
B) Reviewing a distilled skill — distillation proposes a skill as a PR. Design that
   review: the proposed skill content, its provenance back to the trajectories +
   feedback that produced it, and the normal stet / markup / vote affordances. This is
   the flywheel made visible.
Also: a small, quiet indicator on a dispatch showing WHICH skills were injected.
Light + dark. Keep it artifact-like and calm — not a marketplace.

Prompt 10 — Agentic voting​

Building on the master brief + expansion addendum. Design AGENTIC VOTING — a
cross-cutting affordance shown on hunks/PRs, skills, and trajectories.

- The vote control itself (approve / needs-work / reject, or a score — propose the
  cleanest), usable by humans; quiet and native.
- HUMAN consensus vs AGENT consensus shown SEPARATELY and unmistakably — never merged
  into one number. Humans decide; agents advise.
- An agent vote expands to reveal its RATIONALE (a short justification / mini-
  trajectory) — auditable, not an opaque thumbs-up — with attribution (which
  teammate's agent).
- A voter DIVERSITY signal: convey when agent votes come from varied models/lenses vs.
  one model echoed, so consensus isn't faked.
- The opt-in "auto-stet threshold" configuration (advisory by default) and how a hunk
  shows it's near / at threshold.
Design these states on a code hunk (in the margin) and on a skill. Light + dark.
Restraint is everything — this must read as calm signal, not a voting dashboard.

Prompt 11 — The social / collaboration experience​

Building on the master brief + expansion addendum. Design the MULTI-USER experience.

- A PR/file reviewed by several people: teammates' comments, emoji reactions, threads,
  and resolution state, blended in the margin / Tour rail. Subtly distinguish
  forge-native comments (interop with non-Stet users) from Stet-rich markup.
- Threading + resolution (open / resolved) that stays calm and editorial.
- Lightweight PRESENCE (who else is here / recently active) — tasteful, not gaming-y.
- SYNC status: a quiet indicator that collaboration data is syncing (via the forge or
  a self-hosted instance), including an offline / queued state.
- Attribution everywhere: human vs. agent authorship of a comment/reaction.
Light + dark. The bar: a shared galley being marked up by colleagues — not a chat app.

Prompt 12 — Provenance / lineage view​

Building on the master brief + expansion addendum. Design the PROVENANCE view —
"how did this come to be?"

For a given change (commit / PR), visualize its lineage:
  human markup → brief → dispatch (trajectory) → commit
with the SKILLS that were injected and the VOTES that weighed in shown as contributing
nodes. A reviewer should be able to trace any line of code back to the feedback,
reasoning, skills, and consensus that produced it.
- A calm, legible graph or timeline (native, progressively disclosed — not a heavy
  node-graph canvas).
- Clicking a node opens the underlying artifact (trajectory, brief, skill, vote
  rationale) in the canvas.
- Show it both as a compact inline "provenance" affordance on a diff and as a fuller
  dedicated view.
Light + dark.

Prompt 13 — Settings expansion​

Building on the master brief + expansion addendum. EXTEND the Settings design
(Prompt 6) with the new subsystems:
- Collaboration & sync: the embedded database is on by default; a setting to point at
  YOUR OWN INSTANCE (self-hosted) for team sync; sync-topology choice (via the forge
  vs. self-hosted); offline behavior.
- Skill repos: register centralized TEAM and USER skill repositories (the project tier
  is automatic / in-repo).
- Voting: enable agent voting; configure advisory vs. opt-in auto-stet thresholds per
  repo; diversity requirements.
- Privacy & safety: the trajectory redaction + secret-scanner settings (bundled,
  deterministic, on by default), .stetignore management, and audio-retention opt-in
  (off by default).
Keep it native macOS Settings — organized, calm, progressively disclosed. Light + dark.

Expansion pack II — the configuration & ecosystem layer (Prompts 14–20)

Added after ADRs 0015–0017 (the .stet topology, the three primitives — Agents / Skills / Verbs — pins/governance, and composable/importable configs). Send Prompt 14 first to extend the master brief, then the screen prompts. Progressive disclosure remains a hard constraint; this layer may be denser (it is where power users live) but must stay native and legible about where a value came from.

Prompt 14 — Expansion Addendum II (send before Prompts 15–20)​

Addendum II to the Stet master brief — the configuration & ecosystem layer. Builds on
the master brief and Expansion Addendum (Prompt 7); everything prior still holds, and
progressive disclosure is still a hard constraint. This layer is where power users
live, so it may be denser than the reading surfaces — but it must still feel like calm,
native macOS, never config sprawl.

CORE MODEL — three primitives, one topology. Stet has three configuration PRIMITIVES,
all treated as versioned software artifacts:
- VERBS  — what the human can say (emoji/comment → workflow). The input vocabulary.
- AGENTS — who acts (a named, configured actor: harness + model + persona + attached
           skills + handled verbs + guardrails).
- SKILLS — what they know (reusable, often distilled, capability).
All three resolve across a three-level `.stet` TOPOLOGY:
- user    → $USERNAME/.stet (a repo)
- org     → $ORG/.stet (a repo)
- project → <repo>/.stet/ (a directory)
Resolution is most-specific-wins; the precedence DIRECTION is a user SETTING. A higher
tier can PIN a definition non-overridable — a hard governance lock that beats precedence
(mandated config, and auditable provenance of what was mandated).

RECURSION — `.stet` repos are themselves Stet projects, so editing config is itself a
reviewed, voted, dispatched change with its own trajectory. Config gets the same
read/markup/vote/tour experience as code.

FORMAT & ECOSYSTEM — configs are YAML. A `.stet` can IMPORT other `.stet` repos (like
ESLint `extends` / Terraform modules), turning the topology into a dependency graph:
friends base on yours, orgs import vendor packs. Imports pin to a ref (a LOCKFILE).
Trust is downstream-enforced: policy can require the pinned SHA be GPG-SIGNED by an
ALLOWED SIGNER. Importing is importing executable intent, so supply-chain review IS the
normal stet loop.

NEW VOCABULARY: primitive, topology (user/org/project), tier, precedence, pin/enforce,
import, lockfile, signed ref / allowed signer, resolved value, config provenance.

WHAT TO DESIGN NEXT (Prompts 15–20): the config workspace, the agent editor, the verb
editor, the imports/supply-chain surface, governance + config provenance, and the
ecosystem/marketplace. Above all, be legible about WHERE a value came from.

Prompt 15 — The Config Workspace (primitive manager)​

Building on the master brief + Expansion Addenda I & II. Design the CONFIG WORKSPACE
where Agents, Skills, and Verbs are browsed and edited across tiers.

- A unified workspace over the three primitives (Agents · Skills · Verbs); for each,
  its definitions across the three tiers (user · org · project) and any imported bases.
- The RESOLVED VIEW: for a given primitive, show the value that actually wins and —
  legibly — WHICH TIER it came from, whether it's PINNED (mandated, can't override),
  and what it overrode. This "where did this come from" clarity is the whole point.
- Editing a definition (YAML-backed) in a calm editor; make clear that saving is a
  reviewed change to the relevant `.stet` (the recursion), not a silent write.
- Tier switcher / filter; a badge vocabulary for tier · pinned · imported · deprecated.
- Empty states (a project with no local overrides, inheriting everything cleanly).
Light + dark. Denser than the reading surfaces is OK — still native and quiet.

Prompt 16 — Agent editor & library​

Building on the master brief + Expansion Addenda I & II. Design the AGENT editor and
library.

An Agent is a named, versioned actor. The editor configures: harness
(OpenHands/Crush/Pi), model endpoint (bring-your-own, OpenAI-compatible), persona /
system prompt, attached SKILLS, handled VERBS, guardrails (sandbox scope, cost ceiling,
permissions), and an ENFORCEMENT / PIN toggle (mandate this agent; non-overridable at
lower tiers).
- The editor: native and form-like but calm; YAML is the source of truth, the UI is
  friendly; always show the resolved/effective config.
- The agent LIBRARY across tiers (user/org/project + imported): each agent's purpose,
  tier, pinned/imported badges, and — tying to voting — a hint of model DIVERSITY (a
  panel of agents on different models reviews better than one model echoed).
- Show an agent's IDENTITY (owned by a teammate) as used for vote attribution.
- Pinning or deprecating an agent shown as a reviewed change.
Light + dark.

Prompt 17 — Verb editor​

Building on the master brief + Expansion Addenda I & II. Design the VERB editor.

A verb binds an emoji (or comment type) to a workflow — the human's command language
(🐛 investigate, 🎨 refactor-ugly, ❓ explain, 🔥 delete, plus custom). Design:
- Editing a verb PACK: the emoji, its label, and the workflow it triggers (single- or
  multi-step), YAML-backed with a friendly UI.
- Tier + import awareness: which verbs are inherited vs. local, which are pinned, which
  came from an imported pack; how a project overrides one binding while inheriting the
  rest.
- A tasteful emoji/verb picker that reinforces "these are commands, not decoration."
- Preview: what this verb will actually instruct an agent to do.
Light + dark. Authoring a verb should feel playful but precise.

Prompt 18 — Imports & supply chain​

Building on the master brief + Expansion Addenda I & II. Design IMPORTS & SUPPLY CHAIN —
how a `.stet` builds on other `.stet` repos.

- Adding an IMPORT: point at another `.stet` repo and pin it to a ref (a LOCKFILE view
  of exactly what's pinned).
- TRUST status per import: is the pinned commit/tag GPG-SIGNED, and by an ALLOWED
  SIGNER? Show verified / unsigned / untrusted states clearly and calmly — a security
  surface whose states must be unmistakable without being alarmist.
- Reviewing an import as a SUPPLY-CHAIN DIFF: adding/bumping an import is a reviewed,
  voted PR — the human sees exactly which agents/skills/verbs it brings in (importing =
  executable intent).
- UPDATE notifications, Dependabot-style: "upstream bumped; review the diff."
- Org ALLOWLIST / allowed-signers management.
Light + dark. Tone: trustworthy and legible, never a wall of security jargon.

Prompt 19 — Governance & config provenance​

Building on the master brief + Expansion Addenda I & II. Design GOVERNANCE & CONFIG
PROVENANCE — the sibling to code provenance (Prompt 12), but for configuration.

- A calm visualization of the three-level TOPOLOGY (user → org → project) + imported
  bases, showing how a given Agent/Skill/Verb RESOLVES: what each tier contributes,
  what won, and what's PINNED.
- The PRECEDENCE setting (the soft, user-chosen direction) and how pins (the hard lock)
  visibly trump it.
- "Why is this the effective config?" — trace an effective agent/skill/verb back
  through tiers, imports, and pins to its source, with the governing PR/vote.
- Governance made visible: an org mandate ("this security agent is required on every
  repo") shown alongside the reviewed PR that mandated it.
Light + dark. Legible depth on demand — not a dense graph dump.

Prompt 20 — The .stet ecosystem / marketplace (exploratory)​

Building on the master brief + Expansion Addenda I & II. Design (EXPLORATORY — label as
proposed) the `.stet` ECOSYSTEM for discovering importable config.

- A calm, editorial DIRECTORY of importable `.stet` packs (community verb packs, vendor
  agent/skill packs, a friend's setup) — a curated reading list, not an app-store
  carnival.
- Each entry: what it provides (agents/skills/verbs), author/provenance, signed-by
  trust signal, popularity/efficacy hints, and a one-click "import (pinned + reviewed)"
  that drops into the supply-chain review flow (Prompt 18).
- "Fork my setup" / base-yours-on-mine as a first-class, friendly action.
Concept-level fidelity is fine. Light + dark. Tasteful and trustworthy.

Provenance​