githits 0.6.7 → 0.7.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.
Files changed (36) hide show
  1. package/.claude-plugin/marketplace.json +21 -3
  2. package/.claude-plugin/plugin.json +16 -2
  3. package/.codex-plugin/plugin.json +42 -0
  4. package/.cursor-plugin/plugin.json +29 -0
  5. package/.mcp.json +2 -2
  6. package/.plugin/plugin.json +16 -2
  7. package/AGENTS.md +201 -0
  8. package/README.md +22 -6
  9. package/dist/cli.js +6 -6
  10. package/dist/index.js +1 -1
  11. package/dist/shared/{chunk-4cnb4nss.js → chunk-mysf4hjt.js} +1 -1
  12. package/dist/shared/{chunk-xr5k540v.js → chunk-ncsgqtj1.js} +1 -1
  13. package/dist/shared/{chunk-p09q90sj.js → chunk-p8dg49ey.js} +1 -1
  14. package/gemini-extension.json +2 -3
  15. package/mcp_config.json +7 -0
  16. package/package.json +23 -14
  17. package/plugin.json +3 -0
  18. package/server.json +5 -2
  19. package/GEMINI.md +0 -83
  20. package/commands/example.md +0 -27
  21. package/commands/help.md +0 -52
  22. package/commands/login.md +0 -36
  23. package/commands/logout.md +0 -16
  24. package/commands/search.md +0 -27
  25. package/commands/status.md +0 -22
  26. package/plugins/claude/.claude-plugin/plugin.json +0 -12
  27. package/plugins/claude/.mcp.json +0 -8
  28. package/plugins/claude/commands/example.md +0 -27
  29. package/plugins/claude/commands/help.md +0 -52
  30. package/plugins/claude/commands/login.md +0 -36
  31. package/plugins/claude/commands/logout.md +0 -16
  32. package/plugins/claude/commands/search.md +0 -27
  33. package/plugins/claude/commands/status.md +0 -22
  34. package/plugins/claude/skills/githits-mcp/SKILL.md +0 -40
  35. package/plugins/claude/skills/onboarding/SKILL.md +0 -156
  36. package/plugins/claude/skills/search/SKILL.md +0 -44
@@ -1,156 +0,0 @@
1
- ---
2
- name: onboarding
3
- description: >-
4
- Set up GitHits from Claude Code: detect supported tools, install GitHits MCP,
5
- start sign-in/signup, verify auth, and recover from setup issues.
6
- metadata:
7
- internal: true
8
- ---
9
-
10
- Use this skill when the user asks to install, connect, set up, sign up for, or start using GitHits. This is a new-user onboarding skill: assume the user wants to create or connect a GitHits account and configure GitHits unless they explicitly say otherwise.
11
-
12
- ## Current Boundary
13
-
14
- - GitHits sign-in/signup currently uses browser OAuth. You can start and monitor login, but the user may need to approve GitHits in a browser tab.
15
- - Never ask the user to paste passwords, OAuth codes, cookies, access tokens, refresh tokens, or API keys into chat.
16
-
17
- ## Execution Mode
18
-
19
- - Use `npx -y githits@latest ...` for every normal onboarding command. This guarantees the latest published GitHits CLI behavior for new users.
20
- - Do not use a globally installed `githits` binary for onboarding unless the user explicitly asks to test a local, dev, or pinned CLI build.
21
- - If the user explicitly asks for local/dev/pinned testing, preserve the command and environment they provide.
22
- - Run onboarding commands inline in the current agent session.
23
- - Do not use subagents, background agents, background terminals, or long-running background tasks for onboarding.
24
- - Do not delegate `githits`, `npx`, `npm`, `codex`, `claude`, detection, login, or setup commands to subagents or background agents.
25
- - Do not start `npx -y githits@latest init --detect-agents --json` as a background task. Wait for the result before continuing.
26
- - Do not run `pkill`, `ps`, process inspection, or package-source inspection as part of normal onboarding.
27
- - If `npx -y githits@latest ...` fails because of network, DNS, or package-fetch errors, stop and report that GitHits CLI is unavailable.
28
- - If official detection fails or appears stuck, do not inspect package internals, manually probe tools to infer install IDs, or ask the user to type inferred IDs. Report the detection failure and offer to retry, switch setup scope, or stop.
29
-
30
- ## Flow
31
-
32
- 1. Choose setup scope with a structured choice. Do not ask the user to type a freeform response.
33
-
34
- Ask: `Where should GitHits be configured?`
35
-
36
- Options:
37
-
38
- - `My user account (Recommended)` — configures detected tools globally/user-level on this machine so GitHits is available wherever the user works with those agents.
39
- - `This project only` — writes project-local MCP files into this repo; files may be committed.
40
-
41
- 2. Detect supported tools and current MCP state for the selected scope.
42
-
43
- Project-level detection:
44
-
45
- ```bash
46
- npx -y githits@latest init --project --detect-agents --json
47
- ```
48
-
49
- User-level detection:
50
-
51
- ```bash
52
- npx -y githits@latest init --detect-agents --json
53
- ```
54
-
55
- Run detection inline, not in a background terminal. Wait for JSON before continuing.
56
-
57
- Do not offer tools with `unsupported_project_config` for project-level setup.
58
-
59
- 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.
60
-
61
- Before showing the review, classify the detection result:
62
-
63
- - 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.
64
- - 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.
65
- - If supported agents are mixed with `unsupported_project_config`, explain the unsupported tools but continue only with supported agents.
66
- - 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.
67
-
68
- Follow the CLI JSON `instructions` remediation for these states rather than replacing it with generic authentication guidance.
69
-
70
- 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.
71
-
72
- Tell the user:
73
-
74
- - GitHits queries and public package, repository, and documentation targets are sent to GitHits services for processing.
75
- - Feedback submission is an outbound write that sends feedback data to GitHits services.
76
- - Installing GitHits does not itself upload the local workspace.
77
- - 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.
78
-
79
- Ask the user to acknowledge this review before continuing.
80
- If the user does not acknowledge it, stop onboarding without installing or starting authentication.
81
-
82
- 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.
83
-
84
- 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.
85
-
86
- 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?`
87
-
88
- Do not run `init -y` or `init --yes` unless the user explicitly asks to configure every detected tool.
89
-
90
- 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.
91
-
92
- 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.
93
-
94
- 5. Install only approved IDs using the selected scope.
95
-
96
- 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.
97
-
98
- Project-level install:
99
-
100
- ```bash
101
- npx -y githits@latest init --project --install-agents <comma-separated-approved-ids> --json
102
- ```
103
-
104
- User-level install:
105
-
106
- ```bash
107
- npx -y githits@latest init --install-agents <comma-separated-approved-ids> --json
108
- ```
109
-
110
- 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.
111
-
112
- 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.
113
-
114
- 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.
115
-
116
- Check whether login can be skipped because auth is already active:
117
-
118
- ```bash
119
- npx -y githits@latest auth status
120
- ```
121
-
122
- If not authenticated or expired, ask before launching browser login, then run:
123
-
124
- ```bash
125
- npx -y githits@latest login
126
- ```
127
-
128
- Normal login opens the browser when possible and also prints a fallback sign-in URL. If command output is hidden from the user, relay the URL verbatim.
129
-
130
- Use this only when browser launch fails or the environment is headless:
131
-
132
- ```bash
133
- npx -y githits@latest login --no-browser
134
- ```
135
-
136
- 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.
137
-
138
- 7. Verify with the selected scope.
139
-
140
- Project-level verification:
141
-
142
- ```bash
143
- npx -y githits@latest auth status
144
- npx -y githits@latest init --project --detect-agents --json
145
- ```
146
-
147
- User-level verification:
148
-
149
- ```bash
150
- npx -y githits@latest auth status
151
- npx -y githits@latest init --detect-agents --json
152
- ```
153
-
154
- 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.
155
-
156
- 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.
@@ -1,44 +0,0 @@
1
- ---
2
- name: search
3
- description:
4
- Use GitHits MCP tools to find real-world code examples when model knowledge
5
- is insufficient.
6
- metadata:
7
- internal: true
8
- ---
9
-
10
- Use GitHits when:
11
-
12
- - You are blocked, uncertain about an API, or need up-to-date OSS usage.
13
- - You have attempted a solution twice and it still fails - search for a working example before trying again.
14
- - The user asks to search for examples or explicitly mentions GitHits.
15
- - You are implementing non-trivial code in languages where confidence is lower.
16
-
17
- Authentication:
18
-
19
- - If any GitHits tool returns an authentication error, immediately run
20
- `npx -y githits login` in the terminal. This opens the user's browser for
21
- quick OAuth approval. Wait for the command to complete, then retry the
22
- original tool call.
23
- - If the environment has no display (SSH, containers), use
24
- `npx -y githits login --no-browser` instead, which prints a URL for the
25
- user to open on another device.
26
- - Do NOT ask the user to run login manually -- handle it automatically.
27
- - If login fails, inform the user of the error and suggest they set the
28
- `GITHITS_API_TOKEN` environment variable as an alternative.
29
-
30
- Guidelines:
31
-
32
- - Prefer existing search context if it already answers the problem.
33
- - Pass `language` only when you need to force a specific language; use
34
- `search_language` first if the exact language name is uncertain.
35
- - Use `get_example` for one focused example-search question at a time.
36
- - When the task is about indexed dependency or repository internals, prefer
37
- unified `search` instead of
38
- `get_example`.
39
- - Prefer the default compact text output. Request JSON only when exact
40
- structured fields are necessary.
41
- - After using results, send `feedback` with helpful/unhelpful outcome.
42
-
43
- Tool argument details and rich query guidance are provided directly in the MCP
44
- tool descriptions; follow those descriptions as the source of truth.