KodekaTeam

Design, implement, or assess project structure, module ownership, dependency boundaries, and safe file or folder organization. Use when project architecture, feature placement, separation of responsibilities, or architectural refactoring is a primary concern, including new framework projects. For a read-only assessment, do not modify files unless the user also requests changes; do not activate merely because ordinary feature work adds a file.

日本語の概要は準備中です。原文の説明を表示しています。

Add, revise, or remove source-code comments while preserving executable behavior. Use for comment-only cleanup, documentation comments, TODO quality, and reducing narration. Do not use when the requested change modifies logic.

日本語の概要は準備中です。原文の説明を表示しています。

Write or revise user-facing product and marketing copy with a specific voice, verifiable claims, natural rhythm, and useful actions. Use for interface labels, onboarding, landing pages, help text, and product messaging. Do not use for code comments or neutral technical documentation unless tone editing is requested.

日本語の概要は準備中です。原文の説明を表示しています。

Design, implement, review, or repair CI/CD pipelines, release artifacts, environment promotion, deployment rollout, verification, and rollback workflows. Use when software delivery or release safety is a primary part of the task. Do not use merely to run an existing local build or to deploy without explicit authorization for the target environment.

日本語の概要は準備中です。原文の説明を表示しています。

Simplify coding implementations and reviews by reusing existing capabilities and removing unjustified abstractions, dependencies, configuration, and duplication. Use when implementation complexity or over-engineering is in scope. Do not use to weaken required behavior, safety, accessibility, or compatibility.

日本語の概要は準備中です。原文の説明を表示しています。

Investigate, optimize, or review software performance using representative measurements, profiles, budgets, and regression evidence. Use when latency, throughput, resource use, loading, rendering, bundle cost, or scalability is a primary concern. Do not use for speculative micro-optimization without a symptom, target, or demonstrated bottleneck.

日本語の概要は準備中です。原文の説明を表示しています。

Design, implement, review, or improve operational reliability through service objectives, failure isolation, graceful degradation, recovery, observability, and incident readiness. Use when availability, resilience, dependency failure, disaster recovery, or operability is a primary concern. Do not use for ordinary error handling, a single unexplained bug, or speculative distributed-systems machinery.

日本語の概要は準備中です。原文の説明を表示しています。

Design, implement, or repair responsive web and app layouts across narrow, wide, zoomed, and touch-oriented viewports. Use for mobile and desktop composition variants, reflow, overflow, adaptive navigation, content-driven breakpoints, and mobile interaction layout. Do not use for purely visual styling with no responsive impact.

日本語の概要は準備中です。原文の説明を表示しています。

Design, implement, repair, or review automated tests for observable behavior, regressions, contracts, stateful boundaries, and flaky failures. Use when testing is a primary part of the request or when choosing test levels, isolation, fixtures, or reliability requires dedicated judgment. Do not use merely to run existing checks after an ordinary implementation.

日本語の概要は準備中です。原文の説明を表示しています。

Perform a read-only audit of an existing product interface, prove UI findings from governing design evidence and runtime paths, and prepare implementation-ready recommendations or plans. Use for review and design-system drift analysis; do not use when the user asks to implement fixes directly.

日本語の概要は準備中です。原文の説明を表示しています。

Build, redesign, or visually refine product interfaces using project evidence, real content, functional states, and deliberate composition. Use for implementation work on websites, apps, dashboards, landing pages, or component systems. Do not use for read-only audits or logic-only changes.

日本語の概要は準備中です。原文の説明を表示しています。

Design, implement, review, or repair database schemas, queries, indexes, transactions, migrations, and backfills with explicit integrity and rollout constraints. Use when the datastore behavior or data lifecycle is a primary part of the task. Do not use for routine persistence calls whose schema and consistency contracts are unchanged.

日本語の概要は準備中です。原文の説明を表示しています。

Diagnose and repair reproducible, intermittent, environment-specific, or production-observed software failures by tracing evidence to a root cause. Use when a symptom exists but its cause is uncertain or when a proposed fix needs causal validation. Do not use for feature implementation, speculative cleanup, or a general review without a concrete failure.

日本語の概要は準備中です。原文の説明を表示しています。

Create, reconstruct, synchronize, or automatically record durable repository documentation and curated implementation memory from current code, configuration, tests, accepted user intent, existing docs, and Git history. Use for project context, architecture, decisions, implementation change records, timelines, build and distribution guides, maintenance handoffs, or cross-session continuity. After verified material implementation work, record the outcome by default unless the user explicitly opts out. Do not use for incidental comments, raw prompt archiving, or non-material edits.

日本語の概要は準備中です。原文の説明を表示しています。

Design or review product experiences through user goals, journeys, information architecture, task flows, interaction models, feedback, recovery, and cross-screen continuity. Use when the primary question is how users understand and complete a goal across steps or surfaces. Do not use for visual styling, implementation-only logic, or unsupported user-research claims.

日本語の概要は準備中です。原文の説明を表示しています。

Review or implement interface accessibility for semantics, keyboard operation, focus, contrast, status communication, zoom, and assistive technology. Use when accessibility is explicitly requested, required by the product contract, or a changed interaction creates substantial accessibility risk. Do not activate for every visual edit or use it as a generic design audit.

日本語の概要は準備中です。原文の説明を表示しています。

Review a code change, diff, commit, branch, or pull request for actionable defects, regressions, security risks, compatibility breaks, and missing verification. Use when code review is the primary requested outcome. Keep the review read-only unless the user explicitly asks to implement fixes; do not use as a substitute for implementation or a specialized visual audit.

日本語の概要は準備中です。原文の説明を表示しています。

Implement, harden, or review defensive security controls for REST APIs, including authentication and authorization boundaries, validation, rate limiting, abuse prevention, resource limits, SSRF defenses, safe errors, logging, and security tests. Use when API security, endpoint hardening, threat review, rate limiting, token handling, or sensitive business-flow protection is an explicit concern. Do not use for ordinary endpoint logic without meaningful security scope or for offensive exploitation.

日本語の概要は準備中です。原文の説明を表示しています。

Implement or review application behavior, APIs, state transitions, data flow, and business rules with explicit contracts and failure handling. Use for logic-bearing changes across frontend or backend systems. Do not use for visual-only or copy-only work.

日本語の概要は準備中です。原文の説明を表示しています。