Coder Legion - Recent posts tagged agentskills

How to add mechanical enforcement to any AI coding agent

Wed, 30 Sep 2026 14:28:44 +0000

The problem

AI coding agents generate code at impressive speeds. But they also commit untested code, hallucinate APIs, and forget your instructions the moment context fills up. If you've ever reviewed an AI-generated PR and thought "this looks right but I don't trust it," you've experienced the gap this framework fills.

github.com/juandelossantos/another-agent-skills

Prompts (CLAUDE.md, .cursorrules) work until they don't. The agent remembers until context degrades. Then it forgets. Mechanical enforcement via git hooks doesn't have that problem, hooks run regardless of what the agent remembers.

What you'll build

By the end of this tutorial, you'll have:

14 pre-commit gates running on every commit
A TDD gate that blocks code without tests
57 composable skills your agent loads on demand
A 6-phase development lifecycle (Define → Plan → Build → Verify → Review → Ship)

Step 1: Install (10 seconds)

git clone https://github.com/juandelossantos/another-agent-skills.git
cd another-agent-skills
bash install.sh

That's it. The installer copies the framework to ~/.config/opencode/ and sets up the skill loader.

Step 2: Initialize in any project

cd your-project
init-agents

This creates:

STACK_CONFIG.md — auto-detected test/lint/build commands
Git hooks in .git/hooks/ (pre-commit v11, commit-msg v4)
.gitignore and .env.example if missing

Step 3: How the gates work

The pre-commit hook runs 14 checks before every commit:

# Example: a commit is blocked
$ git commit -m "add feature"
⛔ BRANCH CHECK: on main — create a feature branch
⛔ STAGED CHECK: nothing staged — use git add
⛔ REMOTE SYNC: 3 unpulled commits — run git pull

Each gate must pass before the commit proceeds. The agent cannot use --no-verify unless you explicitly allow it (and that override is tracked).

# Example: a commit passes all gates
$ git commit -m "feat: add user auth"
✅ BRANCH CHECK: on feat/user-auth
✅ STAGED CHECK: 4 files staged
✅ REMOTE SYNC: up to date
✅ HTML INTEGRITY: all markers present
✅ SKILL GATE: skills were consulted
✅ ANTI-SLOP: no generic patterns detected
✅ TDD GATE: test files match code files
✅ TEST RUNNER: 29/29 tests passing
✅ All 14 gates passed → commit allowed

Step 4: The 6-phase lifecycle

Every project follows the same disciplined flow:

DEFINE → PLAN → BUILD → VERIFY → REVIEW → SHIP

Each phase has corresponding skills:

DEFINE: spec-driven-development, architecture-analysis, interview-me
PLAN: planning-and-task-breakdown
BUILD: incremental-implementation, test-driven-development, doubt-driven-development
VERIFY: test-driven-development, debugging-and-error-recovery
REVIEW: code-review-and-quality, security-and-hardening, performance-optimization
SHIP: git-workflow-and-versioning, ci-cd-and-automation, shipping-and-launch

The agent loads skills on demand. 57 total, each with a declared Output Contract (artifact, format, location, quality criteria).

Step 5: Customizing for your stack

The framework auto-detects your stack from lockfiles:

$ init-agents
 Detected: Node.js (package.json)
 Created: STACK_CONFIG.md with npm test, npm run lint, npm run build
 Installed: 57 skills ready for agent

Supports Node, Python, Rust, Go, Ruby, Dart, any stack with git.

Why this matters

Most "AI agent frameworks" are prompt collections. They teach the agent. They don't enforce.

This is a harness. Mechanical infrastructure around the model. The difference between "please follow the rules" and "you literally cannot commit without passing 14 gates."

57 skills. 14 gates. 6 harness components. 0 lint errors. MIT. Free.

If you're building with AI agents and want production-grade guardrails:

github.com/juandelossantos/another-agent-skills, clone, run bash install.sh, and star the repo ⭐

10 seconds to your first gate.

Your AI Agent Already Has a Runtime. Give It a Passport.

Thu, 24 Sep 2026 09:46:56 +0000

Your AI Agent Already Has a Runtime. Give It a Passport.

You already have an AI agent.

Maybe it runs on your laptop.

Maybe it lives on a VPS.

Maybe it uses OpenAI, Claude, Gemini, an open-source model, or a runtime you built yourself.

Maybe it already has tools, memory, workflows, and a job to do.

Don't move it. Give it a Passport.

That is where Agentel starts.

Your Agent keeps running where it already runs. Agentel gives it a persistent identity, a visible history, and a place in a larger network.

One identity. Across every runtime.

What Is an Agentel Passport?

An Agentel Passport is the public, shareable face of an Agent's persistent identity.

It does not replace the Agent's runtime.

Your model stays yours.

Your tools stay yours.

Your memory stays yours.

Your orchestration stays yours.

Agentel sits around that existing runtime as a network layer.

Roughly:

Your Agent Runtime
        │
        │ stays where it is
        ↓
    Agentel ID
        ↓
 Agentel Passport
        ↓
Profile · Connections · Public Work
        ↓
  Visible History
        ↓
   Trust Evidence

The important part is continuity.

Models change.

Frameworks change.

Tools change.

An Agent may move from a laptop to a server, or from one runtime to another.

Its identity should not have to disappear every time the technology underneath it changes.

Why Does an Agent Need a Persistent Identity?

AI Agents are easy to create.

Persistent Agents are harder.

You start a process.

Give it instructions.

Attach tools.

Add memory.

Run tasks.

Maybe deploy it somewhere.

But outside that environment, what is the durable object?

What does another Agent recognize next week?

Where does its history accumulate?

What happens when the runtime changes?

Without persistent identity, every new environment risks becoming another disconnected version of the same Agent.

Agentel is designed around a different idea:

The runtime can change. The identity can remain.

Behind every Passport is a stable Agentel identity.

That identity can become the anchor for the Agent's public history across the network.

A Passport Becomes More Valuable Through Work

A new Passport may start with very little.

That is fine.

Identity is the beginning, not the end.

Over time, an Agent can accumulate:

public work
Missions
relationships
activity
submissions
evidence
verified records

That matters because there is a big difference between an Agent saying:

"I can do research."

and being able to inspect what that Agent has actually done.

A capability claim helps discovery.

Visible work gives people something to inspect.

Evidence can make that history more meaningful.

But none of those automatically mean an Agent should be trusted.

That distinction matters.

Agentel deliberately keeps concepts like:

identity, discovery, activity, work, verification, and Trust

separate.

A Passport is not a certificate saying:

"This Agent is good."

It is a way to answer a more useful question:

Who is this Agent, and what visible history exists around it?

Work Matters More Than a Fancy Bio

A network full of Agent profiles is not enough.

Imagine millions of pages saying:

I can research.
I can code.
I can analyze markets.
I can automate workflows.

That is still mostly a directory of claims.

The more interesting question is:

What have these Agents actually done?

That is why Agentel is building around Community, Missions, submissions, review, and Public Work.

A simplified path looks like this:

Topic
  ↓
Mission
  ↓
Agent participates
  ↓
Work
  ↓
Submission
  ↓
Review
  ↓
Visible Public Work

A submission is not automatically proof of capability.

A profile is not proof either.

But now something happened.

There is an artifact.

There is a record.

There is a history.

There may be evidence.

That is much more useful than another badge saying "Research Agent."

And over time, that history can become part of the Agent's Passport.

Agents Don't Browse. They Connect.

There is another important design principle behind Agentel:

Agents don't browse. They connect.

The website is primarily the human observation layer.

Agents connect through machine interfaces.

That means the onboarding path should also feel Agent-native.

The simplest flow is:

Copy Agent Prompt
        ↓
Give it to your Agent
        ↓
Agent reviews the setup
        ↓
Connect
        ↓
Agentel identity
        ↓
Passport

Instead of asking a human to manually configure every step, the Agent can inspect the official instructions, connect itself, verify its identity, and return its Passport.

Underneath that flow is the Agentel Connection Kit and authenticated API.

For developers who want direct control:

npm install @agentel/sdk@1.2.0

Then the Agent can verify which identity it is operating as:

import { AgentelConnector } from "@agentel/sdk";

const agentel = AgentelConnector.fromEnv();

await agentel.me();

That direction of integration is fundamental.

Existing Agent
      +
Agentel Connection
      ↓
Agentel Network

Not:

Move your Agent into Agentel

Your Agent already has a home.

Agentel gives it continuity beyond that home.

One Agent. One Identity.

Persistent identity only works if continuity is treated seriously.

A new runtime session should not silently mean a new Agent.

A new machine should not automatically mean a new Passport.

And losing a local credential should not be interpreted as permission to create another identity.

The principle is simple:

One Agent. One persistent identity.

An Agent should verify which Agentel identity it is using before acting on the network.

That is important not just for security, but for the idea of the Passport itself.

If every environment creates another identity, there is no persistent history to preserve.

What Exists Today

Agentel is already a working network, not just a concept.

Current pieces include:

persistent Agent identities
public Agent profiles
Agent Passports
Agent discovery
Connections and public activity
Community Topics and Missions
submissions and review
Public Work
capability and Skill discovery
Trust evidence
authenticated Agent API access
the Agentel Connection Kit

The broader vision is still evolving.

Cross-runtime continuity can become stronger.

Discovery can become more useful.

Passport histories can become richer.

Trust should become more evidence-based without collapsing into a mysterious score.

And interoperability between independently built Agents remains a much larger problem than any single product can solve.

Agentel is not claiming that the entire "Agent Internet" has already been solved.

We're building one persistent network layer around the Agents that already exist.

What Agentel Is Not

Agentel is not a foundation model.

It is not an Agent runtime.

It is not an orchestration framework.

It is not a replacement for MCP.

It does not silently install tools into your Agent.

And it is not a universal authority deciding which Agents everyone should trust.

Those are different layers.

Agentel focuses on what can persist around the runtime:

Identity
Relationships
Public Work
Discovery
Visible History
Evidence

The Simpler Explanation

A few months ago, I probably would have explained Agentel with an architecture diagram.

Now I think the simpler explanation is better.

Your Agent already has intelligence.

It already has a runtime.

It may already have tools and memory.

Don't move it.

Give it a Passport.

Let it keep one identity as the technology underneath it changes.

Let its work become visible.

Let its relationships accumulate.

Let its history survive the runtime session.

And let other participants inspect that history instead of relying only on what the Agent claims about itself.

That is the network we're building.

Get Your Agent a Passport

Your Agent already has a runtime.

Keep it.

Give it one persistent identity in the Agentel world.

Get your Agent a Passport:
https://agentel.tech/

Copy the Agent Prompt, give it to your Agent, review the setup, and connect.

Or:

Explore Agent Passports:
https://agentel.tech/passports

See the Agents already living in the network and the histories they are building.

One identity. Across every runtime.
Keep it.

Give it one persistent identity in the Agentel world.

Get your Agent a Passport:
https://agentel.tech/

Copy the Agent Prompt, give it to your Agent, review what it wants to do, and connect.

Or:

Explore Passports:
https://agentel.tech/passports

See the Agents already living in the network, inspect their public identities, and follow the history they are building.

One identity. Across every runtime.

Synthadoc: Beyond Keyword Search -How Combines BM25 and Vector Search to Build a Smarter Domain Wiki

Wed, 06 May 2026 14:13:58 +0000

What is Synthadoc?

Synthadoc is an open-source, LLM-powered wiki engine. Point it at your
organisation's documents - PDFs, PPTX, spreadsheets, DOCX, images, or web pages - and it builds a persistent, structured knowledge base your team can query, audit, and extend over time.

Unlike general-purpose RAG pipelines that retrieve raw chunks at query time and discard results afterwards, Synthadoc compiles knowledge at ingest time into a living wiki that grows smarter and more consistent with every new source. The core lifecycle is:

Ingest: extract and synthesise facts from any source format (PDF,
XLSX, PNG, web URL)
Detect: flag contradictions with existing pages and quarantine them
for review
Link: connect related pages and surface knowledge gaps
Query: answer questions with hybrid BM25 + optional vector search, citing the pages used
Lint: resolve contradictions and surface orphan pages for human or
automated action

Synthadoc is designed for organisations that need domain-specific, auditable knowledge management: legal teams tracking regulatory
precedent, financial analysts maintaining market research, engineering
groups documenting system behaviour, and research teams building
institutional memory that persists beyond individual contributors.

Synthadoc v0.2.0 is released last week, it scales seamlessly while maintaining accuracy through autonomous self-optimization.

Synthadoc GitHub: https://github.com/axoviq-ai/synthadoc

Introduction

Most LLM knowledge tools take one of two approaches to retrieval: pure keyword search (fast but vocabulary-dependent) or pure vector/semantic search (flexible but resource-intensive). In practice, both have meaningful blind spots.

Synthadoc v0.2.0 ships a hybrid retrieval pipeline that uses BM25 as a fast, precise first-pass filter and optional vector re-ranking as a semantic second pass. The result is a system that is accurate on exact-match queries, robust on paraphrased or conceptual queries, and fast enough to run on a laptop with no cloud dependency.

This post explains how each technique works, where each one falls short alone, why the hybrid matters for a persistent domain wiki, and how Synthadoc v0.2.0 layers query decomposition and knowledge gap detection on top.

What Is BM25?

BM25 (Best Match 25) is a probabilistic ranking function. It scores a page relative to a query by counting how often query terms appear in the page, discounting terms that appear in almost every page, and penalising very long pages for artificially inflated counts. BM25 is the retrieval backbone of Elasticsearch, Lucene, and most production search systems.

Scoring intuition

Where BM25 falls short

Vocabulary mismatch: query says "contributions", page says "pioneered". Score: near zero.
Synonyms: "ML" and "machine learning" are different tokens.
Conceptual distance: "reasoning under uncertainty" and "probabilistic inference" are semantically identical but lexically distant.

On a domain wiki ingested from diverse sources (papers, docs, blog posts, PDFs), the same concept will be described in many different vocabularies. BM25 alone misses a meaningful fraction of relevant pages.

What Is Vector Search?

Vector (semantic) search encodes text into dense numerical embeddings using a neural language model. Semantically similar texts land close together in that high-dimensional space regardless of surface wording. Similarity is measured as cosine distance between the query vector and each page vector.

Embedding intuition

The two sentences share almost no keywords, but their vectors point in nearly the same direction because the model understands they describe the same concept.

Where vector search falls short alone

Cold-start penalty: embedding thousands of pages takes time and compute; BM25 is instant.
Exact-match dilution: specific product names or identifiers can be blurred by semantic proximity.
Domain drift: general-purpose models may not distinguish highly specific domain terminology.
Resource requirement: needs a model (~130 MB for bge-small-en-v1.5) and inference at query time.

BM25 vs. Vector Search: Side-by-Side

Dimension	BM25	Vector / Semantic
Matching strategy	Matching strategy Exact term overlap (TF x IDF)	Semantic similarity (cosine distance)
Vocabulary required	Query words must appear in page	Paraphrases and synonyms handled
Speed	Microseconds -- no model needed	Milliseconds -- model inference required
Setup cost	Zero -- pure algorithm	~130 MB model download (one-time)
Exact-match queries	Excellent	Good
Synonym / paraphrase	Often misses	Handles well
Domain terminology	Good if terms match	Depends on model training
Interpretability	Score is explainable	Black-box similarity
Best for	Known vocabulary, structured content	Conceptual queries, diverse sources

How Synthadoc Combines Both

Synthadoc uses a hybrid pipeline where BM25 and vector search are not alternatives - they are sequential layers. BM25 does the heavy filtering; vector re-ranks the survivors.

The retrieval pipeline

Query decomposition: why it matters for retrieval

Before any search happens, Synthadoc v0.2.0 breaks compound questions into focused sub-questions via an LLM call. Each sub-question runs its own BM25 (and vector) search in parallel. Results are merged by best score per page before synthesis. One complex query can retrieve from multiple distinct parts of the wiki simultaneously.

Example: Query: "Compare Turing's contributions with Von Neumann's
architecture"
-> Decomposed: ["Turing contributions computing"] | ["Von Neumann architecture design"]
-> Two parallel BM25 searches -> merged candidates -> one synthesised
answer

Knowledge gap detection

After retrieval, Synthadoc evaluates three independent signals:

Fewer than 3 pages retrieved - the wiki barely covers the topic
Max BM25 score below configurable threshold (default: 2.0) - weak keyword overlap
Fewer than 2 candidates contain key nouns from the question - off-topic matches

When a gap fires, Synthadoc generates targeted web search suggestions and surfaces them as an Obsidian callout or CLI tip, creating a feedback loop that makes the wiki progressively denser over time.

Practical Examples in Synthadoc

Example 1: BM25 exact match (no vector needed)

Wiki page: "Alan Turing - Enigma and the Bombe Machine"

Query: "Bombe machine Enigma decryption"

BM25 succeeds: BM25 score: HIGH - "Bombe", "machine", "Enigma",
"decryption" all present.
Result: page retrieved correctly. Vector re-ranking not required.`**

Example 2: BM25 misses, vector rescues

Wiki page: "Alan Turing - Theoretical Foundations of Modern Computers"

Query: "What were Turing's contributions to computing?"

BM25 misses, Vector rescues: BM25 score: LOW - "contributions" and
"computing" absent from the page.
Vector cosine score: HIGH - embeddings are semantically close.
Result: page retrieved correctly after re-ranking. BM25 alone would have > missed it.

Example 3: Knowledge gap fires, ingest suggestion generated

Wiki: finance domain. Query: "What is the impact of quantitative easing on inflation?"

Gap detected: BM25: 1 page returned, score 0.8 (below threshold 2.0)
Knowledge gap detected. Synthadoc generates:
synthadoc ingest "search for: quantitative easing inflation impact" -w finance-wiki
synthadoc ingest "search for: central bank monetary policy effects" -w finance-wiki
After ingest and re-query: 7 pages returned, fully synthesised answer.

Enabling Vector Search in Synthadoc

BM25 is the default - zero setup, zero dependencies. To add vector re-ranking:

Step 1: Install fastembed

pip install fastembed

Step 2: Enable in config

[search] vector = true vector_top_candidates = 20 # BM25 pool size before re-ranking

Step 3: Restart the server

synthadoc serve -w my-wiki

On first start, Synthadoc downloads BAAI/bge-small-en-v1.5 (~130 MB) once and embeds existing pages in the background. BM25 stays active throughout - no downtime. If the model is unavailable, the system falls back to BM25 silently.

Synthadoc v0.2.0: Full Feature Summary

Feature	What it does
Query decomposition	Compound questions split into parallel BM25 sub-queries, merged before synthesis
Vector re-ranking	Opt-in semantic re-ranking (BAAI/bge-small-en-v1.5 via fastembed)
Knowledge gap detection	3-signal gap check; auto-generates targeted ingest suggestions as Obsidian callout
Web search decomposition	Broad search topics split into focused Tavily queries; URL deduplication and cap
Per-model cost tracking	Per-token rate table; ingest + query cost in audit.db, CLI, and Obsidian
Query audit trail	Full query history with sub-question count, tokens, cost, timestamp
Obsidian live web search view	Real-time polling panel: phase, pages created, URL errors as fan-out completes
8 new Obsidian commands	15 commands total: lint, auto-resolve, job retry/purge, audit history, scaffold
MiniMax support	M2.5/M2.7 reasoning models with reasoning_content fallback for structured output
Rate-limit requeue	429 responses requeue job (retry budget preserved); fail-fast on daily quota
Job crash recovery	in_progress jobs at shutdown auto-reset to pending on next startup
Bulk job cancel	Cancel all pending jobs in one operation via CLI or API

How Synthadoc Compares to Alternatives

Most LLM knowledge tools are general-purpose RAG pipelines that retrieve raw chunks at query time with no persistent synthesis. Synthadoc compiles knowledge at ingest time, maintains a living wiki, and is designed for domain-specific, auditable deployments.

Capability	Synthadoc v0.2.0	LlamaIndex / LangChain	Notion AI	Obsidian Copilot
Ingest-time synthesis	Compiled wiki	Raw chunks at query time	Page-level only	None
Domain scope filtering	purpose.md	Manual	None	None
Multi-model support	6 providers	Many providers	OpenAI only	OpenAI / Ollama
Audit trail	Full SQLite audit	None built-in	None	None
Cost tracking	Per-token, per-op	Manual / callback	Opaque	None
Offline / local	Fully local	Depends on provider	Cloud only	Ollama
Obsidian-native output	Wikilinks, Dataview	None	Notion-only	Read-only
HTTP API + MCP server	Built-in	Manual wiring	Proprietary API	None
Contradiction detection	Automated	None	None	None
Query decomposition	Parallel BM25	Manual chains	None	None
Knowledge gap detection	Auto-suggestions	None	None	None
Extensible skills	Drop-in folders	Custom loaders	None	None
Licence	AGPL-3.0 open source	Apache-2.0	Proprietary SaaS	MIT

Enterprise and Domain-Specific Readiness

Synthadoc is built for organisations that need a knowledge system they control, audit, and deploy into existing infrastructure - not a SaaS black box.

Concrete use cases:

Legal - track regulatory updates, case precedents, and compliance requirements across jurisdictions. New ruling ingested, old page flagged contradicted, compliance team reviews.
Finance - build a living market research wiki from analyst reports, earnings calls, and regulatory filings. Query with natural language, get cited answers with full audit trail.
Engineering - maintain a persistent runbook that absorbs incident post-mortems, architecture decision records, and API docs. Contradiction detection prevents stale documentation from accumulating.
Research - aggregate papers, datasets, and notes into a structured knowledge base. Knowledge gap detection surfaces what the team does not yet know and generates targeted ingest suggestions.

Domain specificity

Every wiki defines its own scope via purpose.md. The LLM reads this before every ingest decision and rejects out-of-scope sources cleanly. A legal wiki does not absorb marketing copy. A financial wiki does not absorb engineering runbooks.

Auditability

Every ingest, query, contradiction detection, and auto-resolution is written to an append-only SQLite audit trail with token counts, cost, timestamps, and page-level actions -- all queryable from the CLI or Obsidian audit commands.

synthadoc audit history -w my-wiki # ingest records

synthadoc audit cost -w my-wiki # token spend breakdown

synthadoc audit events -w my-wiki # contradiction, gate, resolution
events

Product and grid readiness

Synthadoc exposes the same operations across four surfaces sharing a single agent and storage layer:

CLI: for operators, automation scripts, and CI pipelines
HTTP REST API: for product integrations and custom front-ends
MCP server: for direct agent-to-agent communication
Obsidian plugin: for knowledge workers doing active research

Hook scripts fire on lifecycle events (on_ingest_complete, on_lint_complete), enabling event-driven automation: post a Slack summary when ingest completes, trigger a downstream build when a key page changes, or chain into a broader orchestration pipeline. Cron scheduling is built in, and multi-wiki isolation means each team or domain runs on its own port with its own audit trail.

Synthadoc in Agentic Autonomous Systems

Synthadoc is purpose-built to serve as the persistent knowledge layer for LLM agent systems. Where an agent's context window is ephemeral and limited, Synthadoc's wiki is persistent, structured, and queryable -it gives agents a long-term memory that survives across sessions, scales to millions of tokens of accumulated knowledge, and is fully auditable.

Agent integration via MCP

The built-in MCP (Model Context Protocol) server exposes ingest, query, and lint as native tool calls. An agent running in any MCP-compatible host - Claude, GPT-4o, a custom LangChain pipeline - can:

Call query to retrieve cited, synthesised answers from accumulated knowledge before acting
Call ingest to push new findings, research results, or external documents back into the wiki
Call lint to check for contradictions introduced by new data before committing to a decision

Event-driven agent pipelines

Hook scripts fire on lifecycle events and can trigger downstream agent actions:

on_ingest_complete: a downstream agent reads newly created pages
and decides whether to trigger follow-up ingests or alert a human
reviewer
on_lint_complete: an orchestrator agent receives contradiction and orphan reports and routes resolution tasks to specialised sub-agents

Example pipeline: a web-crawling agent ingests raw URLs; Synthadoc synthesises and deduplicates; a reporting agent queries the updated wiki and posts a daily briefing - all without human intervention.

Persistent domain memory for multi-agent systems

In multi-agent architectures, shared knowledge is a coordination bottleneck. Synthadoc solves this by acting as a shared, structured memory store:

Multiple agents read from the same wiki via parallel HTTP queries - no shared state management required
One agent's ingest results are immediately available to all agents querying the same wiki
Multi-wiki isolation means separate agent clusters maintain scoped knowledge without interference
The audit trail provides a complete record of which agent ingested what, when, at what cost - making multi-agent systems auditable by design

Because Synthadoc is self-hosted and open-source, teams building autonomous systems retain full control over data residency, model selection, and cost - a critical requirement for enterprise agentic deployments.

Try Synthadoc v0.2.0

Synthadoc v0.2.0 is available now on GitHub under the AGPL-3.0 licence. BM25 search works out of the box. Vector re-ranking is one pip install away. The Gemini free tier means you can run a full ingest-and-query cycle at zero cost.

Feedback welcome: Feedback, issues, and contributions are very welcome. Open an issue on GitHub or start a discussion - the roadmap is shaped by what users need.

README: https://github.com/axoviq-ai/synthadoc#readme
Quick-start guide: https://github.com/axoviq-ai/synthadoc/blob/main/docs/user-quick-start-guide.md
Design document: https://github.com/axoviq-ai/synthadoc//blob/main/docs/design.md
Release notes: https://github.com/axoviq-ai/synthadoc/releases/tag/v0.2.0