mygo/.agents/skills/mygo-api-repo-review/SKILL.md

name, description

name	description
mygo-api-repo-review	Review the MyGO backend repository for material, evidence-backed architecture, security, resilience, data-consistency, performance, and implementation flaws. Use only when explicitly asked to run a MyGO repository audit in diff, main, or full mode, optionally limited to a target path, package, or component; do not use for ordinary implementation or debugging tasks.

MyGO API Repository Review

Perform a read-only, evidence-first review of the MyGO backend. Find material defects and systemic risks without turning unfinished product scope, stylistic preferences, or unsupported hypotheticals into findings.

Resolve the review scope

Resolve two independent inputs: mode and target.

• Default mode to diff when the user does not provide one.
• Default target to all.
• Treat partly as a request for a limited target, not as a fourth mode. Require or safely infer the path, Go package, or logical component to inspect.

Use these mode semantics:

• diff: compare the current workspace with HEAD. Include staged changes, unstaged changes, and relevant untracked files.
• main: compare the current workspace with the merge base of HEAD and the local main branch. Record the local main and merge-base commit IDs. Do not fetch or silently substitute a remote ref. If local main is unavailable, report the limitation.
• full: inspect the current repository as a whole, including tracked code, tests, configuration, and documentation plus relevant untracked source files. Exclude repository metadata, caches, runtime data, build outputs, and generated artifacts unless they are directly relevant.

For a limited target, inspect not only the named files but also the directly affected callers, dependencies, interfaces, tests, configuration, and documentation needed to judge the target correctly.

Preserve the workspace

Keep the review read-only unless the user separately asks for fixes.

1. Capture the initial branch, HEAD, and complete Git status, including untracked files.
2. Do not run commands intended to rewrite source or dependency files, including go fmt ./... and go mod tidy.
3. Do not fetch, pull, commit, stage, or discard changes.
4. Capture Git status again before reporting. If the workspace changed, identify the change and do not erase it.

Review the implementation

Read AGENTS.md, docs/roadmap.md, docs/architecture.md, docs/decisions.md, and docs/development.md before judging the implementation. Treat documented decisions as intent, not as proof that their implementation is correct.

Apply production-grade correctness, security, resilience, and architecture standards to behavior and components that already exist, including implemented paths within WIP features. Do not interpret that standard as requiring every capability of the finished product to exist now.

1. Map the reviewed packages, dependency direction, entry points, state owners, external resources, and lifecycle operations. Use rg and targeted reads; do not read go.sum in full.
2. Reconstruct behavior, boundaries, invariants, state transitions, and trust assumptions from code, tests, configuration, and documentation.
3. Trace important control, data, ownership, resource, concurrency, and failure flows without starting from a predetermined bug list.
4. Use the lenses below for minimum coverage, then challenge every candidate before reporting it.

Treat the lenses as perspectives, not an exhaustive checklist, taxonomy, or finding quota:

• Architecture and evolution: Evaluate whether responsibilities, dependencies, boundaries, data flows, or resource use materially obstruct supported behavior, scaling, committed evolution, extensibility, decoupling, customization, or maintenance.
• Security: Evaluate whether trust, identity, authorization, ownership, confidentiality, integrity, availability, or exposure assumptions can be violated through a reachable execution path or component interaction.
• Resilience: Evaluate whether plausible partial failures, dependency failures, cancellation, concurrency, malformed inputs, or interrupted lifecycle operations can cause disproportionate impact, cascading failure, loss of service, or an unrecoverable state.
• Data consistency: Evaluate whether persistent state, external resources, ownership, and lifecycle transitions preserve required invariants across normal, concurrent, retried, interrupted, and partially failed execution paths.

Continue searching for material problems outside these lenses. Do not manufacture a finding for every lens.

Use parallel review selectively

Keep small diff and narrowly targeted reviews in the main agent by default. For a broad main or full review, use read-only subagents when they are available and parallel review materially improves coverage.

Give every reviewer the complete, non-exhaustive review objective and one primary emphasis such as architecture and performance, security, or resilience and data consistency. Make the emphasis a starting perspective rather than an exclusive boundary. Wait for all reviewers, then independently verify, deduplicate, and rank their candidates in the main agent.

Verify and report

Run the repository-wide checks below unless the user explicitly limits command execution or the environment prevents them:

• go build ./...
• go vet ./...
• go test ./...
• a non-mutating gofmt -l check over tracked Go files

Record each check and its result. When a test fails, inspect the test first and follow the debugging principles in AGENTS.md. Do not convert a command failure into an architecture finding without validating its cause.

After open-ended discovery, read review-calibration.md and apply its admission and falsification rules. Then read report-template.md and follow it exactly. If no candidate qualifies, state Findings: None rather than lowering the threshold.