Jeden Skill in Manus ausführen
mit einem Klick

Jeden Skill in Manus mit einem Klick ausführen

verify

Sterne20

Forks5

Aktualisiert16. Juli 2026 um 16:58

Run this after every code change in this Vue project, before committing, before opening a PR, or whenever the user says "verify", "check", "lint", "run tests", "build", "audit". Diff audit (router guards, store boundaries, UX, /ui consistency, error handling) → lint → tests + coverage gate → build. Coverage drops → add tests, never lower thresholds. Triggers on "is this ready to commit?", "any issues?", "tests passing?".

Installation

Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.

In Manus ausführen

Quelle

pierreb-devkit

pierreb-devkit/Vue

GitHub-Repository öffnen Creator-Repositorys ansehen

Download

In Manus ausführen

Verwandte BerufeSOC

Basierend auf der SOC-Berufsklassifikation

SoftwareentwicklerInformatik- und Mathematikberufe·SOC 15-1252

SKILL.md

readonly

name

verify

description

Verify Skill

Steps

Diff audit — review all changes (git diff master...HEAD or staged changes) using your knowledge of the stack:
- Read CLAUDE.md and ERRORS.md for conventions, architecture, and known pitfalls
- Read the tasks reference module structure for layer/naming conventions
- Check /ui skill for design system and Vuetify conventions
- Analyze the diff: architecture, security, UX, logic, consistency, error handling
- No hardcoded checklist — reason from context. Examples of what to catch:
  - Router guards with permissive matching (startsWith vs exact)
  - Silent error swallowing (catch without user feedback)
  - Store mutations from outside the store
  - Cross-module store imports (only useAuthStore/useCoreStore allowed)
  - Missing form validation or confirmation dialogs on destructive actions
  - Inconsistent selectors in E2E tests (prefer getByRole/getByPlaceholder)
  - Broken or nonexistent route references
  - Store-contract tests that only assert a mock was called, not the resulting store state (interaction-only assertions let a dropped field slip through)
- Fix all issues found before proceeding
Lint — npm run lint
Tests + coverage — check if Node API is reachable (curl -sf http://localhost:3000/api/home):
- Infra up → npm run test:coverage (unit + coverage enforcement) then npm run test:e2e (Playwright E2E)
- Infra down → npm run test:coverage (unit + coverage) + warn: "E2E skipped — run docker compose -f docker-compose.test.yml up -d for full coverage"
- If coverage drops below thresholds (vitest.config.js) → fail. Add tests, never lower thresholds.
Build — npm run build
Summary: ✅ All passed → ready to commit | ❌ Failed → show failures, fix, re-run

Mehr aus diesem Repository

gleiches Repository

pull-request

pierreb-devkit/Vue

Use this whenever the user asks to "open a PR", "ship this", "create the pull request", "make a PR", or once a Vue feature/fix is verified and ready to push. Full lifecycle: branch → commit (commitizen) → issue → draft PR → CI → ready → autonomous monitor loop (fix comments, resolve threads, iterate until CI green + zero unresolved threads). `--perfect` adds a CodeRabbit convergence loop on top. Never works on `main`/`master`, never uses `--no-verify`.

2026-07-1720

pierreb-devkit/Vue

Design system reference for the Devkit Vue stack (Vuetify 4 + custom theme helpers). Use when asked about styling, theming, layout, design system, Vuetify components, visual verification, or UI patterns. Automatically consumed by /feature when the task has a visual component. Can also be invoked directly for design-only tasks (restyle, theme change, layout fix).

2026-07-1620

feature

pierreb-devkit/Vue

Use this whenever the user asks to "implement", "add", "build", "create", or "modify" a feature, page, view, component, or module in this Vue project. Three phases: Phase 0 scope analysis (flows + edge cases + UI needs + plan validation, STOP for user), Phase 1 implementation (layered UI → Store → API, Vue 3 Composition + Vuetify 4, /ui design rules), Phase 2 Definition-of-Done checklist + /verify + /pull-request. Auto-runs /create-module if the target module doesn't exist.

2026-07-1620

update-stack

pierreb-devkit/Vue

Use this whenever a downstream Vue project needs to absorb upstream Devkit Vue changes — triggers on "update stack", "sync with devkit", "merge upstream", "pull stack updates", "resolve stack conflicts". Two-phase: ISO merge (stack modules stay byte-identical to upstream) then project alignment (apply MIGRATIONS.md, diff project modules vs `tasks` reference, /verify). Stack-code failures get an issue on `pierreb-devkit/Vue`.

2026-06-1620

naming

pierreb-devkit/Vue

Use this whenever a new file/folder is created or renamed in this Vue project, when reviewing a module for consistency, or when the right path for a file is unclear. Also triggers on "what should I name this?", "is this file named correctly?", "audit module naming". Enforces kebab-case folders, dot-prefixed `{module}.{name}.{type}.vue|js` files, multi-entity rules, singular vs plural for views, and the layered structure UI → Store → API.

2026-04-1720

create-module

pierreb-devkit/Vue

Use this whenever the user asks to "create a module", "scaffold a feature", "add a Vue domain", "new module called X", or starts work on a brand-new vertical (views + components + store + router entry + tests). Duplicates the canonical `src/modules/tasks` template, applies kebab/Pascal/camel/ UPPER renames, and wires config-driven values. Module stays self-contained.

2026-04-1720

name

verify

description

Verify Skill

Steps

Diff audit — review all changes (git diff master...HEAD or staged changes) using your knowledge of the stack:
- Read CLAUDE.md and ERRORS.md for conventions, architecture, and known pitfalls
- Read the tasks reference module structure for layer/naming conventions
- Check /ui skill for design system and Vuetify conventions
- Analyze the diff: architecture, security, UX, logic, consistency, error handling
- No hardcoded checklist — reason from context. Examples of what to catch:
  - Router guards with permissive matching (startsWith vs exact)
  - Silent error swallowing (catch without user feedback)
  - Store mutations from outside the store
  - Cross-module store imports (only useAuthStore/useCoreStore allowed)
  - Missing form validation or confirmation dialogs on destructive actions
  - Inconsistent selectors in E2E tests (prefer getByRole/getByPlaceholder)
  - Broken or nonexistent route references
  - Store-contract tests that only assert a mock was called, not the resulting store state (interaction-only assertions let a dropped field slip through)
- Fix all issues found before proceeding
Lint — npm run lint
Tests + coverage — check if Node API is reachable (curl -sf http://localhost:3000/api/home):
- Infra up → npm run test:coverage (unit + coverage enforcement) then npm run test:e2e (Playwright E2E)
- Infra down → npm run test:coverage (unit + coverage) + warn: "E2E skipped — run docker compose -f docker-compose.test.yml up -d for full coverage"
- If coverage drops below thresholds (vitest.config.js) → fail. Add tests, never lower thresholds.
Build — npm run build
Summary: ✅ All passed → ready to commit | ❌ Failed → show failures, fix, re-run