Heim

Skill

Produktivität und Workflow

visual-plan

BuilderIO/skills

Wandeln Sie Textentwürfe in interaktive visuelle Dokumente mit Diagrammen, Codeausschnitten und Überprüfungsflächen für Programmierer um.

...Alle erweitern

Zeit aktualisiert 6. September 2026

# diagrams # agent native plans # code snippets # plan documentation # plan mcp # review surface # visual planning

Agent-native Pläne

„Agent-Native Plans“ ist ein strukturierter visueller Planungsmodus für die Programmierung von Agenten. Erstellen Sie den Plan, den Sie normalerweise in Markdown schreiben würden, jedoch als übersichtliches Dokument mit eingebetteten bearbeitbaren Blöcken: Inline-Diagramme, Code-Schnipsel, offene Fragen und einen optionalen oberen Bereich zur visuellen Überprüfung (Wireframe-Leinwand, Live- Prototyp oder beides in Registerkarten). Architektur- und Backend-Pläne bleiben rein dokumentbasiert; UI- und Produktpläne beginnen mit der oberen Arbeitsfläche/dem Prototyp (der Abschnitt „Visual Surface Choice“ legt diese Regel fest).

/visual-plan ist der gepackte Befehl und der Haupteinstiegspunkt. Wählen Sie den Überprüfungsmodus aus der Aufgabe aus: „UI-first“, wenn es sich bei der Arbeit hauptsächlich um die Produkt-UI handelt und die Überprüfung mit Bildschirmen beginnen soll; „Prototype-first“, wenn die Überprüfung mit einem funktionsfähigen Live-Prototyp beginnen soll; „Design-first“, wenn die Überprüfung markenspezifische Bildschirme in voller Detailtreue erfordert, oder „Visual-Intake“, wenn der Nutzer vor der Planung ausdrücklich einen Fragebogen wünscht. Wenn bereits ein Codex, Claude-Code, Markdown oder ein eingefügter Plan vorhanden ist, /visual-plan wird dieser Quellplan als Ausgangspunkt verwendet und die Überprüfungsoberfläche daraus erstellt, anstatt von vorne zu beginnen.

Wann anzuwenden

Erstellen oder passen Sie einen visuellen Plan immer dann an, wenn der Plan als überprüfbares Artefakt besser geeignet ist als ein Chat-Absatz. Dazu gehören kleinere Aufgaben wie eine einzelne UI-Oberfläche mit Zuständen, ein kleiner Workflow, eine Produktänderung vor/nachher oder eine Entscheidung zu Komponenten, APIs oder Datenstrukturen, die abgestimmt werden muss, sowie größere, mehrere Dateien umfassende, mehrdeutige, langwierige, risikobehaftete oder UI-intensive Aufgaben. Verwenden Sie ihn, wenn Architektur / Datenfluss / UI-Ausrichtung / Optionen / offene Fragen von Inline- Diagrammen oder strukturierten Blöcken profitieren würden, wenn der Nutzer vor der Umsetzung auf eine Richtung reagieren muss oder wenn ein bestehender Textplan eine umfangreichere Überprüfungsgrundlage benötigt.

Planungsdisziplin

Gehe bei der Abwägung umsichtig vor. Ein visueller Plan bietet eine umfassendere Überprüfungsgrundlage und ist nicht nur ein Werkzeug für riesige Projekte. Verwende ihn, wenn der Nutzer eine Richtung vor der Code-Umsetzung sehen, vergleichen, kommentieren oder genehmigen muss – selbst bei einer geringfügigen Änderung an UI, Zustand oder Workflow . Lassen Sie ihn bei wirklich trivialen, eindeutigen Aufgaben weg – Tippfehler, einzeilige Korrekturen, eine einzige genau spezifizierte Funktion, alles, dessen Unterschied Sie in einem Satz beschreiben könnten – und nehmen Sie die Änderung einfach vor. Füllen Sie einen Plan niemals mit Füllmaterial auf und liefern Sie niemals einen Ein-Schritt-Plan aus.
Recherchiere, bevor du einen Entwurf erstellst. Lies zuerst die tatsächlichen Dateien, Aktionen, Schemata und Muster; benenne tatsächliche Dateien, Symbole und Datenformen, anstatt sie zu erfinden. Überprüfe vorhandene actions/ , bevor du Endpunkte vorschlägst, und ziehe benannte Client-Helfer dem rohen Abruf vor. Delegiere die umfassende Erkundung an einen Unteragenten. Stelle die Wiederverwendung in den Vordergrund: Nenne für jeden Schritt zunächst, was er wiederverwendet – vorhandene Aktionen, Schemata, Komponenten, Helfer – und erst danach, was er hinzufügt, damit der Plan das wirklich neue Delta erläutert, anstatt bereits Vorhandenes neu zu beschreiben.
Entscheiden Sie sich zuerst für die schwer rückgängig zu machenden Entscheidungen. Bei nicht trivialen Backend-, Daten- oder API- skizzieren Sie, in welche Richtung sich das Feature entwickelt, und benennen Sie dann die Entscheidungen, deren Rückgängigmachen kostspielig ist, sobald Daten oder Aufrufer davon abhängig sind – Datenformat, öffentliche IDs, Form des Datenmodells, Authentifizierungs- und Eigentumsgrenzen – und legen Sie diese im Plan fest, auch wenn der Großteil des Features erst später ausgeliefert wird. Legen Sie dann den Umfang auf den kleinsten ersten Schritt fest, der den Ansatz belegt, ohne ihn vorzeitig festzulegen, und geben Sie dabei sowohl an, was enthalten ist, als auch, was ausdrücklich zurückgestellt wird.
Halten Sie Beispiele auf der richtigen Ebene. Wenn die Idee des Nutzers eine umfassende Änderung des Frameworks, des Produkts oder des Betriebsmodells betrifft, reduzieren Sie diese nicht auf das erste konkrete Beispiel, den ersten Anbieter oder den ersten Synchronisationspfad, den er erwähnt. Trenne die Kernabstraktion von motivierenden Beispielen und App-/Anbieter-Adaptern. Nutze Beispiele, um den Plan verständlich zu machen, kennzeichne sie jedoch als Beispiele, es sei denn, sie stellen den gesamten gewünschten Umfang dar.
Veröffentlichen Sie eigenständige Pläne. Wenn der Nutzer einen Codex-/Claude-Code-/Markdown-Plan eingefügt, darauf verwiesen oder bereits einen solchen besitzt, behandeln Sie diesen als Ausgangsmaterial, aber formulieren Sie den veröffentlichten Plan neu als klaren, eigenständigen Vorschlag. Behalte die nützliche Absicht und die Fakten zur Codebasis des Quellplans bei, kennzeichne abgeleitete visuelle Elemente als „abgeleitet“ und vermeide Formulierungen, die auf eine Überarbeitung hindeuten, wie „den vorherigen Plan beibehalten“, „die alte Idee nicht verwerfen“, „im Gegensatz zur vorherigen Version“ oder „diese Überarbeitung ändert…“. Ein Leser, der den Chat oder frühere Entwürfe nie gesehen hat, sollte den Plan verstehen können.
Gestalten Sie den ersten Leseeindruck konkret. Wenn der Plan dazu bestimmt ist, mit jemandem außerhalb des Chats geteilt zu werden, oder wenn das Konzept abstrakt ist, führen Sie ganz am Anfang mit einem konkreten Produktbeispiel ein, bevor Sie Modustabellen, Architektur oder Roadmaps ansprechen. Für UI-fähige Konzepte bedeutet das in der Regel einen App-Zustand im oberen Bereich der Arbeitsfläche, der den tatsächlichen Benutzer-Workflow in Produktbegriffen darstellt. Verlassen Sie sich nicht auf Formulierungen, die nur im Gespräch Sinn ergeben, und formulieren Sie den Plan nicht als „nicht die alte Idee“; beschreiben Sie das positive Modell direkt.
Die Planung ist schreibgeschützt. Nimm während der Erstellung oder Überprüfung des Plans keine Änderungen am Quelltext vor. Beginne erst mit der Bearbeitung, nachdem der Nutzer die Richtung genehmigt hat.
Klären statt annehmen. Fragen Sie nicht, wie es umgesetzt werden soll – erarbeiten und präsentieren Sie den Ansatz und die Optionen im Plan. Stellen Sie eine klärende Frage nur dann, wenn eine Unklarheit das Design verändern würde und Sie diese nicht anhand des Codes klären können; nutzen Sie den normalen Ablauf des Host-Agenten zum Stellen von Nutzerfragen und stellen Sie 2–4 besonders wichtige Fragen gebündelt, bevor Sie den Plan abschließen. Rufen Sie create-visual-questions für gewöhnliche Klärungen oder Vorabprüfungen; reserviere dies für den visuellen Erfassungsmodus, wenn der Nutzer ausdrücklich um einen visuellen Erfassungsfragebogen bittet. Andernfalls gib die Annahme ausdrücklich an und fahre fort; halte alles Ungeklärte im einzigen unteren question-form „Offene Fragen“. Bei komplexen Plänen führen Sie vor der Übergabe einen abschließenden Durchlauf der offenen Fragen durch: Wenn eine Entscheidung Auswirkungen auf Architektur, Umfang, UX, Datenstruktur oder Rollout hätte, entscheiden Sie entweder im Plan mit Begründung oder tragen Sie sie in das unterste Formular mit einem empfohlenen Standardwert ein.
Der Plan ist die Genehmigungsinstanz. Bitten Sie den Nutzer nach der Vorlage, diesen zu prüfen und zu genehmigen, bevor Sie Code schreiben, und geben Sie an, welche Dateien/Bereiche von der Arbeit betroffen sind. Die Präsentation des Plans und die Einholung der Freigabe sind der Genehmigungsschritt – stellen Sie keine separate Frage wie „Sieht das gut aus?“.
Das Dokument ist die maßgebliche Quelle, nicht der Chat. Wenn sich der Umfang ändert, aktualisieren Sie den Plan mit update-visual-plan , anstatt den Kurs nur im Chat zu ändern, und stellen Sie das aktualisierte Dokument eigenständig bereit. Beschreiben Sie die Aktualisierung nicht als Korrektur eines früheren Entwurfs innerhalb des Plans selbst. Lesen Sie den genehmigten Plan vor größeren Schritten noch einmal durch.

Erstellen Sie einen strukturierten, agenten-nativen Plan – niemals inline

Das Ergebnis ist IMMER ein strukturierter, agenten-nativer Plan, kein reiner Chat-Plan. Der gehostete Plan-MCP-Konnektor (plan Server oder Legacy- agent-native-plans) ist die standardmäßige Oberfläche für Zusammenarbeit und Kommentierung; er ist kein Grund, das Planungsmuster als externe Abhängigkeit oder gemietete Ebene abzulehnen. Pläne sind portable Quellartefakte (plan.mdx, optionaler canvas.mdx / prototype.mdx, JSON- und HTML-Export), und besitzabhängige Workflows können den Modus „Lokale Dateien“ oder eine selbst gehostete/benutzerdefinierte Plan-App-URL nutzen, ohne die Prüfungsdisziplin des Skills zu vernachlässigen. Raten Sie dem Nutzer nicht, /visual-plan , nur weil die Standardoberfläche gehostet ist; wählen Sie den richtigen Plan-Modus entsprechend den Anforderungen des Nutzers hinsichtlich Eigentumsrechten, Datenschutz, Freigabe und Branding.

Erstellen Sie den Plan standardmäßig über den Plan-MCP-Konnektor und geben Sie ihn NIEMALS als Inline-Chat-Inhalt weiter – keine Markdown-Texte, ASCII-Skizzen, Tabellen oder umrandete Wireframes. Falls der plan (oder die älteren agent-native-plans) Tools nicht sichtbar sind, ermitteln Sie diese zunächst über die tool_search zuerst; sollten sie immer noch fehlen, HÖREN SIE AUF und geben Sie dem Nutzer den kundenspezifischen Schritt zur Wiederverbindung an, anstatt einen Inline-Plan zu improvisieren. Vor der Veröffentlichung oder wann immer ein Konnektor- oder Authentifizierungsfehler auftritt, LESEN SIE references/connection.md in diesem Skill-Verzeichnis nach – es ist die einzige verlässliche Quelle für die „Nie-inline“-Regel, die Konnektorerkennung und die klientenbezogenen Schritte zur Wiederverbindung. Der Datenschutzmodus für lokale Dateien (nach der Tool-Anleitung) bildet die Ausnahme.

Kern-Workflow

Dieser Abschnitt beschreibt den standardmäßigen gehosteten Plan-MCP-Workflow. Wenn AGENT_NATIVE_PLANS_MODE=local-files dies eingestellt ist oder der Benutzer vollständig lokale Dateien/keine Schreibvorgänge im gehosteten Plan anfordert, verwende stattdessen den Datenschutzmodus für lokale Dateien; übernehme hier nur die Anleitungen zur Code-Recherche und zur Planerstellung.

Befolgen Sie den normalen Planungsablauf des Host-Agenten: Untersuchen Sie die Codebasis, delegieren Sie bei Bedarf eine umfassende Erkundung, sammeln Sie die erforderlichen Informationen und stellen Sie bei Bedarf native Klärungsfragen, bevor Sie den Plan erstellen. Falls bereits ein Quellplan vorliegt, erfassen Sie dessen genauen Text aus der Einfügung des Benutzers, einer referenzierten Datei oder dem zuletzt sichtbaren Agentenkontext; erfinden Sie keinen Quelltext.
Rufen Sie get-plan-blocks den maßgeblichen Blockkatalog ab – verfassen Sie den Text nicht auf der Grundlage auswendig gelernter Tags. Rufen Sie anschließend das für den Modus geeignete Erstellungstool auf: create-visual-plan für „Document-First“-Pläne (Architektur, Backend, Daten, Refactoring, API), create-ui-plan für UI-First-Pläne, create-prototype-plan für „Prototyp-First“-Pläne, create-plan-design für „Design-First“-Pläne, create-visual-questions nur, wenn der Benutzer ausdrücklich einen visuellen Erfassungsfragebogen anfordert. Wenn bereits ein Quellplan vorhanden ist, übergeben Sie diesen als planText und bewahren Sie die ursprüngliche Absicht des Plans bei, während Sie ein eigenständiges Planungsdokument erstellen – kein Überarbeitungsmemo.
Bei UI-/Produktplänen erstellen Sie zunächst die oberste Arbeitsfläche mit den primären Wireframes und kommentierten Zuständen und verfassen Sie anschließend das Dokument mit nativen Blöcken (siehe references/canvas.md und references/document-quality.md). Bei umfassenden Produktarchitekturplänen mit Auswirkungen auf die Benutzererfahrung fügen Sie eine konkrete visuelle Darstellung („So sieht das in der App aus“) vor den abstrakten Architektur- oder Modustabellen hinzu. Halten Sie das Dokument möglichst nah am eigenständigen Markdown-Plan, den der Agent normalerweise ausgeben würde. Wenn ein bestehender Plan vorliegt, übernehmen Sie die relevanten Fakten und Entscheidungen, ohne auf den vorherigen Entwurf Bezug zu nehmen oder zu erklären, wie sich diese Version unterscheidet. Bei nicht-visuellen Plänen überspringen Sie die oberste visuelle Ebene (die Regel dazu finden Sie unter „Auswahl der visuellen Ebene“ unten) und fügen Sie diagram, data-model, api-endpoint, diff, file-tree, codeund annotated-code Blöcke direkt neben den entsprechenden Text. Das breite Dokumentlayout unterliegt dem Renderer und ist absichtlich zugelassen: Nur wörtliche Code-Review-Oberflächen (diff, annotated-code) sowie tabs Blöcke mit vertikaler Ausrichtung oder diff-ähnlichen Unterelementen, die breiter als der Text sind. Behalten Sie api-endpoint, openapi-spec, data-model, json-explorer, wireframe, Frage und custom-html Blöcke im normalen Dokumentfluss, sofern ihr eigener Renderer nichts anderes vorgibt.
Zeigen Sie den zurückgegebenen „Plans“-Link oder die eingebettete MCP-App an und bitten Sie den Benutzer zur Überprüfung. Fügen Sie im Chat immer die tatsächliche URL ein, damit der nächste Schritt ein Klick in der CLI oder anderen rein textbasierten Hosts ist. Wenn der Host einen eingebetteten Browser/ein Vorschaufenster anzeigt und ein Tool dort beliebige URLs öffnen kann, öffne die zurückgegebene Plan-URL automatisch zur bequemen Überprüfung – als Komfort- und Funktionstest, niemals als einzige Übergabe oder als Zugriffsmodell . Pläne sollten für den lokalen Agenten und die lokale Browsersitzung sofort geladen werden; wenn ein eingebetteter Browser, in dem der Benutzer angemeldet ist, einen lokalen Plan nicht lesen kann, den eine anonyme/Tool-Prüfung lesen kann, korrigieren Sie die App-/Aktionszuordnung oder den Zugriffspfad, anstatt einen einzelnen Plan manuell zu reparieren. Bei Plänen mit hohem Risiko (Architektur, Backend, Daten, mehrere Dateien oder risikobehaftet) sollte zudem der Selbstüberprüfungsdurchlauf in „Self-Review Before Handoff“ gestartet werden, während der Benutzer den Plan liest, anstatt die Übergabe deswegen zu blockieren.
Bei gehosteten Plänen rufen Sie get-plan-feedback vor der Bearbeitung, nach der Überprüfung, nach jeder längeren Pause und vor der endgültigen Antwort auf. Betrachten Sie anchorDetails, die Absicht des Lösers, die jüngsten Überprüfungsereignisse und alle fokussierten Screenshots aus der Browser-Übergabe als die Quelle der Wahrheit dafür, was genau sich geändert hat und worauf sich jeder Kommentar genau bezieht.
Bei gehosteten Plänen sollten Änderungen mit update-visual-planund bevorzugen Sie gezielte contentPatches. Behandeln Sie die Payload der obersten Ebene content Nutzdaten als vollständigen Ersatz und nicht als Zusammenführung; sende kein Teilobjekt content Objekt, um eine Leinwand oder einen Block hinzuzufügen. Wenn ein vollständiger Ersatz unvermeidbar ist, lesen Sie zunächst die vollständige Planquelle/-inhalte, übernehmen Sie jeden bestehenden Block und jede visuelle Oberfläche und überprüfen Sie anschließend die Quelle/den Export , um sicherzustellen, dass der Dokumenttext nicht abgeschnitten wurde. Wenn der Benutzer versionskontrollfreundliche Bearbeitungen wünscht, verwenden Sie patch-visual-plan-source anhand der MDX-Dateien vor, anstatt den Plan neu zu generieren.
Bei gehosteten Plänen exportieren Sie mit export-visual-plan nur dann, wenn der Benutzer eine teilbare Quittung oder Artefakte für das Einchecken in das Repository wünscht.

Selbstüberprüfung vor der Übergabe

Bei Plänen mit hohem Risiko – Architektur, Backend, Datenmodell, Migration, mehrere Dateien oder anderweitig risikobehaftete Arbeiten – führen Sie einen kritischen Selbstüberprüfungsdurchlauf durch, bevor Sie den Plan als endgültig betrachten. Überspringen Sie diesen Schritt bei kleinen, rein UI-bezogenen oder Plänen mit nur einer Entscheidung, bei denen der Aufwand den Nutzen übersteigt. Halten Sie den Durchlauf kostengünstig und nicht blockierend:

Stellen Sie den Plan zunächst bereit und überprüfen Sie ihn parallel dazu. Veröffentlichen Sie den Link und lassen Sie den Nutzer mit dem Lesen beginnen; führen Sie die Überprüfung dann parallel durch – lassen Sie den Nutzer niemals darauf warten.
Überprüfen Sie den schriftlichen Plan; recherchieren Sie nicht erneut. Kritisieren Sie den Plantext und seine eigenen Blöcke. Die Grundlagen wurden bereits beim Verfassen gelegt, daher überprüft die Überprüfung das Ergebnis, anstatt das Repo erneut zu durchforsten.
Setzen Sie einen skeptischen Prüfer ein, dessen einzige Aufgabe darin besteht, Schwachstellen, Lücken oder Fehler zu finden – nicht zu loben. Richten Sie den Fokus auf: schwer rückgängig zu machende Entscheidungen, die implizit oder gar nicht getroffen wurden (Datenformat, öffentliche IDs, Form des Datenmodells, Authentifizierung, Eigentumsverhältnisse); Schritte, die nicht in realen Dateien oder Symbolen verankert sind; eine Auswahl an Optionen, bei der sich der Plan auf eine festlegen sollte; offensichtlich fehlende Entscheidungen („Was passiert, wenn X?“, „Warum nicht Y?“); sowie Fülltext oder Einzelschritt-Füllmaterial.
Beheben statt fragen. Wenden Sie selbst eindeutige Korrekturen an mit update-visual-plan contentPatches — vage Nicht-Ziele, unbegründete Behauptungen, eine offensichtlich fehlende Entscheidung. Leite echte Ermessensentscheidungen stattdessen an den Nutzer zurück: Füge sie am Ende question-form „Offene Fragen“ am Ende hin oder bündeln Sie sie im normalen Ablauf der Benutzerabfragen. Entscheiden Sie nicht stillschweigend darüber.
Überraschen Sie den Nutzer nicht mitten beim Lesen. Wenden Sie bei einem umfangreichen Plan die Korrekturen an, bevor der Editor geladen wird; andernfalls weisen Sie kurz darauf hin, dass eine Selbstüberprüfung läuft, sodass Änderungen am Plan zu erwarten sind. Fassen Sie bei Ihrer nächsten Antwort zusammen, was die Überprüfung geändert hat und welche Entscheidungen der Nutzer nun treffen muss.

Visuelle Auswahloberfläche

Wählen Sie die Oberfläche vor der Erstellung des Plans oder nach dem Lesen des Quellplans aus. Fügen Sie standardmäßig keine visuellen Elemente hinzu:

Bei UI-/Produktplänen ist die oberste Arbeitsfläche in der Regel die primäre Überprüfungsfläche. Platzieren Sie dort die ersten aussagekräftigen Wireframes und verstecken Sie diese nicht als Blöcke im Dokumenttext. Verwenden Sie mehrere Arbeitsflächen, wenn verschiedene Zustände eine Rolle spielen, wie z. B. die Standardansicht, ein Überlaufmenü oder Popover, ein Seitenbereich, Ladevorgänge oder Fehlermeldungen. Platzieren Sie kurze Anmerkungen neben den Frames mit targetId Plus placement; halten Sie Implementierungsdetails, Abwägungen, Dateizuordnungen, Datenkontrakte, Risiken und Verifizierungen im Dokumenttext unterhalb der Arbeitsfläche fest.

Wenn der Nutzer nach einem Ablauf, einem Storyboard, einer Journey, einem Wireframe, einer Arbeitsfläche oder danach fragt, „wie das aussieht“, behandle dies als „Canvas-First“-Anfrage. Erstelle eine Arbeitsfläche pro für den Nutzer sichtbarem Zustand, verbinde nur benachbarte Übergänge und verwende kurze Anmerkungen auf der Arbeitsfläche für die Produktnotizen. Ersetze den Block im Dokumenttext diagram Block für das angeforderte Storyboard nicht einfach durch den Dokumenttext ersetzen, nur weil HTML-Diagramme schneller zu erstellen sind; Diagramme gehören unterhalb der Arbeitsfläche, um Backend-Mechanismen, Architektur oder Datenabläufe zu erläutern.

Halte Produkt-Wireframes und erläuternde/Meta-Diagramme getrennt. Beginne mit reinen Bildschirmen, die wie der besprochene App-Zustand aussehen, ohne Text-Callouts oder Architekturhinweise, die in die Benutzeroberfläche eingebettet sind. Füge Pfeile, Beschriftungen, Verträge, Datenfluss und Modus-Erläuterungen in separate Anmerkungen, separate Canvas-Diagramme oder den Dokumenttext ein.

Wenn der Plan eine bestehende App betrifft, prüfe die aktuelle Shell/die Komponenten, bevor du mit dem Zeichnen beginnst. Das erste Artboard sollte wie die echte App mit derselben Dichte aussehen: Vorhandene Seitenleisten, die Platzierung der Symbolleiste, Überlaufmenüs, App-Chrome und Framework-Agent-Chrome bleiben an ihren tatsächlichen Stellen. Modellieren Sie sekundäre Oberflächen als separate Zustände, wie z. B. ein Überlauf-Popover oben rechts, ein Sheet, ein Panel, einen Ladezustand oder eine separate „AgentSidebar“, anstatt einen permanenten Inspektor zu erfinden oder Framework-Chrome in die Produkt-Benutzeroberfläche zu integrieren.

Keine visuelle Oberfläche für rein architektonische, rein backendbezogene, Datenmigrations-, rein textbezogene oder anderweitig nicht-visuelle Pläne. Verwende die obere Arbeitsfläche nicht für Architektundiagramme, Abhängigkeitskarten, Dateipläne, API-Verträge oder rein datenflussbezogene Überprüfungen. Verwenden Sie ein aussagekräftiges Dokument mit lokalen Inline-Diagrammen nur dann, wenn Beziehungen einer visuellen Erklärung bedürfen – in der Regel ein räumliches Diagramm pro Empfehlung oder Entscheidung. Bevorzugen Sie gruppierte Bereiche, Ebenen, Quadranten, Matrizen oder Vorher-Nachher-Panels gegenüber einer einachsigen Kette, es sei denn, die Beziehung ist wirklich sequenziell.
Verwenden Sie die Arbeitsfläche nur für einen statischen Bildschirm, einen Vorher-Nachher-Vergleich, den Zustand einer Komponente, ein kleines Popover oder eine visuelle Anleitung, die kein Klicken erfordert. Fügen Sie diese Wireframes in content.canvas und lassen Sie content.prototype.
Canvas + Prototyp für mehrstufige UI-Abläufe, Onboarding, Assistenten, Prüf-/Genehmigungsabläufe, Navigationsänderungen oder alles, bei dem der Prüfer das Verhalten ausführen muss. Behalten Sie die statischen Wireframes bei content.canvas, fügen Sie den darauf abgestimmten funktionalen Prototyp content.prototypeund nutzen Sie die oberen visuellen Registerkarten, um zwischen ihnen zu wechseln.
Prototypen Sie zuerst, wenn der Benutzer die Bedienung der Benutzeroberfläche wünscht oder wenn die Interaktion im Mittelpunkt steht. Verwenden Sie create-prototype-plan, wodurch statische Mockups dort erhalten bleiben, wo sie sinnvoll sind.

Bei gemischten „Canvas + Prototyp“-Plänen sollten Sie dieselben echten Beschriftungen, App-Status und Bildschirm-IDs auf beiden Oberflächen wiederverwenden. Der Canvas dient als überprüfbare statische Referenz; der Prototyp ist die interaktive Version desselben Ablaufs, keine separate Designrichtung.

Wireframe-Qualität – siehe `references/wireframe.md`

UI-Zusammenfassungs-/Plan-Wireframes müssen strenge Qualitätsanforderungen erfüllen – Chrome in voller Breite, fixierte untere Leisten, echte Produktinhalte, Vorher-Nachher-Vergleichbarkeit, die richtige surface Voreinstellung, --wf-* Token statt Hex-Werte und keine /

Auf GitHub ansehen

---
name: visual-plan
description: Transform text plans into interactive visual documents with diagrams, code snippets, and review surfaces for coding agents.
---

# Agent-Native Plans

Agent-Native Plans is structured visual planning mode for coding agents. Build
the plan you would normally write in Markdown, but as a scannable document with
editable blocks mixed in: inline diagrams, code snippets,
open questions, and an optional top visual review area (wireframe canvas, live
prototype, or both in tabs). Architecture and backend plans stay document-only;
UI and product plans start with the top canvas/prototype (the Visual Surface
Choice section owns that rule).

`/visual-plan` is the packaged command and main entry point. Choose the review
mode from the task: UI-first when the work is primarily product UI and review
should start with screens, prototype-first when review should start with a
functional live prototype, design-first when review needs full-fidelity branded
screens, or visual-intake when the user explicitly wants a questionnaire before
planning. When a Codex, Claude Code, Markdown, or pasted plan already exists,
`/visual-plan` uses that source plan as the starting point and builds the review
surface from it instead of starting over.

## When To Use

Create or adapt a visual plan whenever the plan would be better as a reviewable
artifact than a chat paragraph. This includes modest work such as a single UI
surface with states, a small workflow, a before/after product change, or a
component/API/data-shape decision that needs alignment, plus larger multi-file,
ambiguous, long-running, risky, or UI-heavy work. Use it when architecture /
data flow / UI direction / options / open questions would benefit from inline
diagrams or structured blocks, when the user needs to react to a direction
before you implement, or when an existing text plan needs a richer review
surface.

## Plan Discipline

- **Gate thoughtfully.** A visual plan is a richer review surface, not only a
  tool for giant projects. Use it when the user needs to see, compare, comment
  on, or approve a direction before code, even for a modest UI/state/workflow
  change. Skip it for truly trivial, unambiguous work — typos, one-line fixes, a
  single well-specified function, anything whose diff you could describe in one
  sentence — and just make the change. Never pad a plan with filler and never
  ship a single-step plan.
- **Research before you draft.** Read the real files, actions, schema, and
  patterns first; name actual files, symbols, and data shapes instead of
  inventing them. Check existing `actions/` before proposing endpoints and prefer
  named client helpers over raw fetch. Delegate wide exploration to a sub-agent.
  Lead with reuse: for each step, name what it reuses — existing actions, schema,
  components, helpers — before what it adds, so the plan explains the genuinely new
  delta instead of redescribing what already exists.
- **Decide the hard-to-reverse bets first.** For non-trivial backend, data, or API
  work, sketch where the feature is headed, then call out the decisions that are
  expensive to undo once data or callers depend on them — wire format, public ids,
  data-model shape, auth and ownership boundaries — and get those right in the plan
  even if most of the feature ships later. Then scope to the smallest first cut that
  proves the approach without foreclosing it, stating both what is in and what is
  explicitly deferred.
- **Keep examples at the right altitude.** When the user's idea is a broad
  framework, product, or operating-model change, do not collapse it into the
  first concrete example, provider, or sync path they mention. Separate the core
  abstraction from motivating examples and app/provider adapters. Use examples
  to make the plan legible, but label them as examples unless they are the whole
  requested scope.
- **Publish standalone plans.** If the user pasted, referenced, or already has a
  Codex / Claude Code / Markdown plan, treat it as source material, but rewrite
  the published plan as a clean standalone proposal. Preserve the source plan's
  useful intent and codebase facts, label inferred visuals as inferred, and avoid
  revision language such as "preserve the prior plan", "do not drop the old
  idea", "unlike the previous version", or "this revision changes...". A reader
  who never saw the chat or earlier drafts should understand the plan.
- **Make the first read concrete.** If the plan is meant to be shared with
  someone outside the chat, or if the concept is abstract, lead near the top with
  one concrete product example before mode tables, architecture, or roadmaps. For
  UI-capable concepts, that usually means a top-canvas app state that shows the
  real user workflow in product terms. Do not rely on phrases that only make
  sense in conversation, and do not frame the plan as "not the old idea"; state
  the positive model directly.
- **Planning is read-only.** Make no source edits while building or reviewing the
  plan. Start editing only after the user approves the direction.
- **Clarify vs. assume.** Do not ask how to build it — explore and present the
  approach and options in the plan. Ask a clarifying question only when an
  ambiguity would change the design and you cannot resolve it from the code; use
  the host agent's normal ask-user-question flow and batch 2-4 high-leverage
  questions before finalizing. Do not call `create-visual-questions` for
  ordinary clarification or preflight; reserve it for the visual-intake mode when
  the user explicitly asks for a visual intake questionnaire. Otherwise state the
  assumption explicitly and proceed, and keep anything unresolved in the plan's
  single bottom `question-form` Open Questions block. For complex plans, do a
  final open-question pass before handoff: if a decision would affect
  architecture, scope, UX, data shape, or rollout, either decide it in the plan
  with rationale or put it in that bottom form with a recommended default.
- **The plan is the approval gate.** After surfacing it, ask the user to review
  and approve before you write code, and name which files/areas the work touches.
  Presenting the plan and requesting sign-off is the approval step — do not ask a
  separate "does this look good?" question.
- **The document is the source of truth, not the chat.** When scope shifts,
  update the plan with `update-visual-plan` rather than only changing course in
  chat, and make the updated document stand alone. Do not describe the update as
  a correction to an earlier draft inside the plan itself. Re-read the approved
  plan before major steps.

## Create A Structured Agent-Native Plan — Never Inline

The deliverable is ALWAYS a structured Agent-Native Plan, not a chat-only plan.
The hosted Plan MCP connector (`plan` server, or legacy `agent-native-plans`) is
the default collaboration and commenting surface; it is not a reason to reject
the planning pattern as an external dependency or rented layer. Plans are
portable source artifacts (`plan.mdx`, optional `canvas.mdx` /
`prototype.mdx`, JSON, and HTML export), and ownership-sensitive workflows can
use local-files mode or a self-hosted/custom Plan app URL without abandoning the
skill's review discipline. Do not advise the user to skip `/visual-plan` because
the default surface is hosted; choose the right Plan mode for the user's
ownership, privacy, sharing, and branding needs.

By default, create the plan via the Plan MCP connector and NEVER hand it over as
inline chat content — no Markdown prose, ASCII sketch, table, or fenced
wireframe. If the `plan` (or legacy `agent-native-plans`) tools are not visible,
discover them through the host's `tool_search` first; if they are still missing,
STOP and give the user the client-specific reconnect step rather than improvising
an inline plan. Before publishing, or whenever a connector or auth error appears,
READ `references/connection.md` in this skill directory — it is the single source
of truth for the never-inline rule, connector discovery, and the per-client
reconnect steps. Local-files privacy mode (after Tool Guidance) is the exception.

## Core Workflow

This section describes the default hosted Plan MCP workflow. If
`AGENT_NATIVE_PLANS_MODE=local-files` is set, or the user asks for fully local
files/no hosted Plan writes, use **Local-Files Privacy Mode** instead; carry
forward only the code-research and plan-composition guidance here.

1. Follow the host agent's normal planning flow: inspect the codebase, delegate
   wide exploration when useful, gather the info needed, and ask native
   clarifying questions as needed before generating the plan. If a source plan
   already exists, gather its exact text from the user's paste, a referenced
   file, or recent visible agent context; do not invent source text.
2. Call `get-plan-blocks` for the authoritative block catalog — do not author
   from memorized tags. Then call the mode-matched create tool:
   `create-visual-plan` for document-first plans (architecture, backend, data,
   refactor, API), `create-ui-plan` for UI-first plans, `create-prototype-plan`
   for prototype-first plans, `create-plan-design` for design-first plans,
   `create-visual-questions` only when the user explicitly asks for a visual
   intake questionnaire. When a source plan already exists,
   pass it as `planText` and preserve the original plan's useful intent while
   producing a standalone plan document, not a revision memo.
3. For UI/product plans, compose the top canvas first with the primary
   wireframes and annotated states, then write the document with native blocks
   (see `references/canvas.md` and `references/document-quality.md`). For
   broad product architecture plans with a user-facing implication, add a
   concrete "what this looks like in the app" visual before the abstract
   architecture or mode tables. Keep the document close to the standalone
   Markdown plan the agent would normally output. If an existing plan was
   provided, carry forward the right facts and decisions without referring to
   the previous draft or explaining how this version differs. For non-visual
   plans, skip the top visual surface (Visual Surface Choice below owns the rule)
   and put `diagram`, `data-model`,
   `api-endpoint`, `diff`, `file-tree`, `code`, and `annotated-code` blocks
   directly next to the relevant prose.
   Wide document layout is renderer-owned and intentionally allowlisted: only
   literal code-review surfaces (`diff`, `annotated-code`) and `tabs` blocks
   with vertical orientation or diff-like children break out wider than prose.
   Keep `api-endpoint`, `openapi-spec`, `data-model`, `json-explorer`,
   `wireframe`, question, and `custom-html` blocks in normal document flow unless
   their own renderer says otherwise.
4. Surface the returned Plans link or inline MCP App and ask the user to review.
   Always include the actual URL in chat so the next step is a click in CLI or
   other text-only hosts. When the host exposes an embedded browser/preview panel
   and a tool can open arbitrary URLs there, open the returned plan URL
   automatically for convenient review — a convenience and smoke test, never the
   only handoff or the access
   model. Plans should load out of the box for the local agent and local browser
   session; if a signed-in embedded browser cannot read a local plan that an
   anonymous/tool check can read, fix the app/action ownership or access path
   rather than patching one plan by hand. For high-stakes plans (architecture,
   backend, data, multi-file, or risky), also kick off the self-review pass in
   **Self-Review Before Handoff** while the user reads, instead of blocking the
   handoff on it.
5. For hosted plans, call `get-plan-feedback` before editing, after review,
   after any long pause,
   and before the final response. Treat `anchorDetails`, resolver intent, recent
   review events, and any focused screenshots from browser handoff as the source
   of truth for exactly what changed and exactly what each comment points at.
6. For hosted plans, apply changes with `update-visual-plan`, preferring
   targeted `contentPatches`.
   Treat the top-level `content` payload as a full replacement, not a merge; do
   not send a partial `content` object to add a canvas or one block. If a full
   replacement is unavoidable, first read the complete plan source/content, carry
   forward every existing block and visual surface, and verify the source/export
   afterward so the document body was not truncated. When the user wants
   source-control friendly edits, use `patch-visual-plan-source` against the MDX
   files instead of regenerating the plan.
7. For hosted plans, export with `export-visual-plan` only when the user wants a
   shareable receipt or repo-check-in artifacts.

## Self-Review Before Handoff

For high-stakes plans — architecture, backend, data-model, migration, multi-file,
or otherwise risky work — run one adversarial self-review pass before treating the
plan as final. Skip it for small, UI-only, or single-decision plans where the cost
outweighs the value. Keep the pass cheap and non-blocking:

- **Surface the plan first, review concurrently.** Post the link and let the user
  start reading, then run the review in parallel — never make the user wait on it.
- **Review the written plan; do not re-research.** Critique the plan text and its
  own blocks. The grounding was already done while drafting, so the review checks
  the output instead of re-exploring the repo.
- **Spawn one skeptical reviewer** whose only job is to find what is weak, missing,
  or wrong — not to praise. Point it at: hard-to-reverse decisions made implicitly
  or not at all (wire format, public ids, data-model shape, auth, ownership); steps
  not anchored in real files or symbols; a menu of options where the plan should
  commit to one; obvious missing decisions ("what happens when X?", "why not Y?");
  and padding or single-step filler.
- **Fix vs. ask.** Apply clear-cut fixes yourself with `update-visual-plan`
  `contentPatches` — vague non-goals, unanchored claims, an obvious missing
  decision. Route genuine judgment calls back to the user instead: add them to the
  bottom `question-form` Open Questions block or batch them into the normal
  ask-user-question flow. Do not silently decide them.
- **Do not surprise the user mid-read.** On a large plan, apply the patches before
  the editor loads; otherwise note briefly that a self-review is running so the
  plan changing under them is expected. When you next respond, summarize what the
  review changed and what it surfaced for the user to decide.

## Visual Surface Choice

Choose the surface before creating the plan or after reading the source plan. Do
not add visual chrome by default:

For UI/product plans, the top canvas is usually the primary review surface. Put
the first meaningful wireframes there, not buried as document-body blocks. Use
multiple canvas artboards when states matter, such as the default view, an
overflow menu or popover, a side panel, loading, or error. Put short annotations
beside frames with `targetId` plus `placement`; keep implementation details,
tradeoffs, file maps, data contracts, risks, and verification in the document
body below the canvas.

When the user asks for a flow, storyboard, journey, wireframe, canvas, or "what
this looks like", treat that as a canvas-first request. Make one artboard per
user-visible state, connect only adjacent transitions, and use short canvas
annotations for the product notes. Do not substitute a document-body `diagram`
block for the requested storyboard just because HTML diagrams are faster to
write; diagrams belong below the canvas for backend mechanics, architecture, or
data-flow explanation.

Keep product wireframes and explanatory/meta diagrams separate. Start with pure
screens that look like the app state under discussion, without callout prose or
architecture notes embedded inside the UI. Put arrows, labels, contracts, data
flow, and mode explanations in separate annotations, separate canvas diagrams,
or the document body.

When the plan touches an existing app, inspect the current shell/components
before drawing. The first artboard should look like the real app at the same
density: existing sidebars, toolbar placement, overflow menus, app chrome, and
framework agent chrome stay in their real places. Model secondary surfaces as
separate states, such as a top-right overflow popover, sheet, panel, loading
state, or separate AgentSidebar, rather than inventing a permanent inspector or
folding framework chrome into the product UI.

- **No visual surface** for architecture-only, backend-only, data migration,
  copy-only, or otherwise non-visual plans. Do not use the top canvas for
  architecture diagrams, dependency maps, file plans, API contracts, or
  data-flow-only reviews. Use a strong document with local inline diagrams
  only when relationships need a visual explanation, usually one spatial diagram
  per recommendation or decision. Prefer grouped regions, layers, quadrants,
  matrices, or before/after panels over a single-axis chain unless the
  relationship is truly sequential.
- **Canvas only** for one static screen, a before/after comparison, a component
  state, a small popover, or a visual direction that does not require clicking.
  Put those wireframes in `content.canvas` and omit `content.prototype`.
- **Canvas + prototype** for multi-step UI flows, onboarding, wizards,
  review/approval flows, navigation changes, or anything where the reviewer
  needs to operate the behavior. Keep the static wireframes in
  `content.canvas`, add the aligned functional prototype in
  `content.prototype`, and rely on the top visual tabs to switch between them.
- **Prototype-first** when the user asks to operate the UI or when interaction is
  the main question. Use `create-prototype-plan`, which still preserves static
  mocks where useful.

For mixed canvas + prototype plans, reuse the same real labels, app statuses,
and screen ids across both surfaces. The canvas is the inspectable static reference;
the prototype is the interactive version of that same flow, not a separate
design direction.

## Wireframe quality — read `references/wireframe.md`

UI recap/plan wireframes must meet a strict quality bar — full-width chrome,
pinned bottom bars, real product content, before/after comparability, the right
`surface` preset, `--wf-*` tokens instead of hex, and no `<html>`/`<style>`/font
tags. Before authoring ANY wireframe / `<Screen>` / `WireframeBlock`, READ
`references/wireframe.md` in this skill directory — it is the single source of
truth for HTML wireframe quality, shared word for word with `/visual-plan`
and `/visual-recap`. Do not author wireframes from memory.

## Canvas — read `references/canvas.md`

The canvas is the single source of truth for static UI mockups: the `surface`
locks each artboard's footprint, mixed surfaces lay out
in lanes, annotations are plain-text designer notes anchored by
`targetId`/`placement`, and edits are surgical `contentPatches`. Before
authoring or editing ANY canvas, artboard, or annotation, READ
`references/canvas.md` in this skill directory — it is the single source of truth
for canvas/artboard mechanics. Do not author canvas layouts from memory.
Canvas artboards use the same HTML wireframe path as document-body
`WireframeBlock` screens: author `<Screen surface="..." html={...} />` with a
semantic HTML fragment. Do not author fresh kit-tree children such as
`<FrameScreen>`, `<Card>`, `<Row>`, or `<Btn>` inside canvas `<Screen>` tags;
those are legacy compatibility markup for old plans and produce brittle canvas
layouts.

## Document quality — read `references/document-quality.md`

The document is a serious technical plan, not marketing: outcome-first,
prose-first, self-contained, built from the right native blocks, with open
questions in a single bottom `question-form` and a pre-handoff visual check.
Before authoring the plan document, READ `references/document-quality.md` in this
skill directory — it is the single source of truth for the document quality bar.
Do not write the document from memory.

## Good vs. bad exemplar — read `references/exemplar.md`

For a worked example of the bar — a great UI-first plan and `/visual-plan`, plus
the anti-patterns to avoid — READ `references/exemplar.md` in this skill
directory before authoring a plan.

## Tool Guidance

- `create-visual-plan`: start one structured visual plan per agent task/run, or
  import an existing text plan by passing `planText`; `content` may include no
  visual surface, canvas only, or canvas + prototype.
- `create-ui-plan`: start a UI-first plan when the work is primarily product UI.
- `create-prototype-plan`: start a prototype-first plan with a functional top
  review surface.
- `create-plan-design`: start a full-fidelity branded Design-tab plan with an
  optional matching Prototype tab.
- `convert-visual-plan-to-prototype`: convert an existing HTML wireframe canvas
  into a prototype plan.
- `create-visual-questions`: use only when the user explicitly asks for a visual
  intake questionnaire, not as `/visual-plan` preflight.
- `update-visual-plan`: revise content, status, or comments with targeted
  `contentPatches` (see Core Workflow step 6).
- `read-visual-plan-source`: read the normalized plan as `plan.mdx`,
  optional `canvas.mdx`, optional `.plan-state.json`, and JSON.
- `patch-visual-plan-source`: apply granular MDX AST patches by stable block,
  artboard, annotation, component, or wireframe-node id.
- `import-visual-plan-source`: create or replace a plan from an MDX folder.
- `get-visual-plan`: read the current structured plan, exported HTML, and
  annotations; it also returns the MDX folder for source workflows.
- `get-plan-feedback`: read unconsumed human feedback. Use it frequently; it
  returns grouped threads, exact anchor details, expected resolver, and recent
  review-event payloads so agents can act only on the comments meant for them.
- `get-plan-blocks`: resolve block tags before authoring — do not memorize tags;
  call this first to get the authoritative tag names, required fields, and prop
  shapes from the live block registry.
- `export-visual-plan`: export HTML, Markdown fallback, structured JSON, and MDX
  files for repo check-in.

When the user critiques a plan's look or structure, fix the renderer or this
skill — never hand-edit one stored plan. Turn feedback into better guidance.

## Local-Files Privacy Mode — read `references/local-files.md`

When the user wants no hosted Plan database writes — no DB writes, no Plan MCP
publish, fully local/offline/private planning, repo-owned source-controlled
artifacts, or `AGENT_NATIVE_PLANS_MODE=local-files` — do not call any hosted Plan
tool except the schema-only `get-plan-blocks` catalog lookup. Author a local MDX
folder and
preview it with `plan local check` / `plan local serve` / `plan local verify`.
Before using local-files mode, READ `references/local-files.md` in this skill
directory — it is the single source of truth for the full contract (catalog
lookup, MDX folder layout, the local bridge commands, and the hosted tools you
must not call). Carry forward only the code-research and plan-composition
guidance from Core Workflow; everything hosted is replaced by the local bridge.

## Interpreting comment anchors

This section applies to hosted plans with `get-plan-feedback` /
`update-visual-plan`. In local-files mode, do not call hosted feedback or update
tools; interpret file/chat feedback directly, edit the MDX files, rerun the
local bridge check/serve/verify command, and report the new local URL.

`get-plan-feedback` returns rich anchors — read them before acting on any comment.

- **Coordinate frames.** `targetX`/`targetY` are percentages *within* the
  element named by `targetSelector`/`targetKind`. Bare `x`/`y` are percentages
  of the whole plan document. `canvasX`/`canvasY` are raw board-world pixels on
  the design canvas (board size given when available).
- **Wireframe pins.** Anchors on wireframes include `targetNodeId` and
  `targetNodePath` (e.g. `card > list > listItem "Acme Inc"`) identifying the
  exact kit node. Use `targetNodeId` directly with wireframe node patch ops;
  use `data-design-id` values from design artboards with
  `update-design-element-style`. Prefer the node id/path over raw coordinates;
  fall back to coordinates plus the focused screenshot (red ring marks the exact
  point) only when no node id is present.
- **Text quotes.** Resolve `textQuote` against current prose using
  `contextBefore`/`contextAfter` for disambiguation. If `ambiguous: true`, ask
  the user — do not guess which occurrence is meant.
- **Detached comments.** `get-plan-feedback` flags threads whose quoted text no
  longer exists as `detached` (in `detachedThreads`). Reconcile these against
  rewritten content — never silently drop them.
- **Routing.** `resolutionTarget` is the only routing signal: act on `agent`,
  treat `human` as context only. `@mentions` are people to notify, never a
  routing signal.
- **Two-axis state.** Mark every ingested comment as consumed
  (`consumedCommentIds` on `update-visual-plan`). Set `status=resolved` only on
  agent-targeted comments you actually addressed; leave human-targeted comments
  open.

## Visibility & Sharing

Use `set-resource-visibility` to change who can see a plan (e.g. public, login,
or org-scoped). Use `share-resource` to grant specific users or roles access
by email or role. Gate visibility before sharing any plan that covers
unreleased or private work — default to the narrowest scope that meets the
review need.

## Setup & Authentication

There are two ways into Plans.

**Coding agent (CLI).** Install once with the Agent-Native CLI. The command
installs the Plans skills, registers the hosted Plans MCP connector, and runs
auth/setup for the selected local client(s) in the same step (a one-time browser
sign-in at setup — this is intended), so the first tool call in that client does
not hit an OAuth wall:

```bash
npx @agent-native/core@latest skills add visual-plans
```

After that, `/visual-plan` and `/visual-recap` are the two installed slash
commands. If you only need one command, use `skills add visual-plan` or
`skills add visual-recap` instead. The other planning modes
(`create-ui-plan`, `create-prototype-plan`, `create-plan-design`,
`create-visual-questions`) are MCP tools reachable from `/visual-plan`, not
separate slash commands. Pass `--no-connect` to register the connector without
authenticating, then run
`npx @agent-native/core@latest connect https://plan.agent-native.com --client all`
whenever you are ready, or choose a narrower `--client`. Auth and MCP tool
loading are per client config/session.

**Browser (people you share with).** Open the Plans editor and create & edit
with no sign-up — you work as a guest. Sign in only when you want to save or
share; signing in claims the plans you made as a guest into your account.

Sharing and commenting require an account: public/shared plans are viewable by
anyone with the link, but commenting on them needs an agent-native account.

For fully offline, no-account use, run the Plans app locally and sync plans to
your repo as MDX. This local mode is a separate advanced path, not the default
hosted flow.

If a Plans tool returns `needs auth`, `Unauthorized`, or `Session terminated`, do
not keep retrying it — stop and give the user the per-client reconnect step from
`references/connection.md`, then continue once the connector is available.

Hosted default: connect `https://plan.agent-native.com/_agent-native/mcp`. Do
not put shared secrets in skill files.