メニュー
Write and apply Conventional Commits — type(scope): subject, imperative mood, with body and BREAKING CHANGE footer when needed. Use when committing staged work or asked to write, review, or standardize a commit message.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Build inclusive, WCAG-compliant UIs. Use for a11y, screen readers, ARIA, keyboard nav, contrast, or accessibility audits.
Analyze a codebase and generate Project_Architecture_Blueprint.md — detected stacks and architecture patterns, diagrams, layers, cross-cutting concerns, extension guidance. Use to document, map, or blueprint a project's architecture or keep it consistent.
Continuous backend delivery loop — cycles subagents through test → diagnose → fix → review → secure → re-test until the suite, quality, and security gates are clean. Use to develop, fix, harden, or finish a backend feature/service/endpoint.
Design backend systems — REST/GraphQL/gRPC APIs, microservices, database schemas, auth, caching, message queues, scalability. Use when designing backend services, APIs, data models, distributed systems, or auth flows.
Shared backend guide for Langfuse's Next.js/tRPC/BullMQ/TypeScript monorepo — tRPC routers, public REST endpoints, BullMQ processors, services, Prisma/ClickHouse access, Zod validation, and backend tests across web/worker/shared.
Turn backend test ambiguity into one practical test packet — API/service/repo/auth coverage, fixture & seed/reset strategy, mock-vs-container choices, contract checks, and flaky-suite stabilization across local and CI.
| name | conventional-commit |
| description | Write and apply Conventional Commits — type(scope): subject, imperative mood, with body and BREAKING CHANGE footer when needed. Use when committing staged work or asked to write, review, or standardize a commit message. |
Produce commit messages that follow the
Conventional Commits specification:
type(scope): description.
git status to review changed files.git diff (or git diff --cached) to inspect the changes — the message must describe
what the diff actually does.git add <file>.git commit -m "type(scope): description" (multi-line body/footer when needed).type(scope): description
[optional body — the why and any context the diff doesn't show]
[optional footer — BREAKING CHANGE: details, or issue references]
feat, fix, docs, style, refactor, perf, test, build, ci,
chore, revert. Append ! for breaking changes (feat!:).auth, parser, ui).BREAKING CHANGE: <details> and/or issue references (Closes #123).feat(parser): add ability to parse arrays
fix(ui): correct button alignment
docs: update README with usage instructions
refactor: improve performance of data processing
chore: update dependencies
feat!: send email on registration (BREAKING CHANGE: email service required)
Before committing, check: the type is in the allowed list, the description is imperative and
matches the staged diff, breaking changes carry ! and a BREAKING CHANGE: footer, and the
commit contains only the files of this one logical change (split unrelated changes into
separate commits).