一键导入
inspecto-onboarding-codex
Use when Codex should install or set up Inspecto in the current frontend project through the shared onboarding workflow.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Use when Codex should install or set up Inspecto in the current frontend project through the shared onboarding workflow.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use when the AI should handle Inspecto annotation sessions through MCP, including claiming the next task, replying with progress, and resolving work when complete.
Use when creating or maintaining assistant-specific Inspecto onboarding skills that should follow the shared detect, plan, apply, and doctor workflow.
Use when the user wants CodeBuddy to install, configure, or diagnose Inspecto in the current project.
Use when Claude Code should install or set up Inspecto in the current frontend project through the shared onboarding workflow.
Help users install, configure, or diagnose Inspecto in the current repository. Use this skill when asked to set up Inspecto.
Use when the user wants Cursor to install or set up Inspecto in the current project.
| name | inspecto-onboarding-codex |
| description | Use when Codex should install or set up Inspecto in the current frontend project through the shared onboarding workflow. |
Use Inspecto's structured CLI flow instead of hand-editing project files.
Always prefer the single-entry onboarding command over the legacy detect/plan/apply sequence.
~/.codex/skills/inspecto-onboarding-codex/scripts/run-inspecto.sh onboard --json.status: "needs_target_selection", explain that this step chooses which local development build target should receive the Inspecto plugin and settings. Show the target candidates, ask the user which exact candidate to use, then rerun with --target <candidateId>, preferring the explicit candidateId field. The CLI also accepts a returned configPath as a compatibility fallback. Do not collapse the user's choice back to a package path when the same package has multiple build configs.status: "needs_confirmation", summarize summary.headline, summary.changes, summary.risks, and summary.manualFollowUp, then ask for approval before rerunning with --yes.needs_confirmation summary and wait for approval.status: "partial_success" and diagnostics.nextSteps includes IDE extension installation, treat that as a blocking onboarding follow-up. Do not move on to dev-server validation until the extension is installed automatically or the user confirms they completed the manual install.code --install-extension inspecto.inspectohttps://marketplace.visualstudio.com/items?itemName=inspecto.inspectohttps://open-vsx.org/extension/inspecto/inspectostatus: "error", summarize diagnostics.errors and diagnostics.nextSteps. Run ~/.codex/skills/inspecto-onboarding-codex/scripts/run-inspecto.sh doctor --json only when explicit recovery diagnostics are still needed.verification field.verification.available is true and verification.devCommand is present, offer to start that exact command immediately for validation.verification.message and tell the user to start their normal dev server command manually.handoff.patches, treat them as the primary source of truth for the remaining work. Apply those patches directly before exploring framework docs or unrelated project files.handoff.dailyUsage, use that payload as the post-onboarding runtime handoff:
Annotate mode tasks should now follow handoff.dailyUsage.skillhandoff.dailyUsage.prompthandoff.dailyUsage.requiresMcp is true, say that continuous task pickup still requires separate MCP configurationFor the common "set up Inspecto in this project" request, use:
~/.codex/skills/inspecto-onboarding-codex/scripts/run-inspecto.sh onboard --json --yes
This should be the default for straightforward single-app repositories when the user did not ask to preview the plan first.
After this fast path succeeds, the next default action should be:
dev script for validation if it is clearly availablehandoff.dailyUsage, close by using that exact runtime handoff for daily MCP-driven annotation work.inspecto/settings.local.json and .inspecto/prompts.local.json unless the user explicitly asks for shared config.code fields as the stable automation signal. Do not branch on free-form message text.scripts/run-inspecto.sh. Use the installed skill launcher or a directly available inspecto executable.verification payload as the source of truth for dev-server validation. Do not guess custom start commands.handoff.patches, handoff.pendingSteps, and handoff.assistantPrompt over ad-hoc investigation. Do not start with Next.js or Nuxt documentation searches when the CLI already returned concrete patch targets.handoff.dailyUsage is present, do not end onboarding without mentioning that runtime handoff.When debugging the skill against a local Inspecto checkout from a project outside the workspace, prefer environment-variable overrides instead of changing the target project:
INSPECTO_CLI_BIN=/absolute/path/to/inspecto/packages/cli/dist/bin.jsINSPECTO_DEV_REPO=/absolute/path/to/inspectoExamples:
INSPECTO_CLI_BIN=/Users/tangjie/hugo.felix/inspecto/packages/cli/dist/bin.js ~/.codex/skills/inspecto-onboarding-codex/scripts/run-inspecto.sh onboard --json --yesINSPECTO_DEV_REPO=/Users/tangjie/hugo.felix/inspecto ~/.codex/skills/inspecto-onboarding-codex/scripts/run-inspecto.sh onboard --json --yesINSPECTO_CLI_BIN forces the skill to use your local CLI build. INSPECTO_DEV_REPO also makes the CLI install local packages/plugin and packages/core instead of fetching published packages.
Use short prompts like:
Use $inspecto-onboarding-codex to set up Inspecto in this projectUse $inspecto-onboarding-codex to show the Inspecto plan before changing filesUse $inspecto-onboarding-codex to diagnose why Inspecto onboarding is blocked