Instruction file imported from charlielinder-del/BP-Product (
.cursor/rules/vp-vc-institutional-review.mdc). Copyright stays with the author.
VP / VC Institutional Review
Whole-platform review. Two independent lenses: (1) VP of Product/Engineering at a Google/Stripe-caliber shop, (2) VC operating partner doing technical/product diligence. Purpose: stop AI-enabled velocity from compounding architectural or technical debt unnoticed.
Not this review. Judged engagement runs, persona answers, stage grades, tracers, round-close. Those may feed evidence. They must never define this methodology. Do not edit institutional-reviews.mdc.
Trigger
User says “Run the Institutional Review” (or equivalent). Reconstruct from prior canvases/packets only as history, not current truth.
Evidence
Every scan produces candidates. For each: detect → investigate → attempt to falsify → verify against source/runtime → classify.
| Disposition | May enter backlog? |
|---|---|
| VERIFIED FINDING — evidence establishes a real deficiency | Yes |
| REDUCED — claim was overstated; file only the corrected version | Corrected version only |
| WITHDRAWN — disproved or intentional/designed | No |
| UNRESOLVED RISK — may be material; repo cannot establish defect | No ticket. State known / unknown / why it matters / what would resolve it |
No finding from grep, AST, linter, npm audit, or an LLM “looking suspicious.” Reward falsification. Do not convert unresolved risks into fake certainty. Do not begin remediation in the review session unless the user asks.
Investigation (parallel specialists when they add independence)
Architecture/quality · Security · Reliability/ops · Data-plane/truth integrity · Testing/evaluation · Observability · OSS/CI/supply chain.
Data plane is first-class: client input → validation → mapping → persistence → promotion → hydration → agent consumption → presentation. Ask whether synthetic/real can be confused, failed retrieval can look like absence, stale can look current, provenance survives, unavailable ≠ negative evidence.
VP lens (after evidence)
Letter grades follow evidence, not the other way around. Areas: architecture · security perimeter · tenancy depth · data/truth integrity · reliability/ops · maintainability · testing · observability · developer tooling · AI-system governance · enterprise production readiness.
Each material finding: Severity · Domain · Evidence · Consequence (commercial/product failure, not “the code is messy”) · Corrective action · Effort.
Also state What I would NOT change — protect good decisions from future cleanup agents.
VC lens (independent, not a translation)
Asset / commodity vs IP · Moat (or none) · RED/YELLOW/GREEN flags: IP provenance, OSS/license, key-person, enterprise-sale blockers, security, reliability, vendor/model concentration, portability, unit economics, implementation scalability, services-vs-software, debt trajectory · Builder signal · Economics (call out missing evidence).
Trajectory + human boundary
Vs prior material findings: Closed / Improved / Persistent / Regressed / Superseded. Then: is debt accumulating or declining?
Human / Runtime Verification Queue: Question · why static review cannot resolve it · expert/test · priority. Knowing where automated confidence ends is part of the review.
Backlog
Only VERIFIED or REDUCED items. Search for an existing equivalent first. Format: Area · Finding · Severity · Evidence · Recommended remediation · Effort · Verification condition (what evidence CLOSES it). Prioritize risk × commercial consequence × architectural leverage ÷ effort. Deletion is a valid intervention. Do not hyperscale-overengineer a prototype-stage product.
Deliverables
- Canvas scorecard (VP verdict, VC verdict, grades/flags, top verified findings, notable withdrawals, trajectory, human queue, execution order).
- Full evidence-backed review in chat.
docs/backlog.mdupdate after verification only.- This rule (the charter). Do not overwrite the run-agent rule.
- Update
docs/technical-due-diligence.htmlonly if current findings materially change its claims.
Final question (both lenses)
If development stopped today and this repo were handed to an experienced product/engineering org for commercial deployment, what would they inherit — and what few things must change before you would put your name behind it? Then the execution sequence.