{"id":1000039,"date":"2026-10-12T11:12:11","date_gmt":"2026-10-12T11:12:11","guid":{"rendered":"https:\/\/www.exam-topics.info\/blog\/anthropic-cca-f-claude-code-skills-commands\/"},"modified":"2026-10-20T15:44:59","modified_gmt":"2026-10-20T15:44:59","slug":"anthropic-cca-f-claude-code-skills-commands","status":"publish","type":"post","link":"https:\/\/www.exam-topics.info\/blog\/anthropic-cca-f-claude-code-skills-commands\/","title":{"rendered":"Anthropic CCA-F: Claude Code Skills and Slash Commands"},"content":{"rendered":"<div class=\"et-b02-editorial-v2\">\n<p>A team reviews database migrations weekly, yet each engineer gives Claude Code a different checklist. One remembers compatibility, another forgets rollback, and a third lets an exploratory review run a command that changes local database state. The solution is not to paste every procedure into an always-on instruction file. Stable repository constraints belong in project instructions; specialized migration steps belong in a discoverable, on-demand skill. The design concern in <a href=\"https:\/\/www.exam-topics.info\/cca-f\">Anthropic CCA-F<\/a> is the separation of these instruction layers from actual tool authority: a skill can describe a safe sequence, but it cannot grant database privileges or make an unsafe command acceptable.<\/p>\n<nav aria-label=\"On this page\"><strong>On this page<\/strong><\/p>\n<ol>\n<li><a href=\"#recognize-when-a-procedure-deserves-a-skill\">Recognize when a procedure deserves a skill<\/a><\/li>\n<li><a href=\"#separate-always-on-instructions-from-specialized-work\">Separate always-on instructions from specialized work<\/a><\/li>\n<li><a href=\"#describe-discoverable-skills-accurately\">Describe discoverable skills accurately<\/a><\/li>\n<li><a href=\"#design-evidence-based-workflow-outputs\">Design evidence-based workflow outputs<\/a><\/li>\n<li><a href=\"#treat-task-arguments-as-data-not-authority\">Treat task arguments as data, not authority<\/a><\/li>\n<li><a href=\"#do-not-confuse-instructions-with-tools\">Do not confuse instructions with tools<\/a><\/li>\n<li><a href=\"#resolve-similar-names-and-conflicting-skill-sources\">Resolve similar names and conflicting skill sources<\/a><\/li>\n<li><a href=\"#measure-whether-the-skill-really-helps\">Measure whether the skill really helps<\/a><\/li>\n<li><a href=\"#review-a-migration-from-request-to-decision\">Review a migration from request to decision<\/a><\/li>\n<\/ol>\n<\/nav>\n<h2 id=\"recognize-when-a-procedure-deserves-a-skill\">Recognize when a procedure deserves a skill<\/h2>\n<p>A skill is useful when a task has stable purpose, meaningful steps and verifiable results. A database migration review may inspect schema differences, dependent queries, rollout order, backfill assumptions, and rollback safety. Engineers should not have to restate those requirements on every release. A reviewed workflow lets different developers obtain comparable analysis while retaining access to the current repository. It does not assert a migration is safe merely because every checklist item was mentioned; supporting tests and operational evidence still matter.<\/p>\n<p>Ask whether the named procedure improves on a one-time prompt. If somebody wants a single explanation of a function, ordinary conversation is enough. If the same workflow recurs across dozens of releases and relies on specialized commands and reviewer evidence, a skill earns its place. Too many tiny or poorly described skills make discovery ambiguous. A collection of shortcuts is not automatically a productive knowledge system if users cannot tell which procedure applies to a situation.<\/p>\n<h2 id=\"separate-always-on-instructions-from-specialized-work\">Separate always-on instructions from specialized work<\/h2>\n<p>The project&#8217;s <code>CLAUDE.md<\/code> describes information that matters broadly: the package manager, repository boundaries, approved commands, and durable conventions. A skill holds a specific procedure such as reviewing migrations or producing a release summary. Today&#8217;s task prompt identifies the particular migration, environment and acceptance criteria. These inputs are complementary. Put a permanent repository convention only in an occasional skill and ordinary sessions may miss it; put every long deployment checklist into <code>CLAUDE.md<\/code> and the coding assistant carries irrelevant instructions into routine changes.<\/p>\n<p>The root instructions may name the approved migration-review skill, while the skill contains steps and expected evidence. That makes maintenance clearer: repository architecture changes update the shared project contract, whereas a better migration test updates the skill. The design also limits context consumption. A frontend correction should not load a page of database rollback commands unless the work actually touches the database. This separation follows the reasoning behind <a href=\"https:\/\/www.exam-topics.info\/blog\/anthropic-cca-f-claude-md-project-instructions\/\">scoped project instructions<\/a>.<\/p>\n<h2 id=\"describe-discoverable-skills-accurately\">Describe discoverable skills accurately<\/h2>\n<p>A Claude Code skill can be represented by a <code>SKILL.md<\/code> file within a named skill directory, with metadata establishing its purpose. Depending on configuration, users may invoke it through slash notation, and Claude may load it when relevant. The description is the discovery interface. Words such as &#8220;useful for engineering&#8221; do not show when to activate a procedure, while &#8220;reviews SQL migrations for backward compatibility, expected lock time, and rollback hazards&#8221; establishes a concrete trigger and expected scope.<\/p>\n<p>Do not assume that every slash entry is a custom skill. Claude Code&#8217;s custom commands have been merged into skills: <code>.claude\/commands\/deploy.md<\/code> and <code>.claude\/skills\/deploy\/SKILL.md<\/code> both expose <code>\/deploy<\/code>; existing command files remain supported, while built-in session commands are a separate category. Discovery and precedence can depend on product version and organizational settings. Test a representative request and verify which skill is selected, whether its supporting files load, and whether sensitive operations are excluded. If a release workflow activates during a harmless request for a summary, refine its name and description rather than trusting the model to guess the unstated distinction.<\/p>\n<h2 id=\"design-evidence-based-workflow-outputs\">Design evidence-based workflow outputs<\/h2>\n<p>A migration-review skill should identify required inputs, ordered checks, output format, and reasons to stop. It might inspect the schema delta, application consumers, migration SQL, rollout order, and rollback proposal. Its report should distinguish confirmed incompatibilities from speculative risks. A conclusion such as &#8220;looks safe&#8221; has little value if a reviewer cannot tell which queries or services were inspected. When a schema snapshot is unavailable, the output should identify the missing evidence instead of treating that absence as a clean result.<\/p>\n<p>The procedure should still leave room for engineering judgment. A destructive column removal needs a compatibility plan, but table size, traffic patterns, and existing backfill mechanisms influence the correct rollout. A skill can require examination of those factors without imposing a universal sequence for every database. Expert oversight remains crucial when the evidence is incomplete. The workflow structures decisions so they can be defended, rather than making every project conform to a mechanical template.<\/p>\n<h2 id=\"treat-task-arguments-as-data-not-authority\">Treat task arguments as data, not authority<\/h2>\n<p>A slash-invoked skill may receive arguments identifying a branch, migration number or environment. These are task inputs to validate, not permission grants. A string that says production does not entitle the agent to production credentials. A read-only migration review should not mutate a database just to collect basic evidence. Match tools and privileges to the current user and runtime, with environment-level permission checks for sensitive operations. Useful instructions do not replace least privilege.<\/p>\n<p>Resource files in a skill can also age. SQL examples, API endpoints, and assumed repository paths may become wrong after a platform migration. Version supporting scripts and check them against representative fixtures. Secrets never belong in the skill text or examples. If the task needs privileged access, reference the approved secrets-management workflow and the required approval step. A reusable procedure that quietly embeds an access token or obsolete destructive command creates a repeatable incident, not repeatable quality.<\/p>\n<h2 id=\"do-not-confuse-instructions-with-tools\">Do not confuse instructions with tools<\/h2>\n<p>A deployment skill may describe a procedure, but an <a href=\"https:\/\/www.exam-topics.info\/blog\/anthropic-cca-f-mcp-server-integration\/\">MCP server connection<\/a> determines which external operations can actually be reached. For uncertain cross-service work, <a href=\"https:\/\/www.exam-topics.info\/blog\/anthropic-cca-f-claude-code-plan-mode\/\">a read-only planning phase<\/a> should identify prerequisites before any privileged tool is enabled. This prevents a concise slash command from disguising an unreviewed change to the operational permission boundary.<\/p>\n<p>A skill tells Claude how to approach a task. A tool or MCP server gives it an actual capability to read or change external state. A skill that asks to create a ticket cannot do so without an appropriately authorized connector. Conversely, granting a ticket tool does not teach the organization&#8217;s classification and escalation rules. Design the workflow and tool contract together, but assess the permissions of each independently. A memorable slash command is not a secret way around production change control.<\/p>\n<p>An organization may have one code-review skill using read-only repository search, and a release skill that requests a protected deployment. Their privileges and evidence gates should differ. The review can summarize risks without writing; the release pathway needs verified tests, approval records and controlled tools. If the runtime cannot enforce the intended boundary, the procedure should not silently proceed on the strength of a sentence saying to be careful. It should explain the limitation and preserve its work for authorized continuation.<\/p>\n<h2 id=\"resolve-similar-names-and-conflicting-skill-sources\">Resolve similar names and conflicting skill sources<\/h2>\n<p>Teams may synchronize organization skills while developers also keep local and project-level skills. Two similarly named commands can represent different procedures, so a user may invoke one thing and receive another. Inspect the active skill list and precedence rules of the installed Claude Code version. Prefer names that identify purpose, not generic labels such as deploy or review when those collide with other tools. Keep the difference between a project-specific workflow and a personal convenience command clear.<\/p>\n<p>Configuration drift deserves testing. After an upgrade, verify that the expected skill description still appears and that a representative task invokes the correct procedure. If one skill&#8217;s behavior is uncertain, do not assume it will safely inherit another skill&#8217;s limitations. Track provenance, revision and maintainer along with code review. These are ordinary software-maintenance disciplines applied to instructions that influence future automated work.<\/p>\n<h2 id=\"measure-whether-the-skill-really-helps\">Measure whether the skill really helps<\/h2>\n<p>A workflow that saves repeated prompting but produces more false-positive findings may be a poor improvement. Establish a handful of representative migration cases: a backward-compatible column addition, a risky rename, a long-running backfill, an index that may block writes, and an absent rollback. A reviewer can compare outputs against known expected observations. Quality includes factual findings, missed dependencies, unnecessary escalation and the usefulness of each proposed follow-up. Record failures rather than editing the examples until the skill appears perfect.<\/p>\n<p>Also measure operational overhead: how much source context the skill loads, whether it needs unavailable tools, whether it leaves a reproducible audit trail, and how often developers must manually repair its reports. A narrower skill can outperform a universal engineering assistant if it consistently handles one important process. The goal is not maximizing the count of skills; it is preserving specific expertise in a form that helps the team make better decisions and exposes uncertainty instead of hiding it.<\/p>\n<h2 id=\"review-a-migration-from-request-to-decision\">Review a migration from request to decision<\/h2>\n<p>An engineer asks for a migration review that renames an order-status field. Project instructions identify the database platform and build commands. The skill examines DDL, application queries, background workers, rollout plan and rollback proposal. It finds that a worker still reads the old field, so a one-step rename risks breaking active processing. The report cites the consumer and recommends a compatibility phase in which both representations are accepted while dependencies migrate. It does not invent permission to alter a live database.<\/p>\n<p>The engineer chooses a staged rollout, validates it in staging, and secures the organization&#8217;s required approval. The useful division of labor is clear: the skill improves consistency, the repository provides current facts, testing establishes behavior, and decision-makers authorize consequential actions. The certification question is not the exact syntax of a slash command. It is where reusable procedural knowledge belongs, how it is selected, and what must be independently established before an assistant&#8217;s recommendation can be trusted.<\/p>\n<\/div>\n","protected":false},"excerpt":{"rendered":"<p>Distinguish reusable Claude Code skills, slash commands, project instructions and enforceable tool permissions.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[41],"tags":[],"class_list":["post-1000039","post","type-post","status-publish","format-standard","hentry","category-anthropic"],"_links":{"self":[{"href":"https:\/\/www.exam-topics.info\/blog\/wp-json\/wp\/v2\/posts\/1000039","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.exam-topics.info\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.exam-topics.info\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.exam-topics.info\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.exam-topics.info\/blog\/wp-json\/wp\/v2\/comments?post=1000039"}],"version-history":[{"count":7,"href":"https:\/\/www.exam-topics.info\/blog\/wp-json\/wp\/v2\/posts\/1000039\/revisions"}],"predecessor-version":[{"id":1002123,"href":"https:\/\/www.exam-topics.info\/blog\/wp-json\/wp\/v2\/posts\/1000039\/revisions\/1002123"}],"wp:attachment":[{"href":"https:\/\/www.exam-topics.info\/blog\/wp-json\/wp\/v2\/media?parent=1000039"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.exam-topics.info\/blog\/wp-json\/wp\/v2\/categories?post=1000039"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.exam-topics.info\/blog\/wp-json\/wp\/v2\/tags?post=1000039"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}