
You've pasted an env block into ChatGPT to "ask a quick question." It left your machine. prompt-scrub rewrites those tokens to stable placeholders before the message does, and keeps the real values on disk.


30 days is the floor. Every whitepaper at the Nano Collective sits in public review for at least that long - status badge shows the close date, anyone can file issues. The build decision waits for the window to close.



"AI conversion" usually means someone else's machine. In `get-md`, `useLLM: true` with no `llm` block runs ReaderLM-v2 on-device via node-llama-cpp. One ~1.12GB download, then the page never leaves your laptop.


Most migration libs throw a generic Error and leave you parsing the message. json-up throws three named types: VersionError, MigrationError, ValidationError. You know what actually went wrong without guessing.


Your tool's parameter values get shell-quoted before they hit the body, so even '; rm -rf /; #' lands in echo as one literal string. nanocoder custom tools block injection at the template layer, not by trusting the model to behave.


Your training data shouldn't leave the machine it's written on.

Nanotune assumes local is the default. LoRA on Apple Silicon, MLX under the hood, no upload anywhere in the pipeline.



The Nano Collective has relaunched its website. This post is a walkthrough of what changed, why, and what it sets up for the next round of announcements.

The starting point is the same one we use for the docs site and the READMEs: the [Brand Guidelines](https://docs.nanocollective.org/collective/organisation/brand) are the source of truth for how the collective is talked about and presented. The previous site drifted from those guidelines in several places. The new site is an attempt to remove that drift.

## The headline change: principles lead

The three principles the collective holds itself to (**Privacy First, Open Source, Local First**) now lead the homepage in the order they appear in the brand guidelines: privacy-respecting, local-first, open for all. That ordering is not decoration. It is the filter applied when deciding what the collective builds, how it builds it, and who gets to shape it.

The previous version had these principles further down the page, framed as values. They are not values. They are the filter. The redesign puts them where the filter belongs.

A note on why this matters for the projects specifically. The principles page in the brand guidelines spells out that the second paragraph of the canonical collective description can be dropped where space is tight, but the principles should never be paraphrased loosely. The site now reflects that. The same three phrases appear in the same order wherever they show up.

## Information architecture

Two structural changes to how the site is organised:

**1. Flagship projects get landing pages.** [Nanocoder](https://github.com/Nano-Collective/nanocoder) and [Nanotune](https://github.com/Nano-Collective/nanotune), the two projects most often pointed at when introducing the collective, each have a dedicated landing page now. The previous site had a single paragraph for each. The new pages describe what the project does, link to the repo, link to the docs, and stay in the same voice as the project's own README.

**2. The full project list is alphabetised on its own page.** The four shipped projects (Nanocoder, Nanotune, get-md, json-up) are listed in alphabetical order on the projects page, with one paragraph each and a link to the corresponding repo. The brand guidelines ask for alphabetised listings unless there is a deliberate reason to prioritise; with the landing pages for the two flagship projects carrying the bulk of the weight, the projects page can default to alphabetised.

get-md and json-up are worth naming explicitly. They often get skipped in copy that leads with the AI-shaped projects, but they are real, shipped, maintained tools under the umbrella. The new site gives them the same one-paragraph treatment as the others.

## Live proof replaces curated snapshots

The old "community" section was a curated screenshot of activity: a Discord message, a GitHub notification, a Reddit thread. The new site has:

- **Live GitHub, Discord, and Reddit stats** on the homepage, updated in real time rather than maintained by hand.
- **A public growth page** that plots the same data over time, so the trajectory is visible to anyone who wants to look.
- **A feed of the latest discussions** surfaced directly from the relevant channels.

These are small changes in isolation, but they matter for the same reason the [Open Collective ledger](https://opencollective.com/nano-collective) matters for finances: live data is harder to misrepresent than curated data. The collective's stated commitment to transparency by default is now extended to its own growth metrics.

A **public analytics page** also ships with the redesign. The collective treats its own site the same way it treats the projects it ships: traffic patterns are visible to anyone who wants to look.

## The branded asset generator

One of the smaller-but-meaningful pieces is a branded asset generator built into the site. Every social post, blog header, and shared image now comes out of the same generator with the same visual rules applied.

The reason this matters: per-channel manual asset tweaks were quietly drifting the brand across surfaces. The previous site's visuals would appear slightly differently on LinkedIn than on the docs site than on a GitHub social card, because each surface was being produced by hand. The generator removes that variation by enforcing the same rules at the source.

It also lowers the bar for contributors. Anyone in the collective who needs to produce a social image now uses the generator rather than asking the design-adjacent folks to produce one. That's a small thing in isolation; in aggregate it's the difference between a brand that's enforced by the people who have time to enforce it and a brand that's enforced by the codebase.

## Visual language

The new visual treatment is high-contrast and deliberately developer-terminal in feel:

- Black-and-white layouts with sharp edges. No rounded pastel blocks.
- Monospace detailing in section headers, badges, labels, and inline code-equivalents.
- An electric-blue accent reserved for interactive elements and emphasis.
- An animated ASCII-art backdrop on the homepage that nods to the kind of environment the collective's tools run in.
- Editorial typography replacing the previous display fonts.

The brief was simple: make the site look like what we actually ship. Our READMEs start with the canonical project tagline ("Built by the Nano Collective, a community collective building AI tooling not for profit, but for the community") and lean on monospace detailing, plain typography, and clear structural hierarchy. The site now reads the same way.

## Under the hood

The codebase was tightened as part of the redesign. Entrance animations are subtler, the layout system is consolidated, the dependency footprint is smaller, and the build pipeline is faster. None of this is headline material on its own, but it removes the small drag that compounds over time.

## What this sets up

ContentForest has been live for a while and now has its own page on the site. The broader pattern (software whose primary job is to coordinate agents and surface their work to humans) is one the collective will keep shipping on. The new site is the place those announcements land.

Nothing else is promised here. The collective is volunteer-led today, and the explicit mission is to grow the contributor community and progressively decentralise. The site is one of the things that has to be in shape for that to work, and it's in better shape now. The next announcements will show up when the projects they're about are ready to be talked about, not before.

## How to read more

- The new site: [nanocollective.org](https://nanocollective.org)
- The brand guidelines (the rules the new site now reflects): [docs.nanocollective.org/collective/organisation/brand](https://docs.nanocollective.org/collective/organisation/brand)
- The organisation overview (how the collective is structured and funded): [docs.nanocollective.org/collective/organisation](https://docs.nanocollective.org/collective/organisation)
- The projects page (the full list and how projects come to life): [docs.nanocollective.org/collective/projects](https://docs.nanocollective.org/collective/projects)

If something on the new site reads as off-message, that's a bug. Open an issue on the docs repo and we'll iterate. The guidelines are versioned and meant to be updated when the brand shifts.

New Nano Collective website: principles first, live proof, tighter codebase


The Nano Collective has relaunched its website. The previous version was soft and colourful. The new one looks and reads like what the collective actually builds.

The headline change is the information architecture. The homepage leads with the three principles the collective holds itself to (Privacy First, Open Source, Local First) rather than burying them. The principles are in that order because that's the order they appear in the [Brand Guidelines](https://docs.nanocollective.org/collective/organisation/brand): privacy-respecting, local-first, open for all. Now the site reflects that.

The flagship projects, [Nanocoder](https://github.com/Nano-Collective/nanocoder) and [Nanotune](https://github.com/Nano-Collective/nanotune), each have a dedicated landing page instead of sharing a single paragraph. The full project list (Nanocoder, Nanotune, get-md, json-up) is on the projects page, alphabetised as the brand guidelines ask.

A few things shipped under the hood that are worth naming:

- **Live community proof.** GitHub, Discord, and Reddit stats on the homepage, plus a feed of the latest discussions. Numbers update in real time rather than being curated snapshots.
- **A growth page** that publishes the same data over time, so the trajectory is visible to anyone who wants to look.
- **A branded asset generator** for consistent social imagery across channels.
- **A public analytics page** so the collective's own site traffic is treated the same way it treats everything else: open and inspectable.
- **A leaner codebase** under the same site, with entrance animations and a tightened layout system.

The visual treatment is deliberate. Black-and-white layouts, sharp edges, monospace detailing, an electric-blue accent, an animated ASCII-art backdrop. The brief was to make the site look like what we actually ship: open-source, local-first, developer-facing. The previous design was pleasant. The new one is honest about what the collective is.

This is also the foundation for what's coming. The site now has the room to announce the tools along the shape we keep talking about, software whose job is to coordinate agents and surface their work to humans, starting with ContentForest and continuing from there. Nothing promised, nothing dated.

The Nano Collective is a community-led group building open-source AI tooling not for profit, but for the community. Read the new site at https://nanocollective.org.


**TL;DR:** We rebuilt the Nano Collective website. The redesign is less about the new visuals and more about the site finally matching the brand guidelines we already had. The three principles lead the homepage, flagship projects get real landing pages, and community stats are live rather than curated.

---

A bit of context. We're the [Nano Collective](https://nanocollective.org), a small community-led group of developers, designers, and maintainers building open-source AI tooling not for profit, but for the community. Everything is [fiscally hosted by the Open Source Collective](https://opencollective.com/nano-collective) and published transparently. We have four shipped projects under the umbrella right now: [Nanocoder](https://github.com/Nano-Collective/nanocoder) (a terminal coding agent), [Nanotune](https://github.com/Nano-Collective/nanotune) (fine-tuning tooling for small local models), [get-md](https://github.com/Nano-Collective/get-md) (HTML to Markdown converter), and [json-up](https://github.com/Nano-Collective/json-up) (type-safe JSON migrations). We also have a number of whitepapers in the [docs site](https://docs.nanocollective.org) covering longer-term ideas (Sentinel, the Private Inference Proxy, the Prompt Scrubber, the Marketplace, the Nano OS, and the Docs Forest).

The old site was fine. It was soft, colourful, and pleasant to look at. The problem was that it didn't read like what we actually ship. Our README files start with the canonical project tagline ("Built by the Nano Collective, a community collective building AI tooling not for profit, but for the community") and lean on monospace detailing, plain typography, and clear structural hierarchy. The old site didn't carry any of that.

## What changed in the design

The new visual treatment is high-contrast and deliberately developer-terminal in feel:

- Black-and-white layouts, sharp edges, no rounded pastel blocks.
- Monospace detailing in section headers, badges, and labels.
- An electric-blue accent reserved for interactive elements and emphasis.
- An animated ASCII-art backdrop on the homepage that nods to the kind of environment our tools actually run in.

Editorial typography replaced the previous display fonts. The effect is a site that reads like internal engineering documentation, closer to our READMEs and release notes than to a marketing page.

## What changed in the information architecture

The three principles (Privacy First, Open Source, Local First) now lead the homepage in the order they appear in the [Brand Guidelines](https://docs.nanocollective.org/collective/organisation/brand). The previous version had them further down, framed as values rather than as the filter they actually are.

Nanocoder and Nanotune each got a dedicated landing page. The full project list moved to a structured projects page, alphabetised, with one paragraph per project and a link to each repo. get-md and json-up are also on the page; flagging them matters because they often get overlooked in copy that leads with the AI-shaped projects.

## What changed in proof

The old site had a "community" section that was a curated screenshot of activity. The new site has:

- **Live GitHub, Discord, and Reddit stats** on the homepage, updated in real time.
- **A public growth page** that plots the same data over time, so the trajectory is visible.
- **A feed of the latest discussions** surfaced directly from the relevant channels.
- **A public analytics page** so traffic to the collective's own site is treated the same way we treat our own work: open and inspectable.

## What changed in the day-to-day

There's a branded asset generator now. Every social post, blog header, and shared image can come out of the same generator with the same visual rules applied. That's a small thing in isolation, but it ends the per-channel manual tweaks that were quietly drifting the brand across surfaces.

Behind the scenes the codebase was tightened. Entrance animations are subtler, the layout system is consolidated, and the dependency footprint is smaller. Nothing flashy, just less to maintain.

## What this site is for next

The redesign creates room for the next round of announcements. ContentForest has been live for a while and has its own page; the broader pattern of software that coordinates agents and surfaces their work to humans is one we'll keep shipping on. The new site is the place those announcements land.

Nothing else to promise. The collective is volunteer-led today and our explicit mission is to grow the contributor community and progressively decentralise. The site is one of the things that has to be in shape for that to work, and it's in better shape now.

If any of this lands (the principles-first ordering, the live stats instead of curated ones, the asset generator removing manual drift), come find us at https://nanocollective.org. The codebase for the site is public, the [docs](https://docs.nanocollective.org) are public, and the contributor channels are linked from both.


The Nano Collective site has been rebuilt around the three principles the collective is actually built on: privacy-respecting, local-first, open for all. Black-and-white layout, monospace detailing, electric-blue accent, live community stats. https://nanocollective.org


get-md v1.6.0 is out. The library is no longer HTML-only: PDF, DOCX, and Markdown inputs join HTML and URLs, with auto-detection on the file extension or magic bytes. Behind that headline is a launch-hardening pass over the whole multi-format surface that closes a set of real bugs surfaced during review.

Built by the [Nano Collective](https://nanocollective.org), a community collective building AI tooling not for profit, but for the community.

## What changed

`convertToMarkdown` and the CLI now accept four input formats: HTML strings, URLs, PDF, DOCX, and Markdown files. Pass a `Buffer` or a `ContentSource` and get-md routes it to the right extractor automatically. The CLI detects format from the file extension, and for stdin it inspects the `%PDF` magic bytes directly.

```typescript
import { convertToMarkdown } from "@nanocollective/get-md";

// PDF
const pdf = await convertToMarkdown(pdfBuffer);
console.log(pdf.markdown);

// DOCX
const docx = await convertToMarkdown(docxBuffer);

// Markdown (skips HTML parsing, runs optimization passes only)
const md = await convertToMarkdown("# Heading\n\nAlready markdown.");
```

## PDF ingestion

Pass a PDF `Buffer` (auto-detected via the `%PDF` magic bytes) or point the CLI at a `.pdf` file or URL. Text is reconstructed into real structure: wrapped lines reflow into paragraphs, ALL-CAPS lines become headings, `•` and numbered lines become lists with wrapped continuations folded in, and repeated running headers and footers are dropped.

Title, author, and creation date are pulled from the PDF info dictionary into the frontmatter, alongside the computed `wordCount` and `readingTime`. The `-- N of M --` page markers that `pdf-parse` emits by default are stripped before output. Readability is disabled for PDF input so body text is never dropped as boilerplate (a class of bug that was reachable in earlier code).

Scanned or text-less PDFs return an empty result with a non-zero `inputLength`, which is the signal that OCR is needed rather than a successful extraction. The extractor is powered by `pdf-parse`.

## DOCX ingestion

Pass a DOCX `Buffer` (auto-detected via the ZIP/`PK` magic bytes) or point the CLI at a `.docx` file or URL. Two new exports are available for direct use:

```typescript
import {
  convertDocxToMarkdown,
  convertDocxToHtml,
} from "@nanocollective/get-md";

const md = convertDocxToMarkdown(buffer, { /* options */ });
const html = convertDocxToHtml(buffer);
```

Supported structure: headings, bold/italic/underline/strikethrough, tables, and ordered/unordered lists. List type is resolved from `word/numbering.xml`, not guessed from `numId` parity, which previously caused ordered lists to flip to unordered at random. Nested tables no longer corrupt the outer table (the traversal now uses direct children). Decompression is capped at 100 MB, and corrupt, encrypted, or `document.xml`-less archives raise clear errors. The extractor is powered by `node-stream-zip`.

## Markdown input

`.md` and `.markdown` files (or `inputType: "markdown"`, or a `ContentSource` with `type: "markdown"`) skip HTML parsing entirely and run only the optimization passes: metadata, frontmatter, and structure normalization.

Existing frontmatter is preserved: your `title` and `author` are kept, and only the computed `wordCount` and `readingTime` are appended. Earlier code could produce a doubled frontmatter block or clobber the real title when a `.md` file already had YAML at the top. That path is fixed. The `--no-links`, `--no-images`, and `--no-tables` filters are honored on Markdown input as well.

## Bug fixes from the launch review

The multi-format surface got a top-to-bottom pass before this release shipped. Highlights:

- **PDF no longer loses body text.** Readability was running on PDF-derived HTML and could strip content it scored as boilerplate. It is now disabled for PDF input, matching the DOCX behaviour.
- **PDF page-marker noise removed.** The `-- N of M --` separators no longer leak into the output.
- **PDF metadata and structure.** Title, author, and date flow into the frontmatter. Extracted text is reconstructed into headings, paragraphs, and lists instead of one flat blob.
- **DOCX list types are correct.** Ordered vs. unordered comes from `word/numbering.xml`, not from a `numId`-parity guess.
- **DOCX tables.** Nested tables no longer corrupt the outer table. Decompression is bounded and archive errors are clear.
- **DOCX buffers via `convertToMarkdown`.** A DOCX `Buffer` now converts through `convertToMarkdown` (via PK/zip detection), matching the PDF buffer path instead of throwing.
- **Markdown input.** A `.md` file that already had frontmatter no longer produces a doubled block or clobbers the real title. `--no-links`, `--no-images`, and `--no-tables` are honored for Markdown input.
- **Build before test.** `scripts/test.sh` and the badges workflow now build first, since the CLI end-to-end tests spawn the compiled `bin/get-md.js` (stale `dist/` would skew results).

## CLI

The CLI advertises all four formats and detects the input type from the extension, or from the `%PDF` magic bytes on stdin:

```bash
getmd handbook.pdf -o handbook.md
getmd contract.docx -o contract.md
getmd notes.md -o cleaned.md
getmd https://example.com/article -o article.md
```

## Documentation

The Conversion API page covers PDF and DOCX buffers, binary auto-detection, `inputType`, the `convertDocx*` exports, and Markdown input. The CLI reference documents format detection and the DOCX/`.md` input paths. Getting Started and Quick Start show PDF, DOCX, and Markdown examples alongside the HTML path.

## Tests

592 passing (up from 528 at 1.5.0). New coverage for PDF extraction, page-marker stripping, info-dict metadata, and structure reconstruction; DOCX buffer routing, `numbering.xml` list resolution, and corrupt-archive errors; Markdown-input frontmatter preservation and content filtering; and real DOCX and PDF CLI end-to-end runs.

## Upgrading

```bash
npm install @nanocollective/get-md@1.6.0
```

Or:

```bash
pnpm add @nanocollective/get-md@1.6.0
```

Node.js 22 or later is required. No peer dependencies are required for the standard HTML/PDF/DOCX/Markdown paths.

If you hit any issues or want to discuss the new format support, open an issue or find us on [Discord](https://discord.gg/ktPDV6rekE).

Repo: https://github.com/Nano-Collective/get-md

get-md v1.6.0: PDF, DOCX, and Markdown ingestion alongside HTML


get-md v1.6.0 ships today. The library is no longer HTML-only: PDF, DOCX, and Markdown inputs join HTML and URLs, with auto-detection on the file extension or magic bytes (`%PDF` for PDF, the ZIP/`PK` signature for DOCX).

What's actually in the release:

- PDF ingestion via `convertToMarkdown` or the CLI. Text is reconstructed into real structure: paragraphs, headings, lists, with running headers and the `-- N of M --` page markers stripped. Title, author, and creation date flow into the frontmatter from the PDF info dictionary. Scanned PDFs return an empty result with a non-zero `inputLength`, which is the signal that OCR is needed rather than a successful extraction.

- DOCX ingestion, plus two new exports (`convertDocxToMarkdown`, `convertDocxToHtml`) for callers who want the DOCX path without going through the unified entry point. List type is resolved from `word/numbering.xml` rather than guessed, and nested tables no longer corrupt the outer table.

- Markdown input. A `.md` file with existing frontmatter is no longer doubled or has its real title clobbered. The optimization passes run without re-parsing the body as HTML.

- A top-to-bottom pass over the new multi-format surface closed a set of real bugs that surfaced during review: PDF body text no longer dropped by Readability, DOCX list ordering no longer flips at random, DOCX buffers now route through `convertToMarkdown` instead of throwing, and the test scripts now build before running.

592 tests passing, up from 528 at v1.5.0.

Install:

```
npm install @nanocollective/get-md@1.6.0
```

Built by the Nano Collective, a community collective building open-source AI tooling not for profit, but for the community.

Repo: https://github.com/Nano-Collective/get-md
Docs: https://docs.nanocollective.org/get-md/docs


We've just shipped get-md v1.6.0, and the headline change is that get-md is no longer HTML-only. PDF, DOCX, and Markdown inputs now join HTML strings and URLs, with format auto-detection on the file extension or the magic bytes (`%PDF` for PDF, the ZIP/`PK` signature for DOCX).

Here's what's actually in the release.

## PDF, DOCX, and Markdown inputs

`convertToMarkdown` now accepts a `Buffer` or a `ContentSource` and routes it to the right extractor automatically. The CLI does the same: pass a `.pdf`, `.docx`, or `.md` file and it figures out the format from the extension. For stdin, it inspects the `%PDF` magic bytes directly.

On the PDF side, text is reconstructed into real structure rather than one flat blob. Wrapped lines reflow into paragraphs, ALL-CAPS lines become headings, and bulleted or numbered lines become lists (with wrapped continuations folded in). Repeated running headers and footers are dropped. Title, author, and creation date flow into the frontmatter from the PDF info dictionary. The `-- N of M --` page markers that `pdf-parse` emits by default are stripped. Readability is disabled for PDF input so body text is never silently dropped as boilerplate. Scanned or text-less PDFs return an empty result with a non-zero `inputLength`, which is the signal that OCR is needed rather than a successful extraction.

On the DOCX side, list type (ordered vs. unordered) is now resolved from `word/numbering.xml` rather than guessed from `numId` parity. That guess was the source of a class of bug where ordered lists would flip to unordered at random. Nested tables no longer corrupt the outer table (we use direct-children traversal now). Decompression is capped at 100 MB, and corrupt, encrypted, or `document.xml`-less archives raise clear errors. Two new exports are available for callers who want the DOCX path directly: `convertDocxToMarkdown(buffer, options)` and `convertDocxToHtml(buffer)`.

On the Markdown input side, `.md` and `.markdown` files (or `inputType: "markdown"`) skip HTML parsing entirely and run only the optimization passes: metadata, frontmatter, and structure normalization. A subtle bug here was that an existing YAML frontmatter block on a `.md` file could get doubled, or its real `title` could get clobbered by the computed frontmatter. That's fixed; existing `title` and `author` are preserved, and only `wordCount` and `readingTime` are appended. The `--no-links`, `--no-images`, and `--no-tables` filters are honored on Markdown input as well.

## Bug fixes from the launch review

The multi-format surface got a top-to-bottom pass before this release shipped. We closed a real set of bugs that surfaced during review:

- PDF no longer loses body text (Readability was running on PDF-derived HTML and could drop content it scored as boilerplate; it's now disabled for PDF input, matching DOCX).
- PDF page-marker noise is removed (`-- N of M --` separators no longer leak into the output).
- PDF metadata and structure (title/author/date flow into the frontmatter, and extracted text is reconstructed into headings/paragraphs/lists instead of one flat blob).
- DOCX list types are correct (resolved from `word/numbering.xml` instead of a `numId`-parity guess).
- DOCX tables (nested tables no longer corrupt the outer table; decompression is bounded and archive errors are clear).
- DOCX buffers via `convertToMarkdown` (a DOCX `Buffer` now converts through `convertToMarkdown` via PK/zip detection, matching the PDF buffer path instead of throwing).
- Markdown input (a `.md` file that already had frontmatter no longer produces a doubled block or clobbers the real title; `--no-links`/`--no-images`/`--no-tables` are honored for Markdown input).
- Build before test (`scripts/test.sh` and the badges workflow now build first, since the CLI end-to-end tests spawn the compiled `bin/get-md.js`).

## Tests and docs

592 tests passing, up from 528 at v1.5.0. New coverage covers PDF extraction, page-marker stripping, info-dict metadata, and structure reconstruction; DOCX buffer routing, `numbering.xml` list resolution, and corrupt-archive errors; Markdown-input frontmatter preservation and content filtering; and real DOCX and PDF CLI end-to-end runs.

The Conversion API page now covers PDF and DOCX buffers, binary auto-detection, `inputType`, the `convertDocx*` exports, and Markdown input. The CLI reference documents format detection and the DOCX and `.md` input paths. Getting Started and Quick Start show PDF, DOCX, and Markdown examples alongside the HTML path.

## Install

```
npm install @nanocollective/get-md@1.6.0
```

Node.js 22 or later is required. No peer dependencies are required for the standard HTML, PDF, DOCX, or Markdown paths.

If you've been holding off on get-md because of the HTML-only surface, this is the release to revisit. And if you've been hitting one of the bugs above on a pre-release branch, this should clear it.

Repo: https://github.com/Nano-Collective/get-md
Discussion: https://github.com/Nano-Collective/get-md/discussions


get-md v1.6.0 is out. PDF, DOCX, and Markdown inputs join HTML and URLs, with auto-detection from file extension or magic bytes. Plus a launch-hardening pass over the whole multi-format surface.

https://github.com/Nano-Collective/get-md

#OpenSource #Markdown


Your agent's tool outputs become its next prompt. `ls`, `git log`, `cat`, `grep` all flow back into the model, full of usernames, paths, and URLs - and most scrubbers only watch the user side. prompt-scrub scrubs every message regardless of origin.


Donations should have nowhere to hide. At the Nano Collective the charter names the only two destinations for every dollar before you give it: the cost of running the collective, or the community fund that pays OSS contributors. That is the whole model.


100ms or 5-10 seconds. get-md does both: Turndown for batch, CI, and real-time; the local ReaderLM-v2 path when the page's structure matters more than the speed. You pick, per call.



A schema change without a migration is a follow-up no one gets to. json-up puts version, schema, and up() in the same PR, so the change ships complete or it doesn't ship.



20+ named adapters, plus anything OpenAI-compatible. The Nanocoder provider list (Ollama, llama.cpp, MLX, Claude, Copilot, OpenRouter) is less a checklist and more a switching surface. The agent you write today runs against whichever backend you point it at tomorrow.



A regex can't tell you if a haiku scans. Nanotune's LLM judge scores open-ended answers against criteria you pick - helpful, accurate, concise, or your own - and shows reasoning per criterion, not just a yes/no. Cloud or local Ollama. Vibe-based evals stop passing.


A VPN doesn't redact the email in your prompt. Privacy at the wire and privacy at the content are different products. prompt-scrub is the second one. It scrubs what the model actually reads, not the route it travels.



Sponsor money at the Nano Collective pays for infra and a ring-fenced community fund for OSS bounties. That is the whole list. No roadmap say, no contributor targeting, no exclusivity, no slot caps. Same words in the charter and on the sponsor page.



Display-rendering a page and feeding it to an LLM are not the same job. Same source, different output. Pretending they are is why so much crawled content enters prompts broken.

`get-md` ships them as two artifacts.



Your JSON already has a version field and the convention is wrong. Rename it and every reader breaks. json-up lets you pass `key: 'version'` (or anything else) to migrate over it as-is, so the schema catches up without a breaking rename.


A risky refactor with an agent feels like a hostage negotiation: commit nothing, hope for the best. /checkpoint create first, let the AI try it twice, /checkpoint load the better one. Files and history roll back together.


A 0.5B to 1.5B fine-tune is useless if it can't leave your laptop. nanotune export fuses your LoRA into the base and writes GGUF down to q4_k_s, so you drop the same file into llama.cpp, Ollama, or LM Studio without rebuilding anything.