mirror of
https://github.com/nexu-io/open-design.git
synced 2026-05-31 19:04:39 +07:00
Add community and use case blog posts (#2103)
* Add community and use case blog posts Co-authored-by: Cursor <cursoragent@cursor.com> * Fix plugin workflow example path Co-authored-by: Cursor <cursoragent@cursor.com> * Fix plugin workflow commands and CTA Co-authored-by: Cursor <cursoragent@cursor.com> * Reduce blog topics diff noise Co-authored-by: Cursor <cursoragent@cursor.com> * Align plugin publishing docs with CLI Co-authored-by: Cursor <cursoragent@cursor.com> --------- Co-authored-by: ashley li <ashleyli@ashleydeMacBook-Air-2.local> Co-authored-by: Cursor <cursoragent@cursor.com>
This commit is contained in:
ashleyashli
GitHub
parent
4f116d9eaf
commit
5d28f1c19d
4 changed files with 187 additions and 12 deletions
|
|
@ -94,6 +94,8 @@ Posts that are live. The right-hand columns get filled by the GSC review automat
|
|||
| 2026-05-13 | byok-design-workflow-claude-codex-qwen | Guides (BYOK) | 18 | pending GSC propagation (3–14d) | pending | — | 2026-06-13 | Seed post. Pairs with the new "BYOK reality check" as the positive-case companion. GSC indexing requested via Issue #4 playbook. |
|
||||
| 2026-05-14 | byok-reality-check-5-things-that-break | Guides (BYOK) | 18 | pending (just shipped) | pending | — | 2026-06-14 | Reactive piece — written same-day after mining gh issues #1619 #1611 #1610 #1603 #1620. Title alternates noted: "BYOK in Open Design: what works today across Gemini, DeepSeek, OpenCode" / "Should you BYOK with Open Design today? Five tests, five real bugs". Pairs with seed `byok-design-workflow-claude-codex-qwen` (positive case) and seeds the future "Open Design on Windows" Guide. |
|
||||
| 2026-05-14 | open-source-alternative-to-claude-design | Guides (comparison) | 19 | pending (just shipped) | pending | — | 2026-06-14 | A1, anchor of the Claude Design keyword cluster (A1–A4 / B1–B3 / C1–C2). Fast-tracked off live SERP intel: opendesigner.io already #2 for "claude design open source alternative"; this post targets the #1 slot. 1446 words. Title alternates: "Open Design vs Claude Design — and which one to pick this quarter" / "If you can't use Claude Design, what do you use instead?". Honest read on Anthropic's Claude Design (Opus 4.7, April 2026), `OpenCoworkAI/open-codesign` (MIT competitor), and Open Design with a who-picks-which table. CTA = `Try the open-source workflow`. Next step: ship A2 (pricing) + B1 (explainer) to thicken the cluster, then cross-post A1 to dev.to / Medium / HN. |
|
||||
| 2026-05-18 | layout-layer-canvas-used-to-hide | Community | 16 | pending (just shipped) | pending | — | 2026-06-18 | Community post from GitHub Discussion #1727. Uses the "Layout Understanding Layer" reply as a product-community signal without promising implementation. CTA = `Contribute a skill`. |
|
||||
| 2026-05-18 | port-figma-workflow-open-design-plugin | Use cases | 17 | pending (just shipped) | pending | — | 2026-06-18 | Use-case post from the 0.8.0-preview plugin call. Turns "port a Figma workflow" into a concrete `SKILL.md` + `open-design.json` + validate/pack/publish path. CTA = `Try this workflow`. |
|
||||
|
||||
## Dropped (with reason)
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,64 @@
|
|||
---
|
||||
title: "The layout layer the canvas used to hide"
|
||||
date: 2026-05-18
|
||||
category: "Community"
|
||||
readingTime: 5
|
||||
summary: "A community reply on the 0.8.0 preview named the real question behind agent-native design: if the canvas stops being the work unit, how do users still understand layout?"
|
||||
---
|
||||
|
||||
A useful community reply does not ask for a bigger button. It names the missing layer.
|
||||
|
||||
That is what happened under the [Open Design 0.8.0-preview discussion](https://github.com/nexu-io/open-design/discussions/1727). The launch thread argued for two shifts: stop treating the canvas as the primary work unit, and make the agent the first-class design worker. One reply agreed with the direction, then pointed at the hard part: when the canvas disappears, users still need a way to understand what the agent made before they can edit it with confidence.
|
||||
|
||||
The phrase in the reply was "Layout Understanding Layer." It is a good name because it refuses the lazy answer. Agent-native design cannot mean "trust the screenshot." It needs a readable model of the artifact: sections, intent, editable parts, stable references, and suggested edit moves.
|
||||
|
||||
## The canvas gave designers spatial confidence
|
||||
|
||||
Figma's canvas is not only a drawing surface. It is also an explanation surface. You can zoom out, see the page hierarchy, click a frame, inspect constraints, rename layers, and understand where one piece of the work ends and another begins.
|
||||
|
||||
That understanding is easy to underestimate until it is gone. A generated landing page can look correct in a sandboxed preview and still be hard to direct. "Make the hero more confident" is useful only if the agent and the human agree on what the hero is. "Tighten the pricing section" works only if the artifact carries a stable section identity across revisions.
|
||||
|
||||
This is the part of the #DeFigma argument that needs care. The canvas may be the wrong unit of work for an agent-native system, but the clarity people got from the canvas is still valuable. Open Design has to move that clarity into the artifact model, not throw it away.
|
||||
|
||||
## Open Design already has the right primitives
|
||||
|
||||
The reason this proposal fits Open Design is that the project is already built around explicit contracts. A skill is a `SKILL.md` file. A design system is a `DESIGN.md` file. A plugin adds an `open-design.json` sidecar. The mechanics are covered in [31 skills, 72 systems: how the Open Design library works](/blog/31-skills-72-systems-how-the-library-works/), and the product argument is in [Why we built Open Design as a skill layer, not a product](/blog/why-we-built-open-design-as-a-skill-layer/).
|
||||
|
||||
The layout layer should follow the same pattern. It should be text the agent can read, state the UI can render, and metadata another agent can reuse.
|
||||
|
||||
In repo terms, that points at three surfaces:
|
||||
|
||||
| Surface | What it should carry |
|
||||
|---|---|
|
||||
| Artifact manifest | Stable IDs for sections, components, assets, and generated files |
|
||||
| Plugin snapshot | Which skill, design system, inputs, and pipeline stages produced the artifact |
|
||||
| Review UI / headless output | A layout map, editable aspects, and suggested edit intents |
|
||||
|
||||
The important constraint: the layer should not become a second proprietary canvas. It should be a plain artifact map that travels with the files.
|
||||
|
||||
## A practical shape for the layout layer
|
||||
|
||||
Here is the smallest version that would make agent-native design feel less opaque:
|
||||
|
||||
1. Each generated artifact gets stable semantic IDs: `hero`, `proof-strip`, `pricing`, `faq`, `final-cta`.
|
||||
2. Each ID carries an intent sentence: "Explain the product promise in one screen," not "top section."
|
||||
3. Each section lists editable aspects: copy, density, layout, color, media, motion, data source.
|
||||
4. Each generated file links back to the section ID that produced it.
|
||||
5. Each review pass emits suggested edit intents: "shorten hero headline," "increase contrast in pricing cards," "split testimonial block."
|
||||
6. The UI renders this as a navigator, while headless users receive the same structure as JSON or Markdown.
|
||||
|
||||
That is enough to let a designer say, "Change `pricing.cards` from three plans to two," and enough to let a code agent patch the right file without guessing from pixels.
|
||||
|
||||
It also gives the community a clean contribution path. A contributor does not need to redesign the product to help here. They can write a plugin, a review atom, a manifest extension, or a test case around one artifact type. The layout layer becomes a public contract, not a private trick inside the app.
|
||||
|
||||
## What to do next
|
||||
|
||||
If this is the kind of problem you want to work on, contribute a small skill or plugin that makes one artifact easier to inspect. Start with a concrete output: a landing page, a deck, or a mobile screen. Add stable section IDs, describe the editable aspects, and open the PR with a before/after artifact.
|
||||
|
||||
[Contribute a skill](https://github.com/nexu-io/open-design/tree/main/skills).
|
||||
|
||||
## Related reading
|
||||
|
||||
- [Why we built Open Design as a skill layer, not a product](/blog/why-we-built-open-design-as-a-skill-layer/) — the product shape that makes public artifact contracts possible
|
||||
- [31 skills, 72 systems: how the Open Design library works](/blog/31-skills-72-systems-how-the-library-works/) — the current file-driven primitives underneath the proposal
|
||||
- [The open-source alternative to Claude Design](/blog/open-source-alternative-to-claude-design/) — the comparison that explains why local, inspectable design work matters
|
||||
|
|
@ -0,0 +1,107 @@
|
|||
---
|
||||
title: "How to port a Figma workflow into an Open Design plugin"
|
||||
date: 2026-05-18
|
||||
category: "Use cases"
|
||||
readingTime: 6
|
||||
summary: "The 0.8.0-preview thread asks contributors to port old design workflows one plugin at a time. Here is the concrete path for a Figma export, token sync, or brand kit."
|
||||
---
|
||||
|
||||
A Figma workflow usually starts as muscle memory: export these frames, sync those tokens, rebuild that deck template, hand the spec to engineering.
|
||||
|
||||
The 0.8.0-preview thread makes a sharper ask: port that muscle memory into a plugin. Not a panel bolted onto a canvas. Not a private script only one team can run. A reusable Open Design workflow that an agent can pick up, execute, review, and hand off through the same local-first loop as any other design task.
|
||||
|
||||
This is the practical version of the [0.8.0-preview call for plugins](https://github.com/nexu-io/open-design/discussions/1727). If your team has one repeatable design workflow today, this post shows what it looks like to turn it into a plugin-shaped contribution.
|
||||
|
||||
## The workflow worth porting is smaller than you think
|
||||
|
||||
Do not start with "replace Figma." Start with one annoying, repeatable job.
|
||||
|
||||
Good first plugin candidates:
|
||||
|
||||
| Current workflow | Plugin-shaped version |
|
||||
|---|---|
|
||||
| Export a Figma marketing page and rebuild it in code | `figma-migration` plugin that extracts layout, maps tokens, and generates a web artifact |
|
||||
| Turn a brand kit into launch slides every month | Deck plugin with a `SKILL.md`, example assets, and a locked design system |
|
||||
| Create the same mobile onboarding mockup for every client | Mobile-screen plugin with input fields for audience, tone, feature list, and platform |
|
||||
| Convert a component spec into Storybook-ready UI | Code-migration plugin that reads the repo, maps components, and writes a reviewable diff |
|
||||
|
||||
The unit is not the whole design department. The unit is one workflow someone already repeats twice a week.
|
||||
|
||||
That is why Open Design's [skill layer](/blog/why-we-built-open-design-as-a-skill-layer/) matters. A plugin is not an opaque runtime extension. It is a folder of files: a `SKILL.md` contract, optional design systems, optional examples, and an `open-design.json` sidecar that tells Open Design how to display and apply the workflow.
|
||||
|
||||
## The Open Design angle is portability
|
||||
|
||||
The plugin spec states the contract plainly: `SKILL.md` stays the executable agent contract, while `open-design.json` adds marketplace metadata, input fields, defaults, previews, and context wiring.
|
||||
|
||||
That gives one workflow two lives. In Open Design, it appears as a plugin with a preview, inputs, provenance, and a one-click "use" path. In Claude Code, Cursor, Codex, Gemini CLI, OpenClaw, or another skill catalog, the same folder still works as a plain agent skill because the core behavior lives in Markdown.
|
||||
|
||||
The [library walkthrough](/blog/31-skills-72-systems-how-the-library-works/) already explains the base primitives: skills, systems, adapters, and the daemon. Plugins add distribution and repeatability around those primitives.
|
||||
|
||||
For a Figma-to-code workflow, the surfaces usually look like this:
|
||||
|
||||
| Surface | Concrete file |
|
||||
|---|---|
|
||||
| Agent behavior | `SKILL.md` |
|
||||
| Open Design metadata | `open-design.json` |
|
||||
| Brand or visual contract | `design-systems/{brand}/DESIGN.md` |
|
||||
| Example output | `example.html` or `examples/{plugin-id}/example.html` inside the plugin folder |
|
||||
| Preview media | `preview/poster.png` or `preview/index.html` inside the plugin folder |
|
||||
|
||||
The result is not a screenshot generator. It is a reusable agent workflow with a visible contract.
|
||||
|
||||
## A concrete porting path
|
||||
|
||||
Here is the minimum path for a plugin that ports one Figma landing-page workflow:
|
||||
|
||||
1. **Name the repeatable job.** Example: "Turn one Figma marketing frame into a responsive Astro page."
|
||||
2. **Write the skill contract.** Create `SKILL.md` with the input shape, output path, constraints, and review checklist.
|
||||
3. **Add the Open Design sidecar.** Create `open-design.json` so the marketplace can show the title, description, required inputs, preview, and source repo.
|
||||
4. **Attach the design system.** If the workflow depends on brand rules, add a `DESIGN.md` file instead of burying color and typography in prose.
|
||||
5. **Include one real example.** Save a generated artifact under `examples/` so reviewers can judge the output, not just the promise.
|
||||
6. **Validate and pack.** Run the plugin commands before opening a PR.
|
||||
|
||||
The current CLI path uses a lowercase plugin id. Avoid slash-separated
|
||||
registry names at scaffold time; `od plugin scaffold` creates
|
||||
`<out>/<id>/...`, so the follow-up commands point at that generated folder:
|
||||
|
||||
```bash
|
||||
od plugin scaffold --id figma-workflow --title "Figma workflow" --out ./plugins/community
|
||||
od plugin validate ./plugins/community/figma-workflow --no-daemon
|
||||
od plugin pack ./plugins/community/figma-workflow
|
||||
```
|
||||
|
||||
When the plugin is ready for registry review, authenticate through GitHub
|
||||
with `od plugin login` and `od plugin whoami --json`, then follow the
|
||||
publishing docs for the current review path. Open Design does not store
|
||||
your GitHub credentials.
|
||||
|
||||
## What this looks like in a real design team
|
||||
|
||||
Imagine a small product team with a Figma frame for a launch page, a house brand system, and a monthly release rhythm.
|
||||
|
||||
Before the plugin, the workflow is a handoff chain: designer exports frames, engineer rebuilds layout, PM rewrites copy, someone checks token drift, someone else files bugs. The work is familiar, but the memory lives in people.
|
||||
|
||||
After the plugin, the workflow becomes a runnable artifact:
|
||||
|
||||
| Step | Who directs it |
|
||||
|---|---|
|
||||
| Choose the plugin | Designer or PM |
|
||||
| Attach Figma URL / screenshot / local assets | Designer |
|
||||
| Pick the brand system | Designer or design engineer |
|
||||
| Generate the web artifact | Claude Code, Cursor, Codex, Gemini CLI, or another detected agent |
|
||||
| Review section IDs, copy, density, and responsive behavior | Human in the Open Design preview |
|
||||
| Export or hand off files | The same local project folder |
|
||||
|
||||
The team still needs taste. The plugin just stops making them re-explain the same workflow every release.
|
||||
|
||||
## What to do next
|
||||
|
||||
If your team has a Figma export, token sync, brand kit, or deck template that keeps coming back, port the smallest repeatable slice first. Start with a `SKILL.md`, add `open-design.json`, validate it, and open the PR before the workflow grows into a private tool nobody else can reuse. The screenshot-to-prototype example shows the plugin-shaped version: a portable skill plus an Open Design sidecar.
|
||||
|
||||
[Try this workflow](https://github.com/nexu-io/open-design/tree/main/plugins/spec/examples/import-screenshot-to-prototype).
|
||||
|
||||
## Related reading
|
||||
|
||||
- [31 skills, 72 systems: how the Open Design library works](/blog/31-skills-72-systems-how-the-library-works/) — the primitives a plugin wraps
|
||||
- [Why we built Open Design as a skill layer, not a product](/blog/why-we-built-open-design-as-a-skill-layer/) — why the workflow is file-shaped instead of account-shaped
|
||||
- [BYOK design workflow: run Claude, Codex, or Qwen on your own key](/blog/byok-design-workflow-claude-codex-qwen/) — how the same plugin can run on the model path your team already trusts
|
||||
|
|
@ -6,22 +6,24 @@ canonical workflow; the product UI and agent flows wrap these commands.
|
|||
## 1. Scaffold
|
||||
|
||||
```bash
|
||||
od plugin scaffold --id vendor/plugin-name --title "Plugin name" --out ./plugins/community
|
||||
od plugin scaffold --id figma-workflow --title "Figma workflow" --out ./plugins/community
|
||||
```
|
||||
|
||||
Public registry IDs must use `vendor/plugin-name`. The generated
|
||||
`open-design.json` must include `plugin.repo`, pointing at the canonical source
|
||||
repository or subdirectory.
|
||||
The scaffold command creates `./plugins/community/figma-workflow/`. Plugin IDs
|
||||
must be lowercase, start with a letter, and use only `[a-z0-9._-]`; slash-
|
||||
separated registry paths are used by catalogs, not by `od plugin scaffold`.
|
||||
The generated `open-design.json` is the Open Design sidecar next to `SKILL.md`.
|
||||
|
||||
## 2. Validate And Pack
|
||||
|
||||
```bash
|
||||
od plugin validate ./plugins/community/plugin-name
|
||||
od plugin pack ./plugins/community/plugin-name --out ./dist
|
||||
od plugin validate ./plugins/community/figma-workflow --no-daemon
|
||||
od plugin pack ./plugins/community/figma-workflow
|
||||
```
|
||||
|
||||
The registry accepts anything that validates and packs. The source repository
|
||||
does not need a special layout beyond `SKILL.md` plus `open-design.json`.
|
||||
`od plugin pack` writes the archive next to the plugin folder by default.
|
||||
|
||||
## 3. Authenticate
|
||||
|
||||
|
|
@ -36,19 +38,19 @@ GitHub credentials.
|
|||
## 4. Publish
|
||||
|
||||
```bash
|
||||
od plugin publish vendor/plugin-name --to open-design --repo https://github.com/vendor/plugin-name
|
||||
od plugin publish figma-workflow --to open-design --repo https://github.com/acme/figma-workflow
|
||||
```
|
||||
|
||||
v1 opens the GitHub registry review flow. The publish payload includes the
|
||||
plugin ID, version, repo, capability summary, package digest, and registry entry
|
||||
path. After merge, CI regenerates `open-design-marketplace.json`.
|
||||
plugin ID, version, repo, capability summary, and target registry entry path.
|
||||
After merge, CI regenerates `open-design-marketplace.json`.
|
||||
|
||||
## 5. Install From The Registry
|
||||
|
||||
```bash
|
||||
od marketplace refresh official
|
||||
od plugin install vendor/plugin-name
|
||||
od plugin info vendor/plugin-name --json
|
||||
od plugin install figma-workflow
|
||||
od plugin info figma-workflow --json
|
||||
```
|
||||
|
||||
Installs preserve marketplace provenance, resolved source, manifest digest, and
|
||||
|
|
@ -58,7 +60,7 @@ archive integrity. `official` and `trusted` sources install as trusted;
|
|||
## 6. Yank A Version
|
||||
|
||||
```bash
|
||||
od plugin yank vendor/plugin-name@1.0.0 --reason "Security issue"
|
||||
od plugin yank figma-workflow@1.0.0 --reason "Security issue"
|
||||
```
|
||||
|
||||
Yanking never deletes metadata or bytes. New installs refuse yanked versions;
|
||||
|
|
|
|||
Loading…
Reference in a new issue