Claude Code for Designers: A Practical Guide
🔗 **Source:** [Claude Code for Designers: A Practical Guide](https://nervegna.substack.com/p/claude-code-for-designers-a-practical?triedRedirect=true)
> [!note]+ Document Notes
> tags: [ai-design, developer-tools, claude-code]
> author: Tommaso Nervegna
> source: Substack
> reference: [https://nervegna.substack.com/p/claude-code-for-designers-a-practical](https://nervegna.substack.com/p/claude-code-for-designers-a-practical)
> date created: 2026-02-15 14:32
>
> # 🏷️ Title: Claude Code for Designers: A Practical Guide
>
<!-- deep-read:sections start -->
## 🧭 Table of Contents
- [📝 Summary](#-summary)
- [📖 Main Content](#-main-content)
- [🗒️ Notes](#️-notes)
- [📚 References](#-references)
- [🗣️ Paraphrase](#️-paraphrase)
- [📰 Newsletter](#-newsletter)
- [✅ Action Items](#-action-items)
- [🧪 Hypotheses](#-hypotheses)
- [📊 Methodology](#-methodology)
- [❓ Questions](#-questions)
- [🔮 Future Research](#-future-research)
- [💡 Implications](#-implications)
- [🧠 Learning Styles Assessment](#-learning-styles-assessment)
- [📊 Accessibility Assessment](#-accessibility-assessment)
- [🌍 DEIB Assessment](#-deib-assessment)
- [✅ Logical Validity](#-logical-validity)
- [🛡️ DARVO Analysis](#-darvo-analysis)
- [🎯 Conclusion](#-conclusion)
### 🔗 References
- Include links cited in or relevant to the article.
## 📝 Summary
- What happened: The author shows how designers can use Claude Code plus the Get Shit Done (GSD) meta-prompting system to design, build, and deploy production-quality products without traditional dev handoff.
- Why it matters: It collapses the gap between design intent and implementation, letting designers ship real systems, not just mockups, via structured AI workflows.
- Key stakeholders: Product designers, design leaders, front-end and design systems teams, AI tooling builders.
- Risks and tradeoffs: Over-reliance on AI without understanding systems; security/config mistakes; organizational friction with existing dev workflows; need for good context engineering.
- Bottom line: With Claude Code + GSD and optionally Figma MCP, designers who think in systems can own end‑to‑end prototypes and even production tools.
## 📖 Main Content
- Core argument: The bottleneck for designers isn’t “not knowing how to code” but the translation layer between design intent and working software. Claude Code plus GSD removes that layer by turning conversational design specs into robust, spec-driven code.
- The author explains that classic “learn to code” advice ignored toolchain overhead and mode-switching. Now, [Claude Code can interpret designer language and turn it into implementation](https://read.readwise.io/read/01khfebfgnat615nmdxe6164t1?endLexposition=0000W_00000-004u&startLexposition=0000I&emphasizeText=Claude+Code+understands+design+intent+and+translates+it+directly+into+working+software).
- GSD is installed as a CLI layer on top of Claude Code and enforces: structured specs, multi-agent research/planning/execution, atomic tasks, and automatic git commits, preventing “vibe coding” and context rot.
- Step-by-step, the article walks through building a portfolio: clarifying goals, auto-generating `REQUIREMENTS.md`, a phased `ROADMAP.md`, then using `discuss-phase`, `plan-phase`, `execute-phase`, and `verify-work` to transform design decisions into stable code.
- The same pattern scales to more advanced apps using Supabase, Vercel, and the Anthropic API for authenticated AI chat, comments, and live deployments.
- A major section covers integrating Figma’s Model Context Protocol so Claude can read design tokens, components, and layouts, then [generate Tailwind config, tokens, and React components that match Figma exactly](https://read.readwise.io/read/01khfebfgnat615nmdxe6164t1?endLexposition=000Cm_00001-0013&startLexposition=000Ca_00001&emphasizeText=Generate+Tailwind+config+with+your+exact+design+tokens).
- The author argues that the future for designers is not “learning to code” but “learning to build with systems that think like designers,” especially when combined with dormant dev intuition.
### 🗒️ Notes
- The author is a former “webmaster”–style full-stack designer who later moved into design leadership, then rediscovered shipping through Claude Code.
- Problem framing: Traditional “learn to code” advice fails because toolchains (build tools, dependencies, framework churn) create a heavy translation tax between design intent and actual code.
- Claude Code can bridge this by accepting designer vocabulary and turning it into implementation details, while the designer critiques behavior and architecture.
- Illustrative projects:
- AI concept testing tool: designers input ideas, Claude generates variants, users vote, insights are stored.
- Figma-to-dev workflow: Figma MCP + Claude Code to pull design tokens and produce production-ready React components; [this runs on real client work](https://read.readwise.io/read/01khfebfgnat615nmdxe6164t1?endLexposition=0000w_00000-001N&startLexposition=0000q&emphasizeText=These+aren%E2%80%99t+just+prototypes.+They%E2%80%99re+production+tools+that+real+people+actually+use.).
- Step 1: Set up Claude Code and install GSD via `npx get-shit-done-cc`; run Claude with `--dangerously-skip-permissions` so it can automate file and git operations.
- GSD benefits:
- Thinks like a product designer: questions goals, edge cases, mobile behavior, undo states.
- Prevents context rot: files and tasks are sized so each executor runs in a fresh 200k-token context.
- Enforces spec-driven dev: requirements and phase plans come before code.
- Orchestrates multiple agents: research, planning, execution, verification.
- Step 2: Terminal basics: `claude`, `cd`, `ls/dir`, `pwd`. Author notes you can embed this in editors like VS Code or Cursor.
- Step 3: Building a portfolio:
- Instead of immediate code generation, GSD enters a Q&A phase about goals, audience, feelings, content updating, analytics, and CTAs to make implicit context explicit.
- It can then spawn research agents to investigate tech stack options, architecture (SSG vs SSR), content strategy, and UX pitfalls.
- The outcome is a `REQUIREMENTS.md` outlining V1, V2, and out-of-scope features, then a `ROADMAP.md` broken into phases (foundation, layout, polish, deployment).
- “Discuss phase” is highlighted as a secret weapon: before planning Phase N, `/gsd:discuss-phase N` captures design preferences (hero alignment, gaps, hover states, spacing rhythm) and writes a `{phase}-CONTEXT.md` that encodes your taste numerically (like “48px gaps,” specific colors, etc.).
- Then GSD:
- Spawns a research agent reading the context file and investigating patterns, libraries, and pitfalls relevant to your decisions.
- Uses a planner agent to create atomic XML task plans (e.g., one plan to create and style the hero section) with verification and “done” criteria.
- Executes each plan in isolated contexts, with automatic git commits per task, producing plan and research markdown files.
- Benefits of this approach:
- Avoids constant refactors due to late-discovered preferences (like spacing or dark mode).
- Every change is traceable via atomic commits; `git bisect` can locate where regressions were introduced.
- Later phases cover:
- GitHub setup and pushing code for backup and collaboration.
- Vercel deployment flow with environment variables.
- Supabase integration for auth, database, and policies (e.g., row-level security policies to control comment insertion).
- Advanced Figma MCP workflow:
- Start project with `/gsd:new-project` and the Figma URL; GSD asks clarifying questions and builds requirements tied to named Figma components.
- Phase 1 focuses on design system extraction via `/gsd:discuss-phase 1` and `/gsd:plan-phase 1`, aligning on color naming (semantic vs raw), typography mapping, spacing systems, and component tokens.
- Execution uses Figma MCP to read tokens, then writes Tailwind config and CSS variables so code matches Figma.
- Subsequent phases build components (like buttons) from Figma’s variants and states, with additional questions about API, accessibility, and state handling.
- Layout phases for screens (landing page, dashboard, etc.) read Auto Layout spacing and responsive behavior, then generate responsive React layouts that reuse the design system.
- Final verification steps compare live implementations against Figma with a structured checklist (spacing, tokens, breakpoints, hover states).
- “Why this works” section emphasizes:
- Context engineering: constraints on file size and per-task contexts to avoid degraded reasoning.
- Multi-agent orchestration: research → planning → checking → execution → verification loops.
- Git hygiene: one commit per task enables clean histories and safe refactors.
- Designer mindset baked into GSD prompts: always asking about empty states, responsive behavior, and performance.
- Real-world applications:
- Technical client proposals: interactive AI prototypes and dashboards delivered much faster than with a traditional dev dependency.
- Design system exploration: generating component libraries and testing accessibility across devices from Figma designs.
- Figma MCP pipelines: [update in Figma → Claude pulls tokens → pushes updated components to GitHub → deploy](https://read.readwise.io/read/01khfebfgnat615nmdxe6164t1?endLexposition=000BY_00002-000E&startLexposition=000BK&emphasizeText=Designers+update+Figma+%E2%86%92+Claude+Code+pulls+changes+%E2%86%92+generates+updated+components+%E2%86%92+pushes+to+GitHub+%E2%86%92+auto-deploys.).
- The author concludes that Claude Code alone is “fast vibe coding,” but GSD turns it into a robust, spec-driven system that lets designers with system intuition build production-grade work. The future is designers learning to build with these systems, not manually learning every framework.
## 📚 References
- Get Shit Done (GSD) – meta-prompting system for Claude Code: https://github.com/glittercowboy/get-shit-done
- Claude Code Documentation: https://docs.anthropic.com
- Figma Model Context Protocol: https://www.figma.com/developers/model-context
- Supabase: https://supabase.com
- Vercel: https://vercel.com
- Article: https://nervegna.substack.com/p/claude-code-for-designers-a-practical
## 🗣️ Paraphrase
- Paragraph A paraphrase: The article argues that AI coding agents like Claude Code, when structured by GSD, let designers convert their system-level thinking into code without battling toolchains, translating intent through human developers, or manually managing complex architectures.
- Paragraph B paraphrase: Through concrete workflows—portfolio sites, auth-backed AI apps, and Figma MCP pipelines—the author shows designers how to turn Figma designs and conversational specs into tested, deployed products, reframing the future of design as learning to build with AI-augmented systems.
## 📰 Newsletter
This week in WordPress, we’re zooming out from block patterns and performance tickets to look at how AI coding agents are reshaping design-to-dev workflows.
Tommaso Nervegna’s guide to Claude Code + the Get Shit Done (GSD) meta-prompting system feels directly relevant to WordPress builders. Imagine speccing a feature in conversational language—states, breakpoints, empty states—and having a structured agent generate atomic tasks, Tailwind tokens, and React components (or block code) that actually match your Figma system.
For WordPress folks, the same patterns could power:
- Prototype-to-plugin flows using WP‑friendly stacks (REST, WP‑CLI, Gutenberg APIs).
- Theme.json and design-token generation driven from Figma via MCP-like context.
- Automated git hygiene for block libraries and custom plugins through atomic AI commits.
If you’re experimenting, pair this with:
- Gutenberg developer docs: https://developer.wordpress.org/block-editor
- Theme.json reference: https://developer.wordpress.org/block-editor/how-to-guides/themes/theme-json
- Vercel/Supabase-inspired patterns for headless WP: https://developer.wordpress.org/rest-api/
Short version: learn the structure (requirements, roadmaps, atomic tasks), then swap in WordPress building blocks. The opportunity is less about magic code and more about teaching AI to think the way good product teams already do.
## ✅ Action Items
#### DevRel
- Document a Claude Code + GSD quickstart for designers, with copyable commands and example projects.
- Build a live demo showing portfolio → auth app progression, with repo and walkthrough talk.
- Add starter templates and example repos that mirror the article’s flows (portfolio, AI chat app).
- Run workshops on “spec-driven AI development” for design and dev communities.
- Collect feedback on pain points (Supabase, Vercel, Claude) and feed into docs/SDK priorities.
- Coordinate with product and security to ensure examples follow best practices for keys and RLS.
#### OSPO
- Define policy for AI-generated code contributions (provenance, review requirements).
- Update contribution guidelines to clarify licensing for AI-assisted code and prompts.
- Establish a regular training cadence on open-source license compliance in AI workflows.
- Include AI-generated components in SBOM inventories and update freshness expectations.
- Offer consult hours for teams adopting Claude Code/GSD pipelines in open projects.
- Explore upstream funding or collaboration with GSD-like tooling if open-sourced.
- Track OKRs on AI-enabled productivity vs review overhead in open-source repos.
#### Community
- Host “roadmap clinics” where maintainers map features into GSD-style phases.
- Create contributor onboarding paths based on small, atomic tasks mirroring GSD plans.
- Pair new contributors with mentors to review AI-generated PRs for quality and style.
- Provide sponsors transparent breakdowns of time saved and quality gains from AI workflows.
- Coordinate cross-project incident drills for AI-generated bugs and security issues.
#### WordPress
- Core: pilot AI-assisted triage to turn bug reports into minimal reproducible plans.
- Core Performance: define perf budgets that GSD-like plans must respect (LCP, TTFB).
- Core AI: codify guidelines for using Claude-like agents in contributor workflows.
- **Core Program Team:** align release milestones with spec-driven phases and review checklists.
- Mobile: explore AI-assisted UI scaffolding using Figma inputs and native layouts.
- Playground: add labs that show Claude-generated themes/plugins running in-browser.
- Community: ship meetup kits on “AI in WordPress workflows” with live demos.
- Training: add lessons on AI-assisted development and spec-writing best practices.
- Marketing: highlight real stories where WP teams shipped faster with AI + structure.
- Support: document known pitfalls of AI-generated code in WordPress and escalation paths.
- Design: propose design-token standards that map cleanly into `theme.json` and Tailwind.
- Documentation: add “examples-first” AI sections showing prompts → code → docs.
- Photos/TV/Openverse: clarify policies for AI-generated media and caption quality.
- Polyglots: test AI-assisted translation, with clear human review steps.
- Accessibility: integrate WCAG checks into any AI-generated themes/plugins pipeline.
- Meta: explore AI-powered contributor tools on .org (issue summaries, task planning).
- CLI: consider scaffolding commands aligned with GSD phases (spec, plan, execute).
- Hosting/Tide: define how AI-generated code is scored, verified, and flagged.
- Themes/Plugins: provide review guidance for AI-heavy submissions, focusing on security and perf.
#### The WPOCC
- Launch microgrants for experiments applying Claude Code/GSD workflows to WordPress.
- Run governance clinics on how AI affects release processes and decision rights.
- Fund documentation sprints around “AI + open source” for design and dev roles.
- Trial matched grants for maintainers who document robust AI-assisted pipelines.
### FAIR
- Encourage local caching and verification of AI-generated artifacts (signatures, checksums).
- Adopt transparent funding and governance models for AI tooling underpinning WP workflows.
- Share reusable governance assets (RACI, contribution policies, AI usage scorecards).
## 🧪 Hypotheses
- H1: Designers using Claude Code + GSD ship functional prototypes significantly faster than designers working through traditional dev handoff.
- H2: GSD-style spec-driven workflows produce fewer regressions than unstructured AI “vibe coding.”
- H3: Integrating Figma MCP with Claude Code yields closer visual fidelity and fewer design-review cycles.
- H4: Designers with prior dev experience derive more value (quality and speed) from Claude Code than those without.
- H5: Atomic git commits per AI task reduce mean time to diagnose and fix bugs.
### 📊 Methodology
- Run controlled studies across teams: half use Claude Code + GSD, half use normal tools; compare time-to-first-deploy, bug counts, and review feedback.
- Instrument repositories to track regression frequency and MTTR for GSD vs non-GSD projects.
- Use design-review logs to measure number and severity of visual discrepancies with and without Figma MCP pipelines.
- Survey designers with varied coding backgrounds, correlating self-reported comfort, time savings, and quality ratings.
- Analyze git histories to determine how often atomic AI commits enable faster `git bisect` and rollback.
### ❓ Questions
- How far can AI-structured workflows go before they conflict with existing engineering governance?
- What minimum level of technical literacy should designers have to safely drive Claude Code projects?
- How stable are these workflows across framework churn (React, Next, Tailwind versions)?
- Can similar pipelines be generalized to WordPress (themes, blocks, plugins) without sacrificing security?
- How should organizations attribute and review AI-assisted contributions?
### 🔮 Future Research
- Comparative studies between Claude Code + GSD and other AI coding agents/prompting systems.
- Longitudinal research on how designer roles and skillsets evolve under AI-augmented building.
- Deeper integration patterns between design tools (Figma, Penpot) and AI code agents.
- Automated observability: integrating logging, metrics, and perf budgets directly into AI task plans.
- Governance models for AI-orchestrated workflows in large open-source communities.
### 💡 Implications
- Practice: Designers can own more of the build loop, but need training in specs, architecture, and verification.
- Policy: Organizations must define acceptable AI usage, review processes, and security baselines for generated code.
- Security: AI tools must embed secure defaults (secrets management, RLS, auth) to avoid systemic risks.
- Education: Curricula for design and HCI should incorporate AI-augmented prototyping and spec writing.
- Funding: Backing high-quality, open AI workflows/tools can drastically improve productivity and inclusivity in open ecosystems.
### 🧠 Learning Styles Assessment
- Reading level estimate: roughly upper high-school to early college (Flesch–Kincaid grade ~11–13) due to technical terms (MCP, RLS, Tailwind), but written conversationally.
#### 👀 Visual learners
- Present: Descriptions of layouts, Figma structures, spacing tokens, and component hierarchies.
- Improve: Add diagrams of GSD agents, phase flows, and Figma-to-code pipelines; before/after visual diffs.
#### 🔊 Aural learners
- Present: None explicitly (no audio).
- Improve: 3–5 minute audio summary and a narrated walkthrough of the portfolio and Figma MCP workflows.
#### 🗣️ Verbal learners
- Present: Clear definitions of concepts like “context rot,” “spec-driven development,” and “multi-agent orchestration.”
- Improve: More analogies comparing these workflows to classic design/development collaboration patterns.
#### 🧩 Kinesthetic learners
- Present: Concrete step-by-step commands (install, `discuss-phase`, `plan-phase`, `execute-phase`, `verify-work`).
- Improve: Checklist PDFs and lab-style exercises with exact tasks and expected outputs.
#### 🧠 Logical learners
- Present: Phase-based roadmaps, atomic task planning, and cause–effect explanations of why GSD improves quality.
- Improve: Tables comparing “with vs without GSD,” plus explicit decision trees for stack selection.
#### 🧑🤝🧑 Social learners
- Present: Implicit emphasis on team workflows (designers, devs, clients).
- Improve: Suggested discussion prompts for design/dev reviews using GSD outputs.
#### 🧘♀️ Solitary learners
- Present: Text-based walkthroughs that can be followed independently.
- Improve: Reflection prompts after each step (“What assumptions did you skip?”) and self-check quizzes.
#### 🌿 Naturalistic learners
- Present: Minimal; focus is on tooling and process.
- Improve: Analogies to ecosystems (agents as species, specs as environments) and brief notes on infra/resource efficiency.
### 📊 Accessibility Assessment
#### Screen reader semantics
- Present: It’s an article; likely basic headings and paragraphs only.
- Improve: Ensure semantic headings, properly labeled code snippets, and clear link text.
#### Keyboard navigation
- Present: Standard web article behavior.
- Improve: For any embedded demos or terminals, ensure full keyboard operability and visible focus.
#### Contrast and readability
- Present: Depends on Substack theme; usually acceptable.
- Improve: Confirm 4.5:1 contrast, increase line-height, and limit very long paragraphs.
#### Text resizing and reflow
- Present: Responsive layout via Substack.
- Improve: Test at 200% zoom, ensure no clipping of code examples; support reduced-motion preferences.
#### Media and captions
- Present: Primarily text; any images/gifs may lack alt text.
- Improve: Provide alt text, text equivalents for diagrams, and avoid autoplaying media.
#### Forms and interactions
- Present: Subscription form only.
- Improve: Ensure labels, errors, and focus handling are accessible.
#### Standards reference
- Map gaps mainly to WCAG 2.2 AA criteria: 1.4.x (contrast, resizing), 2.1.x (keyboard), 1.3.x (structure), 3.3.x (input assistance).
### 🌍 DEIB Assessment
#### Cultural breadth
- Present: Primarily Western, tech-centric examples.
- Improve: Include cases from varied regions and industries; note infra requirements and constraints.
#### Inclusive language
- Present: Generally inclusive, gender-neutral, informal tone.
- Improve: Avoid slang that may not translate; define jargon like MCP, RLS, “vibe coding.”
#### Neurodiversity support
- Present: Clear structure by steps and phases.
- Improve: Further chunking with consistent headings, bullets, and summaries per section.
#### Representation
- Present: Focused on author’s experience; few explicit references to broader identities.
- Improve: Illustrate workflows across diverse teams and contexts.
#### Psychological safety
- Present: Encouraging tone; emphasizes experimentation and learning.
- Improve: Add explicit reassurance about making mistakes, and guidance for safe experimentation (dev vs prod).
### ✅ Logical Validity
#### Strong reasoning
- The spec-driven argument is strong: starting from explicit requirements and roadmaps reduces rework and misalignment; the article backs this with concrete before/after scenarios and artifacts (e.g., `REQUIREMENTS.md`, atomic plans).
- The claim that GSD mitigates context rot is plausible because it constrains context windows and tasks, aligning with known LLM limitations.
#### Fallacies
- Potential selection bias: examples are all successful uses; it doesn’t discuss failures or where Claude/GSD struggle (e.g., highly novel algorithms). A short limitations section would strengthen balance.
- Possible overgeneralization: claims about production readiness may not hold for all domains (e.g., heavy-regulated, deeply backend systems). Clarifying scope (web UIs, CRUD apps, dashboards) would fix this.
#### Tone of voice
- Tone is pragmatic, optimistic, and slightly irreverent (e.g., “Get Shit Done,” “vibe coding”). It’s persuasive but grounded in specific workflows and commands.
### 🛡️ DARVO Analysis
- Deny: The article does not deny problems; it acknowledges AI’s weaknesses (context rot, generic output) and positions GSD as mitigation.
- Attack: There is no attack on critics or individuals; critique is aimed at patterns (“learn to code” advice, unstructured AI coding).
- Reverse victim/offender: No attempt is made to reframe designers or AI tools as victims; instead, it frames designers as empowered agents.
- Overall: The piece is advocacy, not defensive; DARVO patterns are not present.
## 🎯 Conclusion
The article reframes the role of designers in an AI-augmented world, arguing that with Claude Code plus GSD—and optionally Figma MCP—designers can own end-to-end product building, from intent and design systems through code, deployment, and verification. Practical next steps: install GSD, build a small portfolio with full requirements and phases, then graduate to a Figma-driven, tokenized component library, treating each step as a learning lab in structured AI collaboration.
## 🧱 Refactor Appendix (append after 🎯 Conclusion)
### 📚 Literature Split Pad
- Purpose: Stage Konik CEE units that become per-source Literature notes.
- Split level: **H3**.
- Include verbatim quotes under 25 words and a [view highlight] link.
### [H1] AI agents let designers build systems directly
> [!quote] [Claude Code for Designers: A Practical Guide](https://nervegna.substack.com/p/claude-code-for-designers-a-practical) by [[Tommaso Nervegna]] via [[Substack]]. Published 2026-01-26. Accessed 2026-02-15.
> “Claude Code understands design intent and translates it directly into working software.”
Two lines: Designers can bypass traditional handoff by turning conversational specs into code. Use when arguing for AI-augmented design roles.
[view highlight](https://nervegna.substack.com/p/claude-code-for-designers-a-practical#H1) #xref #articleseed ID:rw_[MISSING]
### [H2] Get Shit Done structures AI coding workflows
> [!quote] [Claude Code for Designers: A Practical Guide](https://nervegna.substack.com/p/claude-code-for-designers-a-practical)
> “GSD solves this… enforces spec-driven development… and spawns specialized agents for research, planning, execution, and verification.”
Two lines: GSD turns “vibe coding” into spec-driven, multi-agent workflows that stay stable over long projects.
[view highlight](https://nervegna.substack.com/p/claude-code-for-designers-a-practical#H2) #xref ID:rw_[MISSING]
---
### 🔖 Atomic Split Pad (Zettel Candidates)
- Purpose: Promote reusable claims into Atomic notes.
- Split level: **H4**.
- Each item: one idea, present tense, specific, testable.
#### [Z1] Structured AI prompts reduce context rot
- When tasks are scoped and sequenced, LLMs maintain quality across long projects.
- Pointer: GSD sections on research, planning, and 200k-token execution contexts.
- Links: [[AI-Context-Engineering]] [[Spec-Driven-Development]]
#### [Z2] Figma MCP enables pixel-perfect code generation
- When design tokens and layouts are machine-readable, AI can output visually faithful components.
- Pointer: Sections on design token extraction and Figma-based verification.
- Links: [[Design-Systems]] [[AI-Code-Generation]]
---
### ✏️ Fleeting Queue (Extract by Selection)
- Purpose: Capture quick actions or sparks for Fleeting notes.
- Extraction: **Select one line** → “Refactor: Extract selection to new note (content only).”
- Keep each line short and self-contained.
- [F1] Try building a small WordPress headless prototype using Claude Code + GSD and measure time saved—https://nervegna.substack.com/p/claude-code-for-designers-a-practical #fleeting #inbox
- [F2] Draft a Figma → Tailwind → theme.json pipeline inspired by the Figma MCP workflow—https://nervegna.substack.com/p/claude-code-for-designers-a-practical #fleeting #inbox
- [F3] Create a checklist that mirrors GSD’s phases for spec-driven feature development—https://nervegna.substack.com/p/claude-code-for-designers-a-practical #fleeting #inbox
---
<!-- deep-read:sections end -->
[[3. Resources/Readwise/Full Document Contents/Articles/Claude Code for Designers A Practical Guide|Full Document Contents]]
## Document Notes
---
tags: #ai-design #developer-tools #claude-code
author: Tommaso Nervegna
source: Substack
reference: [https://nervegna.substack.com/p/claude-code-for-designers-a-practical](https://nervegna.substack.com/p/claude-code-for-designers-a-practical)
date created: 2026-02-15 14:32
---
# 🏷️ Title: Claude Code for Designers: A Practical Guide
## 🧭 Table of Contents
- [[#📝 Summary]]
- [[#📖 Main Content]]
- [[#🗒️ Notes]]
- [[#📚 References]]
- [[#🗣️ Paraphrase]]
- [[#📰 Newsletter]]
- [[#✅ Action Items]]
- [[#🧪 Hypotheses]]
- [[#📊 Methodology]]
- [[#❓ Questions]]
- [[#🔮 Future Research]]
- [[#💡 Implications]]
- [[#🧠 Learning Styles Assessment]]
- [[#📊 Accessibility Assessment]]
- [[#🌍 DEIB Assessment]]
- [[#✅ Logical Validity]]
- [[#🛡️ DARVO Analysis]]
- [[#🎯 Conclusion]]
### 🔗 References
- Include links cited in or relevant to the article.
## 📝 Summary
- What happened: The author shows how designers can use Claude Code plus the Get Shit Done (GSD) meta-prompting system to design, build, and deploy production-quality products without traditional dev handoff.
- Why it matters: It collapses the gap between design intent and implementation, letting designers ship real systems, not just mockups, via structured AI workflows.
- Key stakeholders: Product designers, design leaders, front-end and design systems teams, AI tooling builders.
- Risks and tradeoffs: Over-reliance on AI without understanding systems; security/config mistakes; organizational friction with existing dev workflows; need for good context engineering.
- Bottom line: With Claude Code + GSD and optionally Figma MCP, designers who think in systems can own end‑to‑end prototypes and even production tools.
## 📖 Main Content
- Core argument: The bottleneck for designers isn’t “not knowing how to code” but the translation layer between design intent and working software. Claude Code plus GSD removes that layer by turning conversational design specs into robust, spec-driven code.
- The author explains that classic “learn to code” advice ignored toolchain overhead and mode-switching. Now, [Claude Code can interpret designer language and turn it into implementation](https://read.readwise.io/read/01khfebfgnat615nmdxe6164t1?endLexposition=0000W_00000-004u&startLexposition=0000I&emphasizeText=Claude+Code+understands+design+intent+and+translates+it+directly+into+working+software).
- GSD is installed as a CLI layer on top of Claude Code and enforces: structured specs, multi-agent research/planning/execution, atomic tasks, and automatic git commits, preventing “vibe coding” and context rot.
- Step-by-step, the article walks through building a portfolio: clarifying goals, auto-generating `REQUIREMENTS.md`, a phased `ROADMAP.md`, then using `discuss-phase`, `plan-phase`, `execute-phase`, and `verify-work` to transform design decisions into stable code.
- The same pattern scales to more advanced apps using Supabase, Vercel, and the Anthropic API for authenticated AI chat, comments, and live deployments.
- A major section covers integrating Figma’s Model Context Protocol so Claude can read design tokens, components, and layouts, then [generate Tailwind config, tokens, and React components that match Figma exactly](https://read.readwise.io/read/01khfebfgnat615nmdxe6164t1?endLexposition=000Cm_00001-0013&startLexposition=000Ca_00001&emphasizeText=Generate+Tailwind+config+with+your+exact+design+tokens).
- The author argues that the future for designers is not “learning to code” but “learning to build with systems that think like designers,” especially when combined with dormant dev intuition.
### 🗒️ Notes
- The author is a former “webmaster”–style full-stack designer who later moved into design leadership, then rediscovered shipping through Claude Code.
- Problem framing: Traditional “learn to code” advice fails because toolchains (build tools, dependencies, framework churn) create a heavy translation tax between design intent and actual code.
- Claude Code can bridge this by accepting designer vocabulary and turning it into implementation details, while the designer critiques behavior and architecture.
- Illustrative projects:
- AI concept testing tool: designers input ideas, Claude generates variants, users vote, insights are stored.
- Figma-to-dev workflow: Figma MCP + Claude Code to pull design tokens and produce production-ready React components; [this runs on real client work](https://read.readwise.io/read/01khfebfgnat615nmdxe6164t1?endLexposition=0000w_00000-001N&startLexposition=0000q&emphasizeText=These+aren%E2%80%99t+just+prototypes.+They%E2%80%99re+production+tools+that+real+people+actually+use.).
- Step 1: Set up Claude Code and install GSD via `npx get-shit-done-cc`; run Claude with `--dangerously-skip-permissions` so it can automate file and git operations.
- GSD benefits:
- Thinks like a product designer: questions goals, edge cases, mobile behavior, undo states.
- Prevents context rot: files and tasks are sized so each executor runs in a fresh 200k-token context.
- Enforces spec-driven dev: requirements and phase plans come before code.
- Orchestrates multiple agents: research, planning, execution, verification.
- Step 2: Terminal basics: `claude`, `cd`, `ls/dir`, `pwd`. Author notes you can embed this in editors like VS Code or Cursor.
- Step 3: Building a portfolio:
- Instead of immediate code generation, GSD enters a Q&A phase about goals, audience, feelings, content updating, analytics, and CTAs to make implicit context explicit.
- It can then spawn research agents to investigate tech stack options, architecture (SSG vs SSR), content strategy, and UX pitfalls.
- The outcome is a `REQUIREMENTS.md` outlining V1, V2, and out-of-scope features, then a `ROADMAP.md` broken into phases (foundation, layout, polish, deployment).
- “Discuss phase” is highlighted as a secret weapon: before planning Phase N, `/gsd:discuss-phase N` captures design preferences (hero alignment, gaps, hover states, spacing rhythm) and writes a `{phase}-CONTEXT.md` that encodes your taste numerically (like “48px gaps,” specific colors, etc.).
- Then GSD:
- Spawns a research agent reading the context file and investigating patterns, libraries, and pitfalls relevant to your decisions.
- Uses a planner agent to create atomic XML task plans (e.g., one plan to create and style the hero section) with verification and “done” criteria.
- Executes each plan in isolated contexts, with automatic git commits per task, producing plan and research markdown files.
- Benefits of this approach:
- Avoids constant refactors due to late-discovered preferences (like spacing or dark mode).
- Every change is traceable via atomic commits; `git bisect` can locate where regressions were introduced.
- Later phases cover:
- GitHub setup and pushing code for backup and collaboration.
- Vercel deployment flow with environment variables.
- Supabase integration for auth, database, and policies (e.g., row-level security policies to control comment insertion).
- Advanced Figma MCP workflow:
- Start project with `/gsd:new-project` and the Figma URL; GSD asks clarifying questions and builds requirements tied to named Figma components.
- Phase 1 focuses on design system extraction via `/gsd:discuss-phase 1` and `/gsd:plan-phase 1`, aligning on color naming (semantic vs raw), typography mapping, spacing systems, and component tokens.
- Execution uses Figma MCP to read tokens, then writes Tailwind config and CSS variables so code matches Figma.
- Subsequent phases build components (like buttons) from Figma’s variants and states, with additional questions about API, accessibility, and state handling.
- Layout phases for screens (landing page, dashboard, etc.) read Auto Layout spacing and responsive behavior, then generate responsive React layouts that reuse the design system.
- Final verification steps compare live implementations against Figma with a structured checklist (spacing, tokens, breakpoints, hover states).
- “Why this works” section emphasizes:
- Context engineering: constraints on file size and per-task contexts to avoid degraded reasoning.
- Multi-agent orchestration: research → planning → checking → execution → verification loops.
- Git hygiene: one commit per task enables clean histories and safe refactors.
- Designer mindset baked into GSD prompts: always asking about empty states, responsive behavior, and performance.
- Real-world applications:
- Technical client proposals: interactive AI prototypes and dashboards delivered much faster than with a traditional dev dependency.
- Design system exploration: generating component libraries and testing accessibility across devices from Figma designs.
- Figma MCP pipelines: [update in Figma → Claude pulls tokens → pushes updated components to GitHub → deploy](https://read.readwise.io/read/01khfebfgnat615nmdxe6164t1?endLexposition=000BY_00002-000E&startLexposition=000BK&emphasizeText=Designers+update+Figma+%E2%86%92+Claude+Code+pulls+changes+%E2%86%92+generates+updated+components+%E2%86%92+pushes+to+GitHub+%E2%86%92+auto-deploys.).
- The author concludes that Claude Code alone is “fast vibe coding,” but GSD turns it into a robust, spec-driven system that lets designers with system intuition build production-grade work. The future is designers learning to build with these systems, not manually learning every framework.
## 📚 References
- Get Shit Done (GSD) – meta-prompting system for Claude Code: https://github.com/glittercowboy/get-shit-done
- Claude Code Documentation: https://docs.anthropic.com
- Figma Model Context Protocol: https://www.figma.com/developers/model-context
- Supabase: https://supabase.com
- Vercel: https://vercel.com
- Article: https://nervegna.substack.com/p/claude-code-for-designers-a-practical
## 🗣️ Paraphrase
- Paragraph A paraphrase: The article argues that AI coding agents like Claude Code, when structured by GSD, let designers convert their system-level thinking into code without battling toolchains, translating intent through human developers, or manually managing complex architectures.
- Paragraph B paraphrase: Through concrete workflows—portfolio sites, auth-backed AI apps, and Figma MCP pipelines—the author shows designers how to turn Figma designs and conversational specs into tested, deployed products, reframing the future of design as learning to build with AI-augmented systems.
## 📰 Newsletter
This week in WordPress, we’re zooming out from block patterns and performance tickets to look at how AI coding agents are reshaping design-to-dev workflows.
Tommaso Nervegna’s guide to Claude Code + the Get Shit Done (GSD) meta-prompting system feels directly relevant to WordPress builders. Imagine speccing a feature in conversational language—states, breakpoints, empty states—and having a structured agent generate atomic tasks, Tailwind tokens, and React components (or block code) that actually match your Figma system.
For WordPress folks, the same patterns could power:
- Prototype-to-plugin flows using WP‑friendly stacks (REST, WP‑CLI, Gutenberg APIs).
- Theme.json and design-token generation driven from Figma via MCP-like context.
- Automated git hygiene for block libraries and custom plugins through atomic AI commits.
If you’re experimenting, pair this with:
- Gutenberg developer docs: https://developer.wordpress.org/block-editor
- Theme.json reference: https://developer.wordpress.org/block-editor/how-to-guides/themes/theme-json
- Vercel/Supabase-inspired patterns for headless WP: https://developer.wordpress.org/rest-api/
Short version: learn the structure (requirements, roadmaps, atomic tasks), then swap in WordPress building blocks. The opportunity is less about magic code and more about teaching AI to think the way good product teams already do.
## ✅ Action Items
#### DevRel
- Document a Claude Code + GSD quickstart for designers, with copyable commands and example projects.
- Build a live demo showing portfolio → auth app progression, with repo and walkthrough talk.
- Add starter templates and example repos that mirror the article’s flows (portfolio, AI chat app).
- Run workshops on “spec-driven AI development” for design and dev communities.
- Collect feedback on pain points (Supabase, Vercel, Claude) and feed into docs/SDK priorities.
- Coordinate with product and security to ensure examples follow best practices for keys and RLS.
#### OSPO
- Define policy for AI-generated code contributions (provenance, review requirements).
- Update contribution guidelines to clarify licensing for AI-assisted code and prompts.
- Establish a regular training cadence on open-source license compliance in AI workflows.
- Include AI-generated components in SBOM inventories and update freshness expectations.
- Offer consult hours for teams adopting Claude Code/GSD pipelines in open projects.
- Explore upstream funding or collaboration with GSD-like tooling if open-sourced.
- Track OKRs on AI-enabled productivity vs review overhead in open-source repos.
#### Community
- Host “roadmap clinics” where maintainers map features into GSD-style phases.
- Create contributor onboarding paths based on small, atomic tasks mirroring GSD plans.
- Pair new contributors with mentors to review AI-generated PRs for quality and style.
- Provide sponsors transparent breakdowns of time saved and quality gains from AI workflows.
- Coordinate cross-project incident drills for AI-generated bugs and security issues.
#### WordPress
- Core: pilot AI-assisted triage to turn bug reports into minimal reproducible plans.
- Core Performance: define perf budgets that GSD-like plans must respect (LCP, TTFB).
- Core AI: codify guidelines for using Claude-like agents in contributor workflows.
- **Core Program Team:** align release milestones with spec-driven phases and review checklists.
- Mobile: explore AI-assisted UI scaffolding using Figma inputs and native layouts.
- Playground: add labs that show Claude-generated themes/plugins running in-browser.
- Community: ship meetup kits on “AI in WordPress workflows” with live demos.
- Training: add lessons on AI-assisted development and spec-writing best practices.
- Marketing: highlight real stories where WP teams shipped faster with AI + structure.
- Support: document known pitfalls of AI-generated code in WordPress and escalation paths.
- Design: propose design-token standards that map cleanly into `theme.json` and Tailwind.
- Documentation: add “examples-first” AI sections showing prompts → code → docs.
- Photos/TV/Openverse: clarify policies for AI-generated media and caption quality.
- Polyglots: test AI-assisted translation, with clear human review steps.
- Accessibility: integrate WCAG checks into any AI-generated themes/plugins pipeline.
- Meta: explore AI-powered contributor tools on .org (issue summaries, task planning).
- CLI: consider scaffolding commands aligned with GSD phases (spec, plan, execute).
- Hosting/Tide: define how AI-generated code is scored, verified, and flagged.
- Themes/Plugins: provide review guidance for AI-heavy submissions, focusing on security and perf.
#### The WPCC
- Launch microgrants for experiments applying Claude Code/GSD workflows to WordPress.
- Run governance clinics on how AI affects release processes and decision rights.
- Fund documentation sprints around “AI + open source” for design and dev roles.
- Trial matched grants for maintainers who document robust AI-assisted pipelines.
### FAIR
- Encourage local caching and verification of AI-generated artifacts (signatures, checksums).
- Adopt transparent funding and governance models for AI tooling underpinning WP workflows.
- Share reusable governance assets (RACI, contribution policies, AI usage scorecards).
## 🧪 Hypotheses
- H1: Designers using Claude Code + GSD ship functional prototypes significantly faster than designers working through traditional dev handoff.
- H2: GSD-style spec-driven workflows produce fewer regressions than unstructured AI “vibe coding.”
- H3: Integrating Figma MCP with Claude Code yields closer visual fidelity and fewer design-review cycles.
- H4: Designers with prior dev experience derive more value (quality and speed) from Claude Code than those without.
- H5: Atomic git commits per AI task reduce mean time to diagnose and fix bugs.
### 📊 Methodology
- Run controlled studies across teams: half use Claude Code + GSD, half use normal tools; compare time-to-first-deploy, bug counts, and review feedback.
- Instrument repositories to track regression frequency and MTTR for GSD vs non-GSD projects.
- Use design-review logs to measure number and severity of visual discrepancies with and without Figma MCP pipelines.
- Survey designers with varied coding backgrounds, correlating self-reported comfort, time savings, and quality ratings.
- Analyze git histories to determine how often atomic AI commits enable faster `git bisect` and rollback.
### ❓ Questions
- How far can AI-structured workflows go before they conflict with existing engineering governance?
- What minimum level of technical literacy should designers have to safely drive Claude Code projects?
- How stable are these workflows across framework churn (React, Next, Tailwind versions)?
- Can similar pipelines be generalized to WordPress (themes, blocks, plugins) without sacrificing security?
- How should organizations attribute and review AI-assisted contributions?
### 🔮 Future Research
- Comparative studies between Claude Code + GSD and other AI coding agents/prompting systems.
- Longitudinal research on how designer roles and skillsets evolve under AI-augmented building.
- Deeper integration patterns between design tools (Figma, Penpot) and AI code agents.
- Automated observability: integrating logging, metrics, and perf budgets directly into AI task plans.
- Governance models for AI-orchestrated workflows in large open-source communities.
### 💡 Implications
- Practice: Designers can own more of the build loop, but need training in specs, architecture, and verification.
- Policy: Organizations must define acceptable AI usage, review processes, and security baselines for generated code.
- Security: AI tools must embed secure defaults (secrets management, RLS, auth) to avoid systemic risks.
- Education: Curricula for design and HCI should incorporate AI-augmented prototyping and spec writing.
- Funding: Backing high-quality, open AI workflows/tools can drastically improve productivity and inclusivity in open ecosystems.
### 🧠 Learning Styles Assessment
- Reading level estimate: roughly upper high-school to early college (Flesch–Kincaid grade ~11–13) due to technical terms (MCP, RLS, Tailwind), but written conversationally.
#### 👀 Visual learners
- Present: Descriptions of layouts, Figma structures, spacing tokens, and component hierarchies.
- Improve: Add diagrams of GSD agents, phase flows, and Figma-to-code pipelines; before/after visual diffs.
#### 🔊 Aural learners
- Present: None explicitly (no audio).
- Improve: 3–5 minute audio summary and a narrated walkthrough of the portfolio and Figma MCP workflows.
#### 🗣️ Verbal learners
- Present: Clear definitions of concepts like “context rot,” “spec-driven development,” and “multi-agent orchestration.”
- Improve: More analogies comparing these workflows to classic design/development collaboration patterns.
#### 🧩 Kinesthetic learners
- Present: Concrete step-by-step commands (install, `discuss-phase`, `plan-phase`, `execute-phase`, `verify-work`).
- Improve: Checklist PDFs and lab-style exercises with exact tasks and expected outputs.
#### 🧠 Logical learners
- Present: Phase-based roadmaps, atomic task planning, and cause–effect explanations of why GSD improves quality.
- Improve: Tables comparing “with vs without GSD,” plus explicit decision trees for stack selection.
#### 🧑🤝🧑 Social learners
- Present: Implicit emphasis on team workflows (designers, devs, clients).
- Improve: Suggested discussion prompts for design/dev reviews using GSD outputs.
#### 🧘♀️ Solitary learners
- Present: Text-based walkthroughs that can be followed independently.
- Improve: Reflection prompts after each step (“What assumptions did you skip?”) and self-check quizzes.
#### 🌿 Naturalistic learners
- Present: Minimal; focus is on tooling and process.
- Improve: Analogies to ecosystems (agents as species, specs as environments) and brief notes on infra/resource efficiency.
### 📊 Accessibility Assessment
#### Screen reader semantics
- Present: It’s an article; likely basic headings and paragraphs only.
- Improve: Ensure semantic headings, properly labeled code snippets, and clear link text.
#### Keyboard navigation
- Present: Standard web article behavior.
- Improve: For any embedded demos or terminals, ensure full keyboard operability and visible focus.
#### Contrast and readability
- Present: Depends on Substack theme; usually acceptable.
- Improve: Confirm 4.5:1 contrast, increase line-height, and limit very long paragraphs.
#### Text resizing and reflow
- Present: Responsive layout via Substack.
- Improve: Test at 200% zoom, ensure no clipping of code examples; support reduced-motion preferences.
#### Media and captions
- Present: Primarily text; any images/gifs may lack alt text.
- Improve: Provide alt text, text equivalents for diagrams, and avoid autoplaying media.
#### Forms and interactions
- Present: Subscription form only.
- Improve: Ensure labels, errors, and focus handling are accessible.
#### Standards reference
- Map gaps mainly to WCAG 2.2 AA criteria: 1.4.x (contrast, resizing), 2.1.x (keyboard), 1.3.x (structure), 3.3.x (input assistance).
### 🌍 DEIB Assessment
#### Cultural breadth
- Present: Primarily Western, tech-centric examples.
- Improve: Include cases from varied regions and industries; note infra requirements and constraints.
#### Inclusive language
- Present: Generally inclusive, gender-neutral, informal tone.
- Improve: Avoid slang that may not translate; define jargon like MCP, RLS, “vibe coding.”
#### Neurodiversity support
- Present: Clear structure by steps and phases.
- Improve: Further chunking with consistent headings, bullets, and summaries per section.
#### Representation
- Present: Focused on author’s experience; few explicit references to broader identities.
- Improve: Illustrate workflows across diverse teams and contexts.
#### Psychological safety
- Present: Encouraging tone; emphasizes experimentation and learning.
- Improve: Add explicit reassurance about making mistakes, and guidance for safe experimentation (dev vs prod).
### ✅ Logical Validity
#### Strong reasoning
- The spec-driven argument is strong: starting from explicit requirements and roadmaps reduces rework and misalignment; the article backs this with concrete before/after scenarios and artifacts (e.g., `REQUIREMENTS.md`, atomic plans).
- The claim that GSD mitigates context rot is plausible because it constrains context windows and tasks, aligning with known LLM limitations.
#### Fallacies
- Potential selection bias: examples are all successful uses; it doesn’t discuss failures or where Claude/GSD struggle (e.g., highly novel algorithms). A short limitations section would strengthen balance.
- Possible overgeneralization: claims about production readiness may not hold for all domains (e.g., heavy-regulated, deeply backend systems). Clarifying scope (web UIs, CRUD apps, dashboards) would fix this.
#### Tone of voice
- Tone is pragmatic, optimistic, and slightly irreverent (e.g., “Get Shit Done,” “vibe coding”). It’s persuasive but grounded in specific workflows and commands.
### 🛡️ DARVO Analysis
- Deny: The article does not deny problems; it acknowledges AI’s weaknesses (context rot, generic output) and positions GSD as mitigation.
- Attack: There is no attack on critics or individuals; critique is aimed at patterns (“learn to code” advice, unstructured AI coding).
- Reverse victim/offender: No attempt is made to reframe designers or AI tools as victims; instead, it frames designers as empowered agents.
- Overall: The piece is advocacy, not defensive; DARVO patterns are not present.
## 🎯 Conclusion
The article reframes the role of designers in an AI-augmented world, arguing that with Claude Code plus GSD—and optionally Figma MCP—designers can own end-to-end product building, from intent and design systems through code, deployment, and verification. Practical next steps: install GSD, build a small portfolio with full requirements and phases, then graduate to a Figma-driven, tokenized component library, treating each step as a learning lab in structured AI collaboration.
## 🧱 Refactor Appendix (append after 🎯 Conclusion)
### 📚 Literature Split Pad
- Purpose: Stage Konik CEE units that become per-source Literature notes.
- Split level: **H3**.
- Include verbatim quotes under 25 words and a [view highlight] link.
### [H1] AI agents let designers build systems directly
> [!quote] [Claude Code for Designers: A Practical Guide](https://nervegna.substack.com/p/claude-code-for-designers-a-practical) by [[Tommaso Nervegna]] via [[Substack]]. Published 2026-01-26. Accessed 2026-02-15.
> “Claude Code understands design intent and translates it directly into working software.”
Two lines: Designers can bypass traditional handoff by turning conversational specs into code. Use when arguing for AI-augmented design roles.
[view highlight](https://nervegna.substack.com/p/claude-code-for-designers-a-practical#H1) #xref #articleseed ID:rw_[MISSING]
### [H2] Get Shit Done structures AI coding workflows
> [!quote] [Claude Code for Designers: A Practical Guide](https://nervegna.substack.com/p/claude-code-for-designers-a-practical)
> “GSD solves this… enforces spec-driven development… and spawns specialized agents for research, planning, execution, and verification.”
Two lines: GSD turns “vibe coding” into spec-driven, multi-agent workflows that stay stable over long projects.
[view highlight](https://nervegna.substack.com/p/claude-code-for-designers-a-practical#H2) #xref ID:rw_[MISSING]
---
### 🔖 Atomic Split Pad (Zettel Candidates)
- Purpose: Promote reusable claims into Atomic notes.
- Split level: **H4**.
- Each item: one idea, present tense, specific, testable.
#### [Z1] Structured AI prompts reduce context rot
- When tasks are scoped and sequenced, LLMs maintain quality across long projects.
- Pointer: GSD sections on research, planning, and 200k-token execution contexts.
- Links: [[AI-Context-Engineering]] [[Spec-Driven-Development]]
#### [Z2] Figma MCP enables pixel-perfect code generation
- When design tokens and layouts are machine-readable, AI can output visually faithful components.
- Pointer: Sections on design token extraction and Figma-based verification.
- Links: [[Design-Systems]] [[AI-Code-Generation]]
---
### ✏️ Fleeting Queue (Extract by Selection)
- Purpose: Capture quick actions or sparks for Fleeting notes.
- Extraction: **Select one line** → “Refactor: Extract selection to new note (content only).”
- Keep each line short and self-contained.
- [F1] Try building a small WordPress headless prototype using Claude Code + GSD and measure time saved—https://nervegna.substack.com/p/claude-code-for-designers-a-practical #fleeting #inbox
- [F2] Draft a Figma → Tailwind → theme.json pipeline inspired by the Figma MCP workflow—https://nervegna.substack.com/p/claude-code-for-designers-a-practical #fleeting #inbox
- [F3] Create a checklist that mirrors GSD’s phases for spec-driven feature development—https://nervegna.substack.com/p/claude-code-for-designers-a-practical #fleeting #inbox
---
## 🧰 Template Library (paste into Note Refactor → Refactored Note Template)
<!-- Copy ONE template at a time into the plugin before running each batch. -->
### 📝 Fleeting — Refactored Note Template (Konik-ready)
---
type: fleeting
status: inbox
created: {{date:YYYY-MM-DD}} {{time:HH:mm}}
process_by: {{date:YYYY-MM-DD}} # review within 24–48 hrs
source_title: [MISSING]
source_link:
author: [MISSING]
source_type: article|paper|video|podcast|thread
reading_stage: inspectional|analytical|syntopical
project:
tags: #fleeting #inbox
---
# 📝 Fleeting Note — {{title}}
## 🧠 One-liner (my words)
- State the single idea in one short sentence.
## 🧭 Context & cue
- Where did this arise? Page/timecode/speaker.
- Trigger: quote, data point, claim, or question.
## 🧪 Adler checks (quick)
- What is this about as a whole?
- What is said in detail, and how?
- Is it true? Evidence for or against?
- So what? Impact or next move.
## 🔎 Bias & reliability snapshot
- Possible bias or framing?
- What evidence would change my view?
## 🧩 Konik bridge
- Draft a claim header for promotion.
### [H1] 5–10-word present-tense claim
> [!quote] [{{source_title}}]({{source_link}}) by [[{{author}}]]. Accessed {{date:YYYY-MM-DD}}.
> “Short quote under ~25 words.”
One line on why this matters.
[view highlight]({{source_link}}) #xref ID:rw_[MISSING]
## 🧰 Next moves (pick 1–2)
- [ ] Promote to *Literature* with citation.
- [ ] Draft *Atomic* claim from [H1].
- [ ] Park as testable question.
## ✅ Processing checklist
- [ ] Rewrote in my words.
- [ ] Decided: trash | keep | convert.
- [ ] Linked to at least one related note.
- [ ] Tagged and moved out of inbox.
---
### 📚 Literature — Refactored Note Template (Konik-ready)
---
type: literature
status: draft
created: {{date:YYYY-MM-DD}} {{time:HH:mm}}
adler_level: inspectional|analytical|syntopical
reading_stage: inspectional|analytical|syntopical
source_title: [MISSING]
author: [MISSING]
year:
publisher_or_journal:
edition_or_volume:
doi:
url:
accessed: {{date:YYYY-MM-DD}}
citekey:
project:
tags: #literature #reading
---
# 📚 Literature Note — {{title}}
## 🧰 Action Inbox
- [H1] Short action — context/{{url}} #articleseed
- [H2] Short action — context/{{url}} #xref
- [H3] Short action — context/{{url}} #share
## 🧭 Bib Capsule
- Title, author, year, venue, and link.
- One-line scope: what the work attempts.
## 🧠 Author’s Thesis (their words)
- Core claim briefly. Include page/timecode.
## 🧩 Key Arguments
- Argument A — method/evidence — page/time.
- Argument B — method/evidence — page/time.
- Argument C — method/evidence — page/time.
## 🧪 Evaluation (Adler)
- What is this about as a whole?
- How is it argued? Fairly and clearly?
- Is it true or plausible? Why?
- So what? Practical or theoretical impact.
## 🗒️ Notes (Konik CEE units)
### [H1] 5–10-word present-tense claim
> [!quote] [{{source_title}}]({{url}}) by [[{{author}}]] via [[{{publisher_or_journal}}]]. Published {{year}}. Accessed {{accessed}}.
> “Verbatim highlight under ~25 words.”
Two lines: context and use. Link to data if relevant.
[view highlight]({{url}}#H1) #xref #articleseed ID:rw_[MISSING]
### [H2] 5–10-word present-tense claim
> [!quote] [{{source_title}}]({{url}}) by [[{{author}}]] via [[{{publisher_or_journal}}]]. Published {{year}}. Accessed {{accessed}}.
> “Verbatim highlight under ~25 words.”
Two lines: context and use.
[view highlight]({{url}}#H2) #xref ID:rw_[MISSING]
## 🔖 Zettel Candidates
#### [Z1] 5–10-word present-tense claim
- One-line context and page/time.
#### [Z2] 5–10-word present-tense claim
- One-line context and page/time.
## 🏷️ Tag Coverage
#articleseed: 0 • #xref: 0 • #share: 0 • #bmf: 0 • #addendum: 0
## ✅ Processing Checklist
- [ ] Thesis captured in my words.
- [ ] 1–3 Zettel candidates drafted.
- [ ] Action Inbox pruned to high-signal items.
- [ ] Cross-links added and filed.
---
### 🔖 Atomic (Zettel) — Refactored Note Template (Konik-ready)
---
type: atomic
id: {{date:YYYYMMDDHHmm}}-{{title}}
status: evergreen
created: {{date:YYYY-MM-DD}} {{time:HH:mm}}
origin: reading|thinking|experiment
proof_state: conjecture|working|supported|refuted
source_literature: [[Source-Literature-Note]]
citekey:
project:
tags: #zettel #idea
---
# 🔖 {{title}} <!-- 5–10 words, present tense, specific -->
## 🧠 Claim
- One idea only. Clear and testable.
## 🧾 Evidence & Pointers (Konik)
- [H#] from [[{{source_literature}}]] — page/time — brief rationale.
- ID:rw_[MISSING] — link to highlight or dataset.
> [!quote] Evidence snippet (≤25 words) if essential.
> Cite page/time. Keep it minimal.
## 🔍 Scope & Conditions
- When this holds. Boundaries and exceptions.
## 🔗 Links
- Broader: [[Parent-Concept]]
- Narrower: [[Specific-Case]]
- Related: [[Parallel-Idea]]
## 🧪 Tests / Falsifiers
- One check that could disconfirm the claim.
- Simple study or observation plan.
## 🧰 Implications
- Practice, policy, or design moves in one line each.
## 🔙 Backlinks
- From: [[{{source_literature}}]] • Context line.
## ✅ Maintenance
- [ ] Links in and out.
- [ ] Title still precise?
- [ ] Proof state updated.
## Highlights
- Claude Code understands design intent and translates it directly into working software. I describe what I want to build using my designer vocabulary and my developer intuition. It writes the code. I iterate by giving feedback on what I see, informed by years of knowing what should happen under the hood. ([View Highlight](https://read.readwise.io/read/01khfepy8ttqhycr69v0dd1bjx))
- Tags: 👻 ai highlighted
- If you don’t know how to code at all, you can still use Claude Code effectively. You just need to know what you want to build and describe it clearly. Claude Code handles the syntax. ([View Highlight](https://read.readwise.io/read/01khfepyhjyv12rjqv9ee40m52))
- Tags: 👻 ai highlighted