KentoShimizu
@KentoShimizu
Public Skills
ab-testing
by KentoShimizu
"Controlled online experiment workflow for product changes with causal inference, randomization integrity checks, and pre-registered decision criteria. Trigger when ship/no-ship decisions require causal evidence under uncertainty and KPI trade-offs must be quantified. Do not use for feature-flag rollout policy without experiment design, deterministic functional verification, or observability-only analysis."
acceptance-criteria-design
by KentoShimizu
"Design executable acceptance criteria for approved requirements by converting goals/specs into binary pass/fail checks with observable outcomes. Use when implementation handoff, QA validation, or release decisions need testable criteria for stable REQ-/NFR- baselines; do not use for requirement discovery, prioritization, or sprint slicing."
api-design-graphql
by KentoShimizu
GraphQL schema and resolver contract design for type boundaries, nullability, authz, and query-cost safety. Trigger when SDL, resolver behavior, field contracts, or query safety controls are added/changed, and their contract impact is not yet explicitly specified. Do not use for REST/OpenAPI endpoint design, API version lifecycle governance, or standalone error taxonomy design.
accessibility-design
by KentoShimizu
"Accessibility-first design workflow for specifying semantics, keyboard/focus behavior, readability, and assistive-technology expectations. Use when UI accessibility behavior must be defined before implementation or design sign-off; do not use for backend data modeling or deployment pipeline decisions."
api-design-rest
by KentoShimizu
Resource-oriented REST/OpenAPI contract design for URI/method semantics, idempotency, pagination, and HTTP status behavior. Trigger when REST contract diffs are detected in paths, methods, schemas, or status semantics, or when request-response transport choice is still unresolved before implementation. Do not use for GraphQL schema authoring, error-taxonomy-only changes, version lifecycle governance, or consumer-provider contract test implementation.
algorithm-complexity-analysis
by KentoShimizu
"Analyze candidate algorithms for time/space complexity, scalability limits, and resource-budget fit (CPU, memory, I/O, concurrency). Use when feasibility depends on input growth or latency/memory constraints and quantitative bounds are required before implementation; do not use for persistence schema or deployment topology decisions."
algorithm-design
by KentoShimizu
"Design algorithms by modeling constraints, enumerating candidate strategies, proving correctness, and selecting data structures with explicit tradeoffs. Use when implementation success depends on algorithm choice or decomposition under unclear constraints, from vague outcome requests to concrete directives; do not use for persistence schema or deployment topology decisions."
api-error-handling
by KentoShimizu
API failure-contract design for status mapping, stable error codes, retryability semantics, and traceable error payloads across sync and async transports. Trigger when error behavior, retry semantics, or debuggability fields change in specs or source, or when those rules remain implicit. Do not use for full resource/schema modeling or version-channel policy definition.
api-versioning
by KentoShimizu
API version lifecycle governance for breaking-change classification, deprecation windows, migration planning, and support matrix management across internal and external consumers. Trigger when contract diffs may break consumers (for example required-field removal, semantic change, or channel change), when deprecation/sunset planning is required, or when multiple consumer cohorts must be supported in parallel. Do not use for first-pass endpoint/schema design.
api-contract-testing
by KentoShimizu
"Consumer-provider contract testing and release-gate design for compatibility matrices, contract assertions, and CI blocking rules across versions and transports. Trigger when API contract diffs are detected but compatibility evidence is missing or stale (contract test pass, consumer-impact mapping, or compatibility matrix update), or when multiple consumers, versions, or transports must be protected by automated gates. Do not use for first-pass API interface design."
architecture-c4-modeling
by KentoShimizu
"C4 architecture modeling workflow for context, container, and component views that make boundaries and responsibilities explicit. Use when teams need a shared structural model before major implementation or refactoring; do not use as a substitute for decision records."
architecture-clean-architecture
by KentoShimizu
"Clean Architecture workflow for enforcing dependency direction, stable domain boundaries, and use-case-centered application design. Use when teams must separate business rules from frameworks and delivery mechanisms; do not use for isolated module cleanup without boundary implications."
architecture-ddd
by KentoShimizu
"Domain-driven design workflow for bounded context partitioning, aggregate design, and context mapping in complex domains. Use when domain complexity or organizational scaling requires explicit model boundaries; do not use for small CRUD domains without competing language models."
architecture-decision-records
by KentoShimizu
"Architecture Decision Record workflow for capturing technical decisions, alternatives, trade-offs, and revision triggers over time. Use when decisions materially affect system behavior, cost, or team workflow; do not use for trivial implementation choices."
architecture-microservices
by KentoShimizu
"Microservices architecture workflow for service boundary design, independent deployability, and distributed operational safety. Use when domain and team structure justify independent service evolution; do not use as a default scaling strategy for all systems."
chaos-engineering-basics
by KentoShimizu
"Design and execute controlled chaos experiments to validate resilience assumptions with explicit steady-state metrics, blast-radius limits, and abort rules. Use when reliability claims need evidence before wider rollout; do not use for active incident command or postmortem-only reporting."
architecture-monolith
by KentoShimizu
"Modular monolith architecture workflow for strong domain boundaries, transactional consistency, and operational simplicity in a single deployable. Use when teams need fast delivery and coherent data consistency with controlled complexity; do not use when independent runtime scaling boundaries are mandatory."
architecture-event-driven
by KentoShimizu
"Event-driven architecture workflow for asynchronous integration, decoupled workflows, and failure-tolerant event propagation. Use when temporal decoupling and independent evolution are required; do not use when strict synchronous consistency is mandatory across all steps."
ci-cd-pipeline-design
by KentoShimizu
"Design CI/CD pipelines with explicit stage order, quality gates, artifact traceability, and rollback safety. Use when build/test/release flow is being created or changed and teams need deterministic release controls before adoption; do not use for application-domain algorithm or schema design."
csharp-style-guide
by KentoShimizu
"Style, review, and refactoring standards for C#/.NET codebases. Trigger when .cs, .csproj, .sln, .props, .targets, or .razor artifacts are created, modified, or reviewed and C#-specific quality rules (naming, nullability, async patterns, API design consistency) must be enforced. Do not use for Java/Kotlin or JavaScript/TypeScript style concerns unless C# artifacts are also changed. In multi-language pull requests, run together with other applicable *-style-guide skills."
db-physical-design
by KentoShimizu
"Physical database design workflow for storage layout, partitioning, engine settings, and hardware-aware performance behavior. Use when sustained workload efficiency depends on physical data organization; do not use for conceptual modeling tasks."
code-review-general
by KentoShimizu
"Run full-scope code review for correctness, maintainability, and regression risk when no single specialty dominates. Use for broad merge-readiness reviews with explicit findings and evidence; if security or performance risk is primary, prioritize code-review-security or code-review-performance first."
design-review
by KentoShimizu
"Run structured design reviews that produce actionable findings and clear approval decisions. Use when a design artifact needs formal review for usability, accessibility, consistency, and implementation readiness before handoff or approval; do not use for backend data-model or deployment pipeline decisions."
db-query-optimization
by KentoShimizu
"Query optimization workflow for reducing latency and resource cost through plan-aware rewrites and access-path improvements. Use when hot-path query behavior is the bottleneck; do not use for conceptual schema redesign without workload evidence."
code-review-performance
by KentoShimizu
"Run performance-focused code review when changes may affect latency, throughput, or CPU/memory/I/O efficiency on critical paths. Use for merge decisions requiring explicit performance-risk findings; do not use for broad non-performance review scope."
data-structures
by KentoShimizu
"Select data structures using explicit access patterns, mutation behavior, memory limits, and concurrency constraints. Use when implementation correctness or performance depends on choosing between alternatives (array/map/heap/tree/queue/set) under real workload assumptions; do not use for persistence schema or deployment topology decisions."
architecture-principles
by KentoShimizu
"Define architecture principles and review guardrails before choosing monolith, microservices, serverless, or event-driven options. Use when teams need explicit decision criteria; do not use to record final decisions."
design-system-foundations
by KentoShimizu
"Define scalable design-system foundations with clear ownership and adoption boundaries. Use when multiple teams need shared component standards, foundational patterns, and ownership rules to deliver consistent UI across products; do not use for backend data-model or deployment pipeline decisions."
code-review-security
by KentoShimizu
"Run security-focused code review when changes cross trust boundaries or may affect authentication, authorization, input validation, secrets handling, or sensitive-data exposure. Use for merge decisions requiring explicit security findings; do not use for non-security-only review scope."
db-backup-recovery
by KentoShimizu
"Database backup and recovery workflow for defining RPO/RTO-aligned retention, restore strategy, and disaster readiness. Use when data durability and recovery guarantees are in scope; do not use for query-only tuning tasks."
db-replication-sharding
by KentoShimizu
"Replication and sharding workflow for scaling read/write throughput while managing consistency, failover, and data distribution risk. Use when single-node limits are reached or resilience requires topology changes; do not use for local query tuning only."
db-conceptual-modeling
by KentoShimizu
"Conceptual data modeling workflow for domain entities, relationships, and lifecycle boundaries. Use when teams must align on domain meaning before logical/physical schema decisions; do not use for index-only or migration-only tasks."
design-tokens
by KentoShimizu
"Design token architecture workflow for semantic, scalable, implementation-ready token systems. Use when multiple screens or products need consistent color/type/spacing/motion decisions and token definitions before component implementation; do not use for backend data-model or deployment pipeline decisions."
db-index-strategy
by KentoShimizu
"Index strategy workflow for balancing read latency, write amplification, and plan stability on critical query paths. Use when query performance depends on index design trade-offs; do not use for high-level conceptual modeling."
concurrency-patterns
by KentoShimizu
"Design and review concurrency strategy for shared state, coordination, and contention control. Use when parallel execution or async coordination introduces race/deadlock/liveness risk and explicit pattern selection is required; do not use for persistence schema or deployment topology decisions."
db-transaction-design
by KentoShimizu
"Transaction design workflow for boundary definition, isolation-level choice, and contention control under real workload behavior. Use when correctness depends on concurrent read/write semantics; do not use for schema-only tasks that do not affect transaction behavior."
architecture-serverless
by KentoShimizu
"Serverless architecture workflow for event-driven and bursty workloads using managed compute and platform services. Use when elasticity and reduced platform operations justify managed-service constraints; do not use when workload shape requires long-lived stateful control loops."
db-logical-design
by KentoShimizu
"Logical database design workflow for table structure, key strategy, constraints, and relational consistency. Use when durable schema semantics must be defined before physical tuning; do not use for query-only optimization tasks."
cost-optimization-cloud
by KentoShimizu
"Optimize cloud spend with explicit tradeoffs across cost, performance, and reliability. Use when spend or forecast misses budget targets and teams need concrete optimization actions without violating SLOs or compliance constraints; do not use for purely functional product behavior design."
distributed-consensus
by KentoShimizu
"Consensus workflow for quorum, leader election, commit semantics, and membership change safety. Use when replicated-state correctness requires coordinated agreement across nodes under faults; do not use for non-replicated single-node workflows."
deployment-strategy-blue-green
by KentoShimizu
"Design blue-green deployment strategy with explicit cutover checks, rollback triggers, and state/data compatibility safeguards. Use when release risk requires fast rollback and environment-level switch control; do not use for canary-percentage experimentation policy design."
architecture-tradeoff-analysis
by KentoShimizu
"Architecture trade-off analysis workflow for comparing options with explicit criteria, weighting, and sensitivity under uncertainty. Use when multiple viable architecture choices exist and rationale must be defensible; do not use after architecture direction is already fixed."
db-migration-strategy
by KentoShimizu
"Schema migration strategy workflow for sequencing changes, compatibility windows, and rollback-safe rollout in live systems. Use when schema evolution impacts running services; do not use for static greenfield schemas without deployment constraints."
distributed-systems-basics
by KentoShimizu
"Distributed-systems workflow for failure-mode analysis, consistency choices, and reliability primitive selection across networked components. Use when correctness depends on partitions, retries, timeouts, ordering, or partial failures; do not use for single-process implementation details only."
db-normalization
by KentoShimizu
"Normalization workflow for reducing update anomalies while balancing query practicality and domain invariants. Use when schema redundancy and inconsistency risk need deliberate trade-off decisions; do not use for physical indexing-only tasks."
bash-style-guide
by KentoShimizu
"Style, review, and refactoring standards for Bash shell scripting. Trigger when .sh files, files with #!/usr/bin/env bash or #!/bin/bash, or CI workflow blocks with shell: bash are created, modified, or reviewed and Bash-specific quality controls (quoting safety, error handling, portability, readability) must be enforced. Do not use for generic POSIX sh, PowerShell, or language-specific application style rules. In multi-language pull requests, run together with other applicable *-style-guide skills."
deployment-strategy-canary
by KentoShimizu
"Design canary rollout strategy with progressive traffic steps, guardrail metrics, and automated stop/rollback decisions. Use when releases need incremental risk containment and evidence-based promotion gates; do not use for full-environment cutover planning where blue-green is required."
django-app-development
by KentoShimizu
"Django application development workflow for production-grade app changes. Use when Django-specific code (models, views, serializers/forms, routing, settings, middleware, auth flows) must be implemented or revised with framework runtime behavior in scope; do not use for repository-wide architecture governance or release management policy."
design-principles
by KentoShimizu
"Define and align product design principles that teams can apply consistently across UX decisions. Use when product or UX direction is ambiguous and teams need explicit decision guardrails before detailed screens or components are produced; do not use for backend data-model or deployment pipeline decisions."
design-qa-implementation-parity
by KentoShimizu
"Verify implementation parity against approved design specs with severity-based decisions and fix guidance. Use when implemented UI must be compared against approved specs before release or sign-off; do not use for backend data-model or deployment pipeline decisions."