go-boilerplate

Integrator skill for architectural compliance checks. Confirms scope + TODO opt via `AskUserQuestion` (changed files vs full repo), detects which layers are touched, resolves the file list and runs `make lint` ONCE, then fans out the relevant read-only `arch-auditor-*` subagents (`arch-auditor-domain` / `-usecase` / `-controller` / `-infra` / `-pkg`) IN PARALLEL via the Agent tool — passing scope + resolved files + the shared lint output so each auditor skips its own scope question and does not re-run lint. Aggregates findings into a single Japanese report grouped by layer. Each auditor enforces its own README rules + lean A conventions (controller / infra have additional convention enforcement since they're scaffold-derived, not spec-driven). Detection is delegated to the read-only auditor subagents; the integrator itself only writes the optional `// TODO:` hand-off comments (single-threaded, after aggregation) when the user opts in. To audit a single layer, run this integrator and pick that layer in the sco

Analyze the current working-tree changes (staged + unstaged), group them into appropriately-scoped commits with the project's prefix convention (Feat / Fix / Refactor / Perf / Docs / Test / Build / CI / Chore / Style / Revert), and execute each commit in Japanese after user approval. Pre-flight also checks whether the current branch's PR is already merged and, if so, recommends cutting a fresh branch from the base before committing. Commits are made with `git commit --no-verify` to skip lefthook during the split; after all commits succeed, the command runs the lefthook-defined commands directly plus `make fix` as a final verification gate (lefthook itself is bypassed because it skips checks when nothing is staged). Respects CLAUDE.md's git rules (no direct commits to protected branches, no force-push, no auto-push after PR amend, Co-Authored-By footer, HEREDOC commit messages).

The "apply" skill that applies = fixes the findings under tmp/reviews/ generated by full-verify (architecture.md / mod_*.md / _index.md), top-down by severity (Critical → High → Medium → Low). The counterpart to the read-only full-verify. Skips (defers) "suspicious" findings that require design judgment or whose behavior is unclear, leaving a reason. Tracks done/deferred in the tmp/reviews/working.md ledger and stamps a status comment + commit hash at the top of each mod_*.md. Conflicts are first-come-first-served; within one md, related findings are fixed together within the bounds of not breaking the public API. Verifies (build/vet/test/gofmt or make) before committing. Use it when asked to "fix the review findings", "apply reviews", or "full apply".

Verify a whole repository's architecture and the validity of all implementation code in the background, generating a set of Markdown findings (tmp/reviews/architecture.md / mod_*.md / _index.md). The skill itself detects and adapts to the language, structure, and presence of design documents. Use it when asked for a whole-repository structural verification / implementation-soundness review / overall review / full verify — NOT a diff review. Changes no code; read-only plus Markdown generation only.

Local adversarial, low-bias code review of the current change, run by subagents on a DIFFERENT model than the implementer. Mirrors `/code-review`'s finder → verify shape but keeps everything local and adds a runtime (curl + o11y) stage that mocked tests cannot cover. Confirms scope via `AskUserQuestion` (changed files vs branch-vs-base diff vs specific paths), fans out `adversarial-reviewer` subagents — one per lens (correctness / security / architecture / runtime-gap) — plus the dedicated `comment-reviewer` subagent for comment quality, each on a user-selected model (fable / sonnet / opus / haiku; default auto = a model ≠ the implementer) so reviewer ≠ implementer — then verifies each finding with an independent `review-verifier` subagent (CONFIRMED / PLAUSIBLE / REFUTED), optionally runs the runtime curl + o11y check for touched endpoints (orchestrator-driven, per `scaffold-endpoint` Step 3.5), and synthesizes a single Japanese report. The `comment-reviewer` both validates good comments (the What is correct

End-to-end orchestrator that builds a complete onion-architecture endpoint (domain + infra-db + usecase + controller) for one feature — and, when you start from a rough idea instead of finished specs, first drives the feature-dev-style upstream design phases that turn that idea into the input artifacts the deterministic scaffold core needs. Two entry modes, auto-detected: (A) **idea-first** — Discovery + Clarifying Questions (AskUserQuestion) → parallel Codebase Exploration (Explore agents) → Architecture Design (Plan agent, constrained to the lean A / onion / OpenAPI-first / sqlc rails) → draft the OpenAPI YAML + SQL migration + domain.md + usecase.md for user review, then run `make gen-api` / `make gen-query`; (B) **specs-ready** (backward-compatible fast path) — jump straight to the core when `docs/spec/<feature>/{domain,usecase}.md` + OpenAPI + SQL already exist. The deterministic core is unchanged: `verify-spec` → `scaffold-domain` → `scaffold-infra-db` → `scaffold-usecase` → `scaffold-controller` → `mak

Push the current feature branch to `origin` and create or update its GitHub pull request. Detects whether a PR already exists for the current branch via `gh pr view` and automatically chooses between "create" and "update". The PR body is filled from `.github/pull_request_template.md` (sections `概要` / `変更内容` / `動作確認方法`) using the commit history and diff. Title and body are written in Japanese per `CLAUDE.md`. The skill confirms with the user before any push, with the exact wording required by `CLAUDE.md` for the update path. As its first action (Phase 0, right after pre-flight) it asks whether to run a pre-push `/impl-review`; choosing to review cleanly cancels submit-pr and guides the user to review → fix → `/commit` → re-run (a local review produces fixes that must be committed before a clean push, so there is nothing to resume), keeping the review decision before anything is composed or pushed.

Independent quality review of Go test files (`*_test.go`) in this repository, with adversarial finder + skeptical verifier two-stage pipeline. Defaults to `git diff` HEAD-vs-working tree to surface the changed `*_test.go` files; alternative scopes (branch-vs-base, specific paths) selectable via `AskUserQuestion`. Hardcodes no rules — reads `docs/testing-conventions.md` + the target layer's README `Test Strategy` / `Testing strategy` section + `.claude/skills/scaffold-test/SKILL.md` (the canonical generation rules) + the subject source file at runtime as the source of truth, so the reviewer stays in sync as conventions evolve (README > Code > SKILL priority). Fans out four `adversarial-reviewer` subagents on `sonnet` by default (so reviewer ≠ an Opus implementer) — one per lens: (1) **structural compliance** (`t.Parallel()` at every level / `t.Run` per subcase / outermost groups are the literal strings `正常系` / `異常系` with no `正常系_xxx` prefix form, sub-case names inside those groups carry no `正常系_` / `異常系_` pref

Implement the domain layer (entity / Repository interface / constants / errors / value objects / tests) for one feature, driven by `docs/spec/<feature>/domain.md`. The skill reads the spec, references `internal/domain/README.md` (layer-wide convention: principles, naming, getter style, error wrapping, file separation) plus existing sibling aggregates as a secondary structural template, invokes a test-perspective subagent to define the layer's test viewpoints (invariant preservation, state-transition correctness, value object boundary checks) BEFORE writing code, then generates: entity struct + constructor with invariant checks, unexported fields with auto-generated getters (using `ptr.Copy` for pointer types), constants (`min<Field>Length` / `max<Field>Length` etc. derived from spec field constraints), errors (`ErrInvalid<Field>` derived from field names + invariants), Repository interface with `//go:generate mockgen` directive, value objects, and a test file covering invariants + behavior methods + VO bounda

Upgrade the Go version used by this project. Follows the procedure in `docs/maintenance/go-upgrade.md` and updates `mise.toml`, runs `make sync-versions` to propagate the new version to `go.mod` and the relevant Dockerfile / README files, then rebuilds dependencies, tooling, and generated code and verifies with tests and lint. The target version is confirmed with the user at execution time, and the skill also offers an optional Go module dependency update (latest minor / patch-only / skip) as part of the same upgrade.

Audit and refresh the digest pins for the Docker base images referenced by `FROM` in `docker/*/Dockerfile`, with a supply-chain cooldown that refuses freshly-rebuilt digests. The image tag (`golang:1.26.5-alpine`) is the version source of truth and is owned by `go-upgrade` / `tools-upgrade` / `make sync-versions` — this skill NEVER changes tags, only the trailing `@sha256:...` digest. `docker/images-pin.toml` is the resolved `image:tag → digest` lockfile (SSOT), driven by `make pin-images-resolve` / `pin-images-apply` / `pin-images-check` (backed by `scripts/pin-images`). `resolve` re-resolves each tag's current digest via `docker buildx imagetools inspect` and quarantines any whose image-config `created` is younger than `PIN_IMAGES_MIN_AGE_DAYS` (default 14; pass `days=N` to override, `0` disables). Because a mutable tag has no queryable history, the step-back target is the tool's own prior lock entry; on bootstrap a still-fresh image is left tag-only and reported with its re-run date. Verifies with `make pi

Audit `mise.toml` `[tools]` entries against upstream latest versions, with a configurable supply-chain quarantine. For each tool the latest release is fetched from its backend (GitHub Releases for `aqua:` / `go:` tagged modules, npm registry for `npm:`, PyPI for `pipx:`, language download manifests for `go` / `node` / `python`). Releases newer than `min_age_days` are reported as informational only — never applied automatically — to avoid pulling in newly-published malicious versions before upstream has time to detect and revoke them. Confirms `min_age_days` and the per-tool update set via `AskUserQuestion`, rewrites approved entries in `mise.toml` atomically, runs `make sync-versions` if `go` / `node` / `python` changed, and verifies with `make lint` + `make test`. Use this skill on a routine cadence (monthly / quarterly) or after a security advisory.

Create, update, evaluate, and optimize skills under this repository's `.claude/skills/`, wrapping Anthropic's official `skill-creator` methodology and layering this repo's conventions on top (English-canonical SKILL.md + mandatory `SKILL.ja.md` translation pair, dense "pushy" description frontmatter, AGENTS.md scope + hard-protected paths, eval artifacts kept out of version control). This is the single entry point for ANY change to an existing skill under `.claude/skills/`; ALWAYS use it before hand-editing a `SKILL.md` or `SKILL.ja.md`. Use this WHENEVER the user wants to update / modify / change / edit / fix / improve / refactor / rename / extend / adjust / tune an existing skill — its steps, `description`, frontmatter, or behavior — or to build a new skill, author/scaffold a `/<name>` command, turn a repeated workflow into a skill, tune a skill's triggering description, or run evals/benchmarks on a skill — even if they don't say the word "skill-creator". Japanese triggers also apply, e.g. 「スキルを更新したい」「スキルを修

PROVISIONAL / one-off. Full-repository scan that discovers ADR-worthy architectural decisions across the whole repo (not just docs/decisions.md) so decisions.md can be migrated to a formal docs/adr/ set. Fans out read-only discovery over four surfaces — canonical docs (decisions/architecture/rules), subsystem design docs (docs/design/**), deliberate-exclusion docs (docs/project/**, out-of-scope), and latent decisions (per-package READMEs + code "why" comments) — classifying each candidate as decision (ADR-worthy) / rule (stays in rules.md) / inventory (stays in a living reference) / exclusion (ADR-worthy negative decision). Read-only: produces a candidate ADR inventory only, writes no docs/adr files. Delete after the migration format is locked.

Audit and upgrade the SHA-pinned GitHub Actions referenced by `.github/workflows/**` and `.github/actions/**`, with a supply-chain quarantine and automatic step-back to the previous aged version. Default is minor-only (stay within current majors); pass `major` to also bump major versions; pass a number or `days=N` to set the exclusion window (`PIN_ACTIONS_MIN_AGE_DAYS`, default 14). The version source of truth is the trailing tag comment on each `uses: owner/repo@<sha> # <tag>` line; `.github/actions-pin.toml` is the resolved tag→SHA lockfile, driven by `make pin-actions-resolve` / `pin-actions-apply` / `pin-actions-check` (backed by `scripts/pin-actions`). For each target major the skill prefers the moving major tag when its latest is aged, else steps back to the newest exact version older than the exclusion window, else holds — so a freshly published (possibly compromised) release is never adopted. Verifies with `make pin-actions-check` + `make actions-lint`. Major bumps additionally verify `with:` input co

Integrator skill for drift detection across all layers. Confirms scope (changed files vs full repo) + detection categories (A/B/C, multi-select) once via `AskUserQuestion`, detects which layers are touched, resolves the per-layer file list, then fans out the relevant read-only `drift-detector-*` subagents (`drift-detector-domain` / `-usecase` / `-controller` / `-infra` / `-pkg`) IN PARALLEL via the Agent tool — passing scope + resolved files + categories so each detector skips its own scope question. Detectors are STRICTLY read-only and only surface findings (A: README→Code, B: Code→README undocumented pattern, C: Skill↔README duplication) with reasoning + candidate options. The integrator then runs the per-item user-approval loop itself (single-threaded) and performs the README / SKILL writes after explicit per-item confirmation. Does NOT modify implementation code — code fixes are surfaced and left to the user. To check a single layer, run this integrator and pick that layer in the scope question. Recommend

Audit `docs/portal/manifest.yaml` against the real `README.md` / `README.ja.md` files on disk. The manifest is treated as a **curated reading list**, not a complete mirror of disk. Workflow has three quality gates before any reporting: (1) **pair_drift preflight** — if translation sibling files are missing, offer to chain into `canonicalize-doc` to resolve before continuing; (2) **API-doc filter** — applies the N1 (Pure API reference) criterion defined in `.claude/skills/readme-review/SKILL.md` to exclude READMEs that are dominantly Go API references (godoc's responsibility); (3) **manual-worthiness judgment** — each remaining uncurated README is evaluated by applying the P1–P7 positive criteria and the N2–N4 negative criteria from `readme-review`, then classified using its thresholds (manual-worthy / borderline / not-yet-manual-grade / out-of-scope-for-portal). After the gates, the skill surfaces: `stale` (removable), `manual-worthy`, `borderline`, `not-yet-manual-grade`, and `out-of-scope-for-portal` (count

Generate a Japanese release note Markdown file under `.github/release/` summarizing changes between a specified `origin` git tag and `HEAD`. Confirms both the FROM tag and the new release version with the user via `AskUserQuestion`, gathers commit history / diff statistics, categorizes changes, and writes the document in the project's canonical `v1.1.0`-style sectioned format. Triggers: "リリースノートを作成", "release notes", "v1.x.y のリリースノート".

Operational runbook for this repository's recurring, easy-to-trip-on gotchas around generated artifacts, the dockerized tool runners, and the DB. Use when a generated file drifts (`schema.gen.sql`, mocks, portal guides), when `git` suddenly refuses to touch a generated directory because it became root-owned, when a regeneration step fails because the DB container is down or carries stale tables, when building a per-environment image, or when the commit-msg hook errors. The repo runs most code generation inside Docker tool-runner containers as root, which is the root cause of several of these. Read-only knowledge skill — it tells you the exact command to run; it does not silently mutate state. Triggers: "schema.gen.sql が diff る / generate-db-check が落ちる", "git が docs/portal や mock を permission denied", "gen-query が DB に繋がらず落ちる", "per-env イメージのビルド", "commit-msg / commitlint が not found".

Implement the controller (HTTP handler) layer for one feature, derived from OpenAPI gen + usecase Interface (lean A — no spec file). Reads the OpenAPI-generated `ServerInterface` at `internal/controller/handler/<path>/gen/server.gen.go` for operationIds, the target usecase Interface for available methods, and `internal/usecase/README.md` for naming convention. Derives the mapping operationId → usecase method via name-match heuristic. For any operationId without a derivable mapping, **halts with hand-off message** (user resolves: add usecase method, rename for convention, or accept hand-write). Reads `internal/controller/README.md` + `internal/controller/handler/README.md` (which carries the canonical reference snippet — `server` struct + `BindHandler` constructor + `gen.NewStrictHandler` + `gen.RegisterHandlers` pattern). Existing handler packages are secondary reference only; README wins on any drift. Invokes a test-perspective subagent (HTTP I/O conversion, validation paths, apperror→status mapping, middlew

Implement the infrastructure (RDB) layer Repository for one feature, derived from domain Repository IF + sqlc gen functions (lean A — no spec file). Reads the domain Repository Interface at `internal/domain/<aggregate>/<aggregate>_repository.go` for method list, the sqlc gen functions at `internal/infrastructure/rdb/sqlc/gen/*.gen.go` for available DB calls, and `internal/infrastructure/rdb/README.md` for naming convention. Derives the mapping Repository method → sqlc gen function via name-match heuristic. For methods without a derivable mapping, **leaves TODO at the impl location + reports** (user resolves: add SQL + re-run `make gen-query`, or accept hand-write). Wraps each method with tracer span + `pgerror.NormalizeError` + row→entity conversion per the sibling pattern. Reads `internal/infrastructure/README.md` + `internal/infrastructure/rdb/README.md` + an existing `repository/<sibling>/` as structural template, invokes a test-perspective subagent (real DB + rollback via testkit, sqlc gen wrap correctnes

Generate HTTP-boundary integration tests for one feature under `internal/integration/`. These are NOT DB/usecase integration tests — they boot an Echo server via `httptest` and verify only the HTTP path (Router → Middleware → Handler → Presenter) with the usecase MOCKED, per `internal/integration/README.md`'s test strategy. Hardcodes no helper API: reads `internal/integration/README.md` (test strategy + scope) and `internal/integration/helper_test.go` (the package's test helpers — HTTP server bootstrap, request execution, JSON-response assertion, auth-header injection) at runtime to learn their current names + signatures, plus a sibling `<feature>_test.go` as the structural template, the target handler package's `BindHandler` signature, its generated `gen` request/response types, and the usecase mock package. Derives one subtest per operationId (HTTP method + path from the handler `gen`), each: boot Echo → mock the mapped usecase method → bind the handler → drive the endpoint through whatever request/assert h

Implement the usecase (Application Service) layer for one feature, driven by `docs/spec/<feature>/usecase.md`. The skill reads the spec + `internal/usecase/README.md` + `internal/usecase/boundary/README.md` + an existing usecase package as structural template, then invokes a test-perspective subagent to enumerate usecase-layer test viewpoints (workflow ordering, mock strategy for repository/boundary, transaction-boundary correctness, error propagation, DTO conversion) BEFORE writing code. Generates: Usecase interface with `//go:generate mockgen` directive, `usecase` struct with all dependencies injected, `New(...)` constructor, per-method body with tracer span / boundary calls / domain calls / repository calls / DTO mapping per the spec's Workflow section, DTO struct definitions, and a test file using gomock-based mocks for repository + boundaries with real domain entities. Runs `make gen-api` to regenerate the Usecase mock, then updates `internal/di/module/usecase.go` to register the new provider. Verifies w

Inventory every command / skill / agent registered under this project's `.claude/` directory and produce an inventory table plus a dependency map (Mermaid). Reads frontmatter and bodies, extracts cross-references, and renders the report inline or to a file. Read-only by default; writes only when `--output=file` is chosen.

Integrator skill for spec validation. Confirms feature name via `AskUserQuestion` (or receives from `scaffold-endpoint`), detects which spec files exist under `docs/spec/<feature>/` (lean A: `domain.md` and/or `usecase.md`), then fans out the matching read-only `spec-validator-*` subagents (`spec-validator-domain` / `spec-validator-usecase`) IN PARALLEL via the Agent tool — passing the feature name + spec paths so each validator skips its own feature confirmation. Each validator handles format check, internal consistency, plus its specific cross-validation (entity ↔ SQL for domain; cross-spec refs + naming convention for usecase). Does NOT check OpenAPI operationId coverage — that violates dependency direction (usecase doesn't know about HTTP/OpenAPI); the OpenAPI ↔ usecase mapping is verified by `scaffold-controller` at scaffold time. Aggregates findings into a single Japanese report. Read-only orchestration — validators never touch spec or source files. When chained from `scaffold-endpoint`, aborts the down

Generate a Go unit test file for an existing function / method in this repository, following the canonical pattern abstractly extracted from `internal/domain/user/user_domain_test.go`. Hardcodes no test viewpoints and no layer-specific viewpoint seeds — reads `docs/testing-conventions.md` + the target layer's README `Test Strategy` / `Testing strategy` section + sibling test files in the same package at runtime, then invokes a test-perspective subagent that derives the viewpoint set from the README's Test Strategy sub-sections (so the skill stays in sync as READMEs evolve; per the project's README > Code > SKILL priority). For layers where the README intentionally has no Test Strategy section (notably `pkg/**`, which is pure framework-agnostic utilities whose tests reduce to standard Go input-output + edge-case + nil/zero handling), viewpoints are derived from sibling tests + `docs/testing-conventions.md` and this is treated as the layer's normal mode (no warning surfaced). For layers where Test Strategy is e

Integrator skill that creates the 2-layer spec set under `docs/spec/<feature>/` by chaining per-layer skills (`new-spec-domain` / `new-spec-usecase`). lean A 構成では controller / infra に spec を持たず OpenAPI + sqlc gen + 命名規約から導出するため、spec は domain + usecase の 2 ファイルだけ。Confirms feature name (kebab-case) once via `AskUserQuestion`, then asks which layers to scaffold (multi-select, default both) and chains the selected per-layer skills in dependency order (`domain` → `usecase`). Each per-layer skill still collects its own layer-specific identity (aggregate / package / interface name) and writes a Markdown file with YAML code-block placeholders and TODO markers. Skips layers whose target file already exists rather than aborting the chain. Use a per-layer skill (`new-spec-<layer>`) directly when scaffolding a single layer template. Does not invent business content — gathers identity only. All structural section definitions are read from `.claude/scaffold-spec/<layer>-spec.md` at runtime by each per-layer skill, so spec

Add a new environment variable to the project end-to-end, keeping the typed config struct, env file samples, and documentation in sync. Touches `internal/config/envspec.go` (Loader field), `internal/config/model.go` (Config struct + private field), `internal/config/config.go` (New() mapping + getter method), `internal/config/config_testing_mock.go` (expected value + mock setter), `env/.env.{local,ci,dev,stg,prd}` (and `.env` if used) for per-environment values, and `env/README.{md,ja.md}` (table row in the matching subsystem). The subsystem (envPrefix → struct), Go type mapping, and naming conventions are derived from the existing `envspec.go` / `model.go` at runtime — the skill hardcodes no subsystem list. Confirms variable name, type, description (en + ja), required vs default, and per-environment values via `AskUserQuestion` before writing. Does NOT auto-add a testing setter helper in `config_testing_setter.go` (the file explicitly limits additions); offers it only on explicit request. Verifies with `make

Review a single README (canonical English) and judge whether it has "manual-worthy" characteristics for inclusion in the portal at `docs/portal/manifest.yaml`. The evaluation criteria are derived from patterns observed in currently-registered manifest entries (Role / Design Intent / Rules / Architecture diagram / Navigation / Notes / substantive prose). Produces a scorecard with strengths, gaps, concrete improvement suggestions, and a final classification (manual-worthy / borderline / not-yet-manual-grade / out-of-scope-for-portal). Read-only by default; never edits the README or the manifest. When the result is manual-worthy, the skill suggests chaining into `portal-manifest-sync` (curation flow) as the natural next step; it does not perform the addition itself.

Create the domain layer spec template at `docs/spec/<feature>/domain.md`. Asks for feature name (kebab-case) + aggregate name (PascalCase) via `AskUserQuestion`, reads the section structure for the domain layer from `.claude/scaffold-spec/domain-spec.md`, then writes a Markdown file with YAML code-block placeholders and TODO markers for the user to fill in (Overview / Entity / Cross-field Invariants / Behavior Methods / Value Objects / Repository Methods). NEVER overwrites an existing file. Does not invent business content — gathers identity only. Reads the spec format file at runtime so format changes propagate automatically.

Create the usecase layer spec template at `docs/spec/<feature>/usecase.md`. Asks for feature name (kebab-case) + usecase package name (lowercase, e.g., `user`) + Usecase interface name (default `Usecase`) via `AskUserQuestion`, reads the section structure for the usecase layer from `.claude/scaffold-spec/usecase-spec.md`, then writes a Markdown file with YAML code-block placeholders and TODO markers (Overview / Interface / DTOs / Dependencies / Workflow). NEVER overwrites an existing file. Does not invent business content — gathers identity only. Reads the spec format file at runtime so format changes propagate automatically.

Create or sync a canonical English / Japanese translation pair for a specified README, SKILL, or similar Markdown document. Detects the existing file (canonical, translation, or both), confirms the source file and direction with the user via AskUserQuestion, and produces the missing side or syncs both sides while preserving repo conventions (frontmatter rules for SKILL files, sync-note headers for translations, cross-reference links).

Update a specified canonical README so it matches the actual files and directories beneath its location. Detects drift between what the README documents and what exists on disk (missing files, renamed files, removed entries, outdated descriptions) and rewrites the README to reflect reality. For child directories that have their own README, includes only a short digest plus a reference link rather than recursing into their contents. After updating the canonical README, automatically chains into the `canonicalize-doc` skill to re-sync any sibling translation file. Confirms the target README path and update scope with the user via AskUserQuestion before writing.