vue-component-design

星标10

分支3

更新时间2026年4月20日 22:16

Designs or reviews Vue 3 component APIs. Handles prop drilling decisions, applies compound component patterns with provide/inject, defines minimal public API surfaces with typed props/emits/slots, and enforces Vue 3.4+ composition conventions. Invoked when creating new components, refactoring existing ones, or reviewing component contracts.

安装

用 Codex 或 Claude 帮你安装复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。

来源

soulcodex

soulcodex/agentic

打开 GitHub 仓库查看创作者相关仓库

下载

Vue Component Design Skill

Step 1 — Identify the Component's Responsibility

Determine the component type before designing the API:

Page component — orchestrates data fetching, permissions, and layout. Coordinates child components. Tests: mock data fetching, verify correct children are rendered.
Feature component — contains feature-specific business logic and local state. May call store actions. Tests: mock store, assert state changes.
UI component — pure presentational, props + slots only, no async logic, no store access. Tests: assert correct markup for given props.

Step 2 — Design the Public API Surface

Props: minimal, typed with TypeScript interfaces, withDefaults for optional props with safe defaults.
Emits: typed defineEmits<{ eventName: [payload] }>() — one event per user action.
Slots: default for content, named for layout regions, scoped when parent needs child-provided state.
expose(): only for imperative handles (focus, open, reset) — never expose internal state.
Use defineModel<T>() (Vue 3.4+) for two-way binding instead of modelValue + update:modelValue.

Step 3 — Evaluate Prop Drilling Depth

Count how many component levels the data crosses:

1–2 levels → props are acceptable
3+ levels through components that do not use the data → refactor to provide/inject with typed Symbol keys
Global / cross-feature / persisted → Pinia store

// keys.ts
import type { InjectionKey } from 'vue'

export const AccordionKey: InjectionKey<{
  openId: Readonly<Ref<string | null>>
  toggle: (id: string) => void
}> = Symbol('accordion')

Step 4 — Composition Review

Does the component do too much? Apply single responsibility: extract orchestration logic into a composable, keep the template as a thin consumer.
Are slots used where a child component should receive data and render itself? Prefer scoped slots over prop-drilling display logic.
Is <Teleport> needed? Use for modals, toasts, and dropdowns that must escape their stacking context.

Step 5 — Verify

No props passed through more than 2 intermediate components that do not use them
defineModel() used instead of manual modelValue + update:modelValue pattern
Provide/inject keys are typed Symbols, not plain strings
expose() only used for imperative handles (never internal state)
UI components contain no async logic or store access
pnpm tsc --noEmit passes with no errors

同仓库更多 Skills

同仓库

terraform-infrastructure

soulcodex/agentic

Structures, writes, and reviews Terraform infrastructure code. Covers module layout, remote state, workspace strategy, variable and secrets handling, CI plan/apply pipeline, naming conventions, and multi-region deployment patterns (provider aliases, per-region state, failover strategies), while delegating shared risk classification, version guards, and rollback contract to `terraform-risk-playbook`. Invoked when the user asks to write Terraform, set up infrastructure as code, or review IaC.

2026-06-2710

create-terraform-module

soulcodex/agentic

Creates or updates AWS-oriented Terraform module structure and implementation scaffolding. Focuses on file layout, variable/output contracts, provider and version constraints, tagging standards, safe composition patterns, and address-stability guardrails.

2026-06-2710

create-terraform-tests

soulcodex/agentic

Designs and implements Terraform module tests for AWS-targeted modules. Covers terraform-native tests, validation gates, fixture composition, and risk-focused assertions for regressions, address migration, and unsafe changes.

2026-06-2710

design-aws-terraform-iac

soulcodex/agentic

Designs AWS-targeted Terraform infrastructure plans before implementation. Focuses on service selection, module boundaries, state/backends, environment separation, security/compliance guardrails, acceptance criteria, and explicit risk/validation assumptions.

2026-06-2710

terraform-risk-playbook

soulcodex/agentic

Diagnoses Terraform/OpenTofu risk before generating changes. Defines the response contract, failure-mode routing, version/runtime guards, validation commands, and rollback expectations for modules, tests, CI, and state work.

2026-06-2710

use-aws-mini-stack-emulator

soulcodex/agentic

Uses lightweight AWS stack emulation for faster local Terraform iteration. Defines what can be safely validated locally, compatibility caveats, and the handoff boundary to real-AWS verification and reviewed plan/apply flows.

2026-06-2710

name	vue-component-design
description	Designs or reviews Vue 3 component APIs. Handles prop drilling decisions, applies compound component patterns with provide/inject, defines minimal public API surfaces with typed props/emits/slots, and enforces Vue 3.4+ composition conventions. Invoked when creating new components, refactoring existing ones, or reviewing component contracts.
version	1.0.0
tags	["ui","vue","typescript","composition"]
resources	[]
vendor_support	{"claude":"native","opencode":"native","copilot":"prompt-inject","codex":"prompt-inject","gemini":"prompt-inject"}

Vue Component Design Skill

Step 1 — Identify the Component's Responsibility

Determine the component type before designing the API:

Page component — orchestrates data fetching, permissions, and layout. Coordinates child components. Tests: mock data fetching, verify correct children are rendered.
Feature component — contains feature-specific business logic and local state. May call store actions. Tests: mock store, assert state changes.
UI component — pure presentational, props + slots only, no async logic, no store access. Tests: assert correct markup for given props.

Step 2 — Design the Public API Surface

Props: minimal, typed with TypeScript interfaces, withDefaults for optional props with safe defaults.
Emits: typed defineEmits<{ eventName: [payload] }>() — one event per user action.
Slots: default for content, named for layout regions, scoped when parent needs child-provided state.
expose(): only for imperative handles (focus, open, reset) — never expose internal state.
Use defineModel<T>() (Vue 3.4+) for two-way binding instead of modelValue + update:modelValue.

Step 3 — Evaluate Prop Drilling Depth

Count how many component levels the data crosses:

1–2 levels → props are acceptable
3+ levels through components that do not use the data → refactor to provide/inject with typed Symbol keys
Global / cross-feature / persisted → Pinia store

// keys.ts
import type { InjectionKey } from 'vue'

export const AccordionKey: InjectionKey<{
  openId: Readonly<Ref<string | null>>
  toggle: (id: string) => void
}> = Symbol('accordion')

Step 4 — Composition Review

Does the component do too much? Apply single responsibility: extract orchestration logic into a composable, keep the template as a thin consumer.
Are slots used where a child component should receive data and render itself? Prefer scoped slots over prop-drilling display logic.
Is <Teleport> needed? Use for modals, toasts, and dropdowns that must escape their stacking context.

Step 5 — Verify

No props passed through more than 2 intermediate components that do not use them
defineModel() used instead of manual modelValue + update:modelValue pattern
Provide/inject keys are typed Symbols, not plain strings
expose() only used for imperative handles (never internal state)
UI components contain no async logic or store access
pnpm tsc --noEmit passes with no errors