HHostingByteSoftware
Ctrl K
ComunidadGuías…

TERA_PILOT_PROMOTION_IDEAS.md

Rama main · réplica de lectura del repositorio original.

Archivo original ↗Preguntar a KiBot
# Tera Pilot: agent self-promotion ideas

> Working document (draft, September 2026). Recorded ideas, not a launch plan.
> A starting point for discussion; none of this is implemented yet.

---

## 1. Context and principles

Tera Pilot's main promo angle is not "yet another IDE add-on" but
**verifiable, signed agent actions** (Ed25519 + hash chain), locality, and
provider neutrality. Self-promotion should use that same machinery of proof.

Rules that must not be broken even for marketing:

1. **Claims discipline** (see `TERA_PILOT_PRODUCT_STRATEGY.md` §11):
   only measured numbers from the eval harness. No "smarter than Claude Code"
   without our own data.
2. **No telemetry / phone-home**: all scenarios are local or go through
   open APIs (GitHub, Mastodon, Telegram). Otherwise we break our own
   privacy narrative.
3. **The "where" rule**: where the API is open and bots are welcome — the
   agent acts on its own; where self-promotion is harshly punished — the
   agent prepares a draft, a human publishes.
4. Scenarios 1–4 can run right now (testing phase); 5–6 — closer to the
   public release.

---

## 2. Scenarios: "how" the agent promotes itself

### 2.1 Dogfooding — the agent develops its own repository

The most honest and cheapest scenario. The agent works on its own code: fixes
its own bugs, repairs failing tests, refactors, adds features. Every such PR
is a live demo, not a staged video.

- A scheduler (cron / `workflow_dispatch`) assigns the agent a task from the backlog.
- The agent solves it in a clean copy of the repo (as in the eval harness),
  runs the tests, opens a PR with a report.
- Every PR includes a signed audit export
  (`tera-pilot audit export`). Competitors can't do this — they have no
  built-in proof.

### 2.2 Automatic provider benchmark tournament

The strategy forbids quality claims without measurements — so let the agent measure itself.

- Periodic runs of `eval/runner.py` (58 tasks) across the 17 providers and
  local models (Ollama / LM Studio).
- Generating comparative reports (precedents: `GROQ_EVAL_REPORT.md`,
  `eval/REPORT_*.md`) and publishing them.
- Demonstrating multi-provider consensus — a feature in itself.
- Example content: "Measured by Tera Pilot on 58 real tasks: 5/5 on
  OpenRouter, 4/5 on the local 2.6B model".

### 2.3 Content factory — auto-generated materials

The agent writes changelogs, release notes, posts, translations — always based
on real data (git history, eval reports, audit logs), never invented.

- After every release the agent analyses the diff and drafts a post:
  "what changed, measured results, link to signed proof".
- A human publishes (or the agent itself, where the API is open — see platforms).
- Self-verifying content: every number links to a verifiable artifact.

### 2.4 Self-review PRs in its own repository

A GitHub Action workflow generator already exists (`github_automation.py`) —
enable it on the repo itself and get a public live demo of CI readiness.

- For every incoming PR the agent in read-only mode (the `reviewer` profile)
  reviews, comments findings, attaches a report.
- A live example for outsiders: "this is how it will work in your repo".
- Dogfooding, real value, and proof of P1.1 from the readiness plan at once.

### 2.5 Issue triage and community answers

The agent works tickets: reproduces the bug in a clean copy (fixtures already
exist), classifies, prepares a minimal repro and a draft answer.

- A fleet of profiles: one digs through bugs, another answers newcomers.
- Every public thread is a capability demo plus load off the author's shoulders.

### 2.6 Playground "try without installing"

A public demo workspace: anyone drops in, gives the agent a task, and watches
in real time how it plans, edits, runs tests, and asks for confirmation.

- Iteration/token budget caps, approvals visible in the interface.
- Trust-first UX can't be explained in words — you have to see it live once.
- Telegram version: the product already has `--inbound telegram` built in — a
  person messages the bot a task, the agent executes it on the demo workspace
  and replies with the result. A unique feature: try the agent right in Telegram.

---

## 3. Platforms: "where" the agent promotes itself

The center of the system is **GitHub** (native integration:
`github_automation.py`, MCP/ACP, audit). Everything else leads back to it.

| Scenario | Platforms | Who publishes |
|---|---|---|
| 2.1 Dogfooding | GitHub (PR, Issues, Releases); YouTube (video script) | agent itself |
| 2.2 Benchmarks | GitHub README, GitHub Pages, dev.to, Mastodon/Fosstodon; HN | agent itself; HN — human |
| 2.3 Content | X, dev.to, Telegram channel; LinkedIn — drafts | agent + moderation |
| 2.4 Self-review | GitHub Actions (own repo) | agent itself |
| 2.5 Triage/answers | GitHub Issues; Reddit, Discord — drafts | GitHub — agent; Reddit/Discord — human |
| 2.6 Playground | Telegram bot, web sandbox | agent itself |

Platform details:

- **GitHub** — Issues/Discussions (triage, answers, repros), PRs (self-review
  and self-fix), Releases (release notes), README + GitHub Pages (benchmarks
  and docs). The agent acts fully on its own via the API.
- **Awesome lists** — small PRs to `awesome-selfhosted`, `awesome-ollama`,
  `awesome-llm-apps`, `awesome-coding-agents` → target audience
  (Segments A, F from the strategy).
- **Hacker News** — "Show HN" once per release, the agent drafts the post, a
  human publishes (no convenient API; spam kills reputation instantly).
- **Mastodon / Fosstodon** — bot account, the agent posts via API.
  Audience: self-hosted/privacy, bots welcome.
- **X (Twitter)** — the agent posts short reports via API. Careful:
  low frequency, human moderation, otherwise a spam ban.
- **Project Telegram channel** — own subscribers without algorithms; the agent
  publishes itself (built-in integration).
- **Reddit** (r/selfhosted, r/LocalLLaMA, r/ollama, r/OpenSource, r/Python) —
  drafts only: the agent prepares, a human posts. Autoposting = ban.
- **Discord servers** (Ollama, LM Studio, LocalLLaMA) — drafts only.
- **dev.to** — cross-posting articles (Markdown, the agent writes natively).
- **YouTube** — screencast "the agent fixes its own bug live": the agent
  generates a step-by-step script and captions, a human/CI script records.
- **PyPI / npm** — package pages: description, keywords, links
  (a package without a clear description is never found).
- **Product Hunt** — one-shot launch closer to v1.
- **Catalogs** — alternativeto.net, libhunt, Sourcegraph (listing via form).
- **LinkedIn** — drafts for a human only.

---

## 4. Priorities: where to start

The favorite is the 2.1 + 2.4 combo (the agent fixes its own bugs + reviews
its own PRs): cheap, genuinely useful, a stream of live demos with no staged videos.

From "where", first to build:

1. **"Try it" Telegram bot** (2.6) — the feature is already built in
   (`--inbound telegram`), needs a public demo mode with limits.
2. **Self-review Action on this repo** (2.4) — fully automatic.

Then, as ready: the benchmark tournament published to README/Pages
(2.2) and the release content factory (2.3).

---

## 5. Open questions

- Public content language: decided — English-first (this document included).
- Where to host the web sandbox (2.6): Codespaces, VPS, GitHub Pages?
- Do we need a public demo repo with "safe" tasks for the playground?
- Who runs the bot accounts (Mastodon, Telegram, X) and who is responsible
  for the publications?