GitHub repository access in containerized environments using REST API and credential detection. Use when git clone fails, or when accessing private repos/writing files via API.
日本語の概要は準備中です。原文の説明を表示しています。
Chooses the right FORMAT for instructions on Claude.ai — project instructions, a skill, or a standalone prompt — and gives the format-specific structure once chosen. Use when the question is which container an instruction belongs in ("should this be a skill or project instructions", "where do I put this", "how do I set up this project", "is this worth a skill"), or when someone has instructions and does not know how to package them. For the writing principles that apply inside any of the three formats, use writing-instructions. For building, testing and packaging a complete skill directory, use creating-skill.
インストールする前に、エージェントに与えられる指示の中身を確認できます。
Choose the format for instructions on Claude.ai — Project instructions, Skills, or standalone prompts — and structure them for the format chosen.
Overlap notice. The Core Optimization Principles below also appear in
writing-instructions, which carries them in more depth. This skill owns the
format decision; writing-instructions owns how to write well inside a
format. The two descriptions are close enough that a request can land on
either — route by which of those two questions is being asked.
Ask these questions to determine the right format:
Signals: "for this project", "all conversations about X", "team workspace", "project-specific"
Signals: "every time I", "whenever", "reusable", "across projects", "teach Claude how to"
Signals: "for this task", "right now", "just this once", "can you"
Project + Skill:
Skill + Prompt:
These apply to ALL instruction formats:
Frame as direct action commands, not suggestions:
State WHAT to do, not what NOT to do:
WHY: Negative instructions force inference. Positive instructions state desired behavior directly.
Explain WHY requirements exist:
WHY: Context helps Claude make better autonomous decisions in edge cases.
Provide goals and decision frameworks, not step-by-step procedures:
Current models plan from a stated goal. Write out a sequence only where one sequence is the safe one — destructive commands, auth flows, compliance steps.
Claude's system prompt already covers:
ONLY specify project/domain-specific deviations.
See: references/project-instructions.md
Key points:
See: references/creating-skills.md
Key points:
See: references/standalone-prompts.md
Key points:
Read: references/skill-vs-project.md for detailed comparison
Quick reference:
Project = "Here's what you need to know"
Skill = "Here's how to do things"
Example:
Use both together for powerful combinations.
Examples teach every pattern they contain, including the ones you did not intend.
When including examples:
Default to clear organization:
Use structured markup (XML/JSON) only when:
No prompt phrase turns thinking on. Current Claude models think adaptively by
default, and depth is set by configuration — the effort setting on the API,
the UI control on Claude.ai. "Think step by step" and hand-written trigger
phrases buy nothing.
What instructions can usefully carry is which parts of the domain deserve more deliberation, so the reader knows where to raise effort:
[Specific complexity] in this domain is worth extra deliberation because [why].
Match instruction complexity to task needs:
Simple task → Simple prompt or brief instructions Medium task → Structured guidance with decision frameworks Complex task → Comprehensive instructions; raise effort
Before adding complexity: Could simpler formulation work equally well?
Scale density to how far the task sits from what the model does unprompted. State the goal, the constraints, and how success is checked; add procedure only where order is fragile. When the choice is between another rule and more context about why, write the context — that is what the model cannot get elsewhere, and it is what it uses on the cases you did not enumerate.
State explicitly that judgment applies to cases the instructions do not cover.
Before delivering instructions:
Strategic:
Technical:
Execution:
❌ System prompt duplication - "Use web_search for current info, cite sources" ✅ Omit unless project has SPECIFIC deviations
❌ Negative framing - "Don't use lists, never be verbose" ✅ "Present in natural prose paragraphs"
❌ Fake thinking triggers - "Use 'think carefully' for deep thinking" ✅ "Name where deliberation pays in this domain; set effort there"
❌ Procedural micromanagement - "Step 1: X, Step 2: Y..." ✅ "Goal: X. Quality standard: Y. Approach: Z."
❌ Contextless requirements - "Always use formal tone" ✅ "Use formal tone for professional docs because recipients expect authoritative voice"
❌ Imperfect examples - Example uses bullets when you want prose ✅ Either create perfect examples or omit entirely
まだレビューはありません。使ってみた感想をお寄せください。
概要と使いどころ
GitHub repository access in containerized environments using REST API and credential detection. Use when git clone fails, or when accessing private repos/writing files via API.
日本語の概要は準備中です。原文の説明を表示しています。
Decide which model, effort level, and cascade shape each subagent gets, and how to keep improvement loops safe (evaluator-as-selector, stop on regression). Routes on measured cost-per-completed-task rather than per-token price, because a tier's token count varies more by task shape than price varies across tiers. Covers per-model effort semantics, the concision lever, cascade preconditions, context handoff, and watching a subagent fan-out live. Use when choosing a subagent's model or effort, when choosing how to escalate a failed attempt, or when asked which model or effort a task should get. Grounded in a 2026-07 calibration, a 2026-08 coding-cost study, a 2026-09 seeded-bug repair battery, a 2026-10 Haiku 5.5 ladder priced per spawn, and a 2026-10 retry-versus-escalation ladder on 295 SWE-bench Verified tasks; Managed Agents API specifics are operational, not calibrated.
日本語の概要は準備中です。原文の説明を表示しています。
Securely manages API credentials for multiple providers (Anthropic Claude, Google Gemini, GitHub). Use when skills need to access stored API keys for external service invocations.
日本語の概要は準備中です。原文の説明を表示しています。
Guidance for asking clarifying questions when user requests are ambiguous, have multiple valid approaches, or require critical decisions. Use when implementation choices exist that could significantly affect outcomes.
日本語の概要は準備中です。原文の説明を表示しています。
Pre-change blast-radius report for a symbol or file. Walks tree-sitting references, augments with a plain-text scan over non-parsed files (configs, plain docs), and clusters affected sites by feature (`_FEATURES.md`) or top-level package. Use when about to refactor, rename, or delete something in a repo you don't own — "what breaks if I change `validateUser`", "who calls this", "is this safe to remove", "where is this used", "blast radius", "impact analysis". This is the CONVERGENT pre-change risk skill — for "what is this repo?" use exploring-codebases; for "where is X?" use searching-codebases.
日本語の概要は準備中です。原文の説明を表示しています。
Read Bluesky/ATProto without depending on Bluesky's AppView — interactions on a user's posts, thread replies, any repo's records, network-wide backlinks across every lexicon, an account's handle and PDS history, which collections are active network-wide, and layer-by-layer outage diagnosis. Use when bsky.app or the AppView is down or slow, when a Bluesky read returns timeouts or 5xx, when asked who liked/replied/quoted/reposted something, when pulling live Bluesky context cheaply, when reading records straight from a PDS, when asked who references a record or account anywhere on the network, whether an account has changed handle or migrated servers, or which lexicons and non-Bluesky apps are active on atproto. Complements browsing-bluesky, which routes everything through the AppView and fails when it does.
日本語の概要は準備中です。原文の説明を表示しています。