
Use this skill whenever the user needs to scaffold a new REST endpoint or API resource from an OpenAPI 3.1 spec in a Spring Boot 4 project — generating controller + service + repository + DTOs + MapStruct mappers + validation + exception handling + OpenAPI spec in one shot. ALWAYS trigger on: "create endpoint", "add API", "new REST endpoint", "scaffold controller", "API from OpenAPI", "generate controller", "implement API endpoint", "add CRUD endpoint", "create resource". Implicit triggers: user pastes an OpenAPI snippet and asks to "implement it", user describes a new resource with CRUD operations, user mentions REST verbs (POST/GET/PUT/PATCH/DELETE) on a noun resource, user asks for "the endpoint for X". Complements the thinner `api-design` skill which is planning-only — this one writes code. Stack: Java 25 + Spring Boot 4 + Spring Data JDBC (primary) or Spring Data JPA (legacy) + MapStruct 1.6+ + Jakarta Validation + SpringDoc OpenAPI. Encodes the user's API conventions: RFC 9457 Problem Details for errors, response envelope `{data, meta}`, cursor pagination, Idempotency-Key on POST, X-RateLimit-* headers, UUID v7 IDs, ISO 8601 timestamps, money as `{amount: "150.00", currency: "USD"}` string, kebab-case plural resource paths (`/api/v1/payment-links`). Produces compilable code, Testcontainers integration tests, OpenAPI 3.1 spec file, and controller-level slice tests via `@WebMvcTest`.
Use this skill whenever a user provides a specification document (PRD, BRD, API spec, user story, system design doc, ANALYSIS.md, PANEL_ANALYSIS.md, or any structured requirements doc) and wants it broken down and implemented end-to-end into multiple output artifacts. ALWAYS use this skill when the user pastes a PRD/spec and says "implement", "build", "turn this into code", or provides a file path ending in spec/prd/analysis/brd. Primary trigger phrases: "implement this spec", "build this from the PRD", "turn this spec into code", "generate artifacts from this document", "implement this end-to-end", "break this spec into tasks", "implement 1 to N from this doc", "plan and implement from spec", "ship this feature", "build the feature described in", "make this real". Implicit triggers (even without the word "spec"): user pastes a multi-section markdown document with "Requirements", "User Stories", "API endpoints", "Data model" sections; user says "here's the PRD" followed by a link; user asks for code AND tests AND migrations AND API docs in one shot; user mentions multiple output artifacts (code + tests + schema + docs); user wants multi-role task assignment, implementation tracking, or progress reporting across a complex deliverable. This skill orchestrates a specialized sub-agent team (ARCH, DESIGN, BE, FE, FLUTTER, RN, ANDROID, QA, DBA, DEVOPS, SEC, OBS, TECH_WRITER) in parallel waves to compress execution time, with progressive disclosure via agents/ and references/ files. Stack defaults are Java 25 + Spring Boot 4.x + Spring Modulith + Spring Data JDBC + Gradle (or Maven) on the backend and React 19 + Next.js 15 + TypeScript 5 + Tailwind 4 on the web frontend. The skill auto-detects deviations and adapts. It understands fintech patterns (double-entry ledger, SAGA compensation, idempotency, multi-tenancy with PostgreSQL RLS), iGaming patterns (wallet flows, live odds, provider integration), and infrastructure patterns (Temporal workflows, Liquibase/Flyway migrations, Testcontainers, OpenTelemetry observability). Also triggers when a Figma design link or selection is provided alongside a spec — the DESIGN agent extracts Figma context via the MCP server and feeds it to the FE agent. When a handoff artifact from /figma:figma-generate-design is present, the FE agent consumes Figma file keys, node IDs, component maps, and variable bindings directly. Additional Figma trigger phrases: "implement this spec with the Figma designs", "build from PRD and Figma", "use Figma designs from this spec", "the designs are in Figma at [link]", "implement with design context from Figma", "spec plus Figma", "PRD with designs".
--- name: runbook description: Generate an operational runbook for a service or system covering deployment, scaling, failure recovery, and common operations. Triggers: "runbook", "operations guide", "how to deploy", "on-call guide", "playbook". argument-hint: "[service / system]" effort: medium --- # Runbook ## What I'll do Produce an operational runbook that an on-call engineer can follow at 3am to deploy, scale, debug, and recover the service without needing to read the source code. ## Inpu
--- name: ticket-breakdown description: Break a PRD or design doc into epics and engineering tickets with acceptance criteria, dependencies, sequencing, and rollout steps. Triggers: "break this into tickets", "work breakdown", "engineering plan", "Jira tickets", "Linear issues". argument-hint: "[PRD / design doc link or text]" effort: medium --- # Ticket breakdown ## Goal Turn a spec into implementable work items that can be assigned, tracked, and shipped safely. ## What I'll do - Identify th
--- name: ux-review description: Evaluate a UI/UX design or implementation using heuristic analysis, accessibility audit, and cognitive walkthrough. Triggers: "UX review", "usability review", "heuristic evaluation", "accessibility audit", "is this usable". argument-hint: "[feature / screen / URL / mockup]" effort: high --- # UX review ## What I'll do Evaluate a design or implementation for usability, accessibility, and user experience quality using established heuristic frameworks. ## Inputs
--- name: opportunity-assessment description: Evaluate whether a feature or product idea is worth building through cost/benefit analysis, risk assessment, strategic alignment, and effort estimation. Triggers: "should we build this", "opportunity assessment", "cost benefit", "is this worth it", "prioritization". argument-hint: "[feature idea / proposal]" effort: high --- # Opportunity assessment ## What I'll do Produce a structured assessment of whether an opportunity is worth pursuing, how it
Use this skill whenever the user needs to create a database migration — new table, add column, add index, backfill data, rename column, drop a column, or change a constraint — for PostgreSQL projects using Liquibase or Flyway. ALWAYS trigger on: "migration", "new table", "schema change", "add column", "alter table", "add index", "create index", "drop column", "rename column", "backfill", "liquibase", "flyway", "db changeset", "schema evolution", "changelog". Implicit triggers: user describes a new entity that needs persistence, user adds a field to an existing entity (needs matching migration), user talks about a one-time data fix, user asks about zero-downtime migrations, user mentions PostgreSQL `CONCURRENTLY`, user wants to add a foreign key, user asks to normalize or denormalize a table. Auto-detects mode: **Liquibase** (Kifiya monorepo, `db/changelog/changes/sql/*.sql` with `--liquibase formatted sql` header) or **Flyway 10+** (new projects, `V{yyyyMMddHHmmss}__{snake_case}.sql`). Encodes user conventions: naming, audit columns (`created_by`, `created_at TIMESTAMPTZ DEFAULT now()`, `last_modified_by`, `updated_at`), BigInt PKs with application-generated TSIDs, `NUMERIC(20,2)` for fiat money, `NUMERIC(20,8)` for crypto, explicit rollback on every changeset, safety rules (never DROP without confirmation, always CONCURRENTLY for index on populated tables, always ON CONFLICT DO NOTHING for seeds). Produces the migration file, a matching verification query, and a rollback test.
Default-to-rejection quality gate. Assumes NEEDS WORK until overwhelming evidence proves otherwise. Requires actual test output, screenshots, build logs — not claims. Triggers: "evidence review", "prove it works", "show me proof", "quality gate", "final review".
Use this skill whenever the user asks for an architectural review of existing code — checking clean architecture boundaries, dependency direction, transaction boundaries, business logic leakage, circuit breaker presence, and value-object/primitive discipline in a Java + Spring Boot + Modulith codebase. ALWAYS trigger on: "review architecture", "arch review", "clean architecture check", "is this well structured", "check module boundaries", "check dependencies", "dependency direction", "domain leakage", "does this follow clean architecture", "check the hexagonal", "ports and adapters check". Implicit triggers: user shows a controller with business logic inline, user shows an entity exposed directly from a REST response, user mentions "this feels messy", user asks about coupling between modules, user wants to know if a refactor is worthwhile. Complements `code-audit` (which is breadth-first code quality) by being a focused architectural-invariants check. Stack: Java 25 + Spring Boot 4 + Spring Modulith 2.x + Spring Data JDBC/JPA. Produces a findings report with severity, affected files, proposed fixes, and a dependency direction graph. Uses ArchUnit assertions where possible for machine-checkable invariants, otherwise file-by-file analysis. Can run in "report-only" mode (default) or "fix-plan" mode (generates a ticket-breakdown handoff for remediation).
Use this skill whenever existing implementation code needs a rigorous multi-dimensional review — covering code smells, SOLID violations, duplication, algorithm efficiency, security, performance, design pattern fitness, architecture conformance, technology fitness, and a devil's advocate challenge. ALWAYS trigger on: "code audit", "code review", "review this code", "code quality", "code smells", "design patterns review", "architecture review", "is this code good", "review the implementation", "audit this module", "quality check", "assess this codebase". Implicit triggers: user asks whether code is "production-ready", user wants a second opinion on a module, user suspects tech debt but wants specifics, user is onboarding and wants a map of problem areas, user needs evidence for a refactoring ticket. Orchestrates a multi-agent expert panel with model routing (opus for LEAD/ARCH/SEC/SKEPTIC, sonnet for SMELL/DUP/ALGO/PERF/PATTERN/TECH). Reviews **code that exists** — for reviewing **specs before implementation**, use `/spec-panel` instead. Produces a findings report with severity ratings, a quality scorecard, and an ordered improvement roadmap. Does NOT modify code inline — findings route through the fix workflow (systematic-debugging → writing-plans → code-generator skill → requesting-code-review).
--- name: decision-matrix description: Structure a decision with weighted criteria, options evaluation, and clear recommendation. For technical, product, or strategic choices. Triggers: "decision matrix", "help me decide", "compare options", "which should we choose", "trade-off analysis". argument-hint: "[decision to make]" effort: medium --- # Decision matrix ## What I'll do Structure a complex decision into a weighted evaluation framework that makes trade-offs explicit and produces a defensi
Inter-skill artifact protocol. Defines how skills discover and consume prior skill outputs, handle multi-artifact handoffs, track artifact lifecycle, and clean up after consumption. Not a slash command — loaded automatically to enable skill chaining.
--- name: onboarding-doc description: Generate a new team member onboarding guide for a service, domain, or codebase. Covers architecture, key workflows, local setup, and tribal knowledge. Triggers: "onboarding doc", "onboarding guide", "new hire guide", "getting started", "team wiki". argument-hint: "[service / domain / team]" effort: medium --- # Onboarding doc ## What I'll do Produce an onboarding guide that gets a new team member productive in the shortest time possible, capturing the trib
Use this skill whenever a specification, PRD, BRD, design doc, or RFC needs rigorous multi-expert review BEFORE implementation begins. ALWAYS trigger on: "spec panel", "expert review", "panel analysis", "spec analysis", "expert panel review", "review this spec", "audit the PRD", "spec quality check", "is this spec complete", "IEEE 830 audit", "spec smells", "devil's advocate on this spec", "review before we build". Implicit triggers: user pastes a PRD/BRD/spec and asks "what do you think", "any gaps", "is this ready to build", "should we implement this", "am I missing anything"; user wants a second opinion before committing engineering effort; user is deciding whether to proceed to spec-to-impl; user mentions specific concerns about requirements quality, ambiguity, or feasibility; user shows a spec with TBDs, "handle this somehow", or other vague language. Produces a structured findings report with IEEE 830 quality scoring (8 attributes), a spec-smells scan for red-flag language, a cross-cutting concerns checklist (security, performance, observability, compliance), and a multi-expert panel critique with a devil's advocate. Combines codebase investigation, internet research, and domain expertise. This is the gate BEFORE `spec-to-impl` — run this when the spec is drafted but not yet being implemented. Does NOT write code. Does NOT modify the spec in place — produces a separate analysis report that feeds `spec-update` (for spec rewrites) or `spec-to-impl` (for implementation).
--- name: prd description: Write or update a Product Requirements Document. Supports both creating new PRDs from scratch and surgically updating existing PRDs to match implementation changes. Triggers: "write a PRD", "update the PRD", "requirements", "feature brief", "product spec". argument-hint: "[feature / problem / path-to-existing-prd]" effort: high --- # PRD ## What I'll do Turn a rough idea into a clear PRD — or update an existing PRD to reflect design decisions and implementation chang
Design search infrastructure with Elasticsearch and Typesense: index design, mapping, analyzers, relevance tuning, autocomplete, faceting, and sync from source of truth. Triggers: "search design", "elasticsearch", "typesense", "search relevance", "autocomplete", "full-text search".
Use this skill whenever you need to audit or upgrade a custom skill's integration with the superpowers plugin workflow. ALWAYS trigger on: "integrate with superpowers", "upgrade skill integration", "audit my skill", "add superpowers workflow to X", "make this skill superpowers-aware", "check skill integration", "re-sync superpowers workflow", "refresh superpowers integration", "superpowers compliance check". Implicit triggers: user just created a new custom skill and wants it aligned with the superpowers development workflow; user wants to know whether an existing skill correctly routes through brainstorming/plans/TDD/verification/review; superpowers ships a new skill and existing custom skills need re-audit; user is maintaining a skills pack and wants a single source of truth for integration patterns. This is a META-skill: it reads other skills' SKILL.md files and produces either a findings report or an applied upgrade. It does NOT generate domain code. It is IDEMPOTENT — safe to re-run against the same skill at any time. The taxonomy (`references/skill-class-taxonomy.md`) and block templates (`templates/blocks.md`) are the single source of truth for "how custom skills integrate with superpowers". When superpowers adds a new skill, the user's learned a better pattern, or the skill has drifted, update the source-of-truth files and re-run this integrator against every custom skill — one command, full pack re-synced.
Use this skill to produce complete UI/UX design artifacts from a specification document or panel analysis. Triggers include: "design the UI for this spec", "create wireframes", "design this panel", "UX design from spec", "generate component specs", "design tokens", "create the UI design for", "design system for", "wireframe this feature", "design a UI", "create a design system", "design this component", "design the layout", "create a style guide", "design a screen", "UI/UX review", "typography system", "color system", "spacing system", "design this feature", "design the dashboard", "design the onboarding", "create a component library", "design review", "audit the design", "improve the UI", "redesign this", "design system documentation", "create design guidelines", "responsive design", "mobile design", "dark mode design", "design the brand", or any time a spec/panel analysis document needs to be transformed into actionable UI/UX deliverables before implementation. Also triggers for standalone design system creation, component design, design reviews, dark mode/responsive variants, and developer handoff — even before code is involved. Orchestrates a multi-agent design team (UX Lead, UI Designer, Component Architect, Accessibility Reviewer, Design System Engineer, Design Reviewer) in parallel waves. Outputs feed directly into spec-to-impl's FE agent and figma-to-code.
--- name: adr description: Write an Architecture Decision Record (ADR) capturing context, decision, alternatives, and consequences. Triggers: "ADR", "decision record", "why did we choose", "architecture decision". argument-hint: "[decision title]" effort: high --- # ADR (Architecture Decision Record) ## What I'll do Capture an architectural decision so future readers understand *why* the choice was made, what alternatives existed, and what trade-offs were accepted. ## When to write an ADR - C
--- name: api-design description: Design or review an API for consistency, usability, error handling, versioning, pagination, and developer experience. Covers REST, GraphQL, and RPC patterns. Triggers: "API design", "endpoint design", "API review", "REST API", "GraphQL schema". argument-hint: "[API / endpoint / service]" effort: high --- # API design ## What I'll do Design a clear, consistent API (or review an existing one) that's easy for consumers to use correctly and hard to use incorrectly
--- name: competitive-analysis description: Analyze competitors and market positioning with structured feature comparison, strength/weakness assessment, and strategic differentiation opportunities. Triggers: "competitive analysis", "competitor review", "market landscape", "who else does this". argument-hint: "[product / market / feature area]" effort: high --- # Competitive analysis ## What I'll do Produce a structured competitive landscape analysis that identifies key players, compares capabi
--- name: experiment-design description: Design an experiment (A/B test) or staged rollout for a product change: hypothesis, metrics, guardrails, segments, exposure, duration, instrumentation, and decision rule. Triggers: "A/B test", "experiment", "feature flag rollout", "measure impact". argument-hint: "[feature]" effort: high --- # Experiment design ## What I'll produce An experiment plan that's implementable by engineering and interpretable by product/data. ## Inputs I'll use (ask only if
Design data layer across PostgreSQL, MongoDB, Elasticsearch, and Typesense. Covers schema design, indexing, migrations, query patterns, consistency, and cross-store sync. Triggers: "data design", "database design", "schema design", "data model", "data architecture".
--- name: debug-triage description: Triage a bug or production issue into a clear investigation plan: reproduction, hypotheses, logs/metrics to check, bisection strategy, and a minimal safe fix. Triggers: "bug triage", "debug this", "investigate issue", "production bug". argument-hint: "[bug report / error message]" effort: high --- # Debug triage ## Inputs - Bug report / user steps / screenshots (if any) - Error messages or stack traces - Environment (prod/staging/local), version, feature fla
--- name: design-doc description: Create or review a system design doc / RFC for a feature: requirements, constraints, architecture, data model, APIs, rollout, risks, and test plan. Triggers: "design doc", "RFC", "system design", "architecture plan". argument-hint: "[feature name]" effort: high --- # Design doc (RFC) ## How to use - If you say: "Write a design doc for ___", produce a complete doc using the template in `templates/design-doc.md`. - If you give an existing doc, review it and prop
--- name: docs-review description: Review documentation for clarity, correctness, structure, and consistency. Produces actionable edits and a checklist. Triggers: "review docs", "edit this doc", "make this clearer", "docs quality". argument-hint: "[file path | doc text]" effort: medium --- # Docs review ## What I optimize for - Clear audience and purpose - Skimmability (headings, bullets, examples) - Correctness and completeness - Consistent terminology and voice ## How I'll think about this
Post-implementation completion workflow: lint, test, clean up, commit, and create PR. Triggers: "finalize", "commit this", "wrap up", "create PR", "ship it", "done implementing".
Use this skill whenever the user needs to design or implement double-entry ledger operations, wallet movements, balance tracking, or reconciliation for a fintech system. ALWAYS trigger on: "ledger", "double-entry", "debit credit", "wallet operation", "post to ledger", "ledger entry", "balance check", "reconciliation", "hold release", "capture funds", "refund capture", "multi-currency ledger", "fx conversion", "pgledger", "blnk", "ledger_accounts", "ledger_transfers", "ledger_postings". Implicit triggers: user describes money moving between two places (user wallet → merchant wallet, customer → escrow), user mentions "wallet credit" or "wallet debit", user talks about float management, user wants idempotent payment operations, user mentions remittance/payout/collection/settlement, user asks about balance invariants or "balance mismatch". Supports two modes: **Blnk** (Onbilia remittance — uses Blnk Finance engine with HTTP API) and **pgledger** (PayserFlow — pure PostgreSQL implementation with advisory locks, materialized balances, append-only triggers). Auto-detects which mode to use from the project (checks dependencies, configuration, existing tables). Encodes user patterns: posting rules (hold → settle → release / hold → reverse / authorize → capture → refund), idempotency keys on all postings, multi-currency support with FX rate snapshots, sorted account locking to prevent deadlocks, reconciliation hooks (expected vs actual), audit trail via domain events. Generates Java/Spring Boot code (services, DTOs, Liquibase migrations), test fixtures, and reconciliation queries.
Map ALL system paths before writing code: happy paths, validation failures, auth failures, network errors, concurrency conflicts, and recovery paths. Every path becomes a test case. Triggers: "flow map", "map the flows", "what are all the paths", "state diagram", "path mapping".
--- name: go-to-market description: Plan a product or feature launch with messaging, channels, enablement, success criteria, and timeline. Triggers: "go to market", "GTM", "launch plan", "product launch", "feature launch". argument-hint: "[product / feature]" effort: high --- # Go-to-market plan ## What I'll do Produce a launch plan that coordinates messaging, channels, enablement, and measurement so the product reaches users effectively. ## Inputs I'll use (ask only if missing) - What's laun
--- name: incident-response description: Run an incident response workflow: stabilize service, gather facts, assign roles, produce status updates, and track mitigations and follow-ups. Triggers: "incident", "outage", "SEV", "production issue", "status update". argument-hint: "[incident title]" disable-model-invocation: true --- # Incident response ## First priority: stabilize - Stop the bleeding (rollback, disable feature flag, scale, rate limit) - Confirm impact and scope - Preserve evidence
Design infrastructure architecture: Docker containers, Kubernetes orchestration, Terraform IaC, CI/CD pipelines, and deployment strategies. Triggers: "infra design", "infrastructure", "deployment architecture", "k8s design", "terraform", "docker architecture", "CI/CD pipeline".
--- name: linkedin-post description: Draft a LinkedIn post with hook, body, and CTA optimized for engagement and professional credibility. Supports thought leadership, announcements, storytelling, and lessons learned. Triggers: "linkedin post", "linkedin", "linkedin update", "professional post", "thought leadership post". argument-hint: "[topic / announcement / lesson]" --- # LinkedIn post ## What I'll do Produce a publish-ready LinkedIn post that earns attention in the feed, delivers value to
--- name: metrics-review description: Review analytics implementation and data quality for a feature. Covers event taxonomy, data accuracy, instrumentation gaps, and dashboard effectiveness. Triggers: "metrics review", "analytics review", "data quality", "instrumentation check", "are we tracking this right". argument-hint: "[feature / event / dashboard]" effort: medium --- # Metrics review ## What I'll do Audit the analytics instrumentation for a feature to ensure data is accurate, complete, a
--- name: migration-plan description: Plan safe migrations for databases, APIs, data formats, or infrastructure with rollback strategy, validation, and staged execution. Triggers: "migration plan", "database migration", "API migration", "data migration", "schema change". argument-hint: "[what's being migrated]" effort: high --- # Migration plan ## What I'll do Produce a detailed migration plan that moves data, schemas, or systems from state A to state B safely, with rollback capability at ever
Mobile development patterns and guidance for Flutter, React Native, and Android (Kotlin). Covers architecture, state management, navigation, testing, platform channels, and app store readiness. Triggers: "mobile", "flutter", "react native", "android", "ios", "mobile app", "widget test", "app store".
--- name: monitoring-plan description: Design an observability strategy with metrics, alerts, dashboards, SLOs, and on-call response for a service or feature. Triggers: "monitoring plan", "observability", "alerts", "dashboards", "SLO", "on-call". argument-hint: "[service / feature]" effort: high --- # Monitoring plan ## What I'll do Design a comprehensive observability strategy that ensures you know when something is wrong, why it's wrong, and how bad it is — before users tell you. ## Inputs
--- name: performance-review description: Review a feature/PR for performance and reliability risks: budgets, hot paths, query patterns, caching, concurrency, load testing, and monitoring. Triggers: "performance review", "slow", "latency", "throughput", "load test". argument-hint: "[feature / PR]" effort: high --- # Performance review ## What I'll do Produce a practical performance assessment with concrete measurements, identified bottlenecks, and a prioritized optimization plan. ## Inputs I'
--- name: postmortem description: Produce a blameless incident postmortem: timeline, customer impact, root causes, contributing factors, detection gaps, and prioritized action items. Triggers: "postmortem", "RCA", "incident review". argument-hint: "[incident title]" disable-model-invocation: true --- # Postmortem (blameless) ## Inputs - Incident start/end time - Customer impact (who, how, how long) - Symptoms and mitigation steps - Links to dashboards/logs (if available) ## How I'll think abo
--- name: release-notes description: Draft release notes from a set of PRs/commits or a feature description. Produces user-facing notes, internal notes, known issues, and rollout steps. Triggers: "release notes", "changelog", "what shipped". argument-hint: "[version | date range | PR list]" disable-model-invocation: true --- # Release notes ## Inputs - Version number or date range - List of merged PRs or commit range (or a summary of what shipped) - Audience: external users, internal stakehold
--- name: repo-conventions description: Repository-specific engineering conventions: architecture notes, API style, testing approach, and deployment/release norms. Applies automatically when working in this repo. user-invocable: false --- # Repo conventions Update the files in `references/` to match this repository's standards. When working in this repo, follow these rules unless the user explicitly says otherwise: - Prefer existing patterns over introducing new abstractions. - Match naming,
--- name: security-review description: Perform a practical security review (threat-model-lite) for a feature/PR: auth, data access, injection risks, abuse cases, privacy, secrets, logging, and safe defaults. Triggers: "security review", "threat model", "is this safe". argument-hint: "[feature / PR / endpoint]" effort: high --- # Security review (practical) ## What I'll do Produce a lightweight threat model and actionable security findings, prioritized by real-world exploitability. ## Inputs I
--- name: sprint-retro description: Facilitate a sprint retrospective with structured reflection, pattern identification, and actionable improvements. Triggers: "retro", "retrospective", "sprint review", "what went well", "team reflection". argument-hint: "[sprint / iteration / project]" disable-model-invocation: true --- # Sprint retrospective ## What I'll do Facilitate a structured retrospective that surfaces what worked, what didn't, and produces specific action items that actually get done
Use this skill to verify a completed implementation through live testing — API calls, database state checks, and UI automation with Playwright. Triggers include: "test the implementation", "verify this works", "run API tests", "check the database", "test the UI", "end-to-end verify", "smoke test", "sanity check the implementation", "manually test", or any time an implementation needs post-build validation beyond unit tests. Also triggered automatically by spec-to-impl during the integration review phase. Use this when you want real evidence the system works — not just that tests compile. Can consume a pre-generated e2e/test-plan.yaml from spec-to-impl for fully automated test execution.
--- name: stakeholder-update description: Write a structured status update for leadership, cross-functional partners, or investors. Covers progress, risks, decisions needed, and next steps. Triggers: "stakeholder update", "status update", "exec update", "weekly update", "progress report". argument-hint: "[project / initiative / sprint]" disable-model-invocation: true --- # Stakeholder update ## What I'll do Produce a concise, structured status update that gives stakeholders what they need — pr
--- name: tech-debt-assessment description: Inventory and prioritize technical debt by type, cost-of-delay, and strategic impact. Produces an actionable repayment roadmap. Triggers: "tech debt", "technical debt", "code health", "refactoring priorities", "cleanup". argument-hint: "[codebase / area / service]" effort: high --- # Tech debt assessment ## What I'll do Inventory technical debt in a codebase or system, categorize it by type and severity, and produce a prioritized repayment plan based
Use this skill whenever the user needs to design, implement, or review a Temporal.io workflow in Java — especially SAGA compensation chains, long-running orchestrations, config-driven state machines, or multi-step business processes that survive service restarts. ALWAYS trigger when the user mentions: "temporal workflow", "saga", "compensation", "long-running workflow", "state machine workflow", "orchestration", "durable execution", "temporal activity", "workflow retry", "signal handler", "query handler", "workflow versioning", "child workflow", "continue as new". Implicit triggers: user describes a multi-step business process with failure rollback, user wants an idempotent pipeline with retries, user describes "forward execution with compensation on failure", user mentions Kifiya/Onbilia/PayserFlow payment orchestration, user references `io.temporal.workflow.*` imports, user asks how to implement X "that can recover from failure". Stack defaults: Java 25 + Spring Boot 4 + Temporal Java SDK 1.26+ + Gradle (or Maven). Encodes the user's established patterns: config-driven state machines from YAML (reason-codes, transition tables), SAGA with compensation registered BEFORE forward execution, three retry profiles (DEFAULT/LIMITED/AGGRESSIVE), idempotency keys on all activities, workflow/activity separation (workflows are deterministic, activities are idempotent), worker config with task queue routing, signal/query handlers for external inspection. Also produces Spring Boot integration glue (worker beans, activity beans, worker factory), Temporal-specific test setup (TestWorkflowEnvironment), and observability wiring (OpenTelemetry spans across workflow/activity boundaries).
--- name: test-plan description: Create a risk-based test plan for a feature, PR, or release. Includes test strategy, coverage matrix, edge cases, and rollout checks. Triggers: "test plan", "QA plan", "how should we test", "release checklist". argument-hint: "[feature / PR / release]" effort: medium --- # Test plan ## Inputs I'll use - Feature/PR description (or link) - Target platforms (web/iOS/Android/backend) - Risk level and rollout approach (flags, staged release) ## How I'll think about
--- name: user-flow description: Map user journeys through a feature or product, identifying key paths, decision points, friction, error states, and edge cases. Triggers: "user flow", "user journey", "flow diagram", "happy path", "user path". argument-hint: "[feature / user goal]" effort: medium --- # User flow ## What I'll do Map the complete user journey for a feature — from entry point through completion — including happy paths, error states, edge cases, and decision points. > **user-flow