Multi Role Repo Review

Overview

Use this skill to run a practical cross-functional repository review grounded only in files, commands, and documentation available in the target repo.

Core Rules

• Inspect the repository before producing conclusions.
• Use only repository evidence: files, folders, docs, manifests, configs, source, tests, CI/CD files, TODOs, comments, generated artifacts, and command output.
• Do not invent features, users, infrastructure, requirements, business goals, or release criteria.
• If something cannot be determined from repository evidence, say so explicitly.
• Prefer specific file references over generic claims.
• Keep findings concise, practical, and prioritized.
• Treat the roles as review lenses that the root session applies directly. Applying a lens does not change the root session's model, effort, authority, or ownership, and no lens is a reason to launch a subagent.
• An independent read is optional. When its concrete benefit justifies the cost, the root session may dispatch the bundled senior-reviewer subagent on its approved route for a bounded area, under the governing delegation policy and the subagent-orchestration skill. senior-reviewer runs in plan mode and cannot reliably run test suites; when a delegated read needs a suite run, the root session runs it directly or dispatches the bundled test-triager subagent on its approved route. Helper availability alone is not a reason to launch one, and no helper spawns another.
• The root session keeps synthesis, the final judgment on every finding, and every release-blocker, security, and architecture decision. Self-review, including applying the lenses yourself, is not independent verification.

Inspection Workflow

1. Identify the repo root and current branch/status when git metadata is present.
2. Map the top-level structure with a shallow directory listing.
3. Read the README and visible documentation first.
4. Inspect package/dependency manifests, lockfiles, runtime version files, and build/test scripts.
5. Inspect configuration files, environment examples, lint/typecheck/test setup, and framework config.
6. Inspect source code entry points, routing, core services, data models, API boundaries, UI components, and shared utilities.
7. Inspect tests, fixtures, mocks, coverage config, and missing coverage around critical paths.
8. Inspect CI/CD, deployment, container, cloud, and infrastructure files when present.
9. Search for TODO, FIXME, HACK, XXX, BUG, SECURITY, deprecated, and known limitation language.
10. Run lightweight commands only when useful and safe, such as listing package scripts or running focused checks. Do not claim checks passed unless actually run. This skill grants no authority to call cloud services, start shared services, deploy, publish, dispatch remote CI, download files, or execute downloaded code; ask the user first.

Role Lenses

Use these roles in the structured review:

• Product Manager: user value, apparent product scope, unclear requirements, feature completeness, prioritization.
• Project Manager / Scrum Master: delivery sequencing, planning gaps, dependencies, readiness, process risks.
• Tech Lead / Software Architect: architecture, boundaries, data flow, dependency choices, maintainability, engineering risk.
• Frontend Developer: UI implementation, client state, routing, accessibility hooks, component quality, browser-facing fragility.
• Backend Developer: APIs, persistence, validation, domain logic, integrations, error handling, server-side fragility.
• UX/UI Designer: interaction clarity, information architecture, visual consistency, accessibility, usability gaps.
• QA / Test Engineer: test strategy, missing coverage, fragile scenarios, reproducibility, release confidence. Judge retained behavioral coverage by end-to-end tests that drive complete supported UI, API, or CLI flows through real entry points with relevant dependencies and observable outcomes. Recommend end-to-end coverage for missing behavior, not permanent unit tests or isolated integration suites. Report existing required suites and repository gates as found, and do not recommend removing them outside authorized scope.
• DevOps / Cloud Engineer: build/deploy path, runtime configuration, observability, environments, CI/CD, operational risk.
• Security Engineer: auth, authorization, secrets, dependency exposure, input validation, data handling, secure defaults.
• Stakeholder / Client Representative: business impact, adoption concerns, trust, operational fit, unresolved stakeholder questions.

For each role, identify:

• What the project appears to do.
• Key strengths.
• Risks and gaps.
• Possible bugs or fragile areas.
• Missing or weak tests.
• Unclear requirements.
• Technical debt.
• Concrete improvement suggestions.
• Questions for other roles when an issue crosses responsibilities.

Discussion Sequence

Organize the review as a structured team discussion:

1. Each role gives a short initial assessment.
2. Roles discuss disagreements, tradeoffs, blockers, dependencies, and cross-functional questions.
3. The Tech Lead summarizes architecture and main engineering risks.
4. The Product Manager summarizes user value, business value, and priority concerns.
5. QA, Security, and DevOps identify potential release blockers.
6. The full team produces a prioritized action plan.

Final Output

Produce these sections exactly:

1. Project Summary

Briefly describe what the project appears to be, based only on repository evidence.

2. Role-by-Role Findings

Provide findings for each role, including strengths, concerns, and recommendations.

3. Cross-Functional Discussion

Summarize key disagreements, tradeoffs, dependencies, and decisions discussed by the roles.

4. Technical Architecture Summary

Have the Tech Lead describe the apparent architecture, major components, data flow, dependencies, and architectural risks.

5. Key Risks

List the most important product, technical, operational, security, testing, and delivery risks.

6. Release Blockers

Have QA, Security, and DevOps clearly identify any blockers that should prevent release. If release readiness cannot be determined from the repo, say so.

7. Open Questions

List questions that need clarification before confident planning or release.

8. Recommended Next Steps

Provide practical next steps grounded in repository contents.

9. Prioritized Backlog

Create a backlog table with these columns:

Use High, Medium, or Low priority. Keep evidence entries specific enough to trace back to actual repository files or observed command output.