@vextlabs/theron-cli 0.2.1 → 0.4.0

package/skills/options-strategy.md

@@ -0,0 +1,166 @@
+---
+name: options-strategy
+description: Educational options-strategy explainer: given a named strategy or market outlook, produce structure, payoff diagram (ASCII), breakevens, max gain/loss, Greeks, ideal market scenario, risk-first sizing guidance, and a mandatory not-investment-advice disclaimer.
+allowed-tools: Read, Bash, Write
+---
+
+KEY PRINCIPLE: Lead with the worst case, size for survival, and treat every scenario as a hypothesis — the market does not owe you the outcome the strategy was designed for.
+
+═══ HARD RULES ═══
+
+1. EDUCATIONAL ONLY. Every output closes with the full disclaimer block (Phase F). No exceptions, even for partial answers.
+2. NEVER fabricate specific ticker prices, IV levels, bid/ask spreads, or historical returns as ground truth. Label every numeric example "ILLUSTRATIVE."
+3. NEVER recommend position size in dollar terms for a specific user. Provide the sizing methodology; the user applies it to their own account and risk tolerance.
+4. NEVER omit risk/max-loss. Risk comes BEFORE reward in every section — inverting this order = reject the draft.
+5. NEVER conflate a scenario with a forecast. Use "scenario" / "if X occurs" — not "will," "should," or "expect."
+6. NEVER skip the Greeks. Omitting any of delta, gamma, theta, vega, rho (even to say "immaterial at this DTE") is incomplete work.
+7. NEVER advise on tax treatment, margin requirements, or broker-specific rules — flag each as a consult-your-broker item.
+8. If the user describes a position that implies more than 5 % of an implied portfolio, flag concentration risk explicitly before proceeding.
+9. Domain-lock: reject any request to extend this playbook to futures, CFDs, or leveraged ETFs — those instruments require separate treatment with different risk profiles.
+
+═══ PHASE A — INTAKE & CLARIFICATION ═══
+
+A1. Identify the strategy name or the directional/volatility thesis the user wants to express.
+    - Named strategy (e.g., "iron condor", "bull call spread", "short strangle") → proceed to Phase B.
+    - Thesis only (e.g., "I think AAPL drifts sideways for 6 weeks") → map to 2–3 candidate structures;
+      explain the tradeoffs between them; ask user to select one before continuing.
+
+A2. Capture the following before producing analysis:
+    - Underlying asset class (equity, ETF, index — each has assignment and liquidity differences).
+    - Approximate expiry horizon in days-to-expiry (DTE). Flag: strategies behave differently at <21 DTE vs 30–45 DTE vs 60+ DTE.
+    - Whether the user wants to understand an existing position or construct a new one.
+    - American-style vs European-style exercise (American = early assignment risk on short legs; state this explicitly).
+
+A3. IV context:
+    - If IV rank (IVR) or IV percentile is provided, record it and factor it into Phase C4.
+    - If not provided: "Current IV relative to its own history (IVR or IV percentile) is a critical input for strategy selection. Retrieve it from your platform — do NOT rely on any figure I provide."
+
+A4. Flag the following as user-verify items before any trade:
+    - Upcoming earnings date (can cause IV crush or gap risk that invalidates the strategy's assumptions).
+    - Ex-dividend date (relevant for short calls on single stocks — early assignment risk spikes when the short call goes deep ITM near ex-div).
+    - Corporate actions (splits, mergers, spin-offs can alter contract terms).
+    - Pin risk: near expiry, a short strike that lands exactly at the underlying price creates uncertain assignment; flag if expiry is within 1 week.
+
+═══ PHASE B — STRATEGY ANATOMY ═══
+
+B1. STRUCTURE
+    - State the legs in standardized form: [BUY/SELL] [QTY] [EXPIRY] [STRIKE] [CALL/PUT] per leg.
+    - Label each leg's role: long premium leg / short premium leg / hedge wing.
+    - State net debit or net credit (ILLUSTRATIVE, use placeholder prices).
+    - State whether the strategy is **defined-risk** or **UNDEFINED RISK** — bold UNDEFINED RISK if any leg is uncapped.
+    - For American-style short legs: explicitly note early assignment risk and when it is elevated
+      (short calls near ex-dividend; short puts deep ITM; any short leg inside final week of expiry).
+
+B2. PAYOFF DIAGRAM (ASCII)
+    - Draw a profit/loss vs underlying price at expiration diagram.
+    - Mark: max gain zone, max loss zone, each breakeven point, and current underlying price as "S₀ — user must insert."
+    - Redraw the shape appropriate to the actual strategy:
+
+      Single-breakeven, long-debit example (bull call spread):
+        P/L
+         |                  ___________
+         |                 /
+       0 |________________/
+         |  (max loss)
+         +---------------------------------> Underlying at expiry
+                          BE₁
+
+      Double-breakeven, credit-range example (iron condor / short strangle):
+        P/L
+         |         ___________
+         |        /           \
+       0 |_______/             \________
+         |
+         +---------------------------------> Underlying at expiry
+               BE₁              BE₂
+
+    - State which diagram shape applies and adapt it; do not paste a mismatched skeleton.
+
+B3. BREAKEVEN(S)
+    - Derive algebraically from strikes and net premium. Show the formula first, then substitute illustrative figures.
+    - For multi-leg structures: compute each breakeven separately; state which side carries which risk.
+    - Examples of correct formula derivation (ILLUSTRATIVE placeholders):
+        Bull call spread: BE = lower strike + net debit paid
+        Iron condor: upside BE = short call strike + net credit; downside BE = short put strike − net credit
+
+B4. MAX GAIN / MAX LOSS
+    - State maximum loss first.
+    - Defined-risk: express as formula then illustrative dollar figure per contract (= per 100 shares notional).
+    - Undefined-risk: state "theoretically unlimited / capped only by underlying going to zero" as applicable.
+    - State the exact market scenario that produces max loss in plain English.
+    - State the exact market scenario that produces max gain.
+    - Early assignment note for American-style: "A short leg assigned early can convert a defined-risk structure into an undefined-risk position if the long hedge is not also exercised. This is a material risk that must be managed actively, not assumed away."
+
+═══ PHASE C — THE GREEKS ═══
+
+C1. Deliver a table with sign and qualitative magnitude at initiation. Specify whether the analysis assumes ATM, OTM, or ITM positioning:
+
+    | Greek  | Sign at Open | Strategy-specific meaning                                                  |
+    |--------|-------------|-----------------------------------------------------------------------------|
+    | Delta  | +/−/≈0      | Net directional exposure; $1 move in underlying changes position P/L by delta × 100 per contract |
+    | Gamma  | +/−         | Rate of delta change per $1 move; long gamma = you benefit from big moves; short gamma = you bleed on big moves |
+    | Theta  | +/−         | Calendar P/L per day at rest; net credit strategy = positive theta (time is working for you); net debit = negative |
+    | Vega   | +/−         | P/L sensitivity to a 1-vol-point change in implied volatility (e.g., IV moves from 30% to 31% = +1 vega per share) |
+    | Rho    | +/−/≈0      | Interest-rate sensitivity; typically immaterial for positions with DTE < 90; material for long-dated LEAPS |
+
+C2. State the DOMINANT Greek for this strategy — the one most likely to determine P/L in the primary scenario — and explain it in one plain-English paragraph tied to the specific strategy being discussed.
+
+C3. Describe how the Greek profile CHANGES through the trade's life:
+    - Gamma risk: for short options, gamma magnitude increases sharply inside 21 DTE, especially when the underlying is near a short strike. This is the most common source of losses in short-premium strategies that are held too long.
+    - Theta acceleration: theta earned per day is not linear — it accelerates in the final 30 days (the "theta curve" bends steeply). Credit spreads benefit; debit spreads may not recover premium fast enough.
+    - Vega decay: as DTE shrinks, vega decreases — a position that was highly vega-sensitive at 60 DTE is less so at 10 DTE.
+
+C4. IV regime alignment:
+    - State clearly whether this strategy is NET LONG VEGA or NET SHORT VEGA.
+    - High IVR environment (e.g., IVR > 50): net short vega strategies (iron condors, short strangles, credit spreads) are structurally favored because elevated IV means more premium to collect and IV tends to mean-revert.
+    - Low IVR environment (e.g., IVR < 25): net long vega strategies (long straddles, debit spreads, calendar spreads) are structurally favored because cheap options make outright premium purchases more viable.
+    - Instruction: "Check your platform for the current IVR or IV percentile for this underlying before entry. This single data point can confirm or disqualify the strategy."
+
+═══ PHASE D — SCENARIO MAPPING ═══
+
+D1. Label this block prominently: "SCENARIO ANALYSIS — NOT FORECASTS. These are if/then illustrations, not predictions."
+
+D2. Construct exactly three scenarios using realistic placeholder percentage moves anchored to the DTE and asset class (e.g., ±5–10% for a 30–45 DTE equity position; ±2–4% for an index):
+    - BULL scenario: underlying rises [X]% by expiry → illustrative P/L per contract, how Greeks evolved, which leg is now at risk.
+    - BASE scenario: underlying unchanged or drifts ±1–2% → illustrative P/L, theta collected, vega impact if IV changed.
+    - BEAR scenario: underlying falls [Y]% by expiry → illustrative P/L per contract, how Greeks evolved, which leg is now at risk.
+
+D3. For each scenario, state whether early exit or roll is a common practitioner consideration (framework, not advice):
+    - Profit target: "Many short-premium practitioners target closing at 50% of max credit to lock in gains and redeploy capital — this reduces time in the trade and exposure to gamma risk. This is a risk-management heuristic, not a rule. (Source: widely cited in retail options education, popularized by TastyTrade research.)"
+    - Loss management: see Phase E4.
+
+D4. State the specific market condition that makes this strategy wrong even if the thesis is right:
+    - Example: "A long straddle is wrong if IV collapses immediately after entry, even if a large price move eventually occurs — the IV crush can exceed the gains from delta."
+    - Example: "An iron condor is wrong if the underlying trends strongly in one direction — the strategy is built for range-bound behavior, not trending markets."
+
+═══ PHASE E — RISK MANAGEMENT & POSITION SIZING METHODOLOGY ═══
+
+E1. RISK-FIRST FRAMING
+    - Restate maximum dollar loss per contract (from Phase B4) at the top of this section.
+    - State: "Before sizing, determine the maximum dollar amount you are personally willing to lose on this trade. That figure drives contract count — not conviction level, not potential profit."
+
+E2. POSITION SIZING METHODOLOGY (educational framework only — ILLUSTRATIVE)
+    - Fixed-fractional method:
+        max contracts = floor( (account_size × risk_per_trade_fraction) ÷ max_loss_per_contract )
+    - Illustrative example: "A $50,000 account using a 1% per-trade risk rule has a risk budget of $500. If max loss per contract = $250, the formula yields floor(500 ÷ 250) = 2 contracts. ILLUSTRATIVE ONLY — do not apply these numbers to your account without independent verification."
+    - Warn: "The defined max loss above assumes the trade is held to expiry and the broker executes cleanly. Real outcomes include bid/ask slippage on closing, early assignment converting a defined loss to an undefined one, and gap moves at open that bypass intraday stops."
+
+E3. CONCENTRATION & CORRELATION FLAGS
+    - Single stock: flag earnings binary risk, dividend-induced assignment, and sector concentration if the user holds other positions in the same sector.
+    - Index: note that tail events (sudden VIX spikes) cause all short-vega positions across different underlyings to lose simultaneously — correlation converges to 1 in a panic.
+    - Hard Rule 8 trigger: if the user implies more than 5% of portfolio exposure, state the concentration flag explicitly and pause before sizing guidance.
+
+E4. ROLL, ADJUST, OR CLOSE TRIGGERS (framework, not advice — confirm thresholds with a financial professional)
+    - Losing side approaches short strike with >21 DTE remaining: common practitioners evaluate rolling the tested side out in time and/or up/down in strike to collect additional credit or reduce delta.
+    - Credit strategy mark-to-market loss reaches 2× the original credit received: many practitioners close to cap the loss and prevent runaway exposure. Rationale: the trade's expected value has likely degraded beyond the original thesis.
+    - Inside 21 DTE with an untested structure: many practitioners close regardless of P/L to avoid gamma spike risk. The theta remaining is typically not worth the gamma exposure.
+
+E5. BROKER / MARGIN NOTE
+    - Undefined-risk strategies (naked puts, short strangles, ratio spreads) require margin approval — typically Level 3 or 4 depending on broker. "Verify your approval level and margin requirement with your broker before entering — these vary by institution and are not covered here."
+
+═══ PHASE F — CLOSING DISCLAIMER (MANDATORY — NEVER OMIT, OUTPUT VERBATIM) ═══
+
+---
+EDUCATIONAL CONTENT — NOT INVESTMENT, FINANCIAL, OR TAX ADVICE.
+Options trading involves substantial risk of loss and is not appropriate for all investors. The examples, figures, and frameworks above are illustrative only and do not represent actual market prices, returns, or recommendations. Past performance of any strategy does not guarantee future results. Greeks, payoffs, and breakevens assume simplified conditions (European exercise, no dividends, no early assignment risk unless explicitly noted); real American-style contracts may behave differently. Always verify current prices, implied volatility, margin requirements, tax treatment, and suitability with a licensed financial professional and your broker before trading. This content is produced by an AI system and may contain errors — independently verify all calculations before relying on them.
+---

package/skills/peer-review.md

@@ -0,0 +1,96 @@
+---
+name: peer-review
+description: Review a paper/manuscript like a journal referee — summarize the contribution, assess soundness/novelty/reproducibility, separate major from minor, end with a justified recommendation.
+allowed-tools: Read, WebSearch, WebFetch, Write
+---
+
+## PHASE 0 — INGEST
+
+1. Read the full paper top to bottom before writing a single note. Do not critique as you read the first pass; just understand.
+2. Identify: paper type (empirical / theoretical / methods / survey / replication). Your checklist shifts by type.
+3. Pull the abstract's explicit claims into a numbered list. These are your audit targets.
+
+## PHASE 1 — CONTRIBUTION SUMMARY (proves comprehension)
+
+4. In 3-6 sentences, restate the paper's claimed contribution in your own words — no lifted phrases. If you cannot do this, you do not yet understand the paper; re-read.
+5. State the research question the paper is trying to answer and why the authors argue it matters.
+6. Identify the central hypothesis or design choice the whole paper rests on. This is the load-bearing beam you will stress-test.
+
+## PHASE 2 — SOUNDNESS
+
+7. **Methods vs claims:** For each claim in your Phase 0 list, ask: does the described method actually test this? Flag any mismatch as a potential major concern.
+8. **Statistics:** Check reported test statistics, p-values, confidence intervals, and effect sizes for internal consistency (e.g., t-value and p-value must agree; CI must be symmetric for normal assumptions). Note any that look off; never fabricate a recomputation you did not actually do.
+9. **Confounds:** List the top 3 alternative explanations for the key result. Does the paper rule them out? If not, name the uncontrolled confound specifically (e.g., "participants in condition A were tested in the morning and condition B in the afternoon; time-of-day confound is unaddressed").
+10. **Sample and power:** Is the sample size justified? Is there a power calculation? For small-N results, assess whether the claimed effect size is plausible given field norms. Flag underpowered studies explicitly.
+11. **Ablations / controls:** For methods papers, enumerate what was ablated. Flag any missing ablation that would isolate the claimed mechanism.
+12. **Theoretical claims:** For theory papers, check whether the proof sketch is complete or hand-wavy; identify the step most likely to contain an error.
+
+## PHASE 3 — NOVELTY AND SIGNIFICANCE
+
+13. State what you believe the closest 2-3 prior works are. Use WebSearch if needed to verify ("X et al. YEAR, venue").
+14. For each prior work: what exactly does this paper add? Incremental extension, new setting, new mechanism, or genuinely new result?
+15. Is the delta sufficient for the venue? Be explicit: "This extends X by Y; for a Nature Methods paper this is [sufficient / insufficient] because Z."
+16. Flag overclaiming: if the authors write "first ever" or "no prior work," verify it. If wrong, cite the counterexample.
+
+## PHASE 4 — REPRODUCIBILITY
+
+17. List what a replication attempt needs: dataset, code, hardware, hyperparameters, random seeds, preprocessing steps.
+18. Check each against what the paper/supplement provides. Mark each as: PRESENT / PARTIAL / MISSING.
+19. If code is promised but not yet released, note it as a minor concern unless the method is too complex to re-implement without it (then major).
+20. For datasets: is it publicly available, behind a license wall, or proprietary? If proprietary, is a synthetic stand-in sufficient?
+
+## PHASE 5 — FIGURES, TABLES, AND NUMBERS
+
+21. For every figure: does the caption fully describe what is shown? Is the axis labeled with units? Are error bars defined (SD, SEM, 95% CI)?
+22. Cross-check: pick 3-5 numbers that appear in both a figure/table and the text. Do they match exactly? Discrepancies are a red flag — note them with section and line.
+23. Check that the visual encoding is honest: y-axes should start at zero for bar charts (or be explicitly justified); log scales must be labeled.
+24. Verify that all conditions/baselines mentioned in the methods appear in the results. Missing conditions = major concern.
+
+## PHASE 6 — CLAIMS VS EVIDENCE
+
+25. For each abstract claim, score it: SUPPORTED / OVERSTATED / UNSUPPORTED. Document the evidence gap for any overstated or unsupported claim.
+26. Watch for scope creep in the discussion: does the paper generalize results beyond the tested population, domain, or setting without qualification? Flag each instance with the line number.
+27. Hedge appropriately: distinguish between "the method does not work" and "the evidence does not yet establish that the method works."
+
+## PHASE 7 — MAJOR vs MINOR CONCERNS
+
+28. MAJOR concern = threatens the validity of a core claim, requires new experiments/analysis, or reveals a logical flaw. A paper cannot be accepted with unresolved majors.
+29. MINOR concern = does not threaten conclusions; addressable by clarification, additional figure, or wording change.
+30. Format each concern as:
+    - **[MAJOR/MINOR] [Section X, line Y]:** One-sentence statement of the problem. One-sentence explanation of why it matters. One-sentence actionable request.
+31. Do NOT aggregate concerns. Each concern gets its own numbered entry. Bundling hides severity.
+32. Aim for completeness, not length. Three specific majors beat twelve vague ones.
+
+## PHASE 8 — CONSTRUCTIVE TONE
+
+33. Address the work, not the authors. Write "the analysis does not account for..." not "the authors failed to...".
+34. For every major concern, suggest a concrete path to resolution (additional experiment, alternative analysis, reframing of the claim).
+35. Acknowledge genuine strengths before concerns. Identify 2-3 things the paper does well and say so briefly — this is not flattery, it is calibration.
+36. If you are uncertain whether something is a flaw, say so: "I may be missing context, but I could not find where the authors address [X]." Never fabricate certainty.
+
+## PHASE 9 — ETHICS AND INTEGRITY
+
+37. Check: does the study involving human subjects report IRB/ethics board approval?
+38. Check: are conflicts of interest disclosed?
+39. Check: does any figure look manipulated (e.g., gel bands, microscopy images with discontinuities, suspiciously smooth curves)? Note any anomaly; do not accuse — request the raw data.
+40. Check: is the related-work section balanced, or does it systematically omit a competing line of work? Name the omitted line if so.
+41. If you suspect plagiarism or data fabrication, state the specific evidence pattern; do not make the accusation directly in the review — flag it to the editor separately.
+
+## PHASE 10 — RECOMMENDATION
+
+42. Choose exactly one: **Accept** / **Minor Revision** / **Major Revision** / **Reject**.
+43. Accept: no major concerns; minor concerns are optional for authors to address.
+44. Minor Revision: no experiment-level majors; authors must address listed minors and confirm in a response letter.
+45. Major Revision: one or more experiment/analysis-level majors that the authors can plausibly address in 2-4 months.
+46. Reject: core claim is unsupported by the methods, fatal flaw cannot be fixed without a new study, or contribution is insufficient for this venue.
+47. Write 2-4 sentences justifying the recommendation by tying it directly to your listed major concerns (or the absence of them).
+
+## HARD RULES
+
+- Never write "the paper is well-written" as a substitute for engagement with the content.
+- Never claim to have verified a statistical recomputation you did not perform.
+- Never use the word "interesting" without following it with why.
+- Every concern must cite a specific location (section, figure, line, or equation number).
+- Do not recommend rejection solely because you disagree with the authors' research direction.
+- If you used WebSearch to check prior work or facts, say so in the review.
+- The review is confidential; do not reveal your identity or speculate about other reviewers.

package/skills/pentest-plan.md

@@ -0,0 +1,193 @@
+---
+name: pentest-plan
+description: Plan and execute an authorized penetration test: scope lock, attack-surface enumeration mapped to OWASP Top 10 + API/cloud-native vectors, likelihood×impact prioritization, evidence capture standards, and non-destructive guardrails — invoke when asked to pentest, assess, or audit a system for security vulnerabilities.
+allowed-tools: Read, Write, Grep, Bash
+---
+
+⚠️  LEGAL DISCLAIMER: Penetration testing without explicit written authorization is unauthorized computer access under the CFAA (US), Computer Misuse Act (UK), and equivalent statutes worldwide. This skill is for use only by or on behalf of an operator who holds current written authorization for every target system. The operator bears full legal responsibility for proper scoping and authorization. Claude will not assist if authorization cannot be established.
+
+═══ HARD RULES ═══
+
+1. AUTHORIZATION FIRST, ALWAYS. Do not touch a single host, port, or endpoint until you hold written authorization (signed rules-of-engagement doc or equivalent) naming the exact scope. No authorization = no engagement. This is what separates a pentest from a crime.
+2. STAY IN SCOPE. Every action must be traceable to a named scope item. If a pivot would take you out of scope, stop, document the finding ("lateral path would reach out-of-scope asset X via Y"), and report it — do not cross the line.
+3. NON-DESTRUCTIVE BY DEFAULT. Prefer read-only probing. Never delete data, corrupt databases, crash services, lock out real user accounts, or exfiltrate real PII. Proof-of-concept exploits must stop at demonstration of impact (captured response, controlled OOB callback, screenshot) — never at weaponized payload delivery or full data dump.
+4. EVIDENCE IS MANDATORY. Every finding must have reproducible evidence: raw request/response, timestamp, exact tool command and version, screenshot where applicable. A finding without evidence does not exist.
+5. HALT-AND-NOTIFY TRIGGERS. Stop immediately and notify the client if you: hit a live production database with real customer PII, discover an active third-party breach already in progress, or find credentials that grant access to assets outside the authorized scope.
+6. NO FABRICATED FINDINGS. Never inflate severity or invent vulnerabilities. If a test is inconclusive due to WAF interference, rate limiting, or missing client cooperation, record it as Inconclusive with the reason.
+
+═══ PHASE A — SCOPE & AUTHORIZATION LOCK ═══
+
+A1. Obtain and read the signed Rules of Engagement (RoE) document. Extract and record:
+    - In-scope IP ranges (CIDR notation), FQDNs, application URLs, API base paths, GraphQL endpoints, mobile app bundle IDs, and cloud account IDs.
+    - Out-of-scope assets (shared hosting neighbors, third-party SaaS integrations, production DBs if excluded, CDN edge nodes not owned by client).
+    - Permitted test windows (e.g., "weeknights 22:00–06:00 UTC only").
+    - Permitted techniques (confirm explicitly: no DoS / no social engineering / no physical access / no credential stuffing against live user accounts).
+    - Emergency halt contact (name, mobile number, escalation path) and the exact phrase that signals "stop all testing."
+A2. Confirm authorization in writing from a person with legal authority over the target systems — not just a developer, team lead, or project manager. A CISO or legal signatory is the minimum bar for production systems.
+A3. Create an isolated engagement directory immediately. Every tool invocation, stdout/stderr, and observation goes in there with an ISO 8601 timestamp from minute one. Never commingle engagement artifacts with other work.
+A4. Validate scope boundaries technically before any active testing:
+    - Reverse-lookup every in-scope IP to confirm it resolves to a client-controlled asset, not a shared hosting neighbor, CDN edge node, or cloud provider IP block shared with other tenants.
+    - For cloud-hosted targets, confirm the account ID matches the client's documented account — not a staging account owned by a third-party dev shop.
+
+═══ PHASE B — RECONNAISSANCE & ATTACK SURFACE ENUMERATION ═══
+
+B1. Passive recon (zero direct target contact):
+    - DNS: A, AAAA, MX, TXT (SPF/DKIM/DMARC), NS, CNAME, SOA records. Use `dig` or `dnsx`.
+    - Certificate transparency: `curl -s "https://crt.sh/?q=<apex_domain>&output=json" | jq '.[].name_value'` — reveals subdomains and wildcard certs.
+    - Historical exposure: Shodan (`ssl.cert.subject.cn:<domain>`), Censys, FOFA, Netcraft, SecurityTrails.
+    - Wayback Machine / Common Crawl: endpoint discovery for retired but still-live paths (`gau` or `waybackurls <domain>`).
+    - GitHub/GitLab/Bitbucket: `trufflehog github --org=<client_org>` and `git log --all -p | grep -E "(password|api_key|secret|token)"` on any leaked repos.
+    - Job postings and LinkedIn: infer technology stack (e.g., "Senior Rails Engineer" = likely Ruby on Rails with ActiveRecord; "AWS Lambda" = serverless attack surface).
+B2. Active recon (scoped hosts only, no exploitation):
+    - Port scan: `nmap -sV -sC -p- --open -T3 --reason <scope_cidr>` — log every open port, service banner, and OS guess. Flag anything on non-standard ports.
+    - Web fingerprinting: server headers (`Server`, `X-Powered-By`, `X-Generator`), CMS/framework detection (`whatweb`, Wappalyzer), JS bundle analysis for framework version strings (webpack chunk filenames, React DevTools patterns, Angular `ng.version`).
+    - Subdomain enumeration against authorized apex domains: `subfinder -d <domain> | httpx -silent` — test only those that resolve to in-scope IPs.
+    - API surface discovery: `ffuf -u https://<host>/FUZZ -w /path/to/api-wordlist.txt -mc 200,301,401,403` — OpenAPI/Swagger endpoints (`/swagger.json`, `/openapi.yaml`, `/api-docs`), GraphQL (`/graphql`, `/graphiql`), gRPC reflection.
+    - Cloud storage: enumerate S3 buckets/Azure blobs/GCS buckets derived from target name patterns (`<company>-backups`, `<company>-assets`, `<company>-dev`). Test for public read/write only — never write to client storage.
+B3. Map every discovered surface item to an OWASP category (or API Top 10 / cloud-native category) and enter it in the attack surface checklist before proceeding. Nothing advances to Phase C without a checklist entry.
+
+ATTACK SURFACE CHECKLIST TEMPLATE (one row per surface item):
+| ID  | Asset                          | Category              | Entry Vector       | Priority | Status      |
+|-----|--------------------------------|-----------------------|--------------------|----------|-------------|
+| S01 | /api/v1/auth (login)          | OWASP A07 Auth        | HTTP POST, unauth  | —        | Queued      |
+| S02 | /admin (admin panel)           | OWASP A01 BAC        | HTTP GET           | —        | Queued      |
+| S03 | /graphql                       | API1 BOLA            | HTTP POST, authed  | —        | Queued      |
+| S04 | EC2 169.254.169.254 via SSRF   | Cloud IMDS            | HTTP GET via proxy | —        | Queued      |
+| ... | ...                            | ...                   | ...                | —        | ...         |
+
+═══ PHASE C — PRIORITIZATION (LIKELIHOOD × IMPACT) ═══
+
+C1. Score each checklist item on two axes (1–3 scale):
+    - Likelihood: 1=requires auth+rare conditions / 2=requires one auth factor or known exploitation pattern / 3=unauthenticated and internet-exposed.
+    - Impact: 1=information disclosure only / 2=user-scoped data exposure or partial account takeover / 3=full account takeover, RCE, admin compromise, or mass data exfiltration.
+    - Priority = Likelihood × Impact. Score 9 or 6 = P0 (test first), 4 = P1, 1–3 = P2.
+C2. Mandatory P0 checks regardless of score — these have historically carried the highest real-world impact and must not be deprioritized:
+    - Authentication bypass on any login, session management, or MFA endpoint.
+    - SQL injection on any parameter that reaches a relational database.
+    - Remote code execution vectors: Java/PHP deserialization, unrestricted file upload to a web root, SSTI (Jinja2, Twig, Freemarker), and ImageMagick/FFmpeg processing paths.
+    - IDOR / BOLA on any resource keyed to a user ID, document ID, or account ID.
+    - Exposed admin interfaces reachable without VPN or IP allowlist.
+    - SSRF via any URL-fetching feature targeting cloud IMDS (169.254.169.254 / fd00:ec2::254 for IMDSv2).
+
+═══ PHASE D — TESTING EXECUTION ═══
+
+--- D-A01 Broken Access Control (OWASP A01) ---
+- Horizontal escalation: authenticate as User A, manually replace user/account/document IDs in every request with User B's IDs. Flag any 200 or partial data response where 403 is expected.
+- Vertical escalation: with a low-privilege account, directly request admin-only endpoints identified in B2 (`/admin`, `/api/admin/*`, `/management`). Test HTTP method switching (GET→PUT→DELETE) on resource endpoints.
+- JWT privilege escalation: decode the JWT, modify role/group claims, re-sign with `alg:none` or a known-weak secret, and replay.
+- Evidence: raw HTTP request/response pair showing unauthorized data access or operation success.
+
+--- D-A02 Cryptographic Failures (OWASP A02) ---
+- TLS configuration: `testssl.sh --full <host>` — reject TLS 1.0/1.1 (flag), RC4/DES/3DES/EXPORT ciphers (flag as High), missing HSTS (flag as Medium).
+- Cookie security: every `Set-Cookie` response must have `Secure; HttpOnly; SameSite=Lax|Strict`. Missing any = flag.
+- Sensitive data in transit: confirm no plaintext HTTP alternative exists (`curl -I http://<host>` — a 200 instead of redirect = High).
+- Password storage: if source or error messages reveal storage mechanism, flag MD5/SHA-1/unsalted hashes as Critical; bcrypt/argon2/scrypt = acceptable.
+- Evidence: testssl.sh output, response headers verbatim.
+
+--- D-A03 Injection (OWASP A03) ---
+- SQL injection: for every parameterized input, test: `'`, `''`, `1' OR '1'='1`, `1; SELECT SLEEP(5)--`, `' UNION SELECT NULL--`. Confirm blind injection via boolean response diff AND time-based (`SLEEP(5)` / `pg_sleep(5)` / `WAITFOR DELAY '0:0:5'`).
+- NoSQL injection (MongoDB): `{"username": {"$gt": ""}, "password": {"$gt": ""}}` in JSON body; for URL params: `?username[$ne]=x`.
+- OS command injection: in any input that reaches shell execution: `;id`, `|id`, `$(id)`, `` `id` ``. Blind variant: `; sleep 5`.
+- SSTI: inject `{{7*7}}` (Jinja2/Twig), `<%= 7*7 %>` (ERB), `${7*7}` (Freemarker). A `49` in the response = Critical RCE surface.
+- LDAP injection: `*)(uid=*))(|(uid=*`.
+- Evidence: error message, response delta, timing difference, or OOB DNS callback proving injection. Stop at PoC — do not dump tables, exfiltrate data, or escalate to OS shell.
+
+--- D-A04 Insecure Design — Business Logic (OWASP A04) ---
+- Password reset flow: capture the reset token. Test: (a) token reuse after use — replay the link, expect 400/expired; (b) token expiry — wait >1hr, replay, expect expired; (c) token entropy — collect 5 tokens sequentially, confirm they are not sequential or predictable; (d) host-header injection — send reset with `Host: attacker.com`, check if reset link in email uses attacker domain.
+- Multi-step flow manipulation: in checkout/order/enrollment flows, skip steps by directly POSTing to step N+2. Test for negative quantity exploits (`quantity: -1`) producing negative totals or refunds.
+- Race conditions: use Turbo Intruder or `ffuf` with a concurrent thread pool to submit a gift card / coupon code redemption simultaneously on two sessions. If both succeed = finding.
+- Mass assignment: POST a create-user request with extra fields (`role=admin`, `is_verified=true`, `credit_balance=9999`). If reflected in response or applied = Critical.
+- Evidence: request/response pairs showing the business rule being bypassed; for race conditions, show both sessions received the benefit.
+
+--- D-A05 Security Misconfiguration (OWASP A05) ---
+- Directory listing: `curl -I https://<host>/static/` — a `200` with HTML directory index = finding.
+- Default credentials: test admin/admin, admin/password, and product-specific defaults (Tomcat manager: tomcat/tomcat; Jenkins: admin/admin; Grafana: admin/admin; phpMyAdmin root/root).
+- Verbose error messages: trigger a 500 by sending a malformed JSON body or unexpected type. Stack traces exposing file paths, class names, or framework internals = Medium.
+- CORS misconfiguration: set `Origin: https://attacker.com` in the request. If response contains `Access-Control-Allow-Origin: https://attacker.com` AND `Access-Control-Allow-Credentials: true` = Critical (cross-origin cookie theft).
+- HTTP security headers: flag absence of `Content-Security-Policy`, `X-Frame-Options` (or CSP `frame-ancestors`), and `X-Content-Type-Options: nosniff`.
+- Evidence: raw response headers and bodies.
+
+--- D-A06 Vulnerable and Outdated Components (OWASP A06) ---
+- Extract all identified library/framework versions from response headers, JS bundles, package manifest files discovered in recon.
+- Cross-reference with tooling: `trivy fs .` (local repo), `grype <image>` (container), `pip-audit` (Python), `npm audit --audit-level=high` (Node), `osv-scanner` (language-agnostic). Do not rely solely on manual NVD lookup — automated scanners catch transitive dependency CVEs that manual review misses.
+- Do NOT exploit a CVE that would cause service disruption (e.g., DoS, data corruption, crash). Document the CVE ID, CVSS score, and affected version, then defer exploitation to a controlled lab environment if the client requests PoC.
+- Evidence: version string from the application + CVE ID + CVSS v3.1 score + link to NVD advisory.
+
+--- D-A07 Authentication & Session Management (OWASP A07) ---
+- Account lockout: submit ≥10 failed logins. No lockout and no CAPTCHA after 5 = finding (Medium). Confirm lockout persists (not just rate-limited for 30s).
+- JWT attacks: decode with `jwt_tool` or manual base64 decode. Test: (a) `alg:none` — strip signature, set alg to none; (b) RS256→HS256 confusion — re-sign HS256 with the server's public key as the HMAC secret; (c) weak secret — offline brute-force with `hashcat -a 0 -m 16500 <token> rockyou.txt`; (d) `kid` header injection — if `kid` value is used in a filesystem read, inject `../../../dev/null` or a SQL payload.
+- Session fixation: obtain a pre-auth session token, authenticate, confirm the session token rotates post-login. If same token before/after = Critical.
+- MFA bypass: test step-skipping (POST directly to the post-MFA endpoint with a valid pre-MFA session), OTP reuse (replay the same 6-digit code immediately), and backup code entropy.
+- Evidence: demonstration of token reuse, bypass, brute-force window, or session fixation.
+
+--- D-A08 Software & Data Integrity (OWASP A08) ---
+- Dependency confusion: identify internal package names from `package.json`, `requirements.txt`, `go.mod`, or error messages. Search npmjs.com / pypi.org / pkg.go.dev for a public package with the same name. If one exists and resolves at a higher version, the build system may pull the attacker's version — document as Critical if confirmed.
+- Subresource Integrity (SRI): inspect all `<script src="...">` and `<link rel="stylesheet">` tags loading from third-party CDNs. Missing `integrity="sha384-..."` attribute = Medium (supply-chain hijack if CDN is compromised).
+- CI/CD artifact integrity: check if deployment pipelines pull packages without pinned versions (e.g., `pip install requests` vs. `pip install requests==2.31.0`) and without hash verification. Flag unpinned dependencies in requirements files or Dockerfiles as Medium.
+- Auto-update mechanisms: confirm software update endpoints use TLS and verify signed manifests. Test for unsigned update delivery by inspecting update check requests/responses.
+- Evidence: package manifest showing unpinned/unverified source, missing SRI attribute in page source, or public namespace collision found.
+
+--- D-A09 Security Logging & Monitoring (OWASP A09) ---
+- Generate clearly anomalous events in sequence: 10 failed logins, a path traversal attempt (`/../../../etc/passwd`), a SQLi payload in a search field, and a request to a non-existent admin endpoint. Then ask the client (during the engagement debrief, with their cooperation) whether these events appeared in their SIEM/log aggregator and triggered any alert. Absence of alerts = High finding.
+- Log injection: inject a CRLF sequence into a logged parameter (`%0d%0aFakeLogEntry: admin_login_success`). If the fake entry appears in application logs, an attacker can forge log entries — Medium.
+- Sensitive data in logs: request the client share a sanitized log sample. Flag if full credit card numbers, plaintext passwords, or unmasked SSNs appear in log output.
+- Note: testing D-A09 fully requires client cooperation for log access. If unavailable, record as Inconclusive/Untested with the reason.
+- Evidence: client-confirmed log gap, CRLF injection response, or sensitive data present in provided log sample.
+
+--- D-A10 Server-Side Request Forgery (OWASP A10) ---
+- Identify every URL-fetching input: webhook URL fields, "import from URL" features, avatar-by-URL, PDF/screenshot generation services, URL preview generators, XML/SVG parsers with external entity support.
+- Test cloud IMDS: `http://169.254.169.254/latest/meta-data/iam/security-credentials/` (AWS IMDSv1 — no token required, Critical if readable). For IMDSv2, test if the app can be induced to send the `X-aws-ec2-metadata-token` header. Also test: `http://fd00:ec2::254` (IPv6 IMDS), `http://metadata.google.internal/computeMetadata/v1/` (GCP, requires `Metadata-Flavor: Google`), `http://169.254.169.254/metadata/instance` (Azure).
+- Test RFC-1918 internal ranges: `http://10.0.0.1/`, `http://192.168.1.1/`, `http://127.0.0.1:8080/` (localhost admin interfaces).
+- Blind SSRF: use a controlled OOB listener (Burp Collaborator, interactsh) — inject its URL and confirm DNS/HTTP callback. Even a DNS-only callback = confirmed SSRF (Medium if no data returned, High if further exploitable).
+- Evidence: response containing internal data, IAM credential keys, timing difference demonstrating internal routing, or confirmed OOB callback with timestamp.
+
+--- D-CLOUD Cloud-Native Attack Surface ---
+(Include this section for any cloud-hosted or cloud-native target.)
+- IAM role enumeration (AWS): if you have any AWS credentials in scope, `aws iam get-user`, `aws sts get-caller-identity`, `pacu` module `iam__enum_permissions` — map the effective permissions without triggering GuardDuty by keeping request volume low.
+- S3 bucket ACL: `aws s3api get-bucket-acl --bucket <bucket_name>` (with authorized creds), or unauthenticated: `curl -I https://<bucket>.s3.amazonaws.com/` — a 200/403 (not 404) means the bucket exists; test ListBucket with `aws s3 ls s3://<bucket> --no-sign-request`.
+- Lambda/function URL exposure: enumerate via `aws lambda list-functions` if credentialed; test any public function URLs for auth bypass or event injection.
+- Container metadata: if RCE or SSRF is achieved on a container, query `http://169.254.170.2/v2/credentials` (ECS task role) and `http://169.254.169.254/latest/meta-data/iam/security-credentials/` (EC2 role).
+- Evidence: API response containing role ARN, credential keys (redact before pasting into report), or bucket listing output.
+
+--- D-API API-Specific Attacks (OWASP API Top 10) ---
+(Include this section for any target exposing REST, GraphQL, or gRPC APIs.)
+- BOLA/IDOR (API1): same as D-A01 but systematically across every API resource endpoint. Prioritize endpoints returning collections (`GET /api/users`, `GET /api/orders`) — test for missing authorization by removing auth headers entirely.
+- Broken authentication (API2): test API keys in URL params vs. headers; test if API keys are scoped (does key for user A work on user B's resources?). Check for API key leakage in JS bundles (`grep -E "['\"]apiKey['\"]|x-api-key" <bundle.js>`).
+- Excessive data exposure (API3): compare what the API returns vs. what the UI renders. If the JSON response contains 40 fields but the UI shows 5, flag the unexposed fields as potential data over-exposure — especially PII fields.
+- GraphQL introspection (API7): `curl -s -X POST https://<host>/graphql -H "Content-Type: application/json" -d '{"query":"{__schema{types{name}}}"}'` — if introspection is enabled on a production endpoint, enumerate the full schema and map sensitive mutations. Test for batching attacks (send 100 queries in one request body) to bypass rate limits.
+- gRPC reflection: `grpcurl -plaintext <host>:<port> list` — if reflection is enabled, enumerate services and test for missing auth on sensitive RPCs.
+- Mass assignment (API6): POST/PUT with extra fields as in D-A04 — APIs are more frequently vulnerable because frontend validation is bypassed.
+- Evidence: raw request/response pairs, GraphQL schema dump (truncated to relevant types in report), gRPC service listing.
+
+═══ PHASE E — EVIDENCE CAPTURE STANDARD ═══
+
+For EVERY finding, capture ALL of the following before moving to the next test:
+E1. Raw HTTP request (all headers + full body) — copy from Burp/ZAP Proxy history, `curl -v` output, or `mitmproxy` dump. Never paraphrase.
+E2. Raw HTTP response (status code, all headers, body excerpt proving impact). For binary responses, capture the relevant portion.
+E3. Timestamp in ISO 8601 with explicit timezone (e.g., `2026-06-27T14:32:11Z`).
+E4. Tool name and exact version + full command invoked (e.g., `nmap 7.95 — nmap -sV -sC -p 443 10.0.1.5`).
+E5. Screenshot if a browser UI state is relevant to demonstrating impact (attach to report, do not paste as ASCII art).
+E6. Reproduction steps numbered 1–N that a fresh reader with basic pentest skills can follow to reproduce in under 10 minutes. Include any prerequisite account state (e.g., "logged in as a Standard user, not Admin").
+E7. CVSS v3.1 base score — compute it at https://www.first.org/cvss/calculator/3.1 or with `cvss3` CLI. Key vectors to get right: AV (Network vs. Adjacent vs. Local), AC (Low vs. High), PR (None vs. Low vs. High), UI (None vs. Required), S (scope change), C/I/A. Do not guess — wrong CVSS misleads remediation triage.
+E8. Remediation recommendation: specific, actionable, one paragraph. Name the exact fix (e.g., "Apply parameterized queries via PreparedStatement in JDBC" not "sanitize inputs"). Include a reference (OWASP Cheat Sheet URL, CWE ID, or CVE advisory) where applicable.
+
+═══ PHASE F — REPORTING ═══
+
+F1. Executive summary: 3–5 sentences targeting a non-technical audience. What systems were tested, what was the overall risk posture, what is the highest-severity finding and its business impact, and what is the single most important remediation action. No CVSS numbers in this section — translate to business impact (e.g., "an attacker could access any customer's purchase history without authentication").
+F2. Finding sheet per vulnerability (one per finding, ordered Critical→High→Medium→Low→Informational):
+    - Title (descriptive: "Unauthenticated IDOR on /api/orders/{id}" not "Access Control Issue")
+    - Severity: Critical / High / Medium / Low / Informational
+    - CVSS v3.1 base score and vector string
+    - OWASP Top 10 / API Top 10 category
+    - CWE ID
+    - Affected asset (exact URL, host, or resource)
+    - Description: what the vulnerability is, how it arises, why it matters
+    - Evidence: paste raw request/response or link to attachment
+    - Reproduction steps (numbered)
+    - Remediation: specific and actionable
+F3. Attack surface coverage table: every checklist item from Phase B with its test result (Vulnerable / Not Vulnerable / Inconclusive / Untested + reason). Never silently omit an item.
+F4. Untested items must be explicitly listed with the blocking reason (time constraint, WAF preventing confirmation, test would require destructive action, client cooperation not available, etc.).
+F5. Remediation priority order: Critical first, then CVSS descending within severity band. Do not reorder by ease-of-fix — that is the client's call, not the tester's.
+F6. Deliver the report as a file (PDF or Markdown), not a chat message. Confirm delivery method with the client contact named in the RoE before the engagement starts, and again when delivering.
+
+KEY PRINCIPLE: Authorization is what makes penetration testing legal — confirm it in writing, honor its scope exactly, and treat every finding as evidence requiring reproducible proof, never opinion. The moment you cannot trace an action to a scope item and a written authorization, stop.

package/skills/pitch-review.md

@@ -0,0 +1,132 @@
+---
+name: pitch-review
+description: Review a startup pitch deck with senior VC rigor — separates what is missing from what is wrong, benchmarks each dimension to stage norms, surfaces the 3 hardest investor objections, and identifies the single most important fix before the next meeting.
+allowed-tools: Read, Write
+---
+
+KEY PRINCIPLE: The job is not to rank the deck — it is to tell the founder exactly what a top investor will think, why, and what to do before the next meeting. Every output must be actionable before that meeting, not after the round closes.
+
+═══ USAGE ═══
+
+Invoke with: /pitch-review
+Input required: paste the deck text, attach a file the Read tool can access, or provide a slide-by-slide transcript. If none is supplied, refuse to proceed and ask the user to provide content — do not invent findings from a deck you cannot see.
+
+═══ HARD RULES ═══
+
+1. NEVER fabricate market-size figures, comparable funding rounds, or competitor metrics. If the deck supplies a number, interrogate its source. If you supply one, mark it [ESTIMATE] and state the derivation method explicitly.
+2. NEVER conflate MISSING (information the deck should contain but does not) with WRONG (information the deck asserts that is incorrect, incoherent, or will actively hurt the company). Keep these in separate labeled buckets throughout every phase.
+3. Stage-norm every judgment: a pre-seed deck without revenue is normal; a Series B deck without revenue is a red flag. State the inferred or claimed stage at the top and apply only the matching bar.
+4. Never recommend a pass or invest. This tool is diagnostic, not decisional — recommending an outcome would substitute your judgment for the investor's, who has diligence, LP constraints, and portfolio context you cannot see.
+5. Do not comment on deck aesthetics, animation, font, or layout. Fundability is determined by content, not design.
+6. When Phase B produces Missing/Wrong findings per dimension, Phase D must synthesize and deduplicate — do not re-list everything already covered; surface only the items that are cross-cutting or highest-severity.
+
+═══ PHASE A — INGEST AND STAGE-CALIBRATE ═══
+
+A1. Identify the claimed stage (pre-seed / seed / Series A / B / growth) and round size. If unstated, infer from traction signals and note the inference explicitly.
+
+A2. Map the standard slide inventory against what is present:
+    Cover · Problem · Solution · Why Now · Market (TAM/SAM/SOM) · Product · Business Model · Traction · Team · Competition · Go-to-Market · Financials · Ask + Use of Funds
+    Flag each as PRESENT / MISSING / PARTIAL.
+
+A3. Record the founding team names, titles, and any stated domain credentials. Note the gap between claimed expertise and the problem domain.
+
+A4. State the deck's thesis in one sentence — your reconstruction from the deck, not their tagline. Every assessment in Phase B is tested against this thesis. If no coherent thesis can be extracted, flag it here; a deck without a unifying thesis cannot be fixed by better slides.
+
+═══ PHASE B — DIMENSION-BY-DIMENSION ASSESSMENT ═══
+
+For each dimension: assess against the stage from A1, not against the best deck you have ever seen.
+
+B1. TEAM
+   - Relevant prior: have founders built or shipped anything adjacent? Domain expertise vs. operator experience — which matters more for this specific problem?
+   - MISSING: prior exits, relevant domain credentials, key hires made or committed, advisors with actual network in the target market (not honorary titles).
+   - WRONG: title inflation (C-suite of one; "ex-Google" with a 3-month tenure listed without context); founder-market fit asserted without evidence of lived customer experience.
+   - Stage norm: pre-seed = founding story and observable commitment is evidence enough. Series A = team must demonstrably show they can hire and retain people better than themselves.
+
+B2. MARKET
+   - Interrogate the TAM methodology: top-down (analyst citation) vs. bottom-up (unit count × addressable price). Bottom-up always outperforms top-down with sophisticated investors because it shows the founder understands the customer.
+   - MISSING: SAM and SOM with explicit derivation logic; the first target segment named with a reason why that segment and not another.
+   - WRONG: circular TAM ("the market is $X because the analyst says so" with no unit math); inflating TAM by aggregating adjacent markets the product does not serve; citing a market with no demonstrated willingness to pay for a solution like this one.
+   - Stage norm: seed = directional SAM matters more than TAM precision. Series A = bottoms-up SAM with at least one paying-customer proof point validating the assumed unit price.
+
+B3. PROBLEM AND INSIGHT
+   - Is there a falsifiable claim about why this problem is acute today and was not five years ago?
+   - MISSING: customer discovery evidence (number of interviews, verbatim pain quote, current workaround cost in dollars or hours). Without this, the problem is the founder's opinion.
+   - WRONG: solution-first framing dressed as a problem slide; pain described as mission-critical when the current workaround is "we use a spreadsheet" (mild inconvenience, not acute pain).
+
+B4. SOLUTION AND PRODUCT
+   - Does the product directly and minimally address the stated problem, or does it over-engineer a solution for a simpler pain?
+   - MISSING: demo link or screenshot sequence showing the core workflow from the customer's perspective; a concrete mechanism for why the product is differentiated, not just a feature list.
+   - WRONG: feature list presented as differentiation (features are copied; mechanisms are not). In 2026, the highest-frequency error in AI-adjacent decks: claiming AI or an LLM integration as a moat without specifying (a) what proprietary data or feedback loop prevents a competitor from calling the same API, and (b) what happens to the moat when model capabilities commoditize further. "Powered by AI" is not a defensibility claim.
+
+B5. BUSINESS MODEL
+   - Identify the revenue motion precisely: transactional, subscription, usage-based, marketplace take-rate, enterprise license, or hybrid.
+   - MISSING: unit economics at the level of maturity appropriate to stage — pre-seed = rough CAC channel and LTV assumption; seed = observed early CAC and initial retention signal; Series A = LTV/CAC ratio with payback period. Pricing rationale tied to value delivered, not to competitor pricing alone.
+   - WRONG: "we take a small percentage of a huge market" without explaining the mechanism by which money flows to the company; free-to-paid conversion claimed without funnel data; gross margin unstated for any SaaS or marketplace deck.
+
+B6. TRACTION
+   - Map every metric cited: ARR, MRR, DAU, WAU, paying customers, NPS, retention cohorts, pilot count. Flag which are GMV vs. revenue, gross vs. net, contractual vs. recognized.
+   - MISSING: month-over-month growth rate; logo quality (a named reference customer is worth more than an unnamed count); churn or net retention — even qualitative ("all pilots renewed" is better than silence).
+   - WRONG: conflating LOIs or pilots with revenue; annualizing a single month of data without stating that is what was done; describing pilot customers as "customers" when they are not yet paying.
+   - Stage norm: pre-seed = zero traction acceptable; seed = 3–10 paying customers or a waitlist with demonstrated conversion intent; Series A = clear ARR trajectory with defensible retention signal.
+
+B7. MOAT AND DEFENSIBILITY
+   - Categorize the claimed moat by type: data network effect, switching cost, proprietary technology, brand, regulatory capture, supply-side exclusivity.
+   - MISSING: an explicit statement of what prevents a well-capitalized competitor (name one) from replicating the core capability in 18 months; why the moat deepens with scale rather than remaining constant.
+   - WRONG: "first-mover advantage" as a moat (it is a timing advantage, not a structural barrier); patent pending treated as a defensibility claim (patents are slow, expensive, and narrow); open-source dependencies described as proprietary assets.
+
+B8. WHY NOW
+   - Is there a specific enabling condition — regulatory change, infrastructure cost inflection, model capability threshold, demographic cohort reaching decision-making age, platform emergence — that makes this the right moment and not five years ago or five years from now?
+   - MISSING: quantified tailwind (e.g., GPU inference cost per token dropped 40x in 18 months; regulation X takes effect date Y; platform API launched enabling this integration).
+   - WRONG: "the market is ready" with no cited inflection point; recycling a thesis that has been true for several years (implies the window opened long ago and others are already ahead).
+
+B9. GO-TO-MARKET
+   - Is the first-customer-acquisition motion specific and repeatable?
+   - MISSING: named channels with rough CAC estimates; sales cycle length for the target ICP; ICP defined tightly enough to build a prospecting list against (industry + company size + title + trigger event).
+   - WRONG: "social media and partnerships" with no specifics about which platforms, which partners, and why those channels reach the ICP; asserting enterprise sales and product-led growth simultaneously without explaining the sequencing logic and why the same product supports both motions.
+
+B10. COMPETITION
+    - Does the competitive landscape acknowledge the real alternatives, including the status quo (spreadsheets, manual processes, doing nothing, hiring a person)?
+    - MISSING: positioning on axes that actually matter to buyers, not axes chosen to make founders look best.
+    - WRONG: "no direct competitors" (this is always wrong — it signals the founder has not done the work or the market does not exist); a 2×2 matrix with proprietary axes that place the founder in the top-right by construction.
+
+B11. FINANCIALS AND ASK
+    - Do the projections derive from bottoms-up unit assumptions, or are they top-down revenue-share of TAM?
+    - MISSING: a hiring plan driving the OpEx line; burn rate and runway post-close; a use-of-funds breakdown that maps each dollar to a specific milestone, not a category.
+    - WRONG: hockey-stick revenue with no stated assumptions underneath it; asking for 3 years of runway at seed (signals poor capital-efficiency mindset or inability to identify the next milestone); use of funds stated as "sales and marketing" without specifying what sales motion and what marketing channels.
+
+═══ PHASE C — THE THREE HARDEST OBJECTIONS ═══
+
+Construct the three most lethal objections a partner at a top-tier fund would raise in the partner meeting — not the polite questions asked in the room, but the kill-shot concerns raised the next day when the founder is not present. For each:
+
+   - STATE the objection precisely in one sentence, in the voice of the investor.
+   - CLASSIFY it using the Phase B dimension labels: Team / Market / Problem / Solution / Business Model / Traction / Moat / Why Now / GTM / Competition / Financials.
+   - LABEL its source: MISSING (deck could fix this before next meeting) / WRONG (deck must retract or prove) / STRUCTURAL (inherent to the business model or market — no deck fix resolves it).
+   - SPECIFY the minimum evidence that would neutralize the objection — be precise about what form that evidence must take.
+
+═══ PHASE D — MISSING vs. WRONG FINAL LEDGER ═══
+
+Synthesize from Phase B. Do not re-list every per-slide finding — surface only the items that are cross-cutting, highest-severity, or not captured under a single dimension above.
+
+MISSING (information absent that a deck at this stage must contain):
+   — One line per gap. Include the slide or section it belongs on.
+
+WRONG (assertions made that are incorrect, incoherent, or will actively damage credibility):
+   — One line per error. State why it is wrong and what the correct framing is.
+
+═══ PHASE E — SINGLE MOST IMPORTANT FIX ═══
+
+Choose exactly one fix — not a list, not a "top three." The fix that most increases the probability of a term sheet from a qualified investor at this stage. Justify the choice in three sentences: what the fix is, why it outranks every other item on the Phase D ledger, and what the deck should say instead.
+
+═══ PHASE F — STAGE-BENCHMARKED SCORECARD ═══
+
+Rate each dimension against stage norms only:
+
+   Team · Market · Problem/Insight · Solution/Product · Business Model · Traction · Moat · Why Now · GTM · Competition · Financials/Ask
+
+Rating scale (stage-relative, not absolute):
+   STRONG   — exceeds what is expected at this stage; would not prompt questions at the partner meeting
+   ADEQUATE — meets the bar for this stage; may get a follow-up question but will not kill the deal
+   WEAK     — below stage norm; will generate a skeptical question that the founder must answer in the room
+   MISSING  — absent entirely; will generate a hard stop or a pass without a meeting
+
+Output as a compact table. For any WEAK or MISSING rating, add exactly one sentence of justification naming the specific gap or error.