SkillTide Submit
Official description7 sourcesMCP servers8d ago
Doucs91/hivelore

Doucs91/hivelore

Policy gate for agent-written code: briefs agents
View on GitHub ↗Direct link · no redirect page
Config template (adjust for your client)
claude mcp add hivelore -- npx -y hivelore
A pasteable skeleton generated from the repository name. Check the project README for the exact package and arguments.
Star count
4 ★ · Doucs91/hivelore · read from the GitHub search API · (checked 2026-10-16 20:00:20)
Source
collected from the punkpeye/awesome-mcp-servers list · type: MCP server
Harvest history
first seen 2026-10-09 · last seen 2026-10-16 · seen 32× · listed by 7 sources
Score
score 703 · 4 ★ · 7 sources · mcp
FAQ (answers come from our records)
How do I install it?
We did not find an install command for this repository (our install coverage is only about 4%). Check its README or releases page.
Who is it for?
We filed it under these tags: MCP 服务. The tags come from the entry itself, not a taxonomy we imposed.
Who maintains it?
repository Doucs91/hivelore;first catalogued 2026-10-09;last seen 2026-10-16。There is no official certification or quality rating here — we record sources and dates only.
Third-party quality signals

Hivelore

以下摘录自该仓库的 README(片段) · 在 GitHub 读完整 README →

The deterministic policy gate for agent-written code — it refuses the commit that repeats a mistake your team already paid for.
A repo-native context policy for coding-agent harnesses; the rules live as team memory. Formerly published as hAIve ( @hiveai/* ).
Hivelore is the **enforcement layer** inside an AI coding-agent harness. It briefs agents with the team's non-obvious knowledge before they act, then turns each hard-won lesson into a **deterministic gate** — in MCP, Git hooks, and CI — that blocks the change about to repeat it. Same diff, same verdict, on every machine. **Memory is the substrate; the gate is the product.**
A capable model already knows generic best practice. What it *cannot* guess is your team's arbitrary, repo-specific knowledge: that public ids are id + 100000 prefixed AC-, that the status field must be "OK"/"KO", that you never edit an applied migration. Left to itself, a confident agent invents a plausible answer - clean, tested, green, and **wrong by policy**. Hivelore carries that unguessable knowledge into the task and blocks the change that's about to violate it.
> Hivelore's job is not to replace tests, linters, or observability. It makes the repo-specific knowledge those tools cannot infer available, auditable, and enforceable.
Capture a mistake → attach a validated guard → the commit that repeats it is refused. Same diff, same verdict, on every machine and in CI. Reproduce it in 60 seconds ↓
---
The problem
AI coding agents are powerful, but they often act with incomplete repo context. Compaction, parallel sessions, agent switches, and stale advisory docs all create the same failure mode: the agent changes code without carrying the team's current decisions into the work.
Most teams work around this with instructions and hope:
- *"Please read our architecture decisions first."*
- *"Don't repeat the migration mistake from last sprint."*
- *"Remember to capture what you learned."*
- *"Don't merge code that invalidates a team decision."*
Those rules are easy to skip. Hivelore turns them into **repo-native context policy**.
---
How it works
1. hivelore init creates a .ai/ context policy layer in your repo.
2. Agents start every session with get_briefing — one MCP call that returns small default context plus deeper breadcrumbs ranked by task relevance.
3. Decisions, gotchas, failed attempts, and session recaps live as Markdown files anchored to the code paths they describe. When code moves, Hivelore detects stale anchors.
4. hivelore enforce check and CI enforcement block unsafe states: missing briefing, stale critical decisions, an anchored anti-pattern your diff is about to repeat, or uncaptured session knowledge.
> **Memory is the substrate. Context enforcement is the product promise.**
> AI changes should not enter the codebase without consulting the team's current knowledge.
For the changes prompted by the September 18 client reports, including evidence checks, quieter
briefings and completion scoped to a task, see the implementation notes.
Where Hivelore fits in the harness
Harness engineering is about the environment around the model: feedforward guidance before it acts, feedback sensors after it acts, and workflow gates that keep bad states from landing. Hivelore owns the **repo-specific context policy** part of that harness.
| Harness concern | Hivelore role |
|---|---|
| **Feedforward guidance** | get_briefing, module context, skills, decisions, gotchas, failed attempts |
| **Feedback and gates** | MCP ordering policy, pre_commit_check, Git hooks, CI enforcement, stale-anchor detection |
| **Knowledge lifecycle** | Git-native Markdown records, path/symbol anchors, confidence, retirement, linting |
| **Boundaries** | Hivelore complements unit/e2e tests, type checks, runtime traces, security scanners, and LLM evals; it does not try to replace them |
The narrow positioning is intentional: Hivelore is not a general memory database or an agent dashboard. It is the control layer that helps coding agents act with the validated, non-obvious knowledge of the team.
Scope & boundaries — the three harnesses
Harness engineering regulates three different things about agent-written code. Hivelore deliberately
covers two of them and **treats the third as out of scope, for now.**
| Harness dimension | Question it answers | Hivelore today |
|---|---|---|
| **Maintainability** | Is the code clean? (patterns, footguns, conventions) | ✅ **Covered** — executable sensors + anti-pattern gate |
Source
awesome · https://github.com/Doucs91/hivelore
Browse by field
MCP servers
Traction
4 ★
added
yesterday

More in MCP servers

All 5,525 in MCP servers →

Filed under

Every tag opens the full list for that filter. Counts are the live catalogue figures.

Browse all fields →

← Back to index