{"content_id":"9bufu7fxqw","slug":"claude-code-rules-skills-agents-guide","locale":"en","schema_type":"HowTo","category":"tutorial","category_name":"Tutorial","title":"Practical Guide to Claude Code Rules, Skills, and Agents","summary":"Claude Code Rules, Skills, and Agents handle persistent instructions, reusable procedures, and isolated task delegation, respectively. This guide uses practical examples to explain the exact file structures and invocation methods, as well as principles for security and context management.","sponsorship_disclosure":null,"author":{"name":"Injoys Editorial Team","url":"https://injoys.com/ko/about"},"key_points":["Create a `.claude` directory in the project root and distinguish the scope of shared settings from that of personal settings.","Separate standards that must always be followed into Markdown files under `.claude/rules`, and limit their applicable paths if necessary.","Write recurring procedures in `.claude/skills/\u003cname\u003e/SKILL.md` and configure them for automatic or explicit invocation.","Delegate tasks requiring an independent context and role to a `.claude/agents/\u003cname\u003e.md` subagent.","Use small validation tasks to verify loading, tool permissions, and result quality before committing the settings to the team repository."],"content_markdown":"Claude Code extensions are not all the same kind of prompt. **Rules are instructions that apply continuously**, **Skills are reusable procedures for recurring tasks**, and **Agents are role-specific executors that work in separate contexts**. Distinguishing these three features correctly reduces prompt repetition while allowing you to manage the main conversation context efficiently.\n\nThis document explains project-level configuration. Because supported metadata and interfaces may vary by Claude Code version, fields that do not work should be checked again in the official documentation for the installed version.\n\n## Step 1: Define the `.claude` Directory and Configuration Scope\n\nRules, Skills, and Agents shared within a project are generally placed under `.claude` at the repository root.\n\n```text\nmy-project/\n├── .claude/\n│   ├── rules/\n│   │   ├── code-style.md\n│   │   └── api.md\n│   ├── skills/\n│   │   └── fix-issue/\n│   │       └── SKILL.md\n│   └── agents/\n│       ├── code-reviewer.md\n│       └── test-runner.md\n├── src/\n└── package.json\n```\n\nYou can create the directories as follows.\n\n```bash\nmkdir -p .claude/rules\nmkdir -p .claude/skills/fix-issue\nmkdir -p .claude/agents\n```\n\n### Two Misconceptions About `.claude`\n\n1. `.claude` is not required for every Claude Code instruction. Project instructions can also be managed in `CLAUDE.md` at the root or `.claude/CLAUDE.md`, while a user's personal settings can be placed under `~/.claude` in the home directory.\n2. File names are case-sensitive depending on the operating system. It is safest to name the Skill entry file `SKILL.md` in uppercase to match the official format. If it is saved as `skill.md`, it may not be recognized.\n\n### Criteria for Choosing Project or Personal Configuration\n\n| Scope | Suitable Content | Examples |\n|---|---|---|\n| Shared project | Rules and automation that all contributors must follow consistently | Test commands, directory structure, API conventions |\n| Personal user | Personal preferences or settings that should not be exposed in the repository | Personal workflow, choice of local tools |\n| Local only | Paths or experimental settings valid only on a specific computer | Local data paths, temporary debugging procedures |\n\nCommit only files intended for team use to Git. Do not record secret keys, tokens, or internal server passwords in Rules or Skills.\n\n## Step 2: Create Persistent Instructions with Rules\n\nRules allow project instructions that Claude should reference while working to be managed across multiple Markdown files. Among the rules under `.claude/rules`, files without a `paths` condition are loaded as project instructions, while files with path conditions are applied when relevant files are handled.\n\n### Basic Rule Example\n\nYou can write `.claude/rules/code-style.md` as follows.\n\n```markdown\n# Coding Principles\n\n- Write new application code in TypeScript.\n- For public functions, describe inputs, return values, and failure conditions.\n- Do not hide failures by deleting existing tests.\n- Run the relevant tests and type checks after making changes.\n- Write explanations in Korean, but follow existing naming conventions for code identifiers.\n```\n\nA good Rule is verifiable. “Run `npm test` and `npm run typecheck` after making changes” is clearer than “Write good code.”\n\n### Rule Applied Only to Specific Paths\n\nIf the frontend and backend follow different rules, you can narrow the scope using `paths` in YAML front matter.\n\n```markdown\n---\npaths:\n  - \"src/api/**/*.ts\"\n  - \"tests/api/**/*.ts\"\n---\n\n# API Rules\n\n- Validate all API inputs against a schema.\n- Handle authentication failures and insufficient permissions as different errors.\n- When changing an endpoint, update the corresponding API tests as well.\n```\n\nPath-specific rules reduce the problem of unnecessary instructions occupying the context of every task.\n\n### Content That Should Not Be Included in Rules\n\n- A migration procedure that will be performed only once\n- Detailed requirements needed only for a specific issue\n- Conflicting absolute instructions\n- Lengthy repetition of content already enforced through code or linter settings\n- Sensitive data such as passwords, API keys, and customer information\n\nRules are not a “magical guarantee that instructions will always be followed.” Ambiguous or conflicting instructions can produce different results, so deterministic validation methods such as tests, linters, and access controls should be used together with them.\n\n## Step 3: Automate Recurring Procedures with Skills\n\nA Skill packages a description, task procedure, required tools, and supporting materials into a single reusable unit. The basic structure of a project Skill is `.claude/skills/\u003cskill-name\u003e/SKILL.md`, and templates or scripts can be added to the same directory as needed.\n\nUnlike Rules, a Skill is used when needed for a specific task. Claude may select it automatically based on the Skill's description, or the user may invoke it explicitly in the `/\u003cskill-name\u003e` format. It does not necessarily operate only through manual invocation.\n\n### Issue-Fixing Skill Example\n\nThe following is an example of `.claude/skills/fix-issue/SKILL.md`.\n\n```markdown\n---\nname: fix-issue\ndescription: Reproduce a bug, narrow down its cause, and then make the smallest possible fix and perform regression testing.\ndisable-model-invocation: true\nallowed-tools: Read, Grep, Glob, Edit, Bash(npm test:*)\n---\n\n# Issue-Fixing Procedure\n\nTarget issue: $ARGUMENTS\n\n1. Investigate the relevant code and existing tests.\n2. Before making changes, summarize the reproduction steps and expected behavior.\n3. Explain the root cause in one paragraph.\n4. Apply the change with the smallest scope of impact.\n5. Add a regression test or verify that an existing test covers the problem.\n6. Run the permitted tests and summarize the results.\n7. Report the changed files, remaining risks, and items requiring manual verification.\n```\n\nThis Skill can be invoked as follows.\n\n```text\n/fix-issue Profile picture does not update after login\n```\n\n`disable-model-invocation: true` is useful when you want to prevent Claude from running this Skill on its own and require the user to invoke it directly. Supported front matter fields may vary by Claude Code version.\n\n### Design-First Skill Example\n\nTo have Claude create a design document before coding immediately, you can include the following flow in a Skill.\n\n1. Separate the requirements from ambiguous points.\n2. Investigate the existing structure and reusable modules.\n3. Design the data flow, interfaces, and failure conditions.\n4. Write a design document under `docs/design/`.\n5. Implement after confirming the user's approval or the specified approval conditions.\n6. Provide testing and rollback methods.\n\n### Characteristics of a Good Skill\n\n- Its input and final output are clear.\n- The procedure's sequence and stopping conditions are specified.\n- Only the required tools are permitted.\n- Lengthy reference materials are separated into other files.\n- It reports failures instead of continuing at its own discretion.\n- A single Skill does not have too many purposes.\n\nRecurring tasks with clear beginnings and ends, such as writing commits, reviewing code, checking releases, and designing APIs, are suitable for Skills.\n\n## Step 4: Separate Roles and Contexts with Agents\n\nClaude Code subagents perform specific roles in separate contexts and return their results to the main conversation. They are useful when you do not want to accumulate large amounts of search results or test logs in the main context.\n\nProject agents are generally defined in `.claude/agents/\u003cagent-name\u003e.md`. You can inspect or manage agents through the `/agents` command, and you can also request delegation to a specific agent in natural language.\n\n### Code Review Agent Example\n\nYou can write `.claude/agents/code-reviewer.md` as follows.\n\n```markdown\n---\nname: code-reviewer\ndescription: A read-oriented reviewer that examines changed code for defects, security risks, and missing tests\ntools: Read, Grep, Glob, Bash\nmodel: sonnet\n---\n\nYou are an agent dedicated to code review.\n\nReview in the following order of priority.\n\n1. Defects that could cause actual outages or data loss\n2. Security issues related to authentication, permissions, and input validation\n3. Concurrency, transaction, and error-handling problems\n4. Missing tests that leave requirements unverified\n5. Structures that significantly reduce maintainability\n\nFor each finding, include the file path, evidence, conditions under which it occurs, and the minimum direction for a fix.\nDo not report unsupported style preferences as defects.\nDo not modify the code directly; return only the review results.\n```\n\nYou can make a request as follows.\n\n```text\nHave the code-reviewer agent review the changes on the current branch.\n```\n\n### Differences Between Skills and Agents\n\n| Criterion | Rules | Skills | Agents |\n|---|---|---|---|\n| Core purpose | Provide persistent instructions | Reuse recurring procedures | Delegate work by role |\n| When applied | Always or according to path conditions | Automatic selection or explicit invocation | Delegation by Claude or a user request |\n| Context | Included as instructions in the main task | Primarily executed within the current workflow | Performed in a separate context, then results are returned |\n| Typical example | Coding standards | Issue-fixing procedure | Code reviewer |\n| Storage location | `.claude/rules/*.md` | `.claude/skills/\u003cname\u003e/SKILL.md` | `.claude/agents/*.md` |\n\n### Agents and Agent Teams Are Different\n\nThe fact that ordinary subagents use separate contexts does not mean that agents can freely communicate with one another. An ordinary subagent follows a delegation structure in which it performs its assigned task and returns the result to the main agent. Agent Teams, which allow multiple independent sessions to exchange messages with one another, are a separate feature, and their support status and activation requirements must be checked in the official documentation.\n\nDesigning a workflow on the assumption that agents can continuously create other agents in a chain may fail because of version or permission restrictions. It is safer to begin with a simple structure in which the main agent divides work among role-specific subagents and consolidates their results.\n\n## Step 5: Validate Loading, Permissions, and Quality\n\nDo not assume that configuration files work as intended merely because they have been created. Validate each component separately with a small task.\n\n### Recommended Validation Sequence\n\n1. **Check Rules:** Request work on both a file to which a rule applies and one to which it does not, and verify the path conditions.\n2. **Check Skills:** Explicitly invoke a Skill and verify that its input arguments, outputs, and stopping conditions work.\n3. **Check Agents:** Assign a low-risk task such as a read-only review and inspect the result format.\n4. **Check permissions:** Review whether tools capable of making changes, such as Bash and Edit, have been granted only to configurations that truly need them.\n5. **Automated validation:** Independently verify AI results through tests, type checking, linters, and security checks.\n\n### Items to Check When Something Fails\n\n- Is `.claude` actually located at the project root?\n- Is the Skill file named exactly `SKILL.md`?\n- Is the Skill located in the `.claude/skills/\u003cname\u003e/SKILL.md` structure?\n- Is the Agent file a Markdown file directly under `.claude/agents`?\n- Are the beginning and end of YAML front matter enclosed with `---`?\n- Are `name` and `description` specific enough to distinguish the task?\n- Do the path patterns match the actual project structure?\n- Does the installed Claude Code version support the metadata being used?\n- Are tool permissions or organizational policies blocking execution?\n\n## Why Context Budgets and Security Must Be Designed Together\n\nThe purpose of Rules, Skills, and Agents is not merely to add functionality. They are also **context engineering tools** that control what information enters the context and when.\n\nIf rules are excessively long, instructions unrelated to the current task occupy context and increase the likelihood of conflicts. Conversely, delegating exploration and log analysis to subagents allows only conclusions and evidence to remain in the main conversation.\n\nFrom a security perspective, the following principles are important.\n\n- Review Rules and Skills like any other code in the repository.\n- Read Agent or Skill files received from external sources before running them.\n- Minimize permissions for shell commands, network access, and file modification.\n- Do not unconditionally trust commands included in user input or issue descriptions.\n- Include human approval steps for deployment, deletion, payment, and data migration.\n- Do not store secrets in prompt files; use a separate secret management system.\n\n## Which Feature Should You Choose?\n\nYou can decide quickly by asking the following questions.\n\n- Must all relevant tasks follow it? → **Rule**\n- Is it a recurring procedure with a beginning and an end? → **Skill**\n- Does it require a separate role and independent context? → **Agent**\n- Must a deterministic command be run before or after a specific event? → **Consider a Hook**\n\nFor example, “Use TypeScript” is a Rule, while “Perform everything from bug reproduction through regression testing” is a Skill. “Read the changes and report only security defects” is suitable for an Agent. Behavior tied to a specific event, such as always running a formatter after editing a file, may be better suited to Hooks.\n\nThe most reliable configuration treats the three features as complementary rather than competing. Use Rules to provide shared standards, Skills to execute standard procedures, and Agents to separate context-heavy work such as investigation and review, then supplement them with deterministic validation through tests and Hooks.","content_html":"\u003cp\u003eClaude Code extensions are not all the same kind of prompt. \u003cstrong\u003eRules are instructions that apply continuously\u003c/strong\u003e, \u003cstrong\u003eSkills are reusable procedures for recurring tasks\u003c/strong\u003e, and \u003cstrong\u003eAgents are role-specific executors that work in separate contexts\u003c/strong\u003e. Distinguishing these three features correctly reduces prompt repetition while allowing you to manage the main conversation context efficiently.\u003c/p\u003e\n\u003cp\u003eThis document explains project-level configuration. Because supported metadata and interfaces may vary by Claude Code version, fields that do not work should be checked again in the official documentation for the installed version.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#step-1-define-the-claude-directory-and-configuration-scope\" class=\"anchor\" id=\"step-1-define-the-claude-directory-and-configuration-scope\"\u003e\u003c/a\u003eStep 1: Define the \u003ccode\u003e.claude\u003c/code\u003e Directory and Configuration Scope\u003c/h2\u003e\n\u003cp\u003eRules, Skills, and Agents shared within a project are generally placed under \u003ccode\u003e.claude\u003c/code\u003e at the repository root.\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003emy-project/\n\u003c/span\u003e\u003cspan\u003e├── .claude/\n\u003c/span\u003e\u003cspan\u003e│   ├── rules/\n\u003c/span\u003e\u003cspan\u003e│   │   ├── code-style.md\n\u003c/span\u003e\u003cspan\u003e│   │   └── api.md\n\u003c/span\u003e\u003cspan\u003e│   ├── skills/\n\u003c/span\u003e\u003cspan\u003e│   │   └── fix-issue/\n\u003c/span\u003e\u003cspan\u003e│   │       └── SKILL.md\n\u003c/span\u003e\u003cspan\u003e│   └── agents/\n\u003c/span\u003e\u003cspan\u003e│       ├── code-reviewer.md\n\u003c/span\u003e\u003cspan\u003e│       └── test-runner.md\n\u003c/span\u003e\u003cspan\u003e├── src/\n\u003c/span\u003e\u003cspan\u003e└── package.json\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eYou can create the directories as follows.\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003emkdir\u003c/span\u003e\u003cspan\u003e -p\u003c/span\u003e\u003cspan\u003e .claude/rules\n\u003c/span\u003e\u003cspan\u003emkdir\u003c/span\u003e\u003cspan\u003e -p\u003c/span\u003e\u003cspan\u003e .claude/skills/fix-issue\n\u003c/span\u003e\u003cspan\u003emkdir\u003c/span\u003e\u003cspan\u003e -p\u003c/span\u003e\u003cspan\u003e .claude/agents\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003ch3\u003e\n\u003ca href=\"#two-misconceptions-about-claude\" class=\"anchor\" id=\"two-misconceptions-about-claude\"\u003e\u003c/a\u003eTwo Misconceptions About \u003ccode\u003e.claude\u003c/code\u003e\n\u003c/h3\u003e\n\u003col\u003e\n\u003cli\u003e\n\u003ccode\u003e.claude\u003c/code\u003e is not required for every Claude Code instruction. Project instructions can also be managed in \u003ccode\u003eCLAUDE.md\u003c/code\u003e at the root or \u003ccode\u003e.claude/CLAUDE.md\u003c/code\u003e, while a user's personal settings can be placed under \u003ccode\u003e~/.claude\u003c/code\u003e in the home directory.\u003c/li\u003e\n\u003cli\u003eFile names are case-sensitive depending on the operating system. It is safest to name the Skill entry file \u003ccode\u003eSKILL.md\u003c/code\u003e in uppercase to match the official format. If it is saved as \u003ccode\u003eskill.md\u003c/code\u003e, it may not be recognized.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch3\u003e\n\u003ca href=\"#criteria-for-choosing-project-or-personal-configuration\" class=\"anchor\" id=\"criteria-for-choosing-project-or-personal-configuration\"\u003e\u003c/a\u003eCriteria for Choosing Project or Personal Configuration\u003c/h3\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eScope\u003c/th\u003e\n\u003cth\u003eSuitable Content\u003c/th\u003e\n\u003cth\u003eExamples\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Scope\"\u003eShared project\u003c/td\u003e\n\u003ctd data-label=\"Suitable Content\"\u003eRules and automation that all contributors must follow consistently\u003c/td\u003e\n\u003ctd data-label=\"Examples\"\u003eTest commands, directory structure, API conventions\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Scope\"\u003ePersonal user\u003c/td\u003e\n\u003ctd data-label=\"Suitable Content\"\u003ePersonal preferences or settings that should not be exposed in the repository\u003c/td\u003e\n\u003ctd data-label=\"Examples\"\u003ePersonal workflow, choice of local tools\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Scope\"\u003eLocal only\u003c/td\u003e\n\u003ctd data-label=\"Suitable Content\"\u003ePaths or experimental settings valid only on a specific computer\u003c/td\u003e\n\u003ctd data-label=\"Examples\"\u003eLocal data paths, temporary debugging procedures\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003eCommit only files intended for team use to Git. Do not record secret keys, tokens, or internal server passwords in Rules or Skills.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#step-2-create-persistent-instructions-with-rules\" class=\"anchor\" id=\"step-2-create-persistent-instructions-with-rules\"\u003e\u003c/a\u003eStep 2: Create Persistent Instructions with Rules\u003c/h2\u003e\n\u003cp\u003eRules allow project instructions that Claude should reference while working to be managed across multiple Markdown files. Among the rules under \u003ccode\u003e.claude/rules\u003c/code\u003e, files without a \u003ccode\u003epaths\u003c/code\u003e condition are loaded as project instructions, while files with path conditions are applied when relevant files are handled.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#basic-rule-example\" class=\"anchor\" id=\"basic-rule-example\"\u003e\u003c/a\u003eBasic Rule Example\u003c/h3\u003e\n\u003cp\u003eYou can write \u003ccode\u003e.claude/rules/code-style.md\u003c/code\u003e as follows.\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003e# Coding Principles\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003e- Write new application code in TypeScript.\n\u003c/span\u003e\u003cspan\u003e- For public functions, describe inputs, return values, and failure conditions.\n\u003c/span\u003e\u003cspan\u003e- Do not hide failures by deleting existing tests.\n\u003c/span\u003e\u003cspan\u003e- Run the relevant tests and type checks after making changes.\n\u003c/span\u003e\u003cspan\u003e- Write explanations in Korean, but follow existing naming conventions for code identifiers.\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eA good Rule is verifiable. “Run \u003ccode\u003enpm test\u003c/code\u003e and \u003ccode\u003enpm run typecheck\u003c/code\u003e after making changes” is clearer than “Write good code.”\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#rule-applied-only-to-specific-paths\" class=\"anchor\" id=\"rule-applied-only-to-specific-paths\"\u003e\u003c/a\u003eRule Applied Only to Specific Paths\u003c/h3\u003e\n\u003cp\u003eIf the frontend and backend follow different rules, you can narrow the scope using \u003ccode\u003epaths\u003c/code\u003e in YAML front matter.\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003e---\n\u003c/span\u003e\u003cspan\u003epaths:\n\u003c/span\u003e\u003cspan\u003e  - \"src/api/\u003c/span\u003e\u003cspan\u003e**/\u003c/span\u003e\u003cspan\u003e*.ts\"\n\u003c/span\u003e\u003cspan\u003e  - \"tests/api/\u003c/span\u003e\u003cspan\u003e**/\u003c/span\u003e\u003cspan\u003e*.ts\"\n\u003c/span\u003e\u003cspan\u003e---\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003e# API Rules\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003e- Validate all API inputs against a schema.\n\u003c/span\u003e\u003cspan\u003e- Handle authentication failures and insufficient permissions as different errors.\n\u003c/span\u003e\u003cspan\u003e- When changing an endpoint, update the corresponding API tests as well.\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003ePath-specific rules reduce the problem of unnecessary instructions occupying the context of every task.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#content-that-should-not-be-included-in-rules\" class=\"anchor\" id=\"content-that-should-not-be-included-in-rules\"\u003e\u003c/a\u003eContent That Should Not Be Included in Rules\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003eA migration procedure that will be performed only once\u003c/li\u003e\n\u003cli\u003eDetailed requirements needed only for a specific issue\u003c/li\u003e\n\u003cli\u003eConflicting absolute instructions\u003c/li\u003e\n\u003cli\u003eLengthy repetition of content already enforced through code or linter settings\u003c/li\u003e\n\u003cli\u003eSensitive data such as passwords, API keys, and customer information\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eRules are not a “magical guarantee that instructions will always be followed.” Ambiguous or conflicting instructions can produce different results, so deterministic validation methods such as tests, linters, and access controls should be used together with them.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#step-3-automate-recurring-procedures-with-skills\" class=\"anchor\" id=\"step-3-automate-recurring-procedures-with-skills\"\u003e\u003c/a\u003eStep 3: Automate Recurring Procedures with Skills\u003c/h2\u003e\n\u003cp\u003eA Skill packages a description, task procedure, required tools, and supporting materials into a single reusable unit. The basic structure of a project Skill is \u003ccode\u003e.claude/skills/\u0026lt;skill-name\u0026gt;/SKILL.md\u003c/code\u003e, and templates or scripts can be added to the same directory as needed.\u003c/p\u003e\n\u003cp\u003eUnlike Rules, a Skill is used when needed for a specific task. Claude may select it automatically based on the Skill's description, or the user may invoke it explicitly in the \u003ccode\u003e/\u0026lt;skill-name\u0026gt;\u003c/code\u003e format. It does not necessarily operate only through manual invocation.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#issue-fixing-skill-example\" class=\"anchor\" id=\"issue-fixing-skill-example\"\u003e\u003c/a\u003eIssue-Fixing Skill Example\u003c/h3\u003e\n\u003cp\u003eThe following is an example of \u003ccode\u003e.claude/skills/fix-issue/SKILL.md\u003c/code\u003e.\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003e---\n\u003c/span\u003e\u003cspan\u003ename: fix-issue\n\u003c/span\u003e\u003cspan\u003edescription: Reproduce a bug, narrow down its cause, and then make the smallest possible fix and perform regression testing.\n\u003c/span\u003e\u003cspan\u003edisable-model-invocation: true\n\u003c/span\u003e\u003cspan\u003eallowed-tools: Read, Grep, Glob, Edit, Bash(npm test:\u003c/span\u003e\u003cspan\u003e*)\n\u003c/span\u003e\u003cspan\u003e---\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003e# Issue-Fixing Procedure\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003eTarget issue: $ARGUMENTS\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003e1. Investigate the relevant code and existing tests.\n\u003c/span\u003e\u003cspan\u003e2. Before making changes, summarize the reproduction steps and expected behavior.\n\u003c/span\u003e\u003cspan\u003e3. Explain the root cause in one paragraph.\n\u003c/span\u003e\u003cspan\u003e4. Apply the change with the smallest scope of impact.\n\u003c/span\u003e\u003cspan\u003e5. Add a regression test or verify that an existing test covers the problem.\n\u003c/span\u003e\u003cspan\u003e6. Run the permitted tests and summarize the results.\n\u003c/span\u003e\u003cspan\u003e7. Report the changed files, remaining risks, and items requiring manual verification.\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eThis Skill can be invoked as follows.\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003e/fix-issue Profile picture does not update after login\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003e\u003ccode\u003edisable-model-invocation: true\u003c/code\u003e is useful when you want to prevent Claude from running this Skill on its own and require the user to invoke it directly. Supported front matter fields may vary by Claude Code version.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#design-first-skill-example\" class=\"anchor\" id=\"design-first-skill-example\"\u003e\u003c/a\u003eDesign-First Skill Example\u003c/h3\u003e\n\u003cp\u003eTo have Claude create a design document before coding immediately, you can include the following flow in a Skill.\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003eSeparate the requirements from ambiguous points.\u003c/li\u003e\n\u003cli\u003eInvestigate the existing structure and reusable modules.\u003c/li\u003e\n\u003cli\u003eDesign the data flow, interfaces, and failure conditions.\u003c/li\u003e\n\u003cli\u003eWrite a design document under \u003ccode\u003edocs/design/\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eImplement after confirming the user's approval or the specified approval conditions.\u003c/li\u003e\n\u003cli\u003eProvide testing and rollback methods.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch3\u003e\n\u003ca href=\"#characteristics-of-a-good-skill\" class=\"anchor\" id=\"characteristics-of-a-good-skill\"\u003e\u003c/a\u003eCharacteristics of a Good Skill\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003eIts input and final output are clear.\u003c/li\u003e\n\u003cli\u003eThe procedure's sequence and stopping conditions are specified.\u003c/li\u003e\n\u003cli\u003eOnly the required tools are permitted.\u003c/li\u003e\n\u003cli\u003eLengthy reference materials are separated into other files.\u003c/li\u003e\n\u003cli\u003eIt reports failures instead of continuing at its own discretion.\u003c/li\u003e\n\u003cli\u003eA single Skill does not have too many purposes.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eRecurring tasks with clear beginnings and ends, such as writing commits, reviewing code, checking releases, and designing APIs, are suitable for Skills.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#step-4-separate-roles-and-contexts-with-agents\" class=\"anchor\" id=\"step-4-separate-roles-and-contexts-with-agents\"\u003e\u003c/a\u003eStep 4: Separate Roles and Contexts with Agents\u003c/h2\u003e\n\u003cp\u003eClaude Code subagents perform specific roles in separate contexts and return their results to the main conversation. They are useful when you do not want to accumulate large amounts of search results or test logs in the main context.\u003c/p\u003e\n\u003cp\u003eProject agents are generally defined in \u003ccode\u003e.claude/agents/\u0026lt;agent-name\u0026gt;.md\u003c/code\u003e. You can inspect or manage agents through the \u003ccode\u003e/agents\u003c/code\u003e command, and you can also request delegation to a specific agent in natural language.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#code-review-agent-example\" class=\"anchor\" id=\"code-review-agent-example\"\u003e\u003c/a\u003eCode Review Agent Example\u003c/h3\u003e\n\u003cp\u003eYou can write \u003ccode\u003e.claude/agents/code-reviewer.md\u003c/code\u003e as follows.\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003e---\n\u003c/span\u003e\u003cspan\u003ename: code-reviewer\n\u003c/span\u003e\u003cspan\u003edescription: A read-oriented reviewer that examines changed code for defects, security risks, and missing tests\n\u003c/span\u003e\u003cspan\u003etools: Read, Grep, Glob, Bash\n\u003c/span\u003e\u003cspan\u003emodel: sonnet\n\u003c/span\u003e\u003cspan\u003e---\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003eYou are an agent dedicated to code review.\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003eReview in the following order of priority.\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003e1. Defects that could cause actual outages or data loss\n\u003c/span\u003e\u003cspan\u003e2. Security issues related to authentication, permissions, and input validation\n\u003c/span\u003e\u003cspan\u003e3. Concurrency, transaction, and error-handling problems\n\u003c/span\u003e\u003cspan\u003e4. Missing tests that leave requirements unverified\n\u003c/span\u003e\u003cspan\u003e5. Structures that significantly reduce maintainability\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003eFor each finding, include the file path, evidence, conditions under which it occurs, and the minimum direction for a fix.\n\u003c/span\u003e\u003cspan\u003eDo not report unsupported style preferences as defects.\n\u003c/span\u003e\u003cspan\u003eDo not modify the code directly; return only the review results.\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eYou can make a request as follows.\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003eHave the code-reviewer agent review the changes on the current branch.\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003ch3\u003e\n\u003ca href=\"#differences-between-skills-and-agents\" class=\"anchor\" id=\"differences-between-skills-and-agents\"\u003e\u003c/a\u003eDifferences Between Skills and Agents\u003c/h3\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eCriterion\u003c/th\u003e\n\u003cth\u003eRules\u003c/th\u003e\n\u003cth\u003eSkills\u003c/th\u003e\n\u003cth\u003eAgents\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Criterion\"\u003eCore purpose\u003c/td\u003e\n\u003ctd data-label=\"Rules\"\u003eProvide persistent instructions\u003c/td\u003e\n\u003ctd data-label=\"Skills\"\u003eReuse recurring procedures\u003c/td\u003e\n\u003ctd data-label=\"Agents\"\u003eDelegate work by role\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Criterion\"\u003eWhen applied\u003c/td\u003e\n\u003ctd data-label=\"Rules\"\u003eAlways or according to path conditions\u003c/td\u003e\n\u003ctd data-label=\"Skills\"\u003eAutomatic selection or explicit invocation\u003c/td\u003e\n\u003ctd data-label=\"Agents\"\u003eDelegation by Claude or a user request\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Criterion\"\u003eContext\u003c/td\u003e\n\u003ctd data-label=\"Rules\"\u003eIncluded as instructions in the main task\u003c/td\u003e\n\u003ctd data-label=\"Skills\"\u003ePrimarily executed within the current workflow\u003c/td\u003e\n\u003ctd data-label=\"Agents\"\u003ePerformed in a separate context, then results are returned\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Criterion\"\u003eTypical example\u003c/td\u003e\n\u003ctd data-label=\"Rules\"\u003eCoding standards\u003c/td\u003e\n\u003ctd data-label=\"Skills\"\u003eIssue-fixing procedure\u003c/td\u003e\n\u003ctd data-label=\"Agents\"\u003eCode reviewer\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Criterion\"\u003eStorage location\u003c/td\u003e\n\u003ctd data-label=\"Rules\"\u003e\u003ccode\u003e.claude/rules/*.md\u003c/code\u003e\u003c/td\u003e\n\u003ctd data-label=\"Skills\"\u003e\u003ccode\u003e.claude/skills/\u0026lt;name\u0026gt;/SKILL.md\u003c/code\u003e\u003c/td\u003e\n\u003ctd data-label=\"Agents\"\u003e\u003ccode\u003e.claude/agents/*.md\u003c/code\u003e\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003ch3\u003e\n\u003ca href=\"#agents-and-agent-teams-are-different\" class=\"anchor\" id=\"agents-and-agent-teams-are-different\"\u003e\u003c/a\u003eAgents and Agent Teams Are Different\u003c/h3\u003e\n\u003cp\u003eThe fact that ordinary subagents use separate contexts does not mean that agents can freely communicate with one another. An ordinary subagent follows a delegation structure in which it performs its assigned task and returns the result to the main agent. Agent Teams, which allow multiple independent sessions to exchange messages with one another, are a separate feature, and their support status and activation requirements must be checked in the official documentation.\u003c/p\u003e\n\u003cp\u003eDesigning a workflow on the assumption that agents can continuously create other agents in a chain may fail because of version or permission restrictions. It is safer to begin with a simple structure in which the main agent divides work among role-specific subagents and consolidates their results.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#step-5-validate-loading-permissions-and-quality\" class=\"anchor\" id=\"step-5-validate-loading-permissions-and-quality\"\u003e\u003c/a\u003eStep 5: Validate Loading, Permissions, and Quality\u003c/h2\u003e\n\u003cp\u003eDo not assume that configuration files work as intended merely because they have been created. Validate each component separately with a small task.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#recommended-validation-sequence\" class=\"anchor\" id=\"recommended-validation-sequence\"\u003e\u003c/a\u003eRecommended Validation Sequence\u003c/h3\u003e\n\u003col\u003e\n\u003cli\u003e\n\u003cstrong\u003eCheck Rules:\u003c/strong\u003e Request work on both a file to which a rule applies and one to which it does not, and verify the path conditions.\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003eCheck Skills:\u003c/strong\u003e Explicitly invoke a Skill and verify that its input arguments, outputs, and stopping conditions work.\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003eCheck Agents:\u003c/strong\u003e Assign a low-risk task such as a read-only review and inspect the result format.\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003eCheck permissions:\u003c/strong\u003e Review whether tools capable of making changes, such as Bash and Edit, have been granted only to configurations that truly need them.\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003eAutomated validation:\u003c/strong\u003e Independently verify AI results through tests, type checking, linters, and security checks.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch3\u003e\n\u003ca href=\"#items-to-check-when-something-fails\" class=\"anchor\" id=\"items-to-check-when-something-fails\"\u003e\u003c/a\u003eItems to Check When Something Fails\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003eIs \u003ccode\u003e.claude\u003c/code\u003e actually located at the project root?\u003c/li\u003e\n\u003cli\u003eIs the Skill file named exactly \u003ccode\u003eSKILL.md\u003c/code\u003e?\u003c/li\u003e\n\u003cli\u003eIs the Skill located in the \u003ccode\u003e.claude/skills/\u0026lt;name\u0026gt;/SKILL.md\u003c/code\u003e structure?\u003c/li\u003e\n\u003cli\u003eIs the Agent file a Markdown file directly under \u003ccode\u003e.claude/agents\u003c/code\u003e?\u003c/li\u003e\n\u003cli\u003eAre the beginning and end of YAML front matter enclosed with \u003ccode\u003e---\u003c/code\u003e?\u003c/li\u003e\n\u003cli\u003eAre \u003ccode\u003ename\u003c/code\u003e and \u003ccode\u003edescription\u003c/code\u003e specific enough to distinguish the task?\u003c/li\u003e\n\u003cli\u003eDo the path patterns match the actual project structure?\u003c/li\u003e\n\u003cli\u003eDoes the installed Claude Code version support the metadata being used?\u003c/li\u003e\n\u003cli\u003eAre tool permissions or organizational policies blocking execution?\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2\u003e\n\u003ca href=\"#why-context-budgets-and-security-must-be-designed-together\" class=\"anchor\" id=\"why-context-budgets-and-security-must-be-designed-together\"\u003e\u003c/a\u003eWhy Context Budgets and Security Must Be Designed Together\u003c/h2\u003e\n\u003cp\u003eThe purpose of Rules, Skills, and Agents is not merely to add functionality. They are also \u003cstrong\u003econtext engineering tools\u003c/strong\u003e that control what information enters the context and when.\u003c/p\u003e\n\u003cp\u003eIf rules are excessively long, instructions unrelated to the current task occupy context and increase the likelihood of conflicts. Conversely, delegating exploration and log analysis to subagents allows only conclusions and evidence to remain in the main conversation.\u003c/p\u003e\n\u003cp\u003eFrom a security perspective, the following principles are important.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eReview Rules and Skills like any other code in the repository.\u003c/li\u003e\n\u003cli\u003eRead Agent or Skill files received from external sources before running them.\u003c/li\u003e\n\u003cli\u003eMinimize permissions for shell commands, network access, and file modification.\u003c/li\u003e\n\u003cli\u003eDo not unconditionally trust commands included in user input or issue descriptions.\u003c/li\u003e\n\u003cli\u003eInclude human approval steps for deployment, deletion, payment, and data migration.\u003c/li\u003e\n\u003cli\u003eDo not store secrets in prompt files; use a separate secret management system.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2\u003e\n\u003ca href=\"#which-feature-should-you-choose\" class=\"anchor\" id=\"which-feature-should-you-choose\"\u003e\u003c/a\u003eWhich Feature Should You Choose?\u003c/h2\u003e\n\u003cp\u003eYou can decide quickly by asking the following questions.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eMust all relevant tasks follow it? → \u003cstrong\u003eRule\u003c/strong\u003e\n\u003c/li\u003e\n\u003cli\u003eIs it a recurring procedure with a beginning and an end? → \u003cstrong\u003eSkill\u003c/strong\u003e\n\u003c/li\u003e\n\u003cli\u003eDoes it require a separate role and independent context? → \u003cstrong\u003eAgent\u003c/strong\u003e\n\u003c/li\u003e\n\u003cli\u003eMust a deterministic command be run before or after a specific event? → \u003cstrong\u003eConsider a Hook\u003c/strong\u003e\n\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eFor example, “Use TypeScript” is a Rule, while “Perform everything from bug reproduction through regression testing” is a Skill. “Read the changes and report only security defects” is suitable for an Agent. Behavior tied to a specific event, such as always running a formatter after editing a file, may be better suited to Hooks.\u003c/p\u003e\n\u003cp\u003eThe most reliable configuration treats the three features as complementary rather than competing. Use Rules to provide shared standards, Skills to execute standard procedures, and Agents to separate context-heavy work such as investigation and review, then supplement them with deterministic validation through tests and Hooks.\u003c/p\u003e\n","tags":["Context Engineering","Claude Code","AI Coding","Agent Skills","Coding Agent"],"faqs":[{"question":"Is the `.claude` folder required in Claude Code?","answer":"It is used to manage project Rules, Skills, and Agents in a standard structure, but it is not required for every instruction. Project instructions can also be placed in `CLAUDE.md` at the root or in `.claude/CLAUDE.md`, while personal settings can be managed under `~/.claude`."},{"question":"What is the difference between Rules and `CLAUDE.md`?","answer":"`CLAUDE.md` is suitable for providing the project's core instructions in a single document. `.claude/rules` is useful for separating files by topic and applying conditions by path, so it helps modularize rules as the project grows."},{"question":"Should the Skill filename be `skill.md` or `SKILL.md`?","answer":"The entry filename that conforms to the official Agent Skills structure is the uppercase `SKILL.md`. It is safest to place a project Skill at `.claude/skills/\u003cskill-name\u003e/SKILL.md`; on case-sensitive operating systems, `skill.md` is treated as a different file."},{"question":"Does a Claude Code Skill run only when invoked by the user?","answer":"Not always. Claude can review a Skill's description and automatically select it for suitable tasks, and the user can also invoke it with `/\u003cskill-name\u003e`. If automatic invocation must be prevented, you can review the `disable-model-invocation` setting in versions that support it."},{"question":"Should I use a Skill or an Agent?","answer":"A Skill is suitable for carrying out repeatable procedures within the current workflow. An Agent is suitable when a separate role and isolated context are needed, such as for large-scale research, test analysis, or code review. Content that should be applied continuously, such as common coding standards, should be separated into a Rule."},{"question":"Can subagents communicate directly with each other or invoke other agents?","answer":"A typical Claude Code subagent works in a separate context and then returns its results to the main agent. Direct collaboration among multiple independent sessions must be distinguished from the separate Agent Teams feature, and you should check its support status and limitations in the version you are using."},{"question":"If I write Rules, will Claude always follow the instructions perfectly?","answer":"No. Rules are instructions provided continuously, but they are not a deterministic enforcement mechanism. They may be missed due to conflicting or ambiguous instructions, so they should be used together with linters, type checking, tests, Hooks, and code review."},{"question":"Is it safe to immediately use a Skill or Agent obtained from an external source?","answer":"It is best not to run it immediately. First review the instructions, shell commands, permitted tools, and scope of network and file access included in the files, and test it with the minimum necessary permissions. You should also check that it does not contain anything that encourages sending confidential information or making dangerous file changes."}],"sources":[{"url":"https://code.claude.com/docs/en/memory","title":"Claude Code documentation: Manage Claude's memory","type":"source"},{"url":"https://code.claude.com/docs/en/skills","title":"Claude Code documentation: Extend Claude with skills","type":"source"},{"url":"https://code.claude.com/docs/en/sub-agents","title":"Claude Code documentation: Create custom subagents","type":"source"},{"url":"https://code.claude.com/docs/en/settings","title":"Claude Code documentation: Claude Code settings","type":"source"}],"images":[{"id":767,"url":"https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6OTgyOSwicHVyIjoiYmxvYl9pZCJ9fQ==--8ba3d33d24232863ea1d744998bca1e2dbb088c6/ai-7c680af1.webp","is_representative":true,"generation_method":"ai_photo","license":"ai_generated","mime_type":"image/webp","translations":{"ko":{"alt":"책상에서 노트북의 개발 워크플로 대시보드를 살펴보는 사람","caption":"개발자가 노트북에서 프로젝트 파일과 자동화 작업 상태를 확인하고 있다.","description":null},"en":{"alt":"Person viewing a development workflow dashboard on a laptop at a desk","caption":"A developer reviews project files and automation task statuses on a laptop.","description":null},"ja":{"alt":"デスクでノートパソコンの開発ワークフローダッシュボードを見る人","caption":"開発者がノートパソコンでプロジェクトファイルと自動化タスクの状態を確認している。","description":null},"es":{"alt":"Persona viendo un panel de flujo de desarrollo en un portátil sobre un escritorio","caption":"Un desarrollador revisa archivos del proyecto y estados de tareas automatizadas en un portátil.","description":null},"id":{"alt":"Seseorang melihat dasbor alur kerja pengembangan di laptop pada meja","caption":"Seorang pengembang memeriksa berkas proyek dan status tugas otomatis di laptop.","description":null},"pt":{"alt":"Pessoa visualizando um painel de fluxo de desenvolvimento em um notebook","caption":"Um desenvolvedor verifica arquivos do projeto e o status de tarefas automatizadas no notebook.","description":null},"zh-hant":{"alt":"坐在書桌前查看筆電開發工作流程儀表板的人","caption":"開發者正在筆電上檢查專案檔案與自動化任務狀態。","description":null},"de":{"alt":"Person betrachtet ein Dashboard für Entwicklungsabläufe auf einem Laptop am Schreibtisch","caption":"Ein Entwickler prüft Projektdateien und den Status automatisierter Aufgaben auf einem Laptop.","description":null}}},{"id":768,"url":"https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6OTgzNSwicHVyIjoiYmxvYl9pZCJ9fQ==--458d876e5a3cb0d4581f0909c6198e47789eda8b/ai-54d6eb4e.webp","is_representative":false,"generation_method":"ai_image","license":"ai_generated","mime_type":"image/webp","translations":{"ko":{"alt":"폴더, 필터, 자동화 단계, AI 작업 공간, 보안 및 검증 흐름을 연결한 워크플로 다이어그램","caption":"규칙과 자동화 단계가 보안 계층을 거쳐 테스트와 검증으로 이어지는 구조를 보여준다.","description":null},"en":{"alt":"Workflow diagram linking folders, filters, automation steps, an AI workspace, security, and validation","caption":"Rules and automated steps flow through a security layer into testing and validation.","description":null},"ja":{"alt":"フォルダー、フィルター、自動化工程、AI作業環境、セキュリティ、検証を結ぶワークフロー図","caption":"ルールと自動化工程がセキュリティ層を経てテストと検証へ進む構成を示している。","description":null},"es":{"alt":"Diagrama de flujo con carpetas, filtros, automatización, espacio de IA, seguridad y validación","caption":"Las reglas y los pasos automatizados pasan por una capa de seguridad hasta las pruebas y la validación.","description":null},"id":{"alt":"Diagram alur folder, filter, tahap otomatisasi, ruang kerja AI, keamanan, dan validasi","caption":"Aturan dan tahapan otomatis mengalir melalui lapisan keamanan menuju pengujian dan validasi.","description":null},"pt":{"alt":"Diagrama de fluxo com pastas, filtros, automação, ambiente de IA, segurança e validação","caption":"Regras e etapas automatizadas passam por uma camada de segurança até os testes e a validação.","description":null},"zh-hant":{"alt":"連結資料夾、篩選器、自動化步驟、AI 工作區、安全與驗證的流程圖","caption":"規則與自動化步驟經過安全層後，進入測試與驗證流程。","description":null},"de":{"alt":"Workflow mit Ordnern, Filtern, Automatisierung, KI-Arbeitsplatz, Sicherheit und Validierung","caption":"Regeln und automatisierte Schritte führen über eine Sicherheitsebene zu Tests und Validierung.","description":null}}}],"published_at":"2026-08-19T16:14:05+09:00","updated_at":"2026-08-19T16:14:05+09:00","license":"cc_by","translation_status":"reviewed","available_locales":["ko","en","ja","es"],"data_locales":["ko","en","ja","es","id","pt","zh-hant","de"],"url":"https://injoys.com/en/articles/claude-code-rules-skills-agents-guide"}