githits 0.6.5 → 0.6.7

package/dist/shared/{chunk-mar7rmpc.js → chunk-p09q90sj.js}

@@ -1 +1 @@
-import{clearAutoLoginAuthSessionMetadata,createAuthCommandDependencies,createAuthStatusDependencies,createContainer,loadAutoLoginAuthSessionMetadata,recordAuthFingerprint}from"./chunk-29jz9bxq.js";import"./chunk-vef9cbqz.js";export{recordAuthFingerprint,loadAutoLoginAuthSessionMetadata,createContainer,createAuthStatusDependencies,createAuthCommandDependencies,clearAutoLoginAuthSessionMetadata};
+import{clearAutoLoginAuthSessionMetadata,createAuthCommandDependencies,createAuthStatusDependencies,createContainer,loadAutoLoginAuthSessionMetadata,recordAuthFingerprint}from"./chunk-4cnb4nss.js";import"./chunk-xr5k540v.js";export{recordAuthFingerprint,loadAutoLoginAuthSessionMetadata,createContainer,createAuthStatusDependencies,createAuthCommandDependencies,clearAutoLoginAuthSessionMetadata};

package/dist/shared/{chunk-vef9cbqz.js → chunk-xr5k540v.js}

@@ -1,2 +1,2 @@
-import{createRequire}from"node:module";var __require=createRequire(import.meta.url);var description="The code context layer for AI coding agents";var version="0.6.5";
+import{createRequire}from"node:module";var __require=createRequire(import.meta.url);var description="The code context layer for AI coding agents";var version="0.6.7";
 export{__require,description,version};

package/gemini-extension.json

@@ -1,6 +1,6 @@
 {
   "name": "githits",
-  "version": "0.6.5",
+  "version": "0.6.7",
   "description": "The code context layer for AI coding agents",
   "mcpServers": {
     "githits": {

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "githits",
   "description": "The code context layer for AI coding agents",
-  "version": "0.6.5",
+  "version": "0.6.7",
   "mcpName": "com.githits/githits",
   "type": "module",
   "workspaces": [
@@ -104,12 +104,12 @@
     "zod": "^4.4.3"
   },
   "devDependencies": {
-    "@biomejs/biome": "2.5.2",
+    "@biomejs/biome": "2.5.5",
     "@types/bun": "latest",
     "@types/semver": "^7.7.1",
     "bunup": "^0.16.32",
     "husky": "^9.1.7",
-    "lint-staged": "17.0.8",
-    "typescript": "^6.0.3"
+    "lint-staged": "17.2.0",
+    "typescript": "^7.0.2"
   }
 }

package/plugins/claude/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "githits",
-  "version": "0.6.5",
+  "version": "0.6.7",
   "description": "The code context layer for AI coding agents",
   "author": {
     "name": "GitHits"

package/plugins/claude/skills/onboarding/SKILL.md

@@ -56,15 +56,42 @@ Run detection inline, not in a background terminal. Wait for JSON before continu
 
 Do not offer tools with `unsupported_project_config` for project-level setup.
 
-3. If `installableIds` is non-empty, use structured choices for tool selection. Do not ask the user to type comma-separated tool IDs unless no structured choice UI is available.
+Use `actionableIds` when present. If it is absent because the installed CLI predates guidance-aware detection, use `installableIds` for MCP setup and do not infer guidance-only repair from missing fields.
 
-Present `Configure all detected tools (Recommended)` as the first option, then list individual tools for selective setup. Do not present "configure none" as a normal onboarding choice.
+Before showing the review, classify the detection result:
+
+- If every agent is `not_detected`, explain that no supported coding tool was found and stop before review, installation, or authentication. Tell the user to install or open a supported tool, then rerun detection.
+- In project scope, if no agent is `needs_setup` or `already_configured` and at least one is `unsupported_project_config`, explain that project-level setup is unavailable, offer user-level detection, and stop the project flow before review or authentication.
+- If supported agents are mixed with `unsupported_project_config`, explain the unsupported tools but continue only with supported agents.
+- If no effective actionable IDs remain but at least one supported agent is `already_configured`, continue to the review, skip installation after acknowledgment, and then check authentication.
+
+Follow the CLI JSON `instructions` remediation for these states rather than replacing it with generic authentication guidance.
+
+3. When setup can proceed, show the install review before asking for tool approval or starting browser authentication, including the already-configured supported-tool case.
+
+Tell the user:
+
+- GitHits queries and public package, repository, and documentation targets are sent to GitHits services for processing.
+- Feedback submission is an outbound write that sends feedback data to GitHits services.
+- Installing GitHits does not itself upload the local workspace.
+- After installation, open a new coding-agent session so it loads MCP configuration and any supporting instructions. The terminal and machine do not need to be restarted.
+
+Ask the user to acknowledge this review before continuing.
+If the user does not acknowledge it, stop onboarding without installing or starting authentication.
+
+4. Use `actionableIds` for tools needing MCP setup or requested guidance repair. If `actionableIds` is non-empty, use structured choices for tool selection. Do not ask the user to type comma-separated tool IDs unless no structured choice UI is available.
+
+Present `Configure all actionable tools (Recommended)` as the first option, then list individual actionable tools for selective setup. After configure-all approval, execute `suggestedCommand` exactly so scope and guidance intent are preserved. Do not present "configure none" as a normal onboarding choice.
 
 Ask before writing configuration: `I recommend configuring all detected tools so GitHits works wherever you use an agent. Proceed with all, or choose specific tools?`
 
 Do not run `init -y` or `init --yes` unless the user explicitly asks to configure every detected tool.
 
-4. Install only approved IDs using the selected scope.
+For selective setup, build the matching scoped `--install-agents` command and preserve `--no-guidance` when `guidanceRequested` is `false`. Follow the CLI-emitted verification instruction instead of constructing a separate detect command.
+
+If no effective actionable IDs remain and at least one supported tool is already configured, skip installation and continue to authentication only after the user acknowledges the install review.
+
+5. Install only approved IDs using the selected scope.
 
 Guidance is installed by default. It adds the `githits-mcp` skill and a short instruction pointer for tools with verified guidance paths. Add `--no-guidance` only when the user explicitly asks for plain MCP without supporting instructions.
 
@@ -80,7 +107,11 @@ User-level install:
 npx -y githits@latest init --install-agents <comma-separated-approved-ids> --json
 ```
 
-5. Start GitHits sign-in/signup as part of onboarding. Do not ask whether the user wants to log in; login creates or connects the GitHits account.
+Cursor is configured with the remote MCP at `https://mcp.githits.com`. A legacy local `npx ... githits ... mcp start` Cursor entry should be migrated by the install command.
+
+6. Start GitHits sign-in/signup as part of onboarding. Do not ask whether the user wants to log in; login creates or connects the GitHits account.
+
+Local `githits auth status` and `githits login` apply to CLI/stdio integrations, not Cursor's remote MCP OAuth. If Cursor is the only approved tool, skip local CLI login. For mixed installs, use local login for non-Cursor tools but keep Cursor authentication state separate.
 
 Check whether login can be skipped because auth is already active:
 
@@ -104,7 +135,7 @@ npx -y githits@latest login --no-browser
 
 With `--no-browser`, surface the printed sign-in URL clearly so the user can open it in a browser. If command output is hidden from the user, relay the URL verbatim. Do not ask them to paste secrets or OAuth codes back into chat.
 
-6. Verify with the selected scope.
+7. Verify with the selected scope.
 
 Project-level verification:
 
@@ -120,4 +151,6 @@ npx -y githits@latest auth status
 npx -y githits@latest init --detect-agents --json
 ```
 
-Report configured tools, auth state, failures, and whether the user should open a new Claude Code session so MCP config changes load.
+Report configured tools, auth state, failures, and whether the user should open a new Claude Code session so MCP configuration and any supporting instructions load. The terminal and machine do not need to be restarted.
+
+For Cursor, init detection verifies only the remote URL. It cannot verify Cursor-managed OAuth or tool discovery. If `cursor-agent` is available, run `cursor-agent mcp list` and `cursor-agent mcp list-tools GitHits`; if authentication is required, run `cursor-agent mcp login GitHits`, let the user complete browser OAuth, and rerun the checks. Always require a new Cursor Agent chat after installation and confirm in Cursor's MCP tools UI that GitHits is enabled and its tools are listed. Do not report Cursor ready from local CLI auth or init detection alone.

package/server.json

@@ -16,7 +16,7 @@
     "source": "github",
     "id": "1165453165"
   },
-  "version": "0.6.5",
+  "version": "0.6.7",
   "remotes": [
     {
       "type": "streamable-http",
@@ -28,7 +28,7 @@
       "registryType": "npm",
       "registryBaseUrl": "https://registry.npmjs.org",
       "identifier": "githits",
-      "version": "0.6.5",
+      "version": "0.6.7",
       "runtimeHint": "npx",
       "transport": {
         "type": "stdio"

package/skills/githits-code/SKILL.md

@@ -24,7 +24,7 @@ Use GitHits for evidence from real open-source code instead of guessing from mod
 - Exact language name uncertain for `example --lang`: run `githits languages <query>` first.
 - Inspecting a known dependency or GitHub repo: start with `githits search` scoped by `--in`.
 - Need file/path enumeration: use `githits code files`; do not probe directories with `code read`.
-- Know the exact text or regex to match: use `githits code grep`; use `githits search` for discovery.
+- Know the exact text to match: use `githits code grep` (literal by default). Pass `--regex` for RE2 syntax; lookaround and backreferences are unsupported. Use `githits search` for discovery.
 - Need documentation pages: use `githits search "<topic>" --source docs --in <target>` for topic search, or `githits docs list <spec>` to browse available pages.
 
 ## Core Commands
@@ -34,15 +34,15 @@ githits example "how to use express middleware"
 githits example "react hooks patterns" --lang typescript
 githits languages type
 
-githits search "router middleware" --in npm:express
-githits search "debounce" --in npm:lodash --source symbol
+githits search "router middleware" --in npm:express@5.2.1
+githits search "debounce" --in npm:lodash@4.18.1 --source symbol
 githits search '"body parser" OR multer' --in npm:express --source docs --json
 githits search-status <searchRef>
 
-githits code files npm:express lib/ --ext js --limit 100
-githits code read npm:express lib/express.js --lines 1-90
-githits code grep npm:express "process_params" lib/ -C 3
-githits code grep --repo-url https://github.com/expressjs/express --git-ref HEAD "Router" lib/
+githits code files npm:express@5.2.1 lib/ --ext js --limit 100
+githits code read npm:express@5.2.1 lib/express.js --lines 1-90
+githits code grep npm:express@5.2.1 "require('router')" lib/ -C 3
+githits code grep --repo-url https://github.com/expressjs/express --git-ref v5.2.1 "require('router')" lib/
 
 githits docs list npm:express --limit 20
 githits docs read <pageId> --lines 20-120
@@ -52,9 +52,12 @@ githits docs read <pageId> --lines 20-120
 
 - For behavioral claims, prefer source, symbols, tests, and call sites over docs prose.
 - For `githits example` results, report the source repositories/citations shown in GitHits' generated references/provenance section; they are core evidence for the synthesized pattern.
+- Package targets inspect published artifacts and omitted versions resolve to the latest release; repository targets inspect repository trees. For source-layout questions, always pin and report the package version or Git ref.
 - For source work, locate symbols or matches first, then read a focused window with explicit `--lines`.
+- Documentation text reads return at most 150 lines per call. Continue with the reported returned range and `totalLines` when more context is needed.
 - For multi-step code/docs investigations, keep raw CLI output out of the final answer unless it is the evidence the user needs.
 - If output says it used recent/stale indexed evidence, treat the displayed served target as provenance; if freshness matters, retry with a longer `--wait` or use one of the displayed `queryable now` versions/refs, or inspect JSON `targetResolution` for structured candidates.
+- Treat partial documentation coverage as incomplete evidence and retry later when advised. Capped coverage is terminal for the current crawl, so report the limitation instead of retrying.
 - If a code-navigation command returns `INDEXING`, use the elapsed/expected duration in the message to decide whether to retry with `--wait`; prefer any displayed indexed refs/versions when you need an immediate follow-up.
 - After using GitHits results, send feedback when practical. Use `githits feedback <solution_id> --accept|--reject` for `githits example` results, or omit `<solution_id>` for generic session feedback such as `githits feedback --reject --tool search -m "missing kotlin support"`.
 

package/skills/githits-code/references/code-and-docs.md

@@ -32,10 +32,12 @@ Use `search` for discovery and `code grep` only when you know the pattern.
 
 `githits docs list <spec>` browses available documentation pages. It is not topic search.
 
-`githits docs read <pageId>` reads a page. Use `--lines` for bounded windows and `--json` when extracting `totalLines` or source metadata.
+`githits docs read <pageId>` reads a page. Text output returns at most 150 lines per call, including larger explicit ranges; continue from the reported returned range when more context is needed. Use `--lines` for bounded windows and `--json` when extracting `totalLines` or source metadata.
 
 For topic search, use `githits search "<topic>" --source docs --in <target>`, then pass the returned page ID to `docs read`.
 
+When search reports partial documentation coverage, treat the evidence as incomplete and retry later when advised. Capped coverage means the current crawl stopped at a limit; report that limitation instead of retrying.
+
 ## Command Name Mapping
 
 - `githits example` maps to MCP `get_example`.

package/skills/githits-onboarding/SKILL.md

@@ -65,20 +65,43 @@ npx -y githits@latest init --detect-agents --json
 
 Run detection inline, not in a background terminal. Wait for JSON before continuing.
 
-Use the JSON fields to summarize detected tools. `agents[].status` can be `needs_setup`, `already_configured`, `unsupported_project_config`, or `not_detected`. `installableIds` lists detected tools that need setup for the selected scope.
+Use the JSON fields to summarize detected tools. `agents[].status` describes MCP state and can be `needs_setup`, `already_configured`, `unsupported_project_config`, or `not_detected`. `agents[].guidanceStatus` describes supporting guidance. `installableIds` remains MCP-only; use `actionableIds` for tools needing either MCP setup or requested guidance repair.
+
+If `actionableIds` is absent because the installed CLI predates guidance-aware detection, use `installableIds` for MCP setup and do not infer guidance-only repair from missing fields.
 
 For project-level setup, do not offer tools with `unsupported_project_config`. Explain only if needed: those detected tools do not have verified project-level MCP support.
 
-3. Recommend the simplest tool setup choice with structured options.
+Before showing the review, classify the detection result:
+
+- If every agent is `not_detected`, explain that no supported coding tool was found and stop before review, installation, or authentication. Tell the user to install or open a supported tool, then rerun detection.
+- In project scope, if no agent is `needs_setup` or `already_configured` and at least one is `unsupported_project_config`, explain that project-level setup is unavailable, offer user-level detection, and stop the project flow before review or authentication.
+- If supported agents are mixed with `unsupported_project_config`, explain the unsupported tools but continue only with supported agents.
+- If no effective actionable IDs remain but at least one supported agent is `already_configured`, continue to the review, skip installation after acknowledgment, and then check authentication.
+
+Follow the CLI JSON `instructions` remediation for these states rather than replacing it with generic authentication guidance.
+
+3. When setup can proceed, show the install review before asking for tool approval or starting browser authentication, including the already-configured supported-tool case.
+
+Tell the user:
 
-If `installableIds` is non-empty, use structured choices when available. Do not ask the user to type comma-separated tool IDs unless the current agent interface has no structured choice mechanism.
+- GitHits queries and public package, repository, and documentation targets are sent to GitHits services for processing.
+- Feedback submission is an outbound write that sends feedback data to GitHits services.
+- Installing GitHits does not itself upload the local workspace.
+- After installation, open a new coding-agent session so it loads MCP configuration and any supporting instructions. The terminal and machine do not need to be restarted.
+
+Ask the user to acknowledge this review before continuing.
+If the user does not acknowledge it, stop onboarding without installing or starting authentication.
+
+4. Recommend the simplest actionable setup choice with structured options.
+
+If `actionableIds` is non-empty, use structured choices when available. Do not ask the user to type comma-separated tool IDs unless the current agent interface has no structured choice mechanism. Explain whether each ID needs MCP setup, guidance repair, or both.
 
 Ask: `Which tools should I configure?`
 
 Options:
 
-- `Configure all detected tools (Recommended)` — the recommended default option; use all `installableIds`.
-- One selective setup option per installable detected tool, using the tool display name and ID.
+- `Configure all actionable tools (Recommended)` — the recommended default option; after approval execute `suggestedCommand` exactly so scope and guidance intent are preserved.
+- One selective setup option per actionable tool, using the tool display name and ID.
 
 Do not present "configure none" as a normal onboarding choice; if the user does not want any tool configured, pause and clarify whether they want to stop onboarding.
 
@@ -86,7 +109,11 @@ Ask before writing configuration. A good prompt is: `I recommend configuring all
 
 Only install user-approved IDs. Do not run `init -y` or `init --yes` unless the user explicitly asks to configure every detected tool.
 
-4. Install GitHits MCP and supporting guidance for approved tools using the selected scope.
+For selective setup, build the matching scoped `--install-agents` command and preserve `--no-guidance` when `guidanceRequested` is `false`. Follow the CLI-emitted verification instruction instead of constructing a separate detect command.
+
+If no effective actionable IDs remain and at least one supported tool is already configured, skip installation and continue to authentication only after the user acknowledges the install review.
+
+5. Install GitHits MCP and supporting guidance for approved tools using the selected scope.
 
 Guidance is installed by default. It adds the `githits-mcp` skill and a short instruction pointer for tools with verified guidance paths. Add `--no-guidance` only when the user explicitly asks for plain MCP without supporting instructions.
 
@@ -104,10 +131,14 @@ npx -y githits@latest init --install-agents <comma-separated-approved-ids> --jso
 
 Treat `success` and `already_configured` outcomes as usable. Report any `failed` outcome with the tool name and message. For project-level setup, remind the user that project-local MCP files may be committed.
 
-5. Start GitHits sign-in/signup during onboarding.
+Cursor is configured with the remote MCP at `https://mcp.githits.com`, not a local stdio command. An existing Cursor entry that runs `npx ... githits ... mcp start` is legacy and should become `needs_setup`; installing it migrates the entry to the remote URL.
+
+6. Start GitHits sign-in/signup during onboarding.
 
 Do not ask whether the user wants to log in. Login creates or connects the GitHits account, so it is part of onboarding. Ask before launching browser OAuth, then run login unless `auth status` already shows an active session.
 
+This CLI authentication step applies to local GitHits CLI/stdio integrations. Cursor remote MCP authentication is managed separately by Cursor. If Cursor is the only approved tool, skip local CLI login and continue to the Cursor verification below. For a mixed install, use this CLI login step for the non-Cursor tools, but do not treat it as evidence that Cursor is authenticated.
+
 Check auth state:
 
 ```bash
@@ -134,7 +165,7 @@ npx -y githits@latest login --no-browser
 
 With `--no-browser`, surface the printed sign-in URL clearly so the user can open it in a browser. If command output is hidden from the user, relay the URL verbatim. Do not ask them to paste passwords, tokens, cookies, or OAuth codes back into chat.
 
-6. Verify setup after login and installation.
+7. Verify setup after login and installation.
 
 Project-level verification:
 
@@ -150,14 +181,27 @@ npx -y githits@latest auth status
 npx -y githits@latest init --detect-agents --json
 ```
 
-Confirm auth is active and selected tools are `already_configured` for the selected scope. If MCP configuration changed, tell the user to open a new agent session in the project or user environment so the tool reloads its MCP config.
+Confirm auth is active and selected tools are `already_configured` for the selected scope. If MCP configuration or supporting guidance changed, tell the user to open a new coding-agent session in the project or user environment so the tool reloads its MCP configuration and any supporting instructions. The terminal and machine do not need to be restarted.
+
+For Cursor, `already_configured` verifies only that the remote URL is present. It does not verify Cursor-managed OAuth or tool discovery. Do not report Cursor as ready based on `githits auth status` or init detection alone.
+
+If `cursor-agent` is available, verify Cursor directly:
+
+```bash
+cursor-agent mcp list
+cursor-agent mcp list-tools GitHits
+```
+
+If Cursor reports that authentication is required, run `cursor-agent mcp login GitHits`, let the user complete browser OAuth, then rerun both verification commands. Do not ask the user to paste OAuth data into chat.
+
+Whether or not `cursor-agent` is available, tell the user to open a new Cursor Agent chat after installation. In the Cursor MCP tools UI, confirm that GitHits is enabled, complete its OAuth prompt if shown, and confirm that GitHits tools are listed. If the CLI checks cannot run, require the user's confirmation from that new chat before reporting Cursor ready.
 
 ## Completion Response
 
 Report:
 
 - Which tools were configured or already configured.
-- Whether GitHits auth is active, requires browser approval, or could not be verified.
+- Whether local GitHits CLI auth and Cursor-managed OAuth are active, require browser approval, or could not be verified, keeping those states separate.
 - Whether the user needs to restart/open a new agent session.
 - Any failed tool setup with the exact tool name and error message.