Help us improve
Share bugs, ideas, or general feedback.
From deepwiki
Evidence-backed documentation patterns with source code citations. Provides guidelines for citing source files, line numbers, and code examples in technical documentation. Use when writing documentation that needs to reference actual code.
npx claudepluginhub gravity9-tech/claude_code_marketplace_demo --plugin deepwikiHow this skill is triggered — by the user, by Claude, or both
Slash command
/deepwiki:evidence-citationThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Guidelines for creating evidence-backed technical documentation. Every significant claim should be traceable to actual source code.
Writes or updates documentation with code-verified accuracy for READMEs, guides, and API references. Use when creating, reviewing, or updating docs.
Writes READMEs, API references, architecture docs, user guides, and inline comments for codebases, libraries, CLIs, APIs. Audits docs for accuracy, clarity, completeness.
Enforces documentation standards for README structure, code comments, and API docs. Useful when writing or reviewing project docs.
Share bugs, ideas, or general feedback.
Guidelines for creating evidence-backed technical documentation. Every significant claim should be traceable to actual source code.
Never make claims without evidence. Documentation that isn't grounded in actual code becomes stale and misleading. Always cite your sources.
Use when pointing to a specific file:
The system uses FastAPI for the REST API (see `app/main.py`).
Use when pointing to a specific location:
Authentication is handled by the `verify_token` function (see `auth/jwt.py:42`).
Use when referring to a block of code:
The checkout workflow is implemented in `services/checkout.py:15-89`.
Use when referring to multiple files:
All API routes follow RESTful conventions (see `routes/**/*.ts`).
Use when referring to a module or component:
User management is handled by the auth module (see `src/auth/`).
For quick references where the reader can easily find the code:
The system uses PostgreSQL for persistence (see `docker-compose.yml`).
Include brief context about what to look for:
Rate limiting is configured at 100 requests per minute (see `middleware/ratelimit.ts:23` — the `RATE_LIMIT` constant).
Include actual code for critical documentation:
The system uses FastAPI for the REST API (see `app/main.py`):
\`\`\`python
from fastapi import FastAPI
app = FastAPI(title="MyAPI", version="1.0.0")
\`\`\`
| Situation | Citation Level | Example |
|---|---|---|
| Well-known patterns | Level 1 | "Uses React hooks (see hooks/)" |
| Configuration values | Level 2 | "Timeout set to 30s (see config.ts:15 — REQUEST_TIMEOUT)" |
| Critical architecture | Level 3 | Full code sample with file reference |
| Security mechanisms | Level 3 | Full code sample showing implementation |
| Complex algorithms | Level 3 | Full code sample with explanation |
List all factual statements you're making:
For each claim, locate the source code that supports it:
# Search for framework usage
grep -r "from fastapi" --include="*.py"
# Find configuration
grep -r "DATABASE_URL" --include="*.env*"
# Locate specific functions
grep -rn "def authenticate" --include="*.py"
Before citing, verify:
Insert citations using appropriate level based on importance.
The application follows a layered architecture:
- **Presentation layer**: API routes (see `routes/`)
- **Business logic**: Service classes (see `services/`)
- **Data access**: Repository pattern (see `repositories/`)
The frontend is built with React 18 and TypeScript (see `package.json:12-15`):
\`\`\`json
{
"dependencies": {
"react": "^18.2.0",
"typescript": "^5.0.0"
}
}
\`\`\`
The API rate limits requests to 1000/hour per IP (see `config/ratelimit.ts:8`):
\`\`\`typescript
export const RATE_LIMIT = {
windowMs: 60 * 60 * 1000, // 1 hour
max: 1000
};
\`\`\`
The checkout process follows these steps (see `services/checkout.ts:45-120`):
1. Validate cart items (`validateCart()` at line 48)
2. Calculate totals (`calculateTotals()` at line 62)
3. Process payment (`processPayment()` at line 78)
4. Create order (`createOrder()` at line 95)
# Bad
The system handles authentication.
# Good
Authentication uses JWT tokens validated by middleware (see `middleware/auth.ts:15-30`).
# Bad (if code has changed)
See `auth.ts:42` for the login function.
# Better (more resilient)
See the `handleLogin` function in `auth.ts`.
# Bad
The API is secure.
# Good
The API implements security measures including:
- JWT authentication (see `middleware/auth.ts`)
- Rate limiting (see `middleware/ratelimit.ts`)
- Input validation (see `validators/`)
- HTTPS enforcement (see `server.ts:12`)
# Bad (making up code)
\`\`\`python
# This is how it probably works
def authenticate(user):
return check_password(user)
\`\`\`
# Good (actual code from repo)
\`\`\`python
# From auth/service.py:23-28
def authenticate(credentials: LoginCredentials) -> AuthResult:
user = self.user_repo.find_by_email(credentials.email)
if not user or not verify_password(credentials.password, user.password_hash):
raise InvalidCredentialsError()
return AuthResult(user=user, token=self.create_token(user))
\`\`\`
Before finalizing documentation, verify:
Version: 1.0 Last Updated: 2026-01-22