Git Hooks

query 2.md

This all looks like rookie stuff. Solve it how an enterprise solution saas company for code diffs would have done or something better than that.

query.3.md

think like a principal engineer from openAI or anthropic or some top tier org

give me an enterprise solution for the following problem statement:

objective: To perform code reviews locally using precommit and prepush hooks in git to call localhost on a certain port (to call Ollama) & then using the LLM's capabilities to get a fair assessment of the code changes and adherence to our coding guidelines present in the local directory or say, in some URL, or both (e.g. URL shares org standards, while the local shares the repo specific). I think the org context should also matter for the code review tool and therefore, there should be a way to have access to the org wiki. But be conscious about token size and stuff.

The code review tool should tell the user in a readable format critiquing your code in the best constructive format.

This hook should run locally on any repo and should also work without internet connection.

give me the guidelines and code changes

requirements.md

precommit and prepush hooks in git to call localhost on a certain port (to call Ollama) and share the delta i.e. the code changes, coding guidelines docs and the original files on which the changes were made i.e. pushing all to the context window .. and finally, a system prompt which has basic instructions like how the code checker tool should work..

all these execute and give an output in your terminal or wherever it should, critiquing your code for obvious lapses, unobvious mistakes, nitpicked other minor problems like clean code and variable names etc.

this hook runs locally on any repo where these hooks are present regardless of the code.

if the file sizes are too big, then it of course tells the users to split the code apart. But more importantly, if it exceeds the context window, then it recommends the user to keep their code change foot print small. but as of now, I do not have any idea how to solve for this. so, please suggest some ideas and their tradeoffs, and pick the one that has more advantages and fewer issues.

solution.md

Got it — you want Git hooks (pre-commit and pre-push) that automatically send your code changes, guidelines, and original files to a local service (like Ollama) for critique, while also handling context window limits gracefully. Let’s break this down into design ideas, tradeoffs, and then I’ll recommend the most practical approach.

---

🔧 Design Ideas

1. Direct Hook → Ollama Call

• Hooks collect:
  • Changed files (git diff --cached for pre-commit, git diff origin/main..HEAD for pre-push).
  • Coding guidelines (stored in a local doc).
  • Original files (grab from repo).
• Send all to Ollama via curl localhost:11434/api/....
• Ollama critiques and outputs results in terminal.

Pros:

• Simple, minimal moving parts.
• Runs automatically on every commit/push.
• Immediate feedback loop.

Cons:

• Context window overflow risk if diffs are large.
• Slows down commits/pushes (blocking workflow).
• Hard to scale across repos with different guidelines.

---

2. Pre-Hook Summarizer Layer

• Instead of sending raw files, hooks:
  • Summarize diffs (e.g., AST-based summary of changes).
  • Include only relevant guideline sections.
  • Send smaller payload to Ollama.

Abstract Syntax Tree (AST) based change summary analyzes code modifications by parsing source code into a tree structure, identifying semantic changes (additions, deletions, renames) rather than mere text diffs. This approach allows for structural understanding, enabling precise, high-accuracy code edits, refactoring, and automated code review.

Pros:

• Keeps context footprint small.
• Faster execution.
• More intelligent critique (focuses on deltas).

Cons:

• Requires building summarizer logic (extra complexity).
• Risk of missing subtle issues if summaries omit details.

---

3. Async Critique (Non-Blocking)

• Hooks enqueue changes (write to local file or queue).
• Ollama runs separately (background process).
• Feedback delivered later (e.g., via CLI command git critique).

Pros:

• Doesn’t block commits/pushes.
• Handles large files better.
• Flexible scheduling.

Cons:

• Delayed feedback (not immediate).
• Requires extra tooling to check results.

---

4. Hybrid Approach (Delta + Guidelines + Prompt)

• Hooks send:
  • Delta only (diffs).
  • Guidelines doc (static).
  • System prompt (instructions for critique).
• Ollama critiques only the changes, not entire repo.
• If diff > context window:
  • Hook warns user: “Your change footprint is too large, split commits.”

Pros:

• Keeps payload small.
• Immediate, actionable feedback.
• Enforces clean commit practices.

Cons:

• Still blocks commit/push.
• Requires discipline in commit granularity.

---

⚖️ Tradeoff Analysis

Approach	Accuracy	Speed	Complexity	Context Safety
Direct Hook	High	Slow	Low	Risky
Summarizer	Medium	Fast	High	Safer
Async	High	Fast	Medium	Safe
Hybrid (Delta-only)	High	Medium	Medium	Safe

---

✅ Recommended Approach: Hybrid (Delta-only critique)

This balances accuracy (since diffs are precise), speed (smaller payloads), and context safety (avoids full repo dumps). It also nudges developers toward smaller, cleaner commits, which is a best practice anyway.

---

📝 Example Flow

1. System Prompt (for Ollama)

   You are a code critique tool.
   - Review only the provided code changes (diffs).
   - Apply the coding guidelines doc.
   - Flag obvious bugs, subtle mistakes, naming issues, and clean code violations.
   - If diff size exceeds context window, warn user to split commits.
   - Output structured critique in plain text.
   

2. Pre-Commit Hook (simplified)

   #!/bin/sh
   DIFF=$(git diff --cached)
   curl -X POST http://localhost:11434/api/generate \
     -d "{
       \"model\": \"code-critic\",
       \"prompt\": \"$DIFF\",
       \"system\": \"$(cat guidelines.txt)\"
     }"

3. Terminal Output

   Critique:
   - Variable `tmp` is unclear, consider renaming.
   - Missing null check in function `processData`.
   - Commit footprint is large, consider splitting.
   

---

👉 My suggestion: start with the Hybrid Delta-only approach. It’s practical, enforces good commit hygiene, and avoids the complexity of summarizers or async queues. Later, you can layer in summarization if context limits still bite.

Would you like me to draft a ready-to-use pre-commit and pre-push hook script for this setup, so you can drop them into .git/hooks/ and test right away?

solutions2.md

You’re right — what I described earlier was closer to a “developer side project” setup. If you want something that feels enterprise‑grade, like CodeRabbit or SonarQube‑style pipelines, the design needs to be more robust, modular, and scalable. Let’s walk through how a serious solution would be architected.

---

🏗️ Enterprise Architecture for Git Hook–Driven Code Critique

1. Separation of Concerns

• Hooks as lightweight triggers:
  Git hooks should only collect metadata (diffs, commit info, repo context) and enqueue them. They shouldn’t do heavy lifting.
• Local Agent/Daemon:
  A background service (like a local “code critique agent”) receives payloads from hooks and handles communication with Ollama or any LLM.
• Critique Engine:
  The agent applies preprocessing (diff parsing, guideline injection, context window management) before sending to Ollama.

---

2. Context Management Layer

Enterprise systems don’t just dump files into the model. They:

• Delta Extraction: Only diffs, not entire files.
• Guideline Segmentation: Guidelines are chunked and indexed; only relevant rules are injected.
• Adaptive Windowing: If payload > context window:
  • Prioritize diffs + critical guidelines.
  • Summarize unchanged context.
  • Warn user about footprint size.

This is how tools like CodeRabbit avoid blowing up context limits.

---

3. Feedback Delivery

• Immediate CLI feedback (blocking commit/push if severity ≥ threshold).
• Async reports (stored in .codereview/last_report.json).
• Severity levels:
  • 🚨 Blocker (security, compilation errors).
  • ⚠️ Warning (style, naming).
  • ℹ️ Nitpick (minor clean code issues).

---

4. Scalability & Governance

• Centralized guideline repo: Hooks pull coding standards from a shared source (e.g., guidelines.yaml).
• Configurable policies: Teams can decide whether critiques block commits or just warn.
• Audit trail: Reports can be logged for compliance.

---

⚖️ Tradeoffs

Approach	Pros	Cons
Hook-only (rookie)	Simple, fast to set up	Blocks workflow, context overflow, no governance
Enterprise (agent + context mgmt)	Scalable, context-safe, configurable, audit-ready	More infra, requires daemon/service
Cloud-based (like SonarQube)	Centralized, team-wide visibility	Needs server infra, less local autonomy

---

✅ Recommended: Local Agent + Context Management

This mirrors how CodeRabbit or enterprise linters work:

• Hooks stay lean (just enqueue).
• A local agent handles context slicing, guideline injection, and critique.
• Feedback is structured, severity-tagged, and logged.

---

📝 Example Flow (Enterprise Style)

1. Pre-Commit Hook

   #!/bin/sh
   DIFF=$(git diff --cached)
   codereview-agent enqueue --diff "$DIFF" --guidelines ./guidelines.yaml

2. Agent (running locally)

   • Splits payload into chunks.
   • Injects system prompt:

     You are an enterprise code critique tool.
     - Review diffs only.
     - Apply relevant coding guidelines.
     - Classify findings: Blocker, Warning, Nitpick.
     - If payload exceeds context, summarize and warn.
     

   • Calls Ollama with structured request.

3. Terminal Output

   [BLOCKER] Missing null check in processData()
   [WARNING] Variable name 'tmp' unclear
   [NITPICK] Extra whitespace in utils.js
   Context exceeded: recommend splitting commit footprint
   

---

🚀 Why This Wins

• Advantages: Context safety, scalability, governance, structured feedback.
• Fewer Issues: Hooks don’t slow down devs, critiques are consistent, large diffs handled gracefully.
• Future-proof: Can plug into CI/CD, dashboards, or even Slack notifications.

---

👉 If you want, I can draft a reference implementation for the agent (Node.js or Python) that handles context slicing and guideline injection, so your hooks remain featherweight but the critique feels enterprise‑grade. Would you like me to sketch that out?

solutions3.md

Alright, let’s think like a principal engineer designing this as an enterprise‑grade, offline‑capable code review system. The key is to balance local enforcement, organizational context, and LLM integration without bloating token usage or slowing down developer workflows.

---

🔑 Design Guidelines

1. Hook Integration

   • Use Git pre‑commit and pre‑push hooks to trigger the review pipeline.
   • Hooks should call a local HTTP endpoint (e.g., localhost:11434) where Ollama or another LLM server is running.

2. Context Management

   • Repo‑specific guidelines: stored locally in .codereview/config.yml or .codereview/standards.md.
   • Org‑wide guidelines: fetched once from a URL (e.g., wiki export) and cached locally to avoid repeated token usage.
   • Merge both contexts before sending to the LLM, but chunk intelligently to stay within token limits.

3. Token Efficiency

   • Pre‑process diffs: only send changed lines + surrounding context.
   • Summarize org guidelines into embedding vectors or shortened rules stored locally.
   • Use prompt templates that reference guidelines by ID instead of pasting full text.

4. Offline Mode

   • If no internet: rely on cached org guidelines + local repo rules.
   • Hooks should gracefully degrade (e.g., skip org wiki fetch if offline).

5. Output

   • Return structured JSON from LLM (e.g., { "issues": [...], "suggestions": [...] }).
   • Format into readable CLI output with constructive critique (like a senior engineer’s review).

---

⚙️ Example Workflow

1. Developer runs git commit.
2. Pre‑commit hook:
   • Collects staged diff (git diff --cached).
   • Loads repo guidelines + cached org guidelines.
   • Sends payload to localhost:11434 with:

     {
       "diff": "...",
       "repo_guidelines": "...",
       "org_guidelines": "...",
       "mode": "precommit"
     }

3. Ollama responds with structured critique.
4. Hook formats response into CLI output:

   🔍 Code Review Feedback:
   - [STYLE] Variable naming inconsistent with repo guidelines.
   - [SECURITY] Possible SQL injection risk in query builder.
   - [BEST PRACTICE] Consider using async/await instead of callbacks.
   

---

🛠️ Example Hook Implementation

.git/hooks/pre-commit

#!/bin/bash
# Pre-commit hook for local LLM code review

DIFF=$(git diff --cached)
REPO_GUIDELINES=$(cat .codereview/repo.md 2>/dev/null)
ORG_GUIDELINES=$(cat ~/.codereview/org.md 2>/dev/null)

PAYLOAD=$(jq -n \
  --arg diff "$DIFF" \
  --arg repo "$REPO_GUIDELINES" \
  --arg org "$ORG_GUIDELINES" \
  '{diff:$diff, repo_guidelines:$repo, org_guidelines:$org, mode:"precommit"}')

RESPONSE=$(curl -s -X POST http://localhost:11434/api/review \
  -H "Content-Type: application/json" \
  -d "$PAYLOAD")

echo "🔍 Code Review Feedback:"
echo "$RESPONSE" | jq -r '.issues[] | "- " + .'

---

📂 Suggested Directory Layout

.codereview/
  repo.md          # Repo-specific standards
~/.codereview/
  org.md           # Cached org-wide standards (synced periodically)

---

🧩 Enterprise Enhancements

• Caching Layer: Sync org wiki nightly → store in ~/.codereview/org.md.
• Embedding Index: Pre‑compute embeddings of guidelines → match against diff context before sending to LLM.
• Configurable Severity: Allow teams to mark rules as error, warning, or info.
• Extensible Output: JSON output can be piped into CI/CD dashboards.

---

This design ensures:

• Local, offline resilience (no dependency on external APIs).
• Token‑efficient prompts (diff + summarized guidelines).
• Readable, constructive feedback (like a senior engineer’s review).
• Enterprise scalability (org + repo context separation, caching, embeddings).

---

Would you like me to extend this into a full reference implementation (Python/Node service that wraps Ollama with guideline caching + structured JSON output), or keep it at the hook‑level design?