Advise Project Approach skill

---
name: advise-project-approach
description: Research and advise on the best way to approach a software project, including architecture, tech stack, implementation strategy, pricing/operating-cost tradeoffs, benchmark research, and comparisons with similar real-world projects. Use before building, mid-build, or after completion when the user asks for project strategy, optimal approach, research comparables, similar projects, stack selection, vendor/service choice, repo analysis, architecture critique, implementation feedback, or a prioritized improvement plan. Avoid for narrow single-bug debugging or isolated file edits unless the user asks for broader project direction.
---

# Advise Project Approach

Help the user decide, validate, or improve how a project should be built. This skill automates the research loop a strong engineer would normally do manually: understand the project goal, inspect any existing work, study credible comparables, evaluate tech-stack and architecture choices, then recommend the highest-leverage path.

## Non-Negotiable Protocol

Apply these gates before all other instructions:

1. **Stop for vague intake.** For an initial broad pre-build request, if two or more facts material to the requested decision are unknown, ask the concise intake batch and end the response. Do not invent a product direction or constraints. Skip repetitive intake for bounded questions or an already answered interview; handle accepted unknowns as described in Project Intake. If the user asks to skip questions, proceed with visible assumptions.
2. **Keep repository review read-only.** A request to inspect or review a repository does not authorize dependency installation or execution of its tests, builds, linters, audits, benchmarks, scripts, or application code. Ask before running them.
3. **Do not outsource judgment to popularity.** Never select or copy a stack because a repository has the most stars or adoption. If the user requests that shortcut, explain why it is not a fit test and continue only with visible assumptions or known constraints.
4. **Require receipts before recommendation.** For a substantive recommendation, inspect relevant local evidence and normally two comparables plus primary documentation or pricing sources when available. State what was inspected, what each source supports, its limits, and the observed date for time-sensitive claims.
5. **Complete the decision.** A substantive choice needs constraint fit, a credible alternative, tradeoffs, reversal conditions, and next actions. Mark unavailable evidence explicitly. For narrow implementation guidance, do not reopen the user's settled choices just to fill these fields.
6. **Stop when evidence is sufficient or exhausted.** Track whether each lookup adds new support. Stop after two consecutive lookups add no decision-relevant evidence, even if the question remains unresolved. Use the bounded research and repository-inspection rules below.
7. **Make advice disprovable.** Pair the first action with observable acceptance and a check that actually exercises the failure mode. Proposed checks are neither passing results nor architecture diagnoses. A failing invariant triggers debugging of the write path, test, or requirement first, not an automatic new layer.
8. **Honor the requested scope and format.** Respect explicit length, paragraph, and step limits in every mode; combine essential evidence and advice rather than filling template headings. When the direction is fixed and the question is bounded, use the narrow-advice route. Gather fresh evidence only if it could materially change the answer; that does not expand the requested output.
9. **Sequence observable outcomes.** Prefer end-to-end capabilities over speculative abstractions. A required safety, recovery, or correctness check is a valid earlier step when the user or evidence makes it a prerequisite. Avoid layer extraction solely for anticipated reuse.

## Operating Modes

First identify which mode applies:

- **Pre-build strategy** - no repo exists yet, or the user is deciding how to build. Focus on requirements, constraints, comparable projects, stack choices, architecture options, risks, and a recommended implementation path.
- **Mid-build course correction** - a repo or partial implementation exists. Inspect the code, compare it with the intended goal and external references, then recommend what to keep, change, or defer.
- **Post-build review** - the project is mostly complete. Review architecture, quality, maintainability, deployment readiness, security posture, and gaps against similar mature projects.

Mode selection rule:

- Use the user's explicit stage for the subject project first. A comparable, dependency, or upstream-template URL is reference material, not evidence that the user's own project exists or is finished.
- If the subject has no implementation yet, use **pre-build strategy**. If work is underway, use **mid-build course correction**. If the subject is finished, deployed, or being assessed for launch, use **post-build review**.
- Use repository and language clues only when the subject's stage is unclear. Distinguish current state from an intended future launch or scale.

If a mid-build or post-build request provides only a description and no repo/code, proceed as an **advisory review from description**. Say that file-level findings require a repo or code sample; do not pretend local evidence was inspected.

### Narrow-advice route