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 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.