القائمة
Use when you need a one-off MCP server capability during research or debugging without permanently mounting it as a context-polluting integration.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
THE ONLY ENTRY POINT FOR CC10X. Activate this skill for build, debug, review, and plan requests. Use when the user asks to implement, fix, review, plan, test, refactor, or continue code work. Trigger keywords: build, implement, create, write, add, review, audit, debug, fix, error, bug, broken, plan, design, architect, spec, brainstorm, test, refactor, optimize, update, change, research, cc10x, c10x. CRITICAL: Route and execute immediately. Do not stop at describing capabilities.
Implementation skill for writing production code with TDD. Covers the RED-GREEN-REFACTOR cycle, false-RED detection, vertical slicing, scope escalation, test process discipline, and code generation patterns. Loaded by component-builder and bug-investigator.
Resolve an in-progress git merge or rebase conflict hunk by hunk — see the state, find the primary sources for each side's intent, resolve by intent (never --abort), run the project's checks, and finish the operation. Model- invoked: agents reach for it when a git operation reports conflicts.
Canonical deep-module vocabulary (module, interface, depth, seam, adapter, leverage, locality) for designing a module's shape — a lot of behaviour behind a small interface at a clean seam, testable through that interface. The single source of truth for these terms; other skills (architecture, codebase-hygiene, building, planning) point here instead of restating them. Use when designing or improving a module's interface, finding deepening opportunities, deciding where a seam goes, or making code more testable.
Two-mode skill: (1) find semantic duplicates — functions doing the same thing under different names, invisible to copy-paste detectors; (2) deepen shallow modules — thin wrappers and pass-through layers that spread complexity. Advisory and read-only; changes route through BUILD with full gates.
Use when a BUILD phase completes, a commit is staged, or a PR is about to be created, and the diff has not yet been reflected in documentation. Also use when the user says "update docs", "sync docs", "document this", or asks whether documentation is up to date.
| name | mcp-cli |
| description | Use when you need a one-off MCP server capability during research or debugging without permanently mounting it as a context-polluting integration. |
| allowed-tools | Read Bash |
| user-invocable | false |
The mcp CLI (from github.com/f/mcptools) discovers and invokes MCP server capabilities on-demand, then releases them. Use it when a task needs ONE server's tool — a doc fetch, a single query, a quick lookup — instead of permanently mounting that server as an always-loaded integration.
This keeps accelerators transient: spun up for the task, used, and dropped. A permanently mounted MCP server costs context on every session whether you call it or not. The CLI costs nothing until you run it. This is the same context-hygiene principle behind disabling unused MCP servers in monthly /mcp review.
Composes with cc10x:research (transient retrieval, used then released, never resident).
Check first: command -v mcp. If absent, install:
git clone https://github.com/f/mcptools /tmp/mcptools
CGO_ENABLED=0 go build -o ~/.local/bin/mcp /tmp/mcptools/cmd/mcptools
# ensure ~/.local/bin is on PATH
If go is unavailable, report that the accelerator is missing and proceed with built-in tools — do NOT treat the missing binary as a task blocker (it is a fallback message, not a wall).
1. Discover first — always. Never call a tool whose schema you have not seen.
mcp tools <server-command> # list tools
mcp tools --format json <server-command> # full param schema for parsing
mcp resources <server-command> # list resources
mcp prompts <server-command> # list prompts
2. Lead read-only when exploring. Restrict the surface before you touch an unfamiliar server:
mcp guard --allow 'tools:read_*,list_*' --deny 'tools:write_*,delete_*' <server-command>
Drop the guard only once you know exactly which write you intend.
3. Call with params matching the discovered signature exactly (param:str, param:num, [optional]):
mcp call <tool_name> --params '<json>' -f json <server-command>
Output -f json for parsing, -f pretty for reading. Check exit code and stderr on failure — a non-zero exit is a real error, not a fallback message.
Server-command examples:
npx -y @modelcontextprotocol/server-filesystem /path--transport sse--auth-header "Bearer <token>", --auth-user user:pass, or -e ENV_VAR for docker serversIf you call the same server several times, alias it; remove it when the task ends so nothing lingers:
mcp alias add <name> <server-command> # then: mcp tools <name>, mcp call ... <name>
mcp alias remove <name> # release when done
Aliases persist in ~/.mcpt/aliases.json. Cleaning them up is part of keeping the accelerator transient.