codexkit-mcp-onboarding

# MCP Onboarding Use this skill when deciding whether a repo or team should add MCP servers and how to roll them out safely. ## Workflow 1. Start from real engineering tasks, not tool hype. 2. Map each task to the minimum useful MCP capability. 3. Prefer read-only or low-risk integrations first. 4. Define who owns secrets, scopes, and monitoring. 5. Document why each server exists and when to remove it. ## Strong candidates - docs and API lookup - issue tracker triage - repository metadata and pull request context - observability lookups with strict access control ## Avoid - installing every available MCP server - shipping write access without auditability - embedding team-specific secrets in public examples ## Quality Criteria - [ ] Steps are executable in sequence without external context - [ ] Decision points have clear if/then branching - [ ] Rollback or abort procedures are documented for risky steps - [ ] Expected duration or time-per-step is estimated ## Verification (4C) | Check | Question | |-------|----------| | **Correctness** | Do the steps execute correctly in the order specified? | | **Completeness** | Are decision points, error handling, and escalation paths all documented? | | **Context-fit** | Could someone with the right access but no prior context complete this runbook? | | **Consequence** | If Step N fails and the operator skips to Step N+1, what breaks? | ## Edge Cases - **Steps require access the operator doesn't have** — Document exact access requirements upfront. Include escalation contact for emergency access. - **Environment differs from documented state** — Add a pre-flight check as Step 0 to verify prerequisites before starting. - **Runbook is triggered during off-hours** — Document who to contact and which steps can be safely deferred to business hours. ## Changelog - v1.0.0 — Initial release