One private knowledge base across your repositories, each rule tied to the code that enforces it. Install the GitHub App to connect. Cursor, Claude Code, Codex, and VS Code read the rule before they write. Your answer on the pull request updates the record.
Free to start. No credit card required.
Doclific is waiting for an answer.
Business rules / Payments · Refunds
A refund cannot be issued after 90 days.
confirmed by jane · in chat
acme/payments-api · src/refunds/refund-service.ts:42
This PR changes refund eligibility.
Existing section: Refunds / Refund window
This change permits refunds after 120 days for enterprise customers.
Is this intentional?
Doclific / business-context — Needs information · 1 question
DetailsReviews pull requests on GitHub. Answers Cursor, Claude Code, Codex, and VS Code.
§ 1
Examples are illustrative. Your refund window may vary.
#payments
“is the refund window 60 or 90 days now?”
No reply.
Refund policy
last edited 14 months ago
Refunds are available for 60 days.
REFUND_WINDOW_DAYS = 90 // TODO: confirm with finance
agent
> what is the refund window?
REFUND_WINDOW_DAYS = 30
Two answers, one open question, and the agent picked a third.
§ 2
Six moments. One rule. Nothing written back to the repo.
2.1 / Code
Connect a repository through GitHub. Doclific reads it with awareness of every other repo you have connected, and of every rule already written, so the record builds on itself instead of starting over.
2.2 / Documents
Every rule is written in plain language and tied to the exact code that enforces it. Nothing is written back into your repos. Nobody maintains a wiki — you browse the record and talk to it.
2.3 / Agents
Cursor, Claude Code, or Codex asks Doclific and gets exactly the rule and the reason behind it — not a dump of your docs. Agents retrieve the business reason before they write the code.
2.4 / CI
Doclific reads the pull request and reports on it: the docs still match, they need your answer, or they look out of date. Nothing ships silently.
2.5 / Reply
Reply in the thread and the rule updates in place, attributed to you and the pull request it came from. One answer. No ticket. No wiki edit.
2.6 / Loop
The next agent that asks gets the new rule. The next pull request is checked against it. Who wrote it, which PR it came from, and which files it still describes stay attached.
§ 3
Tested against Cursor, Claude Code, Codex, and VS Code. Any MCP-compatible agent can connect.
Pick the repositories Doclific may read. Draft pull requests stay out of it, and so does every repo you leave unconnected.
Create a token in the product. It is shown once. Paste it where you see tok_….
~/.cursor/mcp.json
{
"mcpServers": {
"doclific": {
"url": "https://mcp.doclific.com/mcp",
"headers": {
"Authorization": "Bearer tok_…"
}
}
}
}The next one is checked against the rules you already have. If the record is still thin, answer the questions as they come up. That is how it fills in.
§ 4
Each line is something the product already does, cited the way a rule cites code.
House rules
confirmed by the product · every plan
Your repositories
Doclific never writes to your repositories.
ref GitHub App · contents · read only
Guessing
Doclific never changes a rule on a guess. It asks, and a person answers.
ref pull request comment
What gets reviewed
Draft pull requests are left alone. Repositories you did not connect are not reviewed.
ref connected repositories only
Who can read it
Your record is never visible outside your organization. There is no public catalog and no anonymous read.
ref organization boundary
When someone leaves
Access ends when a person leaves. The connections they created stop working.
ref member access
Merges
Doclific does not block merges. It comments, and you decide. Blocking a merge on a rule you mark non-negotiable is on the roadmap.
ref comment, not a required check
The record, and the bill
Every change is logged, on every plan. Spend never passes the cap you set.
ref audit log · spend cap
§ 5
Free is one member and three repositories. Premium is billed per seat.
§ 6
Short answers. The pricing page has the billing details.
Those files tell an agent how to work in one repository. Doclific is the record of what the software is supposed to do, shared by every agent and checked on every pull request. When a rule changes, you answer on the pull request. You do not edit a file in every repo.
A code reviewer looks for bugs. Doclific looks for a disagreement between the change and a business rule a person already confirmed. When they disagree, it asks. It does not rewrite the rule, and it does not guess.
No. Build the record as you go: ask in chat, let an agent contribute, or answer on the pull request. On Premium, you can draft the whole record from the repositories you have connected.
No. It comments on the pull request, and you decide whether to merge. The option to block a merge on a rule you have marked non-negotiable is on the roadmap.
Read access to the repositories you connect, and permission to comment on pull requests. It does not write to your repositories. Drafts and unconnected repositories are left alone.
Any agent that speaks MCP. Cursor, Claude Code, Codex, and VS Code are the ones we test against.
This page describes a pull request check you haven't tried yet.
Your next PR could be the first one checked against your business rules.
Is this intentional?
Doclific / business-context — Waiting on you · 1 question
Details