菜单
Set up GitHits from an agent session: detect supported coding tools, install GitHits MCP configuration, start account sign-in/signup, verify auth, and recover from setup issues. Use when the user asks to install, connect, set up, sign up for, or start using GitHits.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
Use GitHits MCP tools to find real-world code examples when model knowledge is insufficient.
Use GitHits MCP as an OSS context layer when a task involves open-source packages, frameworks, SDKs, libraries, developer tools, package docs, repository source, examples, planning, research, vulnerabilities, changelogs, dependency graphs, or upgrade-review evidence. Prefer it before relying on model memory or generic web search for public OSS context.
Use when preparing, reviewing, or executing a GitHits CLI release. Covers release-version consistency, plugin manifests, user-visible changelog notes, MCP instruction quality, MCP registry publishing/versioning, and the special lifecycle for published Agent Skills.
Set up GitHits from Claude Code: detect supported tools, install GitHits MCP, start sign-in/signup, verify auth, and recover from setup issues.
Use GitHits CLI for canonical open-source examples, indexed source, docs, grep, file listing, and code navigation. Activate when verifying library behavior from source or examples. For metadata, vulnerabilities, dependency graphs, or changelogs, use githits-package instead.
Use GitHits CLI package-intelligence commands for package/dependency triage: overview, latest version, license, repository health, vulnerabilities, advisory history, dependency graphs, transitive provenance, changelogs, release notes, and upgrade reviews. Activate for packages, dependencies, versions, upgrades, CVEs, dependency footprints, or release changes.
基于 SOC 职业分类
| name | githits-onboarding |
| description | Set up GitHits from an agent session: detect supported coding tools, install GitHits MCP configuration, start account sign-in/signup, verify auth, and recover from setup issues. Use when the user asks to install, connect, set up, sign up for, or start using GitHits. |
| compatibility | Requires shell access, internet access, and npx. Use a local githits binary only for explicit local/dev/pinned testing. |
Use this skill when the user wants to start using GitHits from their agent. 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.
npx -y githits@latest ... for every normal onboarding command. This guarantees the latest published GitHits CLI behavior for new users.githits binary for onboarding unless the user explicitly asks to test a local, dev, or pinned CLI build.--json for staged init commands because agents need stable fields.npx -y githits@latest as a background task. If npx fails because of network, DNS, or package-fetch errors, stop and report that GitHits CLI is unavailable.githits, npx, npm, codex, claude, detection, login, or setup commands to subagents or background agents.npx -y githits@latest init --detect-agents --json as a background task. Run it directly, wait for the result, and only continue after it returns.pkill, ps, process inspection, or package-source inspection as part of normal onboarding. If a command appears stuck, stop and report that official detection did not return.Use the agent's structured choice UI when available. Do not ask the user to type a freeform response for setup scope.
Ask: Where should GitHits be configured?
Options:
My user account (Recommended) — configures detected tools globally/user-level on this machine. Best for onboarding because GitHits will be available wherever the user works with those agents.This project only — writes project-local MCP files into the current repo. Good for repo-specific or team setup. These files may be committed.Project-level detection:
npx -y githits@latest init --project --detect-agents --json
User-level detection:
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.
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.
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.
Ask: Which tools should I configure?
Options:
Configure all detected tools (Recommended) — the recommended default option; use all installableIds.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.
Ask before writing configuration. A good prompt is: I recommend configuring all detected tools so GitHits works wherever you use an agent. Proceed with all, or choose specific tools?
Only install user-approved IDs. Do not run init -y or init --yes unless the user explicitly asks to configure every detected tool.
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.
Project-level install:
npx -y githits@latest init --project --install-agents <comma-separated-approved-ids> --json
User-level install:
npx -y githits@latest init --install-agents <comma-separated-approved-ids> --json
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.
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.
Check auth state:
npx -y githits@latest auth status
Treat Authenticated. and Authenticated via environment variable. as already signed in and skip launching login. Treat Not authenticated. and Token expired. as requiring login.
Explain: I can start GitHits sign-in now. It may open a browser tab where you approve or create your GitHits account. I will not ask you to paste secrets into chat.
Then run:
npx -y githits@latest login
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.
If the browser cannot open automatically, or the session appears to be SSH/container/headless, use:
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.
Project-level verification:
npx -y githits@latest auth status
npx -y githits@latest init --project --detect-agents --json
User-level verification:
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.
Report:
init --yes after a failure; use the staged JSON flow and approved IDs.references/troubleshooting.md before suggesting recovery.Read references/troubleshooting.md for recovery paths when setup, login, storage, or verification fails.