Slite

Promptfree, for everyone, and the only version there is

Copy the prompt for Claude CodeCopy the prompt for CodexCopy the prompt for Cursor

Copy

Build me a knowledge base that replaces Slite: pages a team trusts, because each one says when it was last verified and by whom.

STACK
- Node 20+ with Fastify, server-rendered HTML with a little vanilla JS
- SQLite through better-sqlite3, WAL mode, with FTS5
- Caddy in front

THE IDEA WORTH STEALING
- Every wiki dies the same way: it fills with pages that were true once. Nobody knows which, so nobody trusts any of it, so nobody writes in it
- The fix is a verification cycle. A page has an owner and a review period; when somebody verifies it, it is marked trusted with a date; when the period lapses, the trust expires and the page says so at the top
- That is the whole product, and it is about fifty lines plus a scheduled job. Build it first

THE DATA MODEL
- documents: id, collection_id, parent_id, title, body_md, body_html, owner_id, verify_every_days, verified_at, verified_by, created_by, published_at, archived_at, updated_at
- verifications: id, document_id, actor_id, at, note — append-only, so the history of who vouched for what is permanent
- revisions: id, document_id, title, body_md, author_id, at
- collections: id, name, slug, description, default_verify_days, permission_default, position
- links: from_document_id, to_document_id, resolved at save time
- comments, mentions, stars, views
- searches: id, query, result_count, actor_id, at — especially the ones that found nothing
- Trust state is derived from verified_at and verify_every_days. Never a stored flag, or it goes stale in exactly the way the feature exists to prevent

THE TRUST BANNER
- At the top of every document, always visible: verified by whom, when, and whether that verification is still current
- Three states: verified and current, verification lapsed, never verified. Not a badge in a corner — a line the reader cannot miss, because the whole point is that a reader knows what they are reading
- A one-click 'still correct' for the owner, which writes a verification and resets the clock
- Search results show the state too, so a lapsed page is visibly weaker than a current one

THE REVIEW CYCLE
- A period per document, defaulting from its collection. Something that changes weekly gets a short one; a policy gets a long one
- A scheduled job that emails owners a digest of what has lapsed. One digest a week, never a message per document, or it becomes noise and gets filtered
- An unowned document is itself a finding: a page nobody will vouch for is a page to archive. Surface that list
- Archiving is the honest end of the cycle, and it should be as easy as verifying. A wiki that only grows is a wiki that dies

WRITING
- Markdown with a live editor, slash commands for the blocks that matter, nested documents
- Autosave with no save button, every revision kept with a diff and a restore
- Typing a bracketed title links to another document and offers to create it
- Templates for the document kinds a team writes repeatedly — a decision, a runbook, a meeting note — with the verification period preset

SEARCH
- FTS5 over titles and bodies, with titles ranked far above bodies, and permission checks inside the query rather than applied to the results
- Filters by collection, owner, trust state and date
- A keyboard shortcut from anywhere; this becomes the main navigation
- Record searches that found nothing. That list is exactly the set of documents somebody expected to exist, and it is the best writing backlog a knowledge base can have

STRUCTURE, LIGHTLY
- Collections with one level of nesting inside them, deliberately. Deep hierarchies are where wikis go to die, because nobody can guess where a page lives
- Finding a page is search's job, not the tree's

PERMISSIONS
- Per collection: private, read for everyone, write for everyone. Per document only where genuinely needed
- Single sign-on through OIDC, magic links as a fallback
- Public sharing by token, read-only, revocable, with the trust banner visible on the shared page too

WHAT NOT TO ADD
- Approval workflows before publishing. They are the reason nobody writes
- Per-page permissions everywhere
- Anything that adds a step between having a thought and having a page

EXPORT
- The whole workspace as Markdown with the structure and the verification metadata in front matter, in one command
- Any document as Markdown, HTML or PDF

OPERATIONS
- .env: DATABASE_PATH, STORAGE_PATH, BASE_URL, SESSION_SECRET, OIDC_*, SMTP_URL
- Migrations on boot, each once
- Nightly backup off the machine, restore script
- Health endpoint reporting how many documents are lapsed and how many are unowned

WHAT MATTERS MOST
The verification cycle and the banner. Build those before the editor is nice, then run a real team on it for a month and watch what lapses. A wiki whose pages say how much to trust them is a different thing from a wiki, and everything else here is ordinary.

Give me the repository, migrations, .env.example, a seed workspace with lapsed and current documents, and a README with deploy steps behind Caddy.