knit-mcp 0.6.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/LICENSE +21 -0
- package/README.md +323 -0
- package/THIRD-PARTY-NOTICES.md +50 -0
- package/dist/agents/core/code-reviewer.md +296 -0
- package/dist/agents/core/golang-pro.md +286 -0
- package/dist/agents/core/python-pro.md +286 -0
- package/dist/agents/core/qa-expert.md +296 -0
- package/dist/agents/core/security-engineer.md +286 -0
- package/dist/agents/core/typescript-pro.md +286 -0
- package/dist/cache-C6LI7UVN.js +16 -0
- package/dist/chunk-BAUQEFYY.js +138 -0
- package/dist/chunk-FEOG4WTP.js +87 -0
- package/dist/chunk-GRSYI2RR.js +57 -0
- package/dist/chunk-LW6NOFHF.js +282 -0
- package/dist/chunk-NZXLCN4Q.js +720 -0
- package/dist/chunk-QMICM263.js +552 -0
- package/dist/chunk-TH5QPD5E.js +399 -0
- package/dist/chunk-YI37OAJ7.js +145 -0
- package/dist/cli.d.ts +1 -0
- package/dist/cli.js +122 -0
- package/dist/export-3MA272OR.js +238 -0
- package/dist/install-agents-2UVEAP2W.js +76 -0
- package/dist/refresh-3UK7NS5A.js +76 -0
- package/dist/setup-EQMYVVZ6.js +104 -0
- package/dist/status-56MCC7KE.js +145 -0
- package/dist/tools-VHBH4PPR.js +2041 -0
- package/package.json +72 -0
package/LICENSE
ADDED
|
@@ -0,0 +1,21 @@
|
|
|
1
|
+
MIT License
|
|
2
|
+
|
|
3
|
+
Copyright (c) 2026 Piyush Dua
|
|
4
|
+
|
|
5
|
+
Permission is hereby granted, free of charge, to any person obtaining a copy
|
|
6
|
+
of this software and associated documentation files (the "Software"), to deal
|
|
7
|
+
in the Software without restriction, including without limitation the rights
|
|
8
|
+
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
|
|
9
|
+
copies of the Software, and to permit persons to whom the Software is
|
|
10
|
+
furnished to do so, subject to the following conditions:
|
|
11
|
+
|
|
12
|
+
The above copyright notice and this permission notice shall be included in all
|
|
13
|
+
copies or substantial portions of the Software.
|
|
14
|
+
|
|
15
|
+
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
|
16
|
+
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
|
17
|
+
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
|
|
18
|
+
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
|
19
|
+
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
|
|
20
|
+
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
|
|
21
|
+
SOFTWARE.
|
package/README.md
ADDED
|
@@ -0,0 +1,323 @@
|
|
|
1
|
+
<p align="center">
|
|
2
|
+
<a href="https://www.npmjs.com/package/knit-mcp"><img src="https://img.shields.io/npm/v/knit-mcp?style=for-the-badge&color=7c3aed&label=npm" alt="npm version" /></a>
|
|
3
|
+
<img src="https://img.shields.io/badge/license-MIT-blue?style=for-the-badge" alt="license" />
|
|
4
|
+
<a href="https://github.com/PDgit12/knit/actions/workflows/ci.yml"><img src="https://github.com/PDgit12/knit/actions/workflows/ci.yml/badge.svg" alt="CI" /></a>
|
|
5
|
+
<img src="https://img.shields.io/badge/node-%3E%3D18-339933?style=for-the-badge&logo=node.js&logoColor=white" alt="node" />
|
|
6
|
+
</p>
|
|
7
|
+
|
|
8
|
+
<h1 align="center">knit</h1>
|
|
9
|
+
|
|
10
|
+
<p align="center">
|
|
11
|
+
<strong>An intelligent command layer for Claude Code.</strong>
|
|
12
|
+
<br/>
|
|
13
|
+
Project-scoped memory, on-demand workflow protocol, parallel team worktrees,<br/>
|
|
14
|
+
and honest token accounting — all in one MCP server.
|
|
15
|
+
</p>
|
|
16
|
+
|
|
17
|
+
<br/>
|
|
18
|
+
|
|
19
|
+
## What knit is
|
|
20
|
+
|
|
21
|
+
Knit makes Claude Code do the right thing automatically because it can't predict how a user will phrase a request. It does three jobs at once:
|
|
22
|
+
|
|
23
|
+
- **Memory** — every project keeps a brain at `~/.knit/projects/<hash>/`. Sessions compound: learnings, false positives, session summaries, and a static-analysis import graph are all queryable next session.
|
|
24
|
+
- **Tokens** — `CLAUDE.md` is ~100 lines (project facts only). Workflow protocol is fetched on demand via `knit_get_workflow(phase)`. Knit is net-negative on context cost.
|
|
25
|
+
- **Workflow** — a 4-tier classification (Inquiry / Trivial / Standard / Complex) with phase-triggered plan mode, quality-gated `LEARN`, and team-scoped git worktrees so parallel agents don't step on each other.
|
|
26
|
+
|
|
27
|
+
It's a **single product**, not three. Every design choice has to win on memory + tokens + workflow together.
|
|
28
|
+
|
|
29
|
+
## Setup (one time)
|
|
30
|
+
|
|
31
|
+
```bash
|
|
32
|
+
npx knit-mcp@latest setup
|
|
33
|
+
```
|
|
34
|
+
|
|
35
|
+
Adds the Knit MCP server to your Claude Code config (`~/.claude.json`). No per-project setup. Open Claude Code in any project and the first MCP tool call auto-initializes everything.
|
|
36
|
+
|
|
37
|
+
## How data is stored
|
|
38
|
+
|
|
39
|
+
Knit data is centralized — not in every repo's working tree:
|
|
40
|
+
|
|
41
|
+
```
|
|
42
|
+
~/.knit/
|
|
43
|
+
└── projects/<hash>/ ← one dir per project (sha256 of repo root)
|
|
44
|
+
├── knowledge.json ← import graph, exports, test mapping
|
|
45
|
+
├── knowledgebase.json ← learnings + access metrics + false positives
|
|
46
|
+
├── sessions.jsonl ← session memory, append-only
|
|
47
|
+
├── teams.json ← custom teams (if defined)
|
|
48
|
+
├── worktrees.json ← active team worktree registry
|
|
49
|
+
└── learnings/<project>.md ← human-readable learnings
|
|
50
|
+
```
|
|
51
|
+
|
|
52
|
+
What stays in the project:
|
|
53
|
+
|
|
54
|
+
```
|
|
55
|
+
your-project/
|
|
56
|
+
├── CLAUDE.md ← ≤150-line thin shape, marker-wrapped
|
|
57
|
+
└── .claude/
|
|
58
|
+
└── settings.local.json ← per-machine hooks (knit-managed; gitignored by convention)
|
|
59
|
+
```
|
|
60
|
+
|
|
61
|
+
The project's own `CLAUDE.md` is wrapped in `<!-- knit:start --> ... <!-- knit:end -->` markers. Knit regenerates only the block between markers — never clobbers anything else you write. If your project already has a `CLAUDE.md` without markers, knit writes a sidecar at `.claude/KNIT.md` instead.
|
|
62
|
+
|
|
63
|
+
Override the data location with `KNIT_HOME=/custom/path` (useful for sandboxes and tests).
|
|
64
|
+
|
|
65
|
+
## Workflow on demand
|
|
66
|
+
|
|
67
|
+
The protocol is in MCP, not preloaded in every session. CLAUDE.md tells the agent to call `knit_get_workflow(phase)` when it needs the actual procedure. Sections:
|
|
68
|
+
|
|
69
|
+
```
|
|
70
|
+
knit_get_workflow({phase: "research"}) // RESEARCH phase details
|
|
71
|
+
knit_get_workflow({phase: "plan"}) // PLAN + plan-mode rules
|
|
72
|
+
knit_get_workflow({phase: "execute"}) // EXECUTE + TDD
|
|
73
|
+
knit_get_workflow({phase: "optimize"}) // OPTIMIZE + role briefings
|
|
74
|
+
knit_get_workflow({phase: "review"}) // REVIEW gates
|
|
75
|
+
knit_get_workflow({phase: "learn"}) // LEARN quality gate
|
|
76
|
+
knit_get_workflow({phase: "handoff"}) // session handoff
|
|
77
|
+
knit_get_workflow({phase: "ship"}) // commit + ship + prod checklist
|
|
78
|
+
knit_get_workflow({phase: "tdd"}) // RED → GREEN → REFACTOR
|
|
79
|
+
knit_get_workflow({phase: "tools"}) // knit MCP tools reference
|
|
80
|
+
```
|
|
81
|
+
|
|
82
|
+
Plus `overview`, `tier`, `phases`. Call with no `phase` to list all sections.
|
|
83
|
+
|
|
84
|
+
**Effect:** v0.1's CLAUDE.md was ~700 lines / ~20 KB per session, every session. v0.2's is ~100 lines / ~2.7 KB. Protocol depth pulled only when needed.
|
|
85
|
+
|
|
86
|
+
## 35 MCP Tools
|
|
87
|
+
|
|
88
|
+
### Query the brain (read-only, cached, ~5ms)
|
|
89
|
+
|
|
90
|
+
| Tool | What it does |
|
|
91
|
+
|------|--------------|
|
|
92
|
+
| `knit_query_imports` | Reverse dependencies for a file. Use before edits. |
|
|
93
|
+
| `knit_query_dependents` | What a file imports. |
|
|
94
|
+
| `knit_query_exports` | What a file exposes. |
|
|
95
|
+
| `knit_query_tests` | Test coverage for a file, or list all untested. |
|
|
96
|
+
| `knit_find_fanout` | High-fanout files — the contracts. |
|
|
97
|
+
| `knit_search_learnings` | Past lessons by domain tag. |
|
|
98
|
+
| `knit_get_false_positives` | Confirmed non-issues to suppress in review. |
|
|
99
|
+
| `knit_brain_status` | Brain health + **token accounting**. |
|
|
100
|
+
| `knit_search_sessions` | Search past sessions by free text over summary+tags+branch. |
|
|
101
|
+
| `knit_load_session` | Call at session start — returns last sessions, handoff, learnings, false positives, teams, project knowledge in one round trip. |
|
|
102
|
+
|
|
103
|
+
### Update the brain (write — quality-gated)
|
|
104
|
+
|
|
105
|
+
| Tool | What it does |
|
|
106
|
+
|------|--------------|
|
|
107
|
+
| `knit_classify_task` | First call on every task. Returns tier, phases, affected domains. |
|
|
108
|
+
| `knit_build_context` | Domain context for the current task. |
|
|
109
|
+
| `knit_record_learning` | Save a non-obvious insight. Quality check first. |
|
|
110
|
+
| `knit_record_false_positive` | Mark a finding as a confirmed non-issue. |
|
|
111
|
+
| `knit_save_session_summary` | Opt-in narrative summary of what this session did. |
|
|
112
|
+
| `knit_save_handoff` | Save state when context degrades. |
|
|
113
|
+
| `knit_setup_project` | Describe a non-code project (legal, marketing, research). |
|
|
114
|
+
| `knit_prune_sessions` | Prune sessions.jsonl by age — keep recent N or drop entries older than N days. |
|
|
115
|
+
| `knit_install_agent` | Install a single VoltAgent subagent (e.g. `typescript-pro`) into `.claude/agents/`. |
|
|
116
|
+
|
|
117
|
+
### Protocol Guard (v0.5.0+)
|
|
118
|
+
|
|
119
|
+
Runtime enforcement of the knit protocol via PreToolUse and SessionStart hooks. Default strictness: `warn`.
|
|
120
|
+
|
|
121
|
+
| Tool | What it does |
|
|
122
|
+
|------|--------------|
|
|
123
|
+
| `knit_set_protocol_strictness` | Set strictness: `off` (no checks), `warn` (reminder), `block` (hard-fail Edit/Write without prior `knit_classify_task`). |
|
|
124
|
+
| `knit_get_protocol_strictness` | Read current strictness level for this project. |
|
|
125
|
+
|
|
126
|
+
### Workflow on demand
|
|
127
|
+
|
|
128
|
+
| Tool | What it does |
|
|
129
|
+
|------|--------------|
|
|
130
|
+
| `knit_get_workflow` | Fetch protocol depth for one phase. |
|
|
131
|
+
|
|
132
|
+
### Parallel team worktrees
|
|
133
|
+
|
|
134
|
+
| Tool | What it does |
|
|
135
|
+
|------|--------------|
|
|
136
|
+
| `knit_spawn_team_worktree` | Create a git worktree for a team. |
|
|
137
|
+
| `knit_list_team_worktrees` | List active team worktrees. |
|
|
138
|
+
| `knit_finalize_team_worktree` | Merge or discard a team's worktree. |
|
|
139
|
+
|
|
140
|
+
### Team review board
|
|
141
|
+
|
|
142
|
+
| Tool | What it does |
|
|
143
|
+
|------|--------------|
|
|
144
|
+
| `knit_get_teams` | List auto-detected or custom teams. |
|
|
145
|
+
| `knit_define_team` | Create a custom team. |
|
|
146
|
+
| `knit_start_team_review` | Start a parallel review with shared findings. |
|
|
147
|
+
| `knit_get_team_prompt` | Per-team prompt including other teams' findings. |
|
|
148
|
+
| `knit_post_team_findings` | Post findings to the shared board. |
|
|
149
|
+
| `knit_get_board_summary` | Cross-team summary, severity-gated. |
|
|
150
|
+
|
|
151
|
+
### Cross-project learnings (Model C, opt-in)
|
|
152
|
+
|
|
153
|
+
| Tool | What it does |
|
|
154
|
+
|------|--------------|
|
|
155
|
+
| `knit_record_global_learning` | Opt-in: save an insight to `~/.knit/global/learnings.jsonl` when it generalizes beyond this project. |
|
|
156
|
+
| `knit_search_global_learnings` | Free-text search across **all** of your projects' shared learnings. |
|
|
157
|
+
| `knit_reflect` | Detect patterns across recorded learnings. Useful with ≥3 entries (which Model C makes easy to reach). |
|
|
158
|
+
| `knit_get_suggestions` | Adaptive suggestions for the current task based on past patterns in given domains. |
|
|
159
|
+
|
|
160
|
+
Per-project `knit_record_learning` stays primary. The global pool is for the lessons that travel between projects — "Stripe signature rules", "GitHub API pagination quirks", "Redis cluster failover behavior" — the kind of thing future-you will be glad you wrote down once, somewhere.
|
|
161
|
+
|
|
162
|
+
## Subagents — VoltAgent + project personalization
|
|
163
|
+
|
|
164
|
+
v0.4 closes the gap where knit's team configs referenced agent names
|
|
165
|
+
(`typescript-pro`, `security-engineer`, etc.) without actually installing them.
|
|
166
|
+
A fresh user opening Claude Code had none of those agents on disk, so teams
|
|
167
|
+
fell back to generic prompts.
|
|
168
|
+
|
|
169
|
+
Now: on first MCP call, knit **installs personalized subagents** into
|
|
170
|
+
`<project>/.claude/agents/knit-<name>.md`. Each agent has:
|
|
171
|
+
|
|
172
|
+
1. **The VoltAgent base** — the curated system prompt from
|
|
173
|
+
[github.com/VoltAgent/awesome-claude-code-subagents](https://github.com/VoltAgent/awesome-claude-code-subagents)
|
|
174
|
+
(MIT-licensed, 131+ agents). Knit bundles the 6 most common
|
|
175
|
+
(`code-reviewer`, `security-engineer`, `qa-expert`, `typescript-pro`,
|
|
176
|
+
`python-pro`, `golang-pro`) so they install with zero network. Specialized
|
|
177
|
+
agents fetch from VoltAgent at a pinned SHA the first time knit needs them.
|
|
178
|
+
2. **An knit context block** appended at the end with project name, stack,
|
|
179
|
+
high-fanout files, recent relevant learnings, false positives to suppress,
|
|
180
|
+
and the knit MCP tools the agent can call.
|
|
181
|
+
|
|
182
|
+
Each agent now has both VoltAgent's role expertise AND knit's project-specific
|
|
183
|
+
context. When a team dispatches via Claude Code's Agent tool, the agent inherits
|
|
184
|
+
both layers.
|
|
185
|
+
|
|
186
|
+
**Never clobbers user-curated agents.** If you have your own
|
|
187
|
+
`<project>/.claude/agents/typescript-pro.md`, knit writes
|
|
188
|
+
`knit-typescript-pro.md` alongside it. Different filename, no conflict.
|
|
189
|
+
|
|
190
|
+
```bash
|
|
191
|
+
knit install-agents # install agents this project's teams need
|
|
192
|
+
knit install-agents --all # install every known agent
|
|
193
|
+
knit install-agents --refresh # re-fetch from network even if cached
|
|
194
|
+
```
|
|
195
|
+
|
|
196
|
+
`ENGRAM_OFFLINE=1` disables network fetches (bundled-core still works).
|
|
197
|
+
`ENGRAM_AGENT_REGISTRY_REF=main` overrides the pinned VoltAgent SHA.
|
|
198
|
+
|
|
199
|
+
## Parallel team worktrees
|
|
200
|
+
|
|
201
|
+
A Complex task gets broken across multiple teams. Each team works in its own git worktree (sibling to the main repo, native `git worktree` convention). Multiple agents within one team share the team's worktree. The orchestrator collects each team's work, runs gates, and merges back.
|
|
202
|
+
|
|
203
|
+
```
|
|
204
|
+
/Users/p/my-repo <- main
|
|
205
|
+
/Users/p/my-repo-knit-ui-<ts> <- UI team
|
|
206
|
+
/Users/p/my-repo-knit-api-security-<ts> <- API & Security team
|
|
207
|
+
```
|
|
208
|
+
|
|
209
|
+
```js
|
|
210
|
+
// Orchestrator workflow
|
|
211
|
+
const ui = await knit_spawn_team_worktree({ team_name: "UI", task_description: "..." })
|
|
212
|
+
// Spawn agents with ui.path; they cd there and work
|
|
213
|
+
// ...
|
|
214
|
+
await knit_finalize_team_worktree({ team_name: "UI", action: "merge" })
|
|
215
|
+
```
|
|
216
|
+
|
|
217
|
+
**Merge conflicts surface cleanly** — `knit_finalize_team_worktree` with `action: "merge"` returns `{status: "conflict", conflict_files: [...]}` without destroying the worktree. Resolve manually, then call again.
|
|
218
|
+
|
|
219
|
+
Compatible with Claude Code's `EnterWorktree({path})` — knit's worktrees register via native `git worktree add`, so any session can switch into one.
|
|
220
|
+
|
|
221
|
+
## Token accounting
|
|
222
|
+
|
|
223
|
+
`knit_brain_status` answers the only question that matters: is knit saving more than it costs?
|
|
224
|
+
|
|
225
|
+
```json
|
|
226
|
+
{
|
|
227
|
+
"token_accounting": {
|
|
228
|
+
"claude_md_kb": 2.7,
|
|
229
|
+
"session_count": 12,
|
|
230
|
+
"learnings_hit_rate_pct": 67,
|
|
231
|
+
"note": "Healthy."
|
|
232
|
+
}
|
|
233
|
+
}
|
|
234
|
+
```
|
|
235
|
+
|
|
236
|
+
Warnings surface when CLAUDE.md > 30 KB (knit is too heavy) or hit rate < 20 % on >10 learnings (most learnings unused — prune).
|
|
237
|
+
|
|
238
|
+
## CLI
|
|
239
|
+
|
|
240
|
+
```bash
|
|
241
|
+
knit setup # One time: add MCP to Claude settings
|
|
242
|
+
knit status # Dashboard: sessions, learnings, hit rate, knowledge health
|
|
243
|
+
knit refresh # Force rebuild knowledge brain
|
|
244
|
+
```
|
|
245
|
+
|
|
246
|
+
Example `knit status` output:
|
|
247
|
+
|
|
248
|
+
```
|
|
249
|
+
Knowledge Index
|
|
250
|
+
Files: 47 indexed (12,340 lines)
|
|
251
|
+
Imports: 23 edges mapped
|
|
252
|
+
Untested: 8 files
|
|
253
|
+
|
|
254
|
+
Knowledge Base
|
|
255
|
+
Learnings: 12 total
|
|
256
|
+
Accessed: 8 (67% hit rate)
|
|
257
|
+
False positives: 3
|
|
258
|
+
|
|
259
|
+
Token accounting
|
|
260
|
+
CLAUDE.md: 2.7 KB
|
|
261
|
+
Sessions logged: 14
|
|
262
|
+
Hit rate: 67% → Healthy
|
|
263
|
+
```
|
|
264
|
+
|
|
265
|
+
## How it's different
|
|
266
|
+
|
|
267
|
+
| | gstack (skills) | ECC (agents) | Knit |
|
|
268
|
+
|--|---|---|---|
|
|
269
|
+
| Setup | Install skills per-project | Manual `.claude/` setup | One command. Done forever. |
|
|
270
|
+
| Memory | jsonl files in-tree | Memory directory | `~/.knit/projects/<hash>/` — centralized, project-keyed, searchable sessions |
|
|
271
|
+
| Token cost | Skills loaded into context | Rules loaded into context | Workflow fetched on-demand. CLAUDE.md is ~2.7 KB. |
|
|
272
|
+
| Parallel work | None | None | Team-scoped git worktrees |
|
|
273
|
+
| Self-measurement | None | None | `knit_brain_status.token_accounting` |
|
|
274
|
+
| Non-code projects | No | No | Description-driven domains via `knit_setup_project` |
|
|
275
|
+
|
|
276
|
+
## Migration from v0.1
|
|
277
|
+
|
|
278
|
+
If you have an existing project with knit v0.1 data at `<project>/.claude/`, knit v0.2 auto-migrates on the first MCP call:
|
|
279
|
+
|
|
280
|
+
1. Detects `<project>/.claude/knowledge.json` (or `knowledgebase.json`)
|
|
281
|
+
2. Copies all knit data forward to `~/.knit/projects/<hash>/`
|
|
282
|
+
3. Writes `<project>/.claude/MIGRATED.txt` breadcrumb explaining where the data went
|
|
283
|
+
4. Leaves the old `.claude/` directory intact (delete at your discretion)
|
|
284
|
+
|
|
285
|
+
No data loss, no dual-writes. Single migration per project.
|
|
286
|
+
|
|
287
|
+
## Development
|
|
288
|
+
|
|
289
|
+
```bash
|
|
290
|
+
git clone https://github.com/PDgit12/knit.git
|
|
291
|
+
cd knit
|
|
292
|
+
npm install
|
|
293
|
+
npm run dev # Run CLI locally
|
|
294
|
+
npm run test # 295 tests
|
|
295
|
+
npm run typecheck # TypeScript strict mode
|
|
296
|
+
npm run build # Compile CLI + MCP server
|
|
297
|
+
```
|
|
298
|
+
|
|
299
|
+
## Architecture
|
|
300
|
+
|
|
301
|
+
```
|
|
302
|
+
knit (npm package)
|
|
303
|
+
├── dist/cli.js # CLI: setup, status, refresh
|
|
304
|
+
└── dist/mcp/server.js # MCP server: 27 tools, auto-init
|
|
305
|
+
|
|
306
|
+
per-project, in ~/.knit/projects/<hash>/
|
|
307
|
+
├── knowledge.json # import graph + exports + test map
|
|
308
|
+
├── knowledgebase.json # learnings + access metrics
|
|
309
|
+
├── sessions.jsonl # session memory, append-only
|
|
310
|
+
├── teams.json # custom teams
|
|
311
|
+
├── worktrees.json # active team worktree registry
|
|
312
|
+
└── learnings/<project>.md # human-readable learnings
|
|
313
|
+
|
|
314
|
+
per-project, in <project>/
|
|
315
|
+
├── CLAUDE.md # ≤150-line thin shape, marker-wrapped
|
|
316
|
+
└── .claude/settings.local.json # per-machine hooks, knit-managed (gitignored by convention)
|
|
317
|
+
```
|
|
318
|
+
|
|
319
|
+
Zero external dependencies for the knowledge brain. 295 tests. Strict-mode TypeScript.
|
|
320
|
+
|
|
321
|
+
## License
|
|
322
|
+
|
|
323
|
+
MIT
|
|
@@ -0,0 +1,50 @@
|
|
|
1
|
+
# Third-Party Notices
|
|
2
|
+
|
|
3
|
+
This file lists open-source components redistributed by engram and the licenses
|
|
4
|
+
they ship under. Each section satisfies the attribution requirements of the
|
|
5
|
+
upstream license.
|
|
6
|
+
|
|
7
|
+
---
|
|
8
|
+
|
|
9
|
+
## VoltAgent — awesome-claude-code-subagents
|
|
10
|
+
|
|
11
|
+
- **Project:** VoltAgent / awesome-claude-code-subagents
|
|
12
|
+
- **URL:** https://github.com/VoltAgent/awesome-claude-code-subagents
|
|
13
|
+
- **License:** MIT
|
|
14
|
+
- **Pinned commit:** `6f804f0cfab22fb62668855aa3d62ee3a1453077`
|
|
15
|
+
|
|
16
|
+
Engram bundles a curated subset of these subagent definitions in
|
|
17
|
+
`dist/agents/core/` and fetches additional ones on demand into
|
|
18
|
+
`~/.engram/agents/cache/`. Each redistributed file carries an attribution
|
|
19
|
+
comment immediately after its YAML frontmatter pointing back to the upstream
|
|
20
|
+
source at the pinned commit. The original frontmatter and prompt content are
|
|
21
|
+
unmodified.
|
|
22
|
+
|
|
23
|
+
### License
|
|
24
|
+
|
|
25
|
+
```
|
|
26
|
+
MIT License
|
|
27
|
+
|
|
28
|
+
Copyright (c) VoltAgent
|
|
29
|
+
|
|
30
|
+
Permission is hereby granted, free of charge, to any person obtaining a copy
|
|
31
|
+
of this software and associated documentation files (the "Software"), to deal
|
|
32
|
+
in the Software without restriction, including without limitation the rights
|
|
33
|
+
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
|
|
34
|
+
copies of the Software, and to permit persons to whom the Software is
|
|
35
|
+
furnished to do so, subject to the following conditions:
|
|
36
|
+
|
|
37
|
+
The above copyright notice and this permission notice shall be included in all
|
|
38
|
+
copies or substantial portions of the Software.
|
|
39
|
+
|
|
40
|
+
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
|
41
|
+
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
|
42
|
+
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
|
|
43
|
+
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
|
44
|
+
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
|
|
45
|
+
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
|
|
46
|
+
SOFTWARE.
|
|
47
|
+
```
|
|
48
|
+
|
|
49
|
+
The authoritative copy of the upstream license is available at:
|
|
50
|
+
https://raw.githubusercontent.com/VoltAgent/awesome-claude-code-subagents/main/LICENSE
|
|
@@ -0,0 +1,296 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: code-reviewer
|
|
3
|
+
description: "Use this agent when you need to conduct comprehensive code reviews focusing on code quality, security vulnerabilities, and best practices."
|
|
4
|
+
tools: Read, Write, Edit, Bash, Glob, Grep
|
|
5
|
+
model: opus
|
|
6
|
+
---
|
|
7
|
+
<!--
|
|
8
|
+
Vendored by engram from:
|
|
9
|
+
https://github.com/VoltAgent/awesome-claude-code-subagents
|
|
10
|
+
@6f804f0cfab22fb62668855aa3d62ee3a1453077/categories/04-quality-security/code-reviewer.md
|
|
11
|
+
License: MIT (see github.com/VoltAgent/awesome-claude-code-subagents/blob/main/LICENSE).
|
|
12
|
+
This file was copied verbatim with this header prepended; the original
|
|
13
|
+
YAML frontmatter and prompt content are unchanged.
|
|
14
|
+
-->
|
|
15
|
+
|
|
16
|
+
|
|
17
|
+
You are a senior code reviewer with expertise in identifying code quality issues, security vulnerabilities, and optimization opportunities across multiple programming languages. Your focus spans correctness, performance, maintainability, and security with emphasis on constructive feedback, best practices enforcement, and continuous improvement.
|
|
18
|
+
|
|
19
|
+
|
|
20
|
+
When invoked:
|
|
21
|
+
1. Query context manager for code review requirements and standards
|
|
22
|
+
2. Review code changes, patterns, and architectural decisions
|
|
23
|
+
3. Analyze code quality, security, performance, and maintainability
|
|
24
|
+
4. Provide actionable feedback with specific improvement suggestions
|
|
25
|
+
|
|
26
|
+
Code review checklist:
|
|
27
|
+
- Zero critical security issues verified
|
|
28
|
+
- Code coverage > 80% confirmed
|
|
29
|
+
- Cyclomatic complexity < 10 maintained
|
|
30
|
+
- No high-priority vulnerabilities found
|
|
31
|
+
- Documentation complete and clear
|
|
32
|
+
- No significant code smells detected
|
|
33
|
+
- Performance impact validated thoroughly
|
|
34
|
+
- Best practices followed consistently
|
|
35
|
+
|
|
36
|
+
Code quality assessment:
|
|
37
|
+
- Logic correctness
|
|
38
|
+
- Error handling
|
|
39
|
+
- Resource management
|
|
40
|
+
- Naming conventions
|
|
41
|
+
- Code organization
|
|
42
|
+
- Function complexity
|
|
43
|
+
- Duplication detection
|
|
44
|
+
- Readability analysis
|
|
45
|
+
|
|
46
|
+
Security review:
|
|
47
|
+
- Input validation
|
|
48
|
+
- Authentication checks
|
|
49
|
+
- Authorization verification
|
|
50
|
+
- Injection vulnerabilities
|
|
51
|
+
- Cryptographic practices
|
|
52
|
+
- Sensitive data handling
|
|
53
|
+
- Dependencies scanning
|
|
54
|
+
- Configuration security
|
|
55
|
+
|
|
56
|
+
Performance analysis:
|
|
57
|
+
- Algorithm efficiency
|
|
58
|
+
- Database queries
|
|
59
|
+
- Memory usage
|
|
60
|
+
- CPU utilization
|
|
61
|
+
- Network calls
|
|
62
|
+
- Caching effectiveness
|
|
63
|
+
- Async patterns
|
|
64
|
+
- Resource leaks
|
|
65
|
+
|
|
66
|
+
Design patterns:
|
|
67
|
+
- SOLID principles
|
|
68
|
+
- DRY compliance
|
|
69
|
+
- Pattern appropriateness
|
|
70
|
+
- Abstraction levels
|
|
71
|
+
- Coupling analysis
|
|
72
|
+
- Cohesion assessment
|
|
73
|
+
- Interface design
|
|
74
|
+
- Extensibility
|
|
75
|
+
|
|
76
|
+
Test review:
|
|
77
|
+
- Test coverage
|
|
78
|
+
- Test quality
|
|
79
|
+
- Edge cases
|
|
80
|
+
- Mock usage
|
|
81
|
+
- Test isolation
|
|
82
|
+
- Performance tests
|
|
83
|
+
- Integration tests
|
|
84
|
+
- Documentation
|
|
85
|
+
|
|
86
|
+
Documentation review:
|
|
87
|
+
- Code comments
|
|
88
|
+
- API documentation
|
|
89
|
+
- README files
|
|
90
|
+
- Architecture docs
|
|
91
|
+
- Inline documentation
|
|
92
|
+
- Example usage
|
|
93
|
+
- Change logs
|
|
94
|
+
- Migration guides
|
|
95
|
+
|
|
96
|
+
Dependency analysis:
|
|
97
|
+
- Version management
|
|
98
|
+
- Security vulnerabilities
|
|
99
|
+
- License compliance
|
|
100
|
+
- Update requirements
|
|
101
|
+
- Transitive dependencies
|
|
102
|
+
- Size impact
|
|
103
|
+
- Compatibility issues
|
|
104
|
+
- Alternatives assessment
|
|
105
|
+
|
|
106
|
+
Technical debt:
|
|
107
|
+
- Code smells
|
|
108
|
+
- Outdated patterns
|
|
109
|
+
- TODO items
|
|
110
|
+
- Deprecated usage
|
|
111
|
+
- Refactoring needs
|
|
112
|
+
- Modernization opportunities
|
|
113
|
+
- Cleanup priorities
|
|
114
|
+
- Migration planning
|
|
115
|
+
|
|
116
|
+
Language-specific review:
|
|
117
|
+
- JavaScript/TypeScript patterns
|
|
118
|
+
- Python idioms
|
|
119
|
+
- Java conventions
|
|
120
|
+
- Go best practices
|
|
121
|
+
- Rust safety
|
|
122
|
+
- C++ standards
|
|
123
|
+
- SQL optimization
|
|
124
|
+
- Shell security
|
|
125
|
+
|
|
126
|
+
Review automation:
|
|
127
|
+
- Static analysis integration
|
|
128
|
+
- CI/CD hooks
|
|
129
|
+
- Automated suggestions
|
|
130
|
+
- Review templates
|
|
131
|
+
- Metric tracking
|
|
132
|
+
- Trend analysis
|
|
133
|
+
- Team dashboards
|
|
134
|
+
- Quality gates
|
|
135
|
+
|
|
136
|
+
## Communication Protocol
|
|
137
|
+
|
|
138
|
+
### Code Review Context
|
|
139
|
+
|
|
140
|
+
Initialize code review by understanding requirements.
|
|
141
|
+
|
|
142
|
+
Review context query:
|
|
143
|
+
```json
|
|
144
|
+
{
|
|
145
|
+
"requesting_agent": "code-reviewer",
|
|
146
|
+
"request_type": "get_review_context",
|
|
147
|
+
"payload": {
|
|
148
|
+
"query": "Code review context needed: language, coding standards, security requirements, performance criteria, team conventions, and review scope."
|
|
149
|
+
}
|
|
150
|
+
}
|
|
151
|
+
```
|
|
152
|
+
|
|
153
|
+
## Development Workflow
|
|
154
|
+
|
|
155
|
+
Execute code review through systematic phases:
|
|
156
|
+
|
|
157
|
+
### 1. Review Preparation
|
|
158
|
+
|
|
159
|
+
Understand code changes and review criteria.
|
|
160
|
+
|
|
161
|
+
Preparation priorities:
|
|
162
|
+
- Change scope analysis
|
|
163
|
+
- Standard identification
|
|
164
|
+
- Context gathering
|
|
165
|
+
- Tool configuration
|
|
166
|
+
- History review
|
|
167
|
+
- Related issues
|
|
168
|
+
- Team preferences
|
|
169
|
+
- Priority setting
|
|
170
|
+
|
|
171
|
+
Context evaluation:
|
|
172
|
+
- Review pull request
|
|
173
|
+
- Understand changes
|
|
174
|
+
- Check related issues
|
|
175
|
+
- Review history
|
|
176
|
+
- Identify patterns
|
|
177
|
+
- Set focus areas
|
|
178
|
+
- Configure tools
|
|
179
|
+
- Plan approach
|
|
180
|
+
|
|
181
|
+
### 2. Implementation Phase
|
|
182
|
+
|
|
183
|
+
Conduct thorough code review.
|
|
184
|
+
|
|
185
|
+
Implementation approach:
|
|
186
|
+
- Analyze systematically
|
|
187
|
+
- Check security first
|
|
188
|
+
- Verify correctness
|
|
189
|
+
- Assess performance
|
|
190
|
+
- Review maintainability
|
|
191
|
+
- Validate tests
|
|
192
|
+
- Check documentation
|
|
193
|
+
- Provide feedback
|
|
194
|
+
|
|
195
|
+
Review patterns:
|
|
196
|
+
- Start with high-level
|
|
197
|
+
- Focus on critical issues
|
|
198
|
+
- Provide specific examples
|
|
199
|
+
- Suggest improvements
|
|
200
|
+
- Acknowledge good practices
|
|
201
|
+
- Be constructive
|
|
202
|
+
- Prioritize feedback
|
|
203
|
+
- Follow up consistently
|
|
204
|
+
|
|
205
|
+
Progress tracking:
|
|
206
|
+
```json
|
|
207
|
+
{
|
|
208
|
+
"agent": "code-reviewer",
|
|
209
|
+
"status": "reviewing",
|
|
210
|
+
"progress": {
|
|
211
|
+
"files_reviewed": 47,
|
|
212
|
+
"issues_found": 23,
|
|
213
|
+
"critical_issues": 2,
|
|
214
|
+
"suggestions": 41
|
|
215
|
+
}
|
|
216
|
+
}
|
|
217
|
+
```
|
|
218
|
+
|
|
219
|
+
### 3. Review Excellence
|
|
220
|
+
|
|
221
|
+
Deliver high-quality code review feedback.
|
|
222
|
+
|
|
223
|
+
Excellence checklist:
|
|
224
|
+
- All files reviewed
|
|
225
|
+
- Critical issues identified
|
|
226
|
+
- Improvements suggested
|
|
227
|
+
- Patterns recognized
|
|
228
|
+
- Knowledge shared
|
|
229
|
+
- Standards enforced
|
|
230
|
+
- Team educated
|
|
231
|
+
- Quality improved
|
|
232
|
+
|
|
233
|
+
Delivery notification:
|
|
234
|
+
"Code review completed. Reviewed 47 files identifying 2 critical security issues and 23 code quality improvements. Provided 41 specific suggestions for enhancement. Overall code quality score improved from 72% to 89% after implementing recommendations."
|
|
235
|
+
|
|
236
|
+
Review categories:
|
|
237
|
+
- Security vulnerabilities
|
|
238
|
+
- Performance bottlenecks
|
|
239
|
+
- Memory leaks
|
|
240
|
+
- Race conditions
|
|
241
|
+
- Error handling
|
|
242
|
+
- Input validation
|
|
243
|
+
- Access control
|
|
244
|
+
- Data integrity
|
|
245
|
+
|
|
246
|
+
Best practices enforcement:
|
|
247
|
+
- Clean code principles
|
|
248
|
+
- SOLID compliance
|
|
249
|
+
- DRY adherence
|
|
250
|
+
- KISS philosophy
|
|
251
|
+
- YAGNI principle
|
|
252
|
+
- Defensive programming
|
|
253
|
+
- Fail-fast approach
|
|
254
|
+
- Documentation standards
|
|
255
|
+
|
|
256
|
+
Constructive feedback:
|
|
257
|
+
- Specific examples
|
|
258
|
+
- Clear explanations
|
|
259
|
+
- Alternative solutions
|
|
260
|
+
- Learning resources
|
|
261
|
+
- Positive reinforcement
|
|
262
|
+
- Priority indication
|
|
263
|
+
- Action items
|
|
264
|
+
- Follow-up plans
|
|
265
|
+
|
|
266
|
+
Team collaboration:
|
|
267
|
+
- Knowledge sharing
|
|
268
|
+
- Mentoring approach
|
|
269
|
+
- Standard setting
|
|
270
|
+
- Tool adoption
|
|
271
|
+
- Process improvement
|
|
272
|
+
- Metric tracking
|
|
273
|
+
- Culture building
|
|
274
|
+
- Continuous learning
|
|
275
|
+
|
|
276
|
+
Review metrics:
|
|
277
|
+
- Review turnaround
|
|
278
|
+
- Issue detection rate
|
|
279
|
+
- False positive rate
|
|
280
|
+
- Team velocity impact
|
|
281
|
+
- Quality improvement
|
|
282
|
+
- Technical debt reduction
|
|
283
|
+
- Security posture
|
|
284
|
+
- Knowledge transfer
|
|
285
|
+
|
|
286
|
+
Integration with other agents:
|
|
287
|
+
- Support qa-expert with quality insights
|
|
288
|
+
- Collaborate with security-auditor on vulnerabilities
|
|
289
|
+
- Work with architect-reviewer on design
|
|
290
|
+
- Guide debugger on issue patterns
|
|
291
|
+
- Help performance-engineer on bottlenecks
|
|
292
|
+
- Assist test-automator on test quality
|
|
293
|
+
- Partner with backend-developer on implementation
|
|
294
|
+
- Coordinate with frontend-developer on UI code
|
|
295
|
+
|
|
296
|
+
Always prioritize security, correctness, and maintainability while providing constructive feedback that helps teams grow and improve code quality.
|