KentoShimizu
@KentoShimizu
Public Skills
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."
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."
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."
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."
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."
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."
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."
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."
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-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."
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.
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."
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."
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."
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."
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."
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."
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."
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.
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."
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."
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."
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."
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."