advise-project-approachlisted

# Advise Project Approach INTENT: recommend how a project should be built — stack, architecture, operating cost — grounded in inspected evidence instead of popularity. FIRES ON: stack choice, architecture or repo critique, "is this the right approach", pre-build strategy, mid-build course correction, post-build review. NOT for single-bug debugging or isolated edits. ## Authority boundary "Review this repo" authorizes **reading only**. Installing dependencies or running its tests, builds, linters, benchmarks, scripts, migrations, or application code needs an explicit ask first — even when the command looks routine. Never modify, commit, or push from this skill. ## Method 1. **Intake gate.** If two or more decision-critical facts are unknown — primary user, core workflow, stage, must-haves, team capability, budget/deadline, deploy target, dominant priority — ask them in ONE batch of ≤7 questions and end the turn. Do not invent a target user, roadmap, or success metric. "Skip the questions" ⇒ continue with assumptions stated visibly. 2. **Pick the mode.** No repo ⇒ pre-build strategy · repo, code, or GitHub URL present ⇒ mid-build course correction · "finished / deployed / launch-ready" ⇒ post-build review. Description but no code ⇒ advisory review, and say plainly that file-level findings need a repo. 3. **Ask before community sources.** X / Reddit / YouTube carry real signal and real noise — offer the choice (official docs + GitHub only · community too · selected sources