bilig

GitHub Stars Growth Plan

Status: researched growth plan for taking proompteng/bilig from early public visibility to the first 1000 legitimate GitHub stars.

Research date: 2026-05-07.

Objective

Reach 1000 real GitHub stars for https://github.com/proompteng/bilig by turning @bilig/headless into an easy-to-evaluate, easy-to-share developer tool. Stars should come from developers who understand what the project does, not from paid, automated, reciprocal, or misleading campaigns.

Current Public State

Verified on 2026-05-07:

Research Findings

GitHub stars are a bookmark and appreciation signal, and GitHub explicitly says many repository rankings and Explore surfaces depend on stars. The practical meaning is simple: stars are not a usage metric, but they amplify discovery once real developers begin saving the project.

GitHub’s official discoverability levers are already aligned with the work done so far:

Open source community guidance is consistent with that: documentation is the main conversion surface, responsiveness matters, most contributors are casual, and early projects need to meet users in the places where they already talk.

Case studies and founder writeups are also consistent:

GitHub’s 2026 maintainer guidance adds one important constraint: growth is only useful if the project can absorb it. AI-assisted contributions can increase issue and pull-request volume without increasing quality, so the growth loop needs stronger docs, scoped issues, runnable examples, and fast maintainer triage before a major launch spike.

The 2025 Hacker News launch-diffusion study is directionally useful for launch planning. It analyzed 138 AI and LLM-tool repository launches from 2024-2025 and reported average post-HN gains of 121 stars within 24 hours, 189 within 48 hours, and 289 within a week. It also says timing and launch fit matter. Treat HN as one distribution event in a repeatable proof loop, not as the whole plan.

The most useful 2026 founder playbooks repeat the same lesson: large star growth came from a specific, tryable product plus repeated distribution across HN, Reddit, Product Hunt, X, and community channels. AFFiNE’s public case study claims 1,000 stars in 72 hours and 6,000 in seven days, but the useful takeaway is not the spike; it is the clean positioning, global distribution, and immediate user conversations after the traffic arrived.

Official HN guidance makes the same launch constraint concrete: a Show HN should be something people can try directly, preferably without signups or email gates, and it should be work the poster personally built and can discuss in the thread. For bilig, that means the launch link should point at the repository or public docs with the npm-only quickstart visible immediately, not a generic landing page.

Do not buy stars or run fake-star exchanges. Recent research found increasing fake-star campaigns, and GitHub Trending appears to filter out most superficial fake-star activity. Fake growth creates trust and supply-chain risk for a developer-tool project.

Positioning

Lead with the smallest valuable product:

@bilig/headless is a headless spreadsheet engine for agents and Node services.

Second sentence:

It gives you formulas, structural edits, persistence, validation, and benchmark evidence without opening a browser grid.

Primary audience:

Avoid leading with the full monorepo architecture. The browser shell, renderer, sync, protocol, and WASM work are supporting proof, but the adoption wedge is @bilig/headless.

Star Funnel

0 To 50 Stars

Goal: make every visitor understand the project in under one minute and make the first star feel like a useful bookmark.

Actions:

50 To 250 Stars

Goal: earn attention from targeted developer communities.

Actions:

250 To 1000 Stars

Goal: turn a one-time launch into a repeatable content and proof loop.

Actions:

Continuous X Reply Loop

Goal: earn profile visits from people already discussing spreadsheets, agents, Excel automation, workbook persistence, and formula reliability.

Operating rule: reply only when the post has a clear technical connection to @bilig/headless. Do not use duplicated templates, engagement bait, automated mentions, or bare links.

Daily loop:

  1. Search X for excel ai, spreadsheet agents, workbook api, google sheets ai, formula engine, and hyperformula.
  2. Pick at most 2 to 3 posts where a bilig maintainer can add a concrete technical point.
  3. Reply in lowercase, plain human tone, and lead with the idea rather than the repo.
  4. Link only when it genuinely helps the conversation; otherwise let the profile and previous launch posts carry the repository.
  5. If the same question appears twice, convert the answer into a doc, example, issue, or benchmark note before replying again.

Tone rule:

Sam Altman-style lower-case tone works because it reads casual and compressed: short sentences, minimal punctuation, and little launch-copy polish. Use that shape, but keep the substance specific to bilig; do not impersonate anyone or turn replies into vague hype.

Good reply shapes:

the hard part is not generating a formula once. it is preserving workbook state, formulas, provenance, and writeback so an agent can be checked after it acts.

this is where headless workbook apis matter. screenshots are fine for demos, but agents need ranges, formulas, structural edits, persistence, and readback tests.

the benchmark story only matters if it is auditable. for bilig i’m keeping the artifact, verify command, and p95 caveat in public instead of turning it into a vague “faster than x” claim.

Launch Copy

Use this for the first broad post:

I built @bilig/headless, a TypeScript spreadsheet engine for agents and Node services. It runs formulas, structural edits, persistence round trips, and validation without a browser grid. The repo includes a runnable npm example and checked-in benchmark evidence against HyperFormula-style workloads.

Use this for a benchmark-focused post:

The current WorkPaper benchmark artifact records 46/46 mean wins on scorecard-eligible comparable workloads against HyperFormula-style workloads (38/38 public, 8/8 holdout). The p95 story has nuance, so the evidence doc spells out exactly what is measured and what is not.

Use this for contributor outreach:

If you like spreadsheet engines, formula semantics, local-first software, or agent tools, bilig has useful first contributions: formula parity fixtures, WorkPaper examples, benchmark scenarios, accessibility fixes, and docs that turn architecture notes into runnable code.

Metrics

Track weekly:

Target pace:

The target pace is not guaranteed. Treat misses as signal about positioning, audience, or product friction.

Immediate Next Actions

  1. Post one lower-case X update for the compatibility-boundaries article and XLSX verifier walkthrough.
  2. Manually reply to at most 2 high-fit X posts per day. Start with the idea; add a link only when it materially helps the thread. Use docs/x-reply-growth-playbook.md for the reply budget, tone, examples, and platform-rule boundaries.
  3. Create a Product Hunt draft once the launch image and demo are final. Do not schedule the launch until the personal account is eligible to post and the first maker comment is ready.
  4. Respond to serious Hacker News and GitHub Discussion comments within the same day, then convert repeated feedback into docs or examples. For a concrete Hacker News launch checklist, use docs/show-hn-launch-pack.md.
  5. Keep shipping compact formula-edge fixture articles that follow the XLOOKUP, SUMIFS, and GROUPBY walkthrough pattern: one real formula family, exact fixture inputs, expected result or spill output, and verifier command.
  6. Track GitHub stars, npm downloads, GitHub traffic referrers, and issue quality every week.
  7. Add a Star History chart only after there is enough organic movement for the graph to communicate momentum instead of early-stage emptiness.

Sources