chore: add tests and claude code config missed from PR #29 - #31
Merged
Merged
Conversation
Add bats tests for recursive clone (--recursive, --meta-depth) and plugin install isolation fixes. Include claude code project config (commands, rules, skills) and gitKB settings. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
WalkthroughAdds a set of GitKB documentation and skill definitions, configuration and ignore updates, a SessionStart hook, and expanded tests for recursive cloning and plugin discovery isolation. Changes are primarily new docs, config entries, and test additions; no public API code modifications. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Poem
🚥 Pre-merge checks | ✅ 3 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches
🧪 Generate unit tests (beta)
Comment |
There was a problem hiding this comment.
Actionable comments posted: 9
🤖 Fix all issues with AI agents
In @.claude/commands/kb-board.md:
- Around line 1-44: The file .claude/commands/kb-board.md is missing a top-level
H1 which triggers markdownlint rule MD041; add a single top-level heading line
(e.g., "# GitKB Kanban Board" or similar descriptive title) immediately after
the YAML frontmatter so the first non-frontmatter line is a top-level heading,
preserving the existing content and frontmatter.
In @.claude/commands/kb-commit.md:
- Around line 1-47: The file fails markdownlint rule MD041 because it lacks a
top-level H1 heading after the YAML frontmatter; open
.claude/commands/kb-commit.md, locate the YAML frontmatter block and insert a
single top-level heading (e.g., "# Commit workspace changes" or a suitable
title) immediately after the closing --- so the first non-frontmatter line is an
H1, then save and re-run markdownlint to verify MD041 is resolved.
In @.claude/commands/kb-context.md:
- Around line 1-71: The file fails MD041 because the first non-frontmatter line
is not a top-level heading; after the YAML frontmatter (the leading --- block)
add a single H1 line (e.g., "# Load and validate project context, bootstrapping
if needed") as the first markdown heading so the document begins with a
top-level heading and satisfies the lint rule mentioned in the comment.
In @.claude/commands/kb-status.md:
- Around line 6-10: Add a top-level heading immediately after the YAML
frontmatter in the kb-status markdown (e.g., add a heading like "# KB Status" or
"# Workspace status") so the document has a visible H1 and avoids the MD041
markdownlint warning; ensure the heading appears before the paragraph that
begins "Show the current workspace status..." and keep the existing frontmatter
and content intact.
In @.claude/commands/kb-tasks.md:
- Around line 8-14: Add a top-level heading immediately after the YAML
frontmatter in the .claude/commands/kb-tasks.md file (e.g., "Knowledge Base
Tasks" or similar) so the file begins with a H1 following the frontmatter; this
resolves MD041 and improves readability by ensuring there's a clear document
title before the section that starts "List tasks from the knowledge base with
rich detail."
In @.claude/rules/knowledge-management.md:
- Around line 13-20: Update the fenced example in the knowledge-management rules
so it uses a language tag and includes the required blank line between the
commit title and the body: change the triple-backtick fence to ```text and
ensure there's an empty line after "fix: resolve timeout issue" before
"Implements [[tasks/gitkb-33]]" in the fenced example inside
.claude/rules/knowledge-management.md so the example satisfies MD031/MD040.
In @.claude/skills/before-refactor/SKILL.md:
- Around line 25-33: The fenced code blocks in SKILL.md (e.g., the examples
containing "kb_symbols with search: \"<symbol-name>\"" and "kb_callers with
symbol: \"<full-symbol-id>\"") are missing blank lines and language identifiers;
update every fenced block in this file to include a blank line before and after
the triple-backtick fences and add a language tag (for example ```text) to the
opening fence so they satisfy MD031/MD040 (apply the same pattern to all
occurrences of the kb_symbols and kb_callers example blocks).
In @.claude/skills/explore/SKILL.md:
- Around line 25-39: The fenced code blocks for examples using kb_semantic,
kb_callers, kb_callees, and kb_search need blank lines before and after the
fences and must include a language tag (e.g., ```text) to satisfy markdownlint
rules MD031/MD040/MD029; update each block by inserting a blank line above the
opening triple backticks, add an appropriate language identifier such as "text"
after the opening backticks, and ensure a blank line follows the closing
backticks so all example blocks throughout SKILL.md follow this pattern.
In `@tests/git.bats`:
- Around line 838-859: The create_meta_bare_repo function changes directories
without guaranteeing restoration on error; wrap the workdir operations (the git
clone, cd "$work_dir/checkout", git config/checkout/add/commit/push and cleanup)
in a subshell so directory changes are isolated and failures won't affect the
caller; ensure you still create work_dir before the subshell and remove it (rm
-rf "$work_dir") either inside the subshell or via a trap outside, and reference
the existing symbols create_meta_bare_repo, work_dir, "$work_dir/checkout", and
TEST_DIR when locating where to apply the subshell refactor.
Comment on lines
+1
to
+44
| --- | ||
| allowed-tools: | ||
| - mcp__gitkb__kb_list | ||
| - mcp__gitkb__kb_show | ||
| - mcp__gitkb__kb_graph | ||
| - Bash(git kb:*) | ||
| description: Show GitKB kanban board with task status columns | ||
| --- | ||
|
|
||
| Display the kanban board and provide actionable context about the current workstream. | ||
|
|
||
| ## Steps | ||
|
|
||
| ### 1. Show the Board | ||
|
|
||
| ```bash | ||
| git kb board --all | ||
| ``` | ||
|
|
||
| ### 2. Analyze Blocked Tasks | ||
|
|
||
| If any tasks are in the BLOCKED column (or have `blockedBy` relationships): | ||
| - Use `kb_show` to load each blocked task | ||
| - Identify what's blocking them | ||
| - Summarize: "X is blocked by Y because Z" | ||
|
|
||
| ### 3. Suggest Next Task | ||
|
|
||
| Look at ACTIVE and DRAFT tasks. Suggest what to work on next based on: | ||
| - **Priority**: high > medium > low | ||
| - **Dependencies**: unblocked tasks first | ||
| - **Momentum**: tasks related to recently completed work | ||
|
|
||
| ### 4. Flag Staleness | ||
|
|
||
| If any task has been ACTIVE with no progress log entries in the last 7 days, flag it: | ||
| - "task-slug has been active since [date] with no progress updates in 7+ days — is it still being worked on?" | ||
|
|
||
| ### 5. Present Summary | ||
|
|
||
| Show the board output, then add: | ||
| - Count of tasks by status | ||
| - Any blocked items with reasons | ||
| - Suggested next task with rationale |
There was a problem hiding this comment.
Add a top-level H1 to satisfy MD041.
markdownlint reports “first line in a file should be a top-level heading”; add an # heading after the frontmatter.
✅ Suggested fix
---
allowed-tools:
- mcp__gitkb__kb_list
- mcp__gitkb__kb_show
- mcp__gitkb__kb_graph
- Bash(git kb:*)
description: Show GitKB kanban board with task status columns
---
+# KB Board
+
Display the kanban board and provide actionable context about the current workstream.📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| --- | |
| allowed-tools: | |
| - mcp__gitkb__kb_list | |
| - mcp__gitkb__kb_show | |
| - mcp__gitkb__kb_graph | |
| - Bash(git kb:*) | |
| description: Show GitKB kanban board with task status columns | |
| --- | |
| Display the kanban board and provide actionable context about the current workstream. | |
| ## Steps | |
| ### 1. Show the Board | |
| ```bash | |
| git kb board --all | |
| ``` | |
| ### 2. Analyze Blocked Tasks | |
| If any tasks are in the BLOCKED column (or have `blockedBy` relationships): | |
| - Use `kb_show` to load each blocked task | |
| - Identify what's blocking them | |
| - Summarize: "X is blocked by Y because Z" | |
| ### 3. Suggest Next Task | |
| Look at ACTIVE and DRAFT tasks. Suggest what to work on next based on: | |
| - **Priority**: high > medium > low | |
| - **Dependencies**: unblocked tasks first | |
| - **Momentum**: tasks related to recently completed work | |
| ### 4. Flag Staleness | |
| If any task has been ACTIVE with no progress log entries in the last 7 days, flag it: | |
| - "task-slug has been active since [date] with no progress updates in 7+ days — is it still being worked on?" | |
| ### 5. Present Summary | |
| Show the board output, then add: | |
| - Count of tasks by status | |
| - Any blocked items with reasons | |
| - Suggested next task with rationale | |
| --- | |
| allowed-tools: | |
| - mcp__gitkb__kb_list | |
| - mcp__gitkb__kb_show | |
| - mcp__gitkb__kb_graph | |
| - Bash(git kb:*) | |
| description: Show GitKB kanban board with task status columns | |
| --- | |
| # KB Board | |
| Display the kanban board and provide actionable context about the current workstream. | |
| ## Steps | |
| ### 1. Show the Board | |
🧰 Tools
🪛 markdownlint-cli2 (0.20.0)
[warning] 10-10: First line in a file should be a top-level heading
(MD041, first-line-heading, first-line-h1)
🤖 Prompt for AI Agents
In @.claude/commands/kb-board.md around lines 1 - 44, The file
.claude/commands/kb-board.md is missing a top-level H1 which triggers
markdownlint rule MD041; add a single top-level heading line (e.g., "# GitKB
Kanban Board" or similar descriptive title) immediately after the YAML
frontmatter so the first non-frontmatter line is a top-level heading, preserving
the existing content and frontmatter.
Comment on lines
+1
to
+47
| --- | ||
| allowed-tools: | ||
| - mcp__gitkb__kb_status | ||
| - mcp__gitkb__kb_diff | ||
| - mcp__gitkb__kb_commit | ||
| - mcp__gitkb__kb_show | ||
| description: Commit workspace changes to the knowledge base with validation | ||
| --- | ||
|
|
||
| Review, validate, and commit pending workspace changes. | ||
|
|
||
| ## Steps | ||
|
|
||
| ### 1. Review Changes | ||
|
|
||
| Use `kb_status` to see what will be committed, then `kb_diff` to review actual changes. | ||
|
|
||
| ### 2. Validate Before Committing | ||
|
|
||
| Check for common issues in the diff: | ||
|
|
||
| **Status change without body update (AGENTS.md rule #8):** | ||
| If a document's `status` field changed to `completed`/`done`/`resolved` but the body has no corresponding updates (no completion evidence, no checked acceptance criteria), **warn the user**: | ||
| > "This changes status to completed but the document body doesn't show completion evidence. Consider adding a Completion Evidence section or checking off acceptance criteria before committing." | ||
|
|
||
| **Graph-derived fields being committed:** | ||
| If the diff shows changes to fields that are graph-derived (`blocks`, `children`, `references`), warn: | ||
| > "The field `blocks` is graph-derived — it's computed from other documents' `blocked_by` fields. Committing it may cause unexpected behavior. Consider removing it from the frontmatter." | ||
|
|
||
| **Empty or skeleton documents:** | ||
| If a new document has only frontmatter and no body content, warn: | ||
| > "This document has no body content. Consider adding at least an Overview section before committing." | ||
|
|
||
| ### 3. Generate Commit Message | ||
|
|
||
| Analyze the changes and draft a concise commit message: | ||
| - Summarize what changed (created, modified, status transitions) | ||
| - Reference document slugs | ||
| - Keep it under 72 characters for the first line | ||
|
|
||
| ### 4. Commit | ||
|
|
||
| Use `kb_commit` with the generated message and `author: "Claude <claude@anthropic.com>"`. | ||
|
|
||
| ### 5. Confirm | ||
|
|
||
| Show what was committed and the resulting state. |
There was a problem hiding this comment.
Add a top-level H1 to satisfy MD041.
markdownlint reports “first line in a file should be a top-level heading”; add an # heading after the frontmatter.
✅ Suggested fix
---
allowed-tools:
- mcp__gitkb__kb_status
- mcp__gitkb__kb_diff
- mcp__gitkb__kb_commit
- mcp__gitkb__kb_show
description: Commit workspace changes to the knowledge base with validation
---
+# KB Commit
+
Review, validate, and commit pending workspace changes.📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| --- | |
| allowed-tools: | |
| - mcp__gitkb__kb_status | |
| - mcp__gitkb__kb_diff | |
| - mcp__gitkb__kb_commit | |
| - mcp__gitkb__kb_show | |
| description: Commit workspace changes to the knowledge base with validation | |
| --- | |
| Review, validate, and commit pending workspace changes. | |
| ## Steps | |
| ### 1. Review Changes | |
| Use `kb_status` to see what will be committed, then `kb_diff` to review actual changes. | |
| ### 2. Validate Before Committing | |
| Check for common issues in the diff: | |
| **Status change without body update (AGENTS.md rule #8):** | |
| If a document's `status` field changed to `completed`/`done`/`resolved` but the body has no corresponding updates (no completion evidence, no checked acceptance criteria), **warn the user**: | |
| > "This changes status to completed but the document body doesn't show completion evidence. Consider adding a Completion Evidence section or checking off acceptance criteria before committing." | |
| **Graph-derived fields being committed:** | |
| If the diff shows changes to fields that are graph-derived (`blocks`, `children`, `references`), warn: | |
| > "The field `blocks` is graph-derived — it's computed from other documents' `blocked_by` fields. Committing it may cause unexpected behavior. Consider removing it from the frontmatter." | |
| **Empty or skeleton documents:** | |
| If a new document has only frontmatter and no body content, warn: | |
| > "This document has no body content. Consider adding at least an Overview section before committing." | |
| ### 3. Generate Commit Message | |
| Analyze the changes and draft a concise commit message: | |
| - Summarize what changed (created, modified, status transitions) | |
| - Reference document slugs | |
| - Keep it under 72 characters for the first line | |
| ### 4. Commit | |
| Use `kb_commit` with the generated message and `author: "Claude <claude@anthropic.com>"`. | |
| ### 5. Confirm | |
| Show what was committed and the resulting state. | |
| --- | |
| allowed-tools: | |
| - mcp__gitkb__kb_status | |
| - mcp__gitkb__kb_diff | |
| - mcp__gitkb__kb_commit | |
| - mcp__gitkb__kb_show | |
| description: Commit workspace changes to the knowledge base with validation | |
| --- | |
| # KB Commit | |
| Review, validate, and commit pending workspace changes. | |
| ## Steps | |
| ### 1. Review Changes | |
| Use `kb_status` to see what will be committed, then `kb_diff` to review actual changes. | |
| ### 2. Validate Before Committing | |
| Check for common issues in the diff: | |
| **Status change without body update (AGENTS.md rule `#8`):** | |
| If a document's `status` field changed to `completed`/`done`/`resolved` but the body has no corresponding updates (no completion evidence, no checked acceptance criteria), **warn the user**: | |
| > "This changes status to completed but the document body doesn't show completion evidence. Consider adding a Completion Evidence section or checking off acceptance criteria before committing." | |
| **Graph-derived fields being committed:** | |
| If the diff shows changes to fields that are graph-derived (`blocks`, `children`, `references`), warn: | |
| > "The field `blocks` is graph-derived — it's computed from other documents' `blocked_by` fields. Committing it may cause unexpected behavior. Consider removing it from the frontmatter." | |
| **Empty or skeleton documents:** | |
| If a new document has only frontmatter and no body content, warn: | |
| > "This document has no body content. Consider adding at least an Overview section before committing." | |
| ### 3. Generate Commit Message | |
| Analyze the changes and draft a concise commit message: | |
| - Summarize what changed (created, modified, status transitions) | |
| - Reference document slugs | |
| - Keep it under 72 characters for the first line | |
| ### 4. Commit | |
| Use `kb_commit` with the generated message and `author: "Claude <claude@anthropic.com>"`. | |
| ### 5. Confirm | |
| Show what was committed and the resulting state. |
🧰 Tools
🪛 markdownlint-cli2 (0.20.0)
[warning] 10-10: First line in a file should be a top-level heading
(MD041, first-line-heading, first-line-h1)
🤖 Prompt for AI Agents
In @.claude/commands/kb-commit.md around lines 1 - 47, The file fails
markdownlint rule MD041 because it lacks a top-level H1 heading after the YAML
frontmatter; open .claude/commands/kb-commit.md, locate the YAML frontmatter
block and insert a single top-level heading (e.g., "# Commit workspace changes"
or a suitable title) immediately after the closing --- so the first
non-frontmatter line is an H1, then save and re-run markdownlint to verify MD041
is resolved.
Comment on lines
+1
to
+71
| --- | ||
| allowed-tools: | ||
| - mcp__gitkb__kb_context | ||
| - mcp__gitkb__kb_status | ||
| - mcp__gitkb__kb_list | ||
| - mcp__gitkb__kb_show | ||
| - mcp__gitkb__kb_checkout | ||
| - mcp__gitkb__kb_create | ||
| - mcp__gitkb__kb_commit | ||
| - Bash(git kb:*) | ||
| description: Load and validate project context, bootstrapping if needed | ||
| --- | ||
|
|
||
| Load project context following the AGENTS.md PATH A/B/C flow. | ||
|
|
||
| ## Steps | ||
|
|
||
| ### 1. Detect KB State | ||
|
|
||
| ```bash | ||
| git kb list --path context/ | ||
| ``` | ||
|
|
||
| ### 2. Follow the Right Path | ||
|
|
||
| **If no context documents exist (PATH A — First-Time Setup):** | ||
|
|
||
| The KB is fresh. Help the user establish context: | ||
|
|
||
| 1. Ask about the project: what it does, who it's for, tech stack, current state | ||
| 2. Create the 7 context documents: | ||
| - `context/immutable/project-brief` (type: brief) | ||
| - `context/immutable/patterns` (type: patterns) | ||
| - `context/immutable/architecture` (type: architecture) | ||
| - `context/extensible/product` (type: context) | ||
| - `context/extensible/tech` (type: context) | ||
| - `context/overridable/active` (type: context) | ||
| - `context/overridable/progress` (type: context) | ||
| 3. Populate each with gathered information | ||
| 4. Commit: `"Initial context setup"` | ||
|
|
||
| **If context documents exist (PATH B — Load and Validate):** | ||
|
|
||
| 1. Use `kb_context` to load the full context bundle | ||
| 2. Validate completeness — check all 7 docs exist: | ||
| - `context/immutable/project-brief` | ||
| - `context/immutable/patterns` | ||
| - `context/immutable/architecture` | ||
| - `context/extensible/product` | ||
| - `context/extensible/tech` | ||
| - `context/overridable/active` | ||
| - `context/overridable/progress` | ||
| 3. If any are missing, flag them and offer to create them | ||
| 4. **Detect staleness** in overridable docs: | ||
| - Check if `context/overridable/active` references tasks that are now completed | ||
| - Check if `context/overridable/progress` shows phases as "in progress" when all their tasks are done | ||
| - If stale, warn: "Active context appears stale — it references [X] as in-progress but that work is complete. Consider running `/kb-handoff` to update it." | ||
|
|
||
| **If context was already loaded this session (PATH C — Quick Resume):** | ||
|
|
||
| 1. Check `kb_status` for pending changes | ||
| 2. Quick-refresh `context/overridable/active` | ||
| 3. Resume work | ||
|
|
||
| ### 3. Present Context Summary | ||
|
|
||
| After loading, present a concise summary: | ||
| - Current focus (from active context) | ||
| - Task board summary (counts by status) | ||
| - Any blockers or stale items | ||
| - Confidence level: 100% if all context loaded and validated |
There was a problem hiding this comment.
Add a top-level H1 to satisfy MD041.
markdownlint reports “first line in a file should be a top-level heading”; add an # heading after the frontmatter.
✅ Suggested fix
---
allowed-tools:
- mcp__gitkb__kb_context
- mcp__gitkb__kb_status
- mcp__gitkb__kb_list
- mcp__gitkb__kb_show
- mcp__gitkb__kb_checkout
- mcp__gitkb__kb_create
- mcp__gitkb__kb_commit
- Bash(git kb:*)
description: Load and validate project context, bootstrapping if needed
---
+# KB Context
+
Load project context following the AGENTS.md PATH A/B/C flow.📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| --- | |
| allowed-tools: | |
| - mcp__gitkb__kb_context | |
| - mcp__gitkb__kb_status | |
| - mcp__gitkb__kb_list | |
| - mcp__gitkb__kb_show | |
| - mcp__gitkb__kb_checkout | |
| - mcp__gitkb__kb_create | |
| - mcp__gitkb__kb_commit | |
| - Bash(git kb:*) | |
| description: Load and validate project context, bootstrapping if needed | |
| --- | |
| Load project context following the AGENTS.md PATH A/B/C flow. | |
| ## Steps | |
| ### 1. Detect KB State | |
| ```bash | |
| git kb list --path context/ | |
| ``` | |
| ### 2. Follow the Right Path | |
| **If no context documents exist (PATH A — First-Time Setup):** | |
| The KB is fresh. Help the user establish context: | |
| 1. Ask about the project: what it does, who it's for, tech stack, current state | |
| 2. Create the 7 context documents: | |
| - `context/immutable/project-brief` (type: brief) | |
| - `context/immutable/patterns` (type: patterns) | |
| - `context/immutable/architecture` (type: architecture) | |
| - `context/extensible/product` (type: context) | |
| - `context/extensible/tech` (type: context) | |
| - `context/overridable/active` (type: context) | |
| - `context/overridable/progress` (type: context) | |
| 3. Populate each with gathered information | |
| 4. Commit: `"Initial context setup"` | |
| **If context documents exist (PATH B — Load and Validate):** | |
| 1. Use `kb_context` to load the full context bundle | |
| 2. Validate completeness — check all 7 docs exist: | |
| - `context/immutable/project-brief` | |
| - `context/immutable/patterns` | |
| - `context/immutable/architecture` | |
| - `context/extensible/product` | |
| - `context/extensible/tech` | |
| - `context/overridable/active` | |
| - `context/overridable/progress` | |
| 3. If any are missing, flag them and offer to create them | |
| 4. **Detect staleness** in overridable docs: | |
| - Check if `context/overridable/active` references tasks that are now completed | |
| - Check if `context/overridable/progress` shows phases as "in progress" when all their tasks are done | |
| - If stale, warn: "Active context appears stale — it references [X] as in-progress but that work is complete. Consider running `/kb-handoff` to update it." | |
| **If context was already loaded this session (PATH C — Quick Resume):** | |
| 1. Check `kb_status` for pending changes | |
| 2. Quick-refresh `context/overridable/active` | |
| 3. Resume work | |
| ### 3. Present Context Summary | |
| After loading, present a concise summary: | |
| - Current focus (from active context) | |
| - Task board summary (counts by status) | |
| - Any blockers or stale items | |
| - Confidence level: 100% if all context loaded and validated | |
| --- | |
| allowed-tools: | |
| - mcp__gitkb__kb_context | |
| - mcp__gitkb__kb_status | |
| - mcp__gitkb__kb_list | |
| - mcp__gitkb__kb_show | |
| - mcp__gitkb__kb_checkout | |
| - mcp__gitkb__kb_create | |
| - mcp__gitkb__kb_commit | |
| - Bash(git kb:*) | |
| description: Load and validate project context, bootstrapping if needed | |
| --- | |
| # KB Context | |
| Load project context following the AGENTS.md PATH A/B/C flow. | |
| ## Steps | |
| ### 1. Detect KB State | |
🧰 Tools
🪛 markdownlint-cli2 (0.20.0)
[warning] 14-14: First line in a file should be a top-level heading
(MD041, first-line-heading, first-line-h1)
🤖 Prompt for AI Agents
In @.claude/commands/kb-context.md around lines 1 - 71, The file fails MD041
because the first non-frontmatter line is not a top-level heading; after the
YAML frontmatter (the leading --- block) add a single H1 line (e.g., "# Load and
validate project context, bootstrapping if needed") as the first markdown
heading so the document begins with a top-level heading and satisfies the lint
rule mentioned in the comment.
Comment on lines
+6
to
+10
| --- | ||
|
|
||
| Show the current workspace status including any uncommitted changes. | ||
|
|
||
| 1. Use `kb_status` to see created/modified/deleted documents |
There was a problem hiding this comment.
Add a top‑level heading after frontmatter.
This avoids the MD041 markdownlint warning and improves scanability.
📝 Suggested fix
---
+# KB Status
+
Show the current workspace status including any uncommitted changes.📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| --- | |
| Show the current workspace status including any uncommitted changes. | |
| 1. Use `kb_status` to see created/modified/deleted documents | |
| --- | |
| # KB Status | |
| Show the current workspace status including any uncommitted changes. | |
| 1. Use `kb_status` to see created/modified/deleted documents |
🧰 Tools
🪛 markdownlint-cli2 (0.20.0)
[warning] 8-8: First line in a file should be a top-level heading
(MD041, first-line-heading, first-line-h1)
🤖 Prompt for AI Agents
In @.claude/commands/kb-status.md around lines 6 - 10, Add a top-level heading
immediately after the YAML frontmatter in the kb-status markdown (e.g., add a
heading like "# KB Status" or "# Workspace status") so the document has a
visible H1 and avoids the MD041 markdownlint warning; ensure the heading appears
before the paragraph that begins "Show the current workspace status..." and keep
the existing frontmatter and content intact.
Comment on lines
+8
to
+14
| --- | ||
|
|
||
| List tasks from the knowledge base with rich detail. | ||
|
|
||
| **Input:** `$ARGUMENTS` | ||
|
|
||
| Optional filter: `active`, `draft`, `completed`, `blocked`, `all`, or a search term. |
There was a problem hiding this comment.
Add a top‑level heading after frontmatter.
Prevents MD041 and improves readability.
📝 Suggested fix
---
+# KB Tasks
+
List tasks from the knowledge base with rich detail.📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| --- | |
| List tasks from the knowledge base with rich detail. | |
| **Input:** `$ARGUMENTS` | |
| Optional filter: `active`, `draft`, `completed`, `blocked`, `all`, or a search term. | |
| --- | |
| # KB Tasks | |
| List tasks from the knowledge base with rich detail. | |
| **Input:** `$ARGUMENTS` | |
| Optional filter: `active`, `draft`, `completed`, `blocked`, `all`, or a search term. |
🧰 Tools
🪛 markdownlint-cli2 (0.20.0)
[warning] 10-10: First line in a file should be a top-level heading
(MD041, first-line-heading, first-line-h1)
🤖 Prompt for AI Agents
In @.claude/commands/kb-tasks.md around lines 8 - 14, Add a top-level heading
immediately after the YAML frontmatter in the .claude/commands/kb-tasks.md file
(e.g., "Knowledge Base Tasks" or similar) so the file begins with a H1 following
the frontmatter; this resolves MD041 and improves readability by ensuring
there's a clear document title before the section that starts "List tasks from
the knowledge base with rich detail."
Comment on lines
+13
to
+20
| - Add progress entries to the active task document as you make progress | ||
| - Include `[[tasks/...]]` wikilinks in git commit messages for related tasks: | ||
| ``` | ||
| fix: resolve timeout issue | ||
|
|
||
| Implements [[tasks/gitkb-33]] | ||
| ``` | ||
| - When you discover bugs or issues, create incident documents — don't just fix and forget |
There was a problem hiding this comment.
Add blank lines + language to the fenced example.
This addresses MD031/MD040 warnings.
📝 Suggested fix
- Include `[[tasks/...]]` wikilinks in git commit messages for related tasks:
- ```
- fix: resolve timeout issue
-
- Implements [[tasks/gitkb-33]]
- ```
+
+ ```text
+ fix: resolve timeout issue
+
+ Implements [[tasks/gitkb-33]]
+ ```🧰 Tools
🪛 markdownlint-cli2 (0.20.0)
[warning] 15-15: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
[warning] 15-15: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
[warning] 19-19: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
🤖 Prompt for AI Agents
In @.claude/rules/knowledge-management.md around lines 13 - 20, Update the
fenced example in the knowledge-management rules so it uses a language tag and
includes the required blank line between the commit title and the body: change
the triple-backtick fence to ```text and ensure there's an empty line after
"fix: resolve timeout issue" before "Implements [[tasks/gitkb-33]]" in the
fenced example inside .claude/rules/knowledge-management.md so the example
satisfies MD031/MD040.
Comment on lines
+25
to
+33
| 1. **Find the symbol and its location:** | ||
| ``` | ||
| kb_symbols with search: "<symbol-name>" | ||
| ``` | ||
|
|
||
| 2. **Get all callers (who would break if you change the signature):** | ||
| ``` | ||
| kb_callers with symbol: "<full-symbol-id>" | ||
| ``` |
There was a problem hiding this comment.
Add blank lines and language identifiers to fenced blocks.
Addresses MD031/MD040 warnings; please apply the same pattern to all fenced blocks in this file.
📝 Example fix (apply consistently)
1. **Find the symbol and its location:**
- ```
- kb_symbols with search: "<symbol-name>"
- ```
+
+ ```text
+ kb_symbols with search: "<symbol-name>"
+ ```🧰 Tools
🪛 markdownlint-cli2 (0.20.0)
[warning] 26-26: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
[warning] 26-26: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
[warning] 31-31: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
[warning] 31-31: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
🤖 Prompt for AI Agents
In @.claude/skills/before-refactor/SKILL.md around lines 25 - 33, The fenced
code blocks in SKILL.md (e.g., the examples containing "kb_symbols with search:
\"<symbol-name>\"" and "kb_callers with symbol: \"<full-symbol-id>\"") are
missing blank lines and language identifiers; update every fenced block in this
file to include a blank line before and after the triple-backtick fences and add
a language tag (for example ```text) to the opening fence so they satisfy
MD031/MD040 (apply the same pattern to all occurrences of the kb_symbols and
kb_callers example blocks).
Comment on lines
+25
to
+39
| 1. **Run semantic search across code and docs:** | ||
| ``` | ||
| kb_semantic with query: "<user query>", scope: "all" | ||
| ``` | ||
|
|
||
| 2. **For interesting code matches, dig deeper:** | ||
| ``` | ||
| kb_callers with symbol: "<matched-symbol>" | ||
| kb_callees with symbol: "<matched-symbol>" | ||
| ``` | ||
|
|
||
| 3. **Search KB documents for related context:** | ||
| ``` | ||
| kb_search with query: "<keywords>" | ||
| ``` |
There was a problem hiding this comment.
Fix fenced blocks to satisfy markdownlint (blank lines + language tags).
MD031/MD040/MD029 warnings indicate fenced blocks need blank lines and language specifiers. Apply this pattern throughout the file.
📝 Example fix (apply consistently)
1. **Run semantic search across code and docs:**
- ```
- kb_semantic with query: "<user query>", scope: "all"
- ```
+
+ ```text
+ kb_semantic with query: "<user query>", scope: "all"
+ ```📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| 1. **Run semantic search across code and docs:** | |
| ``` | |
| kb_semantic with query: "<user query>", scope: "all" | |
| ``` | |
| 2. **For interesting code matches, dig deeper:** | |
| ``` | |
| kb_callers with symbol: "<matched-symbol>" | |
| kb_callees with symbol: "<matched-symbol>" | |
| ``` | |
| 3. **Search KB documents for related context:** | |
| ``` | |
| kb_search with query: "<keywords>" | |
| ``` | |
| 1. **Run semantic search across code and docs:** |
🧰 Tools
🪛 markdownlint-cli2 (0.20.0)
[warning] 26-26: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
[warning] 26-26: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
[warning] 31-31: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
[warning] 31-31: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
[warning] 37-37: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
[warning] 37-37: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
🤖 Prompt for AI Agents
In @.claude/skills/explore/SKILL.md around lines 25 - 39, The fenced code blocks
for examples using kb_semantic, kb_callers, kb_callees, and kb_search need blank
lines before and after the fences and must include a language tag (e.g.,
```text) to satisfy markdownlint rules MD031/MD040/MD029; update each block by
inserting a blank line above the opening triple backticks, add an appropriate
language identifier such as "text" after the opening backticks, and ensure a
blank line follows the closing backticks so all example blocks throughout
SKILL.md follow this pattern.
Greptile SummaryThis PR adds previously uncommitted bats tests for
Confidence Score: 4/5
|
| Filename | Overview |
|---|---|
| tests/git.bats | Adds create_meta_bare_repo helper and 4 new bats tests for meta git clone --recursive and --meta-depth options. Well-structured tests with proper cleanup. Minor concern: helper uses cd side-effects but restores properly. |
| tests/plugin_install.bats | Improves test isolation by adding META_DATA_DIR override and PATH filtering to exclude meta-* binaries. PATH filtering approach could drop directories containing critical tools (git, python3) if they also contain meta-* binaries. |
| .claude/settings.json | Adds a SessionStart hook to auto-start the GitKB daemon service. Uses fail-safe pattern with ` |
| .claude/skills/gitkb/SKILL.md | Comprehensive GitKB skill document with full MCP tool reference, CLI commands, workflows, and document conventions. |
| .kb/.gitignore | New gitignore for KB directory, excluding runtime/cache directories (backup, cache, store, workspace, worktrees). |
| .kb/config.toml | Expanded KB config with code indexing, embeddings, and auth settings. All values are reasonable defaults. |
Flowchart
flowchart TD
subgraph PR["PR #31 Changes"]
direction TB
subgraph Tests["Test Files"]
GB["tests/git.bats<br/>+146 lines"]
PI["tests/plugin_install.bats<br/>isolation fix"]
end
subgraph Claude["Claude Code Config"]
direction TB
CMD["Commands<br/>kb-board, kb-commit,<br/>kb-context, kb-status, kb-tasks"]
RUL["Rules<br/>code-intelligence,<br/>knowledge-management,<br/>refactoring-safety"]
SKL["Skills<br/>before-refactor, explore,<br/>gitkb, understand"]
SET[".claude/settings.json<br/>+SessionStart hook"]
end
subgraph KB["GitKB Config"]
KBC[".kb/config.toml<br/>embeddings, auth, code index"]
KBG[".kb/.gitignore<br/>runtime dirs excluded"]
end
end
GB -->|"tests"| RC["meta git clone --recursive"]
GB -->|"tests"| MD["--meta-depth limiting"]
PI -->|"isolates"| PD["META_DATA_DIR + PATH filter"]
SET -->|"auto-starts"| KBSVC["git kb service"]
Last reviewed commit: a9d6e49
- Wrap cd in subshell in create_meta_bare_repo so caller's cwd is preserved if a git command fails mid-function - Filter PATH by known .meta/plugins directory pattern instead of scanning for meta-* binaries, which could drop shared dirs like /usr/local/bin Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Fix all issues with AI agents
In `@tests/git.bats`:
- Around line 835-860: The comment for create_meta_bare_repo incorrectly states
it "Returns the file:// URL" but the function never echoes/returns anything;
update the function to actually return the URL or change the header to remove
the return claim. If you choose to return the URL, after creating the bare repo
(using the existing bare_dir variable) echo the file URL (e.g.,
file://$bare_dir) as the function's output; if you prefer to modify the comment,
remove the "Returns the file:// URL" line or reword it to state it only creates
the bare repo and sets up the .meta file. Ensure references to
create_meta_bare_repo and the bare_dir/meta_format variables remain accurate.
Comment on lines
+835
to
+860
| # Helper: create a bare repo containing a .meta config with given projects. | ||
| # Usage: create_meta_bare_repo <bare_dir> <projects_json> | ||
| # Returns the file:// URL suitable for cloning. | ||
| create_meta_bare_repo() { | ||
| local bare_dir="$1" | ||
| local meta_content="$2" | ||
| local meta_format="${3:-.meta}" # default to JSON .meta | ||
|
|
||
| local work_dir="$(mktemp -d)" | ||
| git init --bare --quiet "$bare_dir" | ||
| git -C "$bare_dir" symbolic-ref HEAD refs/heads/main | ||
|
|
||
| git clone --quiet "$bare_dir" "$work_dir/checkout" | ||
| ( | ||
| cd "$work_dir/checkout" | ||
| git config user.email "test@test.com" | ||
| git config user.name "Test" | ||
| git checkout -b main --quiet 2>/dev/null || true | ||
| echo "$meta_content" > "$meta_format" | ||
| git add "$meta_format" | ||
| git commit --quiet -m "Add meta config" | ||
| git push --quiet -u origin main | ||
| ) | ||
|
|
||
| rm -rf "$work_dir" | ||
| } |
There was a problem hiding this comment.
🧹 Nitpick | 🔵 Trivial
Helper comment claims a return value that isn’t provided.
The header says it “Returns the file:// URL,” but the function doesn’t echo/return anything. Please update the comment (or return the URL) to avoid confusion.
♻️ Suggested comment fix
-# Returns the file:// URL suitable for cloning.
+# Creates the bare repo at the given path for cloning.📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| # Helper: create a bare repo containing a .meta config with given projects. | |
| # Usage: create_meta_bare_repo <bare_dir> <projects_json> | |
| # Returns the file:// URL suitable for cloning. | |
| create_meta_bare_repo() { | |
| local bare_dir="$1" | |
| local meta_content="$2" | |
| local meta_format="${3:-.meta}" # default to JSON .meta | |
| local work_dir="$(mktemp -d)" | |
| git init --bare --quiet "$bare_dir" | |
| git -C "$bare_dir" symbolic-ref HEAD refs/heads/main | |
| git clone --quiet "$bare_dir" "$work_dir/checkout" | |
| ( | |
| cd "$work_dir/checkout" | |
| git config user.email "test@test.com" | |
| git config user.name "Test" | |
| git checkout -b main --quiet 2>/dev/null || true | |
| echo "$meta_content" > "$meta_format" | |
| git add "$meta_format" | |
| git commit --quiet -m "Add meta config" | |
| git push --quiet -u origin main | |
| ) | |
| rm -rf "$work_dir" | |
| } | |
| # Helper: create a bare repo containing a .meta config with given projects. | |
| # Usage: create_meta_bare_repo <bare_dir> <projects_json> | |
| # Creates the bare repo at the given path for cloning. | |
| create_meta_bare_repo() { | |
| local bare_dir="$1" | |
| local meta_content="$2" | |
| local meta_format="${3:-.meta}" # default to JSON .meta | |
| local work_dir="$(mktemp -d)" | |
| git init --bare --quiet "$bare_dir" | |
| git -C "$bare_dir" symbolic-ref HEAD refs/heads/main | |
| git clone --quiet "$bare_dir" "$work_dir/checkout" | |
| ( | |
| cd "$work_dir/checkout" | |
| git config user.email "test@test.com" | |
| git config user.name "Test" | |
| git checkout -b main --quiet 2>/dev/null || true | |
| echo "$meta_content" > "$meta_format" | |
| git add "$meta_format" | |
| git commit --quiet -m "Add meta config" | |
| git push --quiet -u origin main | |
| ) | |
| rm -rf "$work_dir" | |
| } |
🤖 Prompt for AI Agents
In `@tests/git.bats` around lines 835 - 860, The comment for create_meta_bare_repo
incorrectly states it "Returns the file:// URL" but the function never
echoes/returns anything; update the function to actually return the URL or
change the header to remove the return claim. If you choose to return the URL,
after creating the bare repo (using the existing bare_dir variable) echo the
file URL (e.g., file://$bare_dir) as the function's output; if you prefer to
modify the comment, remove the "Returns the file:// URL" line or reword it to
state it only creates the bare repo and sets up the .meta file. Ensure
references to create_meta_bare_repo and the bare_dir/meta_format variables
remain accurate.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
meta git clone --recursiveand--meta-depththat were written during fix: use PR workflow for homebrew tap updates #29 but not committedTest plan
🤖 Generated with Claude Code
Summary by CodeRabbit
New Features
Documentation
Configuration
Tests & Chores