Redacted sample deliverable

What a ¥29.9 deploy read actually looks like

This is the shape of the compact deploy / packaging read I send when a bot, agent, or infra repo technically works, but still feels janky in the public deploy story: token confusion, reverse-WS ambiguity, Docker glue, weak README framing, or a landing page that still feels like a hobby demo.

This sample is intentionally redacted / synthetic. The point is not perfect prose. The point is to show the level of bluntness, prioritization, and ready-to-paste edits someone gets back.

Buy deploy read See payment options Back to review page

Input

10-second read

Runnable bridge, weak deploy story. The core is better than the packaging, but trust leaks everywhere in the first five minutes: too many paths, token / WS confusion, and not enough “this is the shortest sane way in.”

Better target story:

Self-hosted bot infrastructure scaffold with one clear deploy path, one honest compatibility story, and one README / landing-page flow that makes a stranger believe the repo is real before they read the code.

What is helping

  • the repo already has a real transport / agent boundary
  • Docker is present, so “runnable” is not fake
  • health / status / metrics surfaces already make the project feel more infra-like
  • there is enough material to look stronger without inventing fake scale or fake polish

What is hurting

  • the shortest deploy path is not dominant enough
  • token / reverse-WS / OneBot ownership still feels easy to misunderstand
  • README and project page sell too many “capabilities” before selling one clear path
  • landing-page CTA is useful, but still sounds more like “support me” than “here is the exact help you can buy”

Top 3 fixes

1. Pick one canonical first-run path and over-sell it

Right now the repo has multiple valid stories. For strangers, that reads as uncertainty. Push one path harder: Docker demo → NapCat WebUI → /ping → /status. Everything else should be framed as “after that works”.

2. Make token / WS ownership feel idiot-proof

If a reader can’t immediately tell where the token lives and who dials whom, they mentally downgrade the repo from “infra scaffold” to “fiddly bot glue”. Repeat the same wording in README, sample config, and landing-page copy.

3. Sell deploy confidence, not just features

Feature bullets are already okay. The missing proof is confidence: “this path is the shortest sane way in”, “this is what is verified”, and “this is what I will bluntly fix for your repo if you buy the read”.

Ready-to-paste README direction

A production-minded QQ ↔ AI bridge for OneBot 11 / NapCat / LLOneBot that gives you one clear self-hosted path from transport to ACP-compatible agents, with persistent sessions, progress streaming, health endpoints, and a Docker demo that proves the chain before you swap in your own runtime.

Ready-to-paste landing-page CTA

If your own bot repo already works but still looks toy-like, the fastest paid path here is a ¥29.9 deploy read: one blunt paragraph, top 3 fixes, and the exact deploy / README / landing-page story to rewrite first.

30-minute action list

  1. move the Docker demo higher than the generic capability list
  2. repeat the token / reverse-WS ownership rule in one sentence, three times, in three different places
  3. rewrite one sentence on the project page so it sells the canonical path, not all possible paths
  4. make the paid CTA specific: deploy read, not generic support

What the ¥99 pass adds

  • concrete README paragraph rewrites
  • better project-page structure and CTA ordering
  • stronger role / product / maintainer framing
  • more than one page / surface together
  • clearer “what to hide vs what to highlight” decisions
  • higher-confidence packaging for interviews, users, or donors
Open deploy-read email Upgrade to async review
Deploy read sample · Shirong Lu / happysnaker