claude-code

これはレビュー時に保存された抜粋です。完全で最新の内容は外部ソースを確認してください。

---
# name: stable kebab-case skill identifier; must match the parent directory.
name: claude-code
# description: routing contract — pushy positive trigger + explicit negative boundary.
description: "Use when deciding whether to run a task in the Claude Code agent harness, when scoping work to its native capabilities (skills, hooks, subagents, MCP, plan mode, 1M-context Opus, background tasks, slash commands), or when choosing Claude Code versus a different harness (Codex, OpenCode, Copilot) for a given piece of work. Covers what the harness is good at, the extensibility stack and when each layer earns its keep, and the decision boundaries against rival harnesses. Do NOT use for writing Anthropic SDK / API code (use `claude-api`), for choosing which Claude MODEL to route a task to versus GPT (use `gpt-5-5`), or for designing a generic autonomous agent loop (use `autonomous-loop-patterns`)."
# subject: primary browse shelf — the competency the skill teaches.
subject: agent-ops
# subjects: optional polyhierarchy, max 2, primary first.
subjects:
  - agent-ops
  - ai-engineering
# public: publishability gate. true = safe for public marketplace (no private data).
public: true
# scope: required PRD-style free-text statement of what the skill teaches and excludes.
scope: "Choosing and scoping work for the Claude Code agent/CLI harness — its capability surface (the skills + hooks + subagents extensibility stack, MCP, plan mode, 1M-context Opus, run_in_background tasks, slash commands), what it is decisively good at, and how to decide between it and a rival harness (Codex, OpenCode, Copilot) for a task. Portable across any project that uses Claude Code; principle- and capability-grounded, not repo-bound. Excludes Anthropic SDK/API coding (claude-api), Claude-vs-GPT model routing (gpt-5-5), and generic agent-loop design (autonomous-loop-patterns)."
# taxonomy_domain: optional hierarchical sub-path within `subject`.
taxonomy_domain: agent/harness
# mental_model: the one-sentence frame for how to think about this concept.
mental_model: "The harness is the body; the model is the brain. The model decides what to do; the harness decides what the model is allowed to do and how its actions are gated, rendered, parallelized, and persisted. Choosing this harness is choosing that body — its permission model, extensibility layers, and context budget — not just the underlying model."
# purpose: why this concept exists / the problem it solves.
purpose: "A frontier model alone cannot safely operate a codebase. The harness supplies the missing scaffolding — typed tool surfaces the host can gate, lifecycle hooks for automation and security, isolated subagent context windows, on-demand skill loading, and a plan-before-act mode — so a long-horizon coding task can run autonomously without losing control or context."
# concept_boundary: what this concept is explicitly NOT.
concept_boundary: "It is not the model provider's API or SDK (that is application code you write), not the model itself (the model is swappable inside the harness), and not a generic 'agent framework' you assemble — it is one specific, opinionated harness with a fixed protocol."
# analogy: a concrete comparison that makes the concept click.
analogy: "Picking a harness is like picking the cockpit, not the pilot — the same pilot flies differently depending on which instruments, autopilot, and safety interlocks the cockpit gives them."
# misconception: the most common wrong belief about this concept.
misconception: "That the harness and the model are the same choice. They are two orthogonal decisions: which harness (this one vs a rival) and which model runs inside it. Conflating them leads to picking a harness for a model strength it does not own, or vice versa."
# stability: lifecycle marker (experimental until audited and proven in routing).
stability: experimental
# license: SPDX identifier for the skill content.
license: MIT
# compatibility: runtime/portability notes.
compatibility:
  n