<!-- Generated by mstack from Misbah's Build Like This workflow. Regenerate instead of editing. -->

repository-audit

This skill is part of Misbah Khursheed's Build Like This workflow. Thinking, evidence, and explicit trade-offs come before generated output.

Project identity and sources of truth

The repository where this skill is installed is the host project being built. Build Like This is the method used to build it; mstack only installs and reconciles method resources. Do not assume mstack or Build Like This is the product unless project-owned sources explicitly identify this repository as mstack itself.

Use project-owned docs/, decisions, executable code, and tests as sources of truth. .mstack/templates/ are reference scaffolds to copy and adapt into project-owned documents, not product requirements and not a replacement for docs/.

Purpose

Produce an evidence-based health assessment that helps maintainers prioritize concrete risks rather than chase a generic best-practice checklist.

Required inputs

• Repository tree, manifests, source modules, tests, automation, instructions, and relevant project documents.
• Intended product/deployment shape and known pain points if available.
• Allowed diagnostic commands and constraints on running builds or external tools.

If a missing input would materially change the result, state the gap and obtain or discover it before proceeding. Otherwise label the assumption and continue.

Process

1. Inventory entry points, packages, ownership boundaries, generated artifacts, and dependency direction.
2. Inspect build/test/type/lint/release commands and run the safest representative checks.
3. Sample critical paths for validation, authorization, errors, secrets, observability, and recovery behavior.
4. Compare documentation and agent instructions with executable behavior; identify stale or missing sources of truth.
5. Review dependency hygiene, dead/duplicate code signals, migration state, and production configuration risks.
6. Rank findings by user/operational impact, likelihood, and effort; separate quick fixes from structural work.

Output contract

• Repository map and concise health scorecard backed by inspected files and commands.
• Prioritized findings with evidence, impact, and recommended owner/action.
• A sequenced 30/60/90-style improvement path only when the breadth warrants it.

Guardrails

• Do not infer a defect solely from an unfamiliar convention; trace actual behavior.
• Do not recommend broad rewrites when a boundary or automation fix addresses the risk.
• Do not mutate the repository during an audit unless explicitly asked to fix findings.

Delegation and parallel safety

• Material lifecycle work must delegate at least one bounded specialist lane when subagents are available. Prefer two or more concurrent lanes only for independent evidence gathering, analysis, or non-overlapping file ownership.
• The active lead owns integration and acceptance. Supporting agents do not recursively delegate unless explicitly promoted to lead a named lane.
• Assign distinct outputs and ownership. Serialize shared docs, contracts, schemas, migrations, deployments, external writes, and overlapping file edits.
• When subagents are unavailable, perform the same named specialist passes sequentially and state that constraint instead of implying parallel verification.
• Delegation never grants permission for outreach, consequential external actions, destructive changes, paid resources, or production operations.

End with the evidence gathered, verification performed, and any residual risk or unresolved decision.