syakoo-lab

Periodic code health checkup for design drift not caught by CI. Use at version bumps or when asked for a code health check / 健康診断 / 健診. Audits logged advisory deviations and runs a deepen-modules pass.

Perform a project release: bump the semver `version` in package.json, summarize changes since the last release, and hand off to the health-checkup. Use when cutting a release, bumping the project version, or asked to "version up".

Project coding conventions and architecture constraints. Use when implementing, creating, or modifying components and modules (e.g. "create a component", "implement this feature").

Create a PR aligned with the AI-led workflow: summary, design (when relevant), impact and risks. Use when creating a pull request, opening a PR, pushing for review, or completing implementation of an issue.

Triage GitHub PR review feedback (top-level, inline, threads); implement agreed items; escalate disagreements or questions. Includes lint/test checks, per-thread replies with commit SHA, and a chat summary. Use when fixing review feedback on an open PR—not for greenfield implementation only.

Propose codifying reusable lessons from trial-and-error or explicit user requests into lint, rules, or skills. Use near task completion after failed first attempts, or when the user asks to "make it a rule" or "leave a lesson". NOT for empirically testing instructions on fresh agents (tune-prompt) or drafting a new skill without a lesson to codify.

Empirically test skills, rules, or prompts on fresh agents with scored checklists; edit one theme per cycle until instructions land. Use after creating or heavily revising agent instructions, when agents misbehave on those instructions, or when validating that a skill is followed correctly. NOT for codifying runtime lessons after task failures (suggest-improvement) or drafting a new skill without empirical validation.

Read-only review of an open pull request: scope, FSD layout, coding conventions, hygiene, tests, and PR body. Post findings as a GitHub PR comment. Use when a PR is opened or when asked to review a PR.

Draft GitHub issue titles and bodies for this repository using `.github/ISSUE_TEMPLATE` form definitions. Use when opening or preparing a GitHub issue or feature request (e.g. "open an issue", "機能要望").

Explore the codebase for chances to turn shallow modules into deep modules per A Philosophy of Software Design. Use when improving architecture, finding refactoring opportunities, looking for shallow modules, or the user mentions "deepen".

When designing a module or API, run parallel subagents to produce fundamentally different options and compare them. The first idea is rarely best—practice "Design It Twice" from A Philosophy of Software Design. Use when designing an API, exploring interface shapes, or the user mentions "design it twice" or "interface comparison".

Read a GitHub Issue and run branch creation through implementation, commit, and PR. Use when the user asks to implement, work on, or execute a GitHub issue (e.g. "implement #123", "work on Issue #42").

Feature-Sliced Design (FSD) project layout: layer dependencies, slice structure, and naming conventions. Use when creating directories, moving files between layers, or deciding where to place modules (e.g. "where does this component go?", "explain the directory structure").