Status: ready-to-adapt community outreach pack for bilig.
Use this after the Show HN pack is reviewed or when a maintainer wants a slower community-by-community distribution path. The rule is the same across every channel: adapt to the specific community, disclose the maintainer relationship, and do not ask for votes, stars, or artificial engagement.
The goal is to earn useful technical feedback and legitimate bookmarks from developers who care about spreadsheet automation, formula engines, Node services, local-first workbooks, and agent tooling.
Use Reddit only when the subreddit rules explicitly allow projects, open-source tools, Show-off posts, feedback posts, or link submissions. Reddit’s spam policy defines spam broadly as repeated or unsolicited actions that harm communities, including repetitive mass posting and off-topic link sharing.
Do:
Do not:
Candidate subreddits to evaluate:
r/opensource: only if the post is framed around open-source implementation,
contribution paths, and feedback.r/typescript: only if the post emphasizes TypeScript package design and
engine architecture.r/node: only if the post emphasizes the Node service package and runnable
example.r/javascript: only if the post is technical enough for the community and
not just a release announcement.r/coolgithubprojects: likely the most direct GitHub-project fit, but still
check current rules first.Draft for a permissive open-source or GitHub-project subreddit:
I built a headless spreadsheet engine for Node services and agents
I maintain an open-source TypeScript spreadsheet engine called bilig. The public wedge is @bilig/headless: a Node package for workbook creation, formula evaluation, structural edits, persistence round trips, and readback without opening a browser grid.
The problem I am trying to solve is that a lot of business logic still lives in spreadsheet-shaped models, but service automation and coding agents usually either screen-scrape Excel/Sheets or rewrite formulas in ad hoc code.
Try path:
npm install @bilig/headless
or:
git clone https://github.com/proompteng/bilig.git
cd bilig/examples/headless-workpaper
npm install
npm start
Repo: https://github.com/proompteng/bilig
The repo includes benchmark evidence and compatibility caveats. It is not a finished Excel clone. The most useful feedback would be API friction, missing formula semantics, import/export expectations, or real workbook automation cases you would want reduced into fixtures.
Feedback thread: https://github.com/proompteng/bilig/discussions/115
DEV’s terms say posts should be on-topic, high quality, and not primarily for promotion or backlink creation. A DEV post should therefore be a real technical article, not a thin link wrapper.
Ready-to-adapt repo draft:
docs/dev-to-workbook-apis-post.md
It includes DEV-style front matter, a canonical URL, tags, the current social preview image, a concrete Node example, benchmark caveats, and feedback prompts. Use that draft as the source of truth, then edit in the DEV composer for community-specific polish.
Article title:
Why agents need workbook APIs instead of spreadsheet screenshots
Tags to consider:
typescript node opensource ai
Article outline:
@bilig/headless Node example.Opening draft:
Spreadsheets are still one of the most common ways teams encode business logic. That creates an awkward problem for automation: the logic is structured like a workbook, but most programmatic workflows either drive a browser grid or rewrite the model in application code.
That is especially fragile for coding agents. A screenshot can show a grid, but it cannot give an agent a stable contract for formulas, structural edits, persistence, validation, or post-write readback.
I maintain an open-source TypeScript project called bilig. The public package is @bilig/headless, a Node-facing WorkPaper API for programmatic workbook automation. This post explains the API shape and the current caveats, not a claim that the project is a finished Excel clone.
Close with:
The repo is here if you want to inspect the package, examples, benchmark evidence, or starter issues:
https://github.com/proompteng/bilig
Lobsters is a computing-focused discussion community with explicit self-promotion guidance. It is not a good first launch surface unless the maintainer is already an invited participant and the submission is a technical article rather than a product announcement.
Use only if:
Better candidate link:
https://github.com/proompteng/bilig/blob/main/docs/why-agents-need-workbook-apis.md
Possible title:
why agents need workbook apis instead of spreadsheet screenshots
Likely tags to evaluate in the UI:
programming, typescript, practices
Do not submit the repository homepage as a product announcement.
Product Hunt is a distribution surface for packaged products. It is probably
premature until the project has a tighter demo asset, small gallery images, and a
clear product page for @bilig/headless. Use it after at least one technical
community launch produces feedback.
Draft listing:
Name: Bilig Headless
Tagline: Headless spreadsheet engine for Node services and agents
URL: https://github.com/proompteng/bilig
Maker comment draft:
I built Bilig Headless because a lot of business logic still lives in spreadsheet-shaped models, but service automation and coding agents usually have to choose between screen-scraping a browser grid or rewriting formulas in application code.
The current package, @bilig/headless, gives Node services a WorkPaper API for formulas, structural edits, persistence round trips, validation, and readback. The repo includes a runnable external example, benchmark evidence, and compatibility caveats.
It is early infrastructure, not a finished Excel clone. I would most like feedback from people building spreadsheet-backed services, formula engines, import/export pipelines, or agent workflows that need reliable workbook state.
Do not launch on Product Hunt until these are ready:
Track every community post in the GitHub feedback discussion:
https://github.com/proompteng/bilig/discussions/115
24 and 72 hoursThe real metric is not raw post score. It is whether the post drives qualified visitors, stars, npm installs, issues, reduced fixtures, or concrete maintainer feedback.
Use this when there is no obvious launch window:
Cadence: one community post per week is enough while the project is early. More volume only helps after comments are being answered quickly and the repo is turning feedback into visible improvements.