Existing Project Audit
Purpose
Understand what already exists before changing it. Produce an accurate picture of the repository — structure, stack, applications, tests, security posture, and state — that requirements, application, and stack decisions can rely on.
When to Use
- Any request against an existing codebase (enhancement, feature, bug, refactor, migration, review).
- Before recommending changes or a stack for an existing repo.
- Not for greenfield work (record "greenfield" and skip).
Inputs
- Read access to the repository.
- The classified request (to scope the audit).
Discovery Questions
- Which parts of the repo are in scope for this request?
- Are there known problem areas, recent incidents, or fragile modules?
- What is the current build/test/deploy story?
Responsibilities
- Inventory structure (apps, packages, modules, entry points).
- Detect the stack actually in use (frameworks, DB, data layer, testing tools).
- Identify applications present (mobile/web/dashboard/backend/worker/etc.).
- Assess tests (levels, tools, coverage signal).
- Assess security posture at a high level (secrets, auth, exposure) — flag, don't fix here.
- Determine implementation state (what's done, in-progress, stubbed).
- Record findings; do not edit code during the audit.
Required Workflow
- Scope the audit to the request.
- Map structure and entry points.
- Detect stack and applications from manifests/config/code.
- Survey tests and CI.
- Note security-relevant signals (hand deep analysis to
security-review).
- Summarize state and risks in
../../projects/current/ / ../../generated/audits/.
Decision Rules
- Report what the repo proves, separate from what you infer.
- If the request is small, scope the audit to the affected area — don't audit the whole repo needlessly.
- Deep security/performance analysis is delegated (
security-review, performance-review), not done here.
Rules
- Read-only: no edits during the audit.
- Do not print discovered secret values — flag location/type, redacted (
../../system/SECURITY_RULES.md).
- Ground later stages in findings, not guesses.
Anti-Patterns
- Proposing changes before understanding the current state.
- Auditing the entire monorepo for a one-file fix.
- Treating inferences as confirmed facts.
Validation Checklist
Definition of Done
A recorded audit (scoped to the request) covering structure, stack, applications, tests, security signals, and state — with confirmed vs inferred separated — ready to inform requirements, applications, and stack.
Related Skills
request-classification, requirements-analysis, application-selection, stack-recommendation, dependency-audit, environment-audit, security-review, performance-review.
Related Knowledge
../../knowledge/ (existing architecture notes, if any).
Related References
None typically; a stack reference folder only if an unfamiliar framework is present.
Context Loading Guidance
- Requires: repository read access, the classified request.
- Does not require: the full stack decision space, unrelated references, or every skill.
- May load:
dependency-audit, environment-audit for deeper inventory; security-review for posture.
- Stop when: the scoped audit is recorded.
Token Efficiency Guidance
Read entry points, manifests, and config first; sample representative files rather than reading everything. Summarize into findings; don't paste large files into the record.
1---2name: existing-project-audit3description: Use when a codebase already exists, before proposing any changes. It inventories structure, stack, applications present, tests, security posture, and implementation state so planning is grounded in reality rather than assumptions.4---56# Existing Project Audit78## Purpose910Understand what already exists before changing it. Produce an accurate picture of the repository — structure, stack, applications, tests, security posture, and state — that requirements, application, and stack decisions can rely on.1112## When to Use1314- Any request against an existing codebase (enhancement, feature, bug, refactor, migration, review).15- Before recommending changes or a stack for an existing repo.16- **Not** for greenfield work (record "greenfield" and skip).1718## Inputs1920- Read access to the repository.21- The classified request (to scope the audit).2223## Discovery Questions2425- Which parts of the repo are in scope for this request?26- Are there known problem areas, recent incidents, or fragile modules?27- What is the current build/test/deploy story?2829## Responsibilities3031- Inventory **structure** (apps, packages, modules, entry points).32- Detect the **stack** actually in use (frameworks, DB, data layer, testing tools).33- Identify **applications present** (mobile/web/dashboard/backend/worker/etc.).34- Assess **tests** (levels, tools, coverage signal).35- Assess **security posture** at a high level (secrets, auth, exposure) — flag, don't fix here.36- Determine **implementation state** (what's done, in-progress, stubbed).37- Record findings; do **not** edit code during the audit.3839## Required Workflow40411. Scope the audit to the request.422. Map structure and entry points.433. Detect stack and applications from manifests/config/code.444. Survey tests and CI.455. Note security-relevant signals (hand deep analysis to `security-review`).466. Summarize state and risks in `../../projects/current/` / `../../generated/audits/`.4748## Decision Rules4950- Report what the repo **proves**, separate from what you **infer**.51- If the request is small, scope the audit to the affected area — don't audit the whole repo needlessly.52- Deep security/performance analysis is delegated (`security-review`, `performance-review`), not done here.5354## Rules5556- Read-only: no edits during the audit.57- Do not print discovered secret values — flag location/type, redacted (`../../system/SECURITY_RULES.md`).58- Ground later stages in findings, not guesses.5960## Anti-Patterns6162- Proposing changes before understanding the current state.63- Auditing the entire monorepo for a one-file fix.64- Treating inferences as confirmed facts.6566## Validation Checklist6768- [ ] Structure and entry points mapped.69- [ ] Stack and applications detected.70- [ ] Tests and CI surveyed.71- [ ] Security signals flagged (redacted).72- [ ] Implementation state and risks recorded.73- [ ] No code edited.7475## Definition of Done7677A recorded audit (scoped to the request) covering structure, stack, applications, tests, security signals, and state — with confirmed vs inferred separated — ready to inform requirements, applications, and stack.7879## Related Skills8081`request-classification`, `requirements-analysis`, `application-selection`, `stack-recommendation`, `dependency-audit`, `environment-audit`, `security-review`, `performance-review`.8283## Related Knowledge8485`../../knowledge/` (existing architecture notes, if any).8687## Related References8889None typically; a stack reference folder only if an unfamiliar framework is present.9091## Context Loading Guidance9293- **Requires:** repository read access, the classified request.94- **Does not require:** the full stack decision space, unrelated references, or every skill.95- **May load:** `dependency-audit`, `environment-audit` for deeper inventory; `security-review` for posture.96- **Stop when:** the scoped audit is recorded.9798## Token Efficiency Guidance99100Read entry points, manifests, and config first; sample representative files rather than reading everything. Summarize into findings; don't paste large files into the record.
ahtishamshahzad