stitch-ui-vue-bootstrap-components

Stitch to Vue 3 + Bootstrap Components

Constraint: Only use this skill when the user explicitly mentions "Stitch" and converting Stitch screens to Vue 3 + Bootstrap (Vite, .vue SFC, BootstrapVue Vue 3 or BootstrapVueNext).

You are a frontend engineer turning Stitch designs into clean, modular Vue 3 + Bootstrap code. Use Stitch MCP (or stitch-mcp-get-screen) to retrieve screen metadata and HTML; use scripts and resources in this skill for reliable fetch and quality checks. Target stack: Vue 3 + BootstrapVue Vue.js 3 Support (@vue/compat) or BootstrapVueNext (Bootstrap 5 + Vue 3).

Prerequisites

• Stitch MCP Server (https://stitch.withgoogle.com/docs/mcp/guide/)
• Node.js and npm (for Vite/Vue 3 project)
• Stitch project and screen IDs — two ways: (1) From a Stitch design URL: parse projectId (path) and screenId (node-id query). (2) When no URL or when browsing: use stitch-mcp-list-projects and stitch-mcp-list-screens to discover and obtain IDs.

Official Documentation

• Bootstrap Vue: Official · Vue 3 support · Docs · Components · GitHub
• Full links and usage: references/official.md

Retrieval and Networking

1. Discover Stitch MCP prefix: Run list_tools to find the prefix (e.g. mcp_stitch__stitch:).
2. Fetch screen metadata: Construct name: projects/{project}/screens/{screen} from the string ID segments and call [prefix]:get_screen to get design JSON, htmlCode.downloadUrl, screenshot.downloadUrl, dimensions, deviceType.
3. High-reliability HTML download: AI fetch tools can fail on Google Cloud Storage URLs. Use Bash to run the skill script:

   bash scripts/fetch-stitch.sh "<htmlCode.downloadUrl>" "temp/source.html"
   

   Ensure the URL is quoted.
4. Visual reference: Use screenshot.downloadUrl to confirm layout and details.

Architectural Rules

• Modular components: Split the design into separate .vue files; avoid one giant SFC.
• Logic isolation: Put event handlers and composables in src/composables/ or within script setup.
• Data decoupling: Move static text, image URLs, and lists into src/data/mockData.js (or .ts).
• Bootstrap components only (use framework components when available): Use b-card for cards, b-alert for tips; do not use div.card or custom .card-header/.tips-text. Use <b-container>, <b-row>, <b-col>, <b-button>, etc. per references/contract.md; do not use raw <button class="btn"> or <div class="card"> when b-* applies.
• Project-specific: Omit third-party license headers from generated components.

Execution Steps

1. Environment: If the project has no node_modules, run npm install.
2. Data layer: Create src/data/mockData.js from the design content.
3. Component drafting: Use resources/component-template.vue as base; replace placeholder with real component name and Bootstrap Vue tags per contract.
4. Wiring: Update the app entry (e.g. App.vue or router) to render the new components.
5. Quality check: Verify against resources/architecture-checklist.md; run npm run dev to confirm visually.

Integration with This Repo

• Get screen: Use stitch-mcp-get-screen with projectId and screenId. Obtain IDs either by parsing a Stitch design URL or by using stitch-mcp-list-projects and stitch-mcp-list-screens when no URL or when the user needs to browse/select.
• Design spec: If Stitch was generated with stitch-ui-contract-bootstrap constraints, map to Vue SFC and Bootstrap Vue components. If converting from Stitch HTML (e.g. get_screen htmlCode), use references/tailwind-to-bootstrap.md for Tailwind utility → Bootstrap utilities/components, then references/contract.md for component API.
• Design system: If the project has DESIGN.md (from stitch-design-md), align colors and spacing with that system when mapping to Bootstrap tokens.

Troubleshooting

• Fetch errors: Quote the URL in the bash command; ensure scripts/fetch-stitch.sh is executable.
• Component mapping: Follow references/contract.md for layout (b-container/b-row/b-col), buttons (b-button), forms (b-form-group, b-form-input), cards (b-card).

Keywords

English: Stitch, Vue 3, Bootstrap, BootstrapVue, Vite, b-container, b-button.
Chinese keywords: Stitch, Vue 3, Bootstrap, components.

References

• Examples
• Scripts
• Component index (per-component doc links)
• Tailwind → Bootstrap Vue — Tailwind utility → Bootstrap when converting Stitch HTML.
• Contract (Bootstrap mapping)
• Component API (props/events quick reference)
• Official documentation
• Architecture checklist
• Component template
• Stitch API / MCP

When to use

Load this skill when the user needs to select and execute a verifiable, recoverable professional workflow for the current request . First extract the goal, inputs, constraints, delivery format, and acceptance criteria from the request; the description summary is: Convert Stitch designs into modular Vite/Vue 3 and BootstrapVue or BootstrapVueNext components. Uses [BootstrapVue Vue 3] support; Stitch MCP get_screen for retrieval; high-reliability fetch via scripts; enforces Vue SFC structure and Bootstrap component contracts b-container b-row b-button etc..

Rules

• Read before write: first confirm the current state and real capabilities, then execute actions that change external state.
• Least privilege: use only the files, tools, accounts, and network scope required to complete the current step.
• Evidence first: when run results, resource IDs, versions, hashes, or test output are missing, clearly mark them as NOT_VERIFIED。
• Idempotency first: preserve request identifiers and phase state; when results are unclear, query first and do not retry blindly.
• Privacy and security: logs, examples, receipts, and error messages must not contain tokens, cookies, keys, or personally sensitive data.

Workflow

Step 1: Clarify intent

Confirm whether this skill matches the goal; if it is only an adjacent need, hand it off to a more precise skill.

Step 2: Run prechecks

Confirm the goal, inputs, constraints, available tools, success criteria, and failure boundaries; if any critical condition is unknown, stop at the read-only stage.

Step 3: Form a plan

List the tools to be called, the objects that will change, the success criteria, and the safe exit method after failure.

Step 4: Execute actions

Execute in the minimum sufficient steps, and record evidence at key state changes; preserve an associated state or receipt for every external call.

Step 5: Verify delivery

Output the results, verification evidence, unfinished items, risks, and clear next steps, and state facts, inferences, and unverified items separately.

Validation checklist

• The skill trigger conditions match the user's intent, and adjacent tasks were not misrouted to this skill.
• The inputs, target objects, versions, and output locations are all clear, and no required values were replaced with guesses.
• All write, paid, publish, or irreversible actions are within the scope authorized by the user.
• The results have been verified with independent checks; only "the command succeeded" or "the file exists" does not count as complete acceptance.
• The output includes actual evidence, failed/skipped items, remaining risks, and executable next steps.

Gotchas

1. Treating the plan as the result: a document or prompt is not equal to actual execution; the actual level of execution must be indicated.
2. Retrying on error: a timeout or lost response may already have produced remote state; query first before deciding whether to retry.
3. Implicit scope expansion: batch, full-scale, publish, overwrite, and paid actions are not natural extensions of ordinary reads and writes.
4. Version drift: when referencing external resources, record the version, tag, or commit; do not treat a mutable branch as release evidence.
5. Stale evidence: caches, old screenshots, and historical tests cannot prove the current environment; refresh key evidence before delivery.

Non-applicability and boundaries

Do not exceed the user-specified scope; write, payment, publishing, and irreversible actions require explicit authorization. If the request requires another skill, do not copy its body text; hand off by skill name and preserve the current task context.

Progressive disclosure

• When input/output, state, and authorization points need to be determined, read references/workflow-contract.md。
• When pre-delivery self-check is needed, read references/validation-checklist.md。
• When encountering timeout, partial success, or recovery scenarios, read references/error-recovery.md。
• For first run, privilege escalation refusal, and failure recovery, refer respectively to examples/happy-path.md、examples/boundary-refusal.md、examples/failure-recovery.md。