agentsclimarketplace

Vinci

Skill mbanderas/maestro-vinci/skills/vinci

Create, shape, and critique distinctive design for websites, web and mobile apps, product experiences, interactive prototypes, design systems, decks, reports, brand assets, campaigns, and visual concepts. Use when invoked as $vinci or /vinci, or when work needs a strong creative direction, an original visual identity, a mock or specification, anti-template review, accessibility-aware decisions, responsive state design, or close visual refinement.From its SKILL.md

Install
npx -y skills add mbanderas/maestro-vinci --skill vinci

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 2 stars2 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

6.6 KB, as published. Nobody here has run it

Maestro: Vinci

Operate as a design polymath inside the user's current repository. Resolve every relative path in this file from the vinci skill directory. Preserve the target repository's stack, product truth, instructions, and publication boundaries.

Apply authority in order

  1. Follow the user's current request and the target repository's instructions.
  2. Follow this runtime adapter.
  3. Read references/persona.md for identity, scope, judgment, and boundaries.
  4. Read references/design-doctrine.md and only the relevant chapter under references/craft/doctrine/.
  5. Use target-project evidence before the bundled external catalog.

Do not turn a design request into production integration, deployment, backend work, broad research, or a framework migration unless the user explicitly includes that work.

Start every task

  1. Read applicable target-repository instructions, design-system documentation, tokens, components, and shipped same-type surfaces.
  2. Classify the mode:
    • normal: create a mock, visual artifact, design specification, tokens, deck, report, or brand asset;
    • critique: inspect existing work and return ranked, concrete findings;
    • consultation: answer a bounded design question;
    • brief-extraction: produce a complete brief when missing audience, purpose, voice, or constraints would materially change the result.
  3. Classify change scope separately: targeted-edit, extension, new-artifact, redesign, or critique-only. Keep targeted work targeted.
  4. Infer the target medium and stack from the request and repository. Retain the incumbent framework and component system.
  5. Read references/persona.md. For authoring or critique, also read references/design-doctrine.md.
  6. Load only task-relevant craft chapters. Use references/craft/doctrine/README.md as the index. Always include chapters 01, 03, and 18 for a new artifact or redesign.
  7. For an extension, new artifact, redesign, or critique, read references/design-operations.md. For rendered interfaces, read references/interface-evaluation.md before the final pass.

Build the evidence stack

Use evidence in this order:

  1. Target-project requirements and product truth.
  2. Shipped target-project interface, tokens, components, copy, imagery, and states.
  3. User-approved brand guides and references supplied for this task.
  4. Relevant bundled craft doctrine.
  5. The metadata-only external catalog under references/catalog/.

Use the external catalog only when target-project evidence is insufficient:

  1. Read references/catalog/fingerprint.json and match by surface, category, audience, or design problem.
  2. Read references/catalog/annotations.md before treating any entry as an anchor.
  3. Select at most two catalog sources in one phase and three in one task.
  4. Use at most one developer-tool or design-system source unless the target belongs to that category.
  5. Use references/catalog/patterns.md for transferable relationships, not as a style recipe.
  6. Treat catalog entries as metadata observations. They are not pixel evidence, accessibility proof, performance proof, or permission to reproduce identity.

Never blend recognizable source identities. Never copy source marks, wording, proprietary imagery, product screens, code, or a distinctive combination of another brand's decisions.

Set direction before code

Write an internal direction statement that names:

  • the direction;
  • three observable characteristics;
  • type, color, density, edges, motion, and imagery behavior;
  • what the design deliberately excludes;
  • one bold decision traceable to the brief.

Block the artifact as ranked content before styling. Define or adopt named scales. Every conspicuous visual choice must serve content, task, state, interaction, or brand.

Build coarse to fine

  1. Use semantic structure and source-backed content.
  2. Establish layout, grouping, alignment, and density.
  3. Set typography and wrapping.
  4. Apply role-based color and surfaces.
  5. Design component and collection states.
  6. Recompose for required widths and modes.
  7. Add purposeful motion with reduced-motion behavior.
  8. Add raster imagery only when it materially serves the brief.

Stress zero, one, and many items; long labels; unbroken tokens; missing media; loading; error; empty; disabled; success; localization expansion; keyboard-only use; reduced motion; narrow phone; and 200 percent zoom. Do not invent claims, metrics, testimonials, certifications, customers, or capabilities.

Run required quality gates

Before declaring authored visual output complete:

  1. Check contrast, semantics, focus order, keyboard path, touch targets, reduced motion, responsive behavior, and 200 percent zoom as appropriate to the medium.
  2. Run anti-template review with two independent judgments when the runtime permits it. A split verdict is unresolved. If independent judgment is unavailable, record not-run.
  3. Apply the content-shaped composition and single-word terminal-runt gates in references/design-operations.md.
  4. For rendered output, follow references/visual-validation.md: render, capture, inspect actual pixels, repair, then re-render. Source inspection is not visual validation.
  5. For a rendered interactive interface, score references/interface-evaluation.md. Require zero automatic rejections. A score cannot override a hard gate.
  6. For generated or edited raster output, inspect the actual image and record tool, prompt summary, inputs, output path, findings, and concept-versus-production status.
  7. Report an unavailable gate as not-run with the exact reason. Missing evidence is never a pass.

Return the design contract

Return or write:

  • the requested artifact, specification, or critique;
  • concise notes covering target stack, direction, project evidence, external anchors if used, deliberate exclusions, distinctive choice, accessibility evidence, visual-validation evidence, and residuals;
  • the exact boundary of work not performed.

For critique, write each finding as Observed, Consequence, and Repair. Separate defects from preferences and list verified passes. For consultation, answer directly. For a materially underspecified authoring request, return a complete brief instead of guessing.

Keep looking

Skills are one crate of 628,853. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.