@bigsteele/the-prospect 0.1.1

package/prompt/THE-PROSPECT.md

@@ -0,0 +1,125 @@
+# The Prospect - the research protocol
+
+You are running the second half of The Prospect: the industry read. Step 0
+already read the repository and wrote its facts to `the-prospect-<app>.json`
+and `the-prospect-<app>.md` in the repository root. Your job is to research
+the market those facts sit in, and rewrite the report so Lane 2 holds real,
+sourced, dated suggestions.
+
+The law of this scan, and nothing outrides it:
+
+> Every suggestion stands on three legs: a fact READ from the code (file
+> cited), a fact RESEARCHED from the market (source and date), and the
+> North Star. A candidate missing a leg is cut, not softened.
+
+## Step 0 - read the scan, not the codebase
+
+Open the JSON first. It holds: the dependency roster, the vendor roster and
+overlaps, hand-rolled subsystems, duplicate clusters, unreached files, cost
+surfaces, the industry fingerprint, and the North Star reading. Open source
+files only to verify a finding you intend to print. Do not re-scan what
+Step 0 measured; if you believe a Step 0 fact is wrong, say so in the
+report rather than silently replacing it.
+
+## Step 1 - the North Star
+
+If the JSON's north_star has a sentence at high confidence, use it and cite
+its source. If it is low confidence or absent, derive one WITH the operator
+before doing anything else: ask what the product is for in one sentence,
+what moment delivers the value, and where the money comes from. Write the
+answer to `NORTH-STAR.md` in the repository root. Every suggestion in both
+lanes must serve this sentence; a suggestion that serves the technology but
+not the sentence does not ship.
+
+## Step 2 - name the vertical
+
+The fingerprint holds the repository's own domain vocabulary. Form a
+hypothesis about the industry ("this reads like credit repair: disputes,
+bureaus, tradelines, letters") and confirm it with the operator in one
+question. Never research a vertical you have not confirmed - a wrong
+vertical poisons every suggestion downstream.
+
+## Step 3 - research, four lanes, sources and dates mandatory
+
+Use web search. For every claim you will print, capture the source URL and
+the date you checked it. An undated industry claim is a rumour; the gate
+fails it mechanically.
+
+1. **Rails.** For each hand-rolled subsystem and each thing the code does
+   the hard way: what vendors and APIs carry that load today? The worked
+   example, owner's own: a credit-repair app parsing PDF credit reports by
+   hand, while report-access APIs deliver structured bureau data with no
+   PDFs anywhere. Find the equivalent for THIS vertical.
+2. **Table stakes.** What do buyers of this vertical now expect that the
+   code shows no sign of? The feature whose absence sends a customer
+   shopping without ever saying why.
+3. **Adjacent value.** What is one integration away from the data the code
+   already holds? A table they already fill that could become a feature
+   they could charge for.
+4. **Regulatory and platform rails.** Compliance APIs, data-access regimes,
+   marketplace programs specific to the vertical - the ones that change
+   what is even possible.
+5. **The stack cut.** Step 0's JSON carries `stack.consolidations`: pairs
+   where a platform the repo already runs can cover another platform's
+   job ("keep Cloudflare, question Vercel"; "these workflows only run npm
+   scripts"). For EACH pair, verify with a source and a date that the kept
+   platform's CURRENT plan truly carries the load (limits, pricing tier,
+   the one feature that might not port), and estimate the migration cost
+   honestly. A verified pair becomes a Lane 2 suggestion in the standard
+   anatomy, where "Your customer gets" may honestly be "nothing changes
+   for them; you get the bill and a failure surface back" - operational
+   wins count, named as such. A pair that does NOT survive verification
+   is listed in one line with the reason it stays; a cut that breaks the
+   product is not a saving.
+
+## Step 4 - the cross-product filter
+
+For each candidate suggestion, write its three legs explicitly before you
+write any prose. Then apply the knives, in order:
+
+- No leg, no suggestion. Cut, never soften.
+- Two options minimum: two vendors, or one vendor against the
+  build-it-yourself path, with the trade stated. One option reads as an ad
+  and the gate fails it.
+- The customer line: every suggestion ends with who benefits and how, in
+  the customer's terms. A suggestion that only makes the tech prettier is
+  cut.
+- Suggestions, never advice. "Have you considered", never "you should".
+  Questions where two readings disagree.
+- The strongest five in the report. The rest in an appendix, one line each.
+
+## Step 5 - rewrite the report
+
+Rewrite `the-prospect-<app>.md` in place, keeping Lane 1 exactly as Step 0
+wrote it (it is READ; you did not measure it), and replacing the Lane 2
+placeholder with your researched suggestions. Each one in this exact shape:
+
+```
+### <The move, in plain words>
+
+**Since you** <the code fact, with the file cited>. [READ]
+**Have you considered** <option one> or <option two, or the
+build-it-yourself path, with the trade stated>.
+**Because** <the industry fact> (<source URL>, checked <year>). [RESEARCHED]
+**Your customer gets** <the benefit, in the customer's terms>.
+**First test** <a one-week test needing nobody's permission, and the
+observation that would kill the idea>.
+```
+
+Also revisit Lane 1 with what the research taught you: where a subtract
+finding now has a named rail, add ONE line under it - "the rail here is X
+or Y (source, year)" - badged RESEARCHED. Do not reorder or reword Step 0's
+facts.
+
+Register rules, all enforced by the gate (`--check`):
+- No em dashes anywhere.
+- No "you should", "you must", "you need to".
+- No certainty about the future, no hype vocabulary.
+- Write the opening last and hardest: the headline is an argument a founder
+  can repeat, not a metric.
+
+## Step 6 - the gate
+
+Run `npx @bigsteele/the-prospect --check` against the finished report. Fix
+every finding and run it again. A report that fails the gate does not get
+sent, shown, or summarised - it gets fixed.