Claude Skills Beginner's Guide: Concepts, Structure, and Best Practices (with Skills Recommendations)

As LLM applications evolve from simple conversation to intelligent Agents capable of autonomous planning and execution, mastering Claude Code Skills has become crucial for developers building efficient engineering systems in terminal environments. As an in-depth Claude Code Skills best practices guide and comprehensive tutorial, this article aims to help developers bridge the gap between natural language and local toolchains, transforming scattered interactions into reusable, maintainable productivity components. We will deeply analyze the SKILL.md-centric configuration system, providing verified SKILL.md configuration templates and a detailed SKILL.md syntax reference. We will explain how the synergy between Frontmatter metadata and Markdown instruction bodies achieves precise mapping from semantic understanding to local script execution. Beyond the basics of building Claude Code automation workflows, we focus on advanced topics determining execution quality: using Claude Skills prompt engineering to optimize adherence to complex instructions, designing efficient and unambiguous Claude Skills trigger commands, and essential Claude Code permission setting strategies for file I/O and system operations. Additionally, we summarize practical Claude Skills debugging techniques to help you quickly locate the root causes of routing failures or execution deviations encountered during development. By systematically studying this guide, you will be able to encapsulate repetitive tasks like code review and test generation into deterministic engineering capabilities, truly unleashing the full potential of Claude Code as a next-generation coding assistant.

What are Claude Code Skills?

In the Claude Code CLI environment, Skills are a user-defined custom tool mechanism. They are not merely preset Prompts, but executable units structured via Markdown files, allowing Claude to invoke specific scripts, follow strict engineering standards, or execute complex multi-step workflows within the terminal environment.

Unlike standard conversational interactions, Skills transform Claude from a passive Q&A bot into an Agent capable of actively executing tasks. By configuring Skills, developers can encapsulate repetitive engineering tasks (such as code review, automated test generation, or writing documentation in specific formats) into standard capabilities, allowing Claude to invoke this custom logic just like calling built-in commands.

Core Workflow: From Definition to Triggering

The process of creating a Skill follows a standard "define-register-call" lifecycle. Claude Code automatically scans configurations in specified directories and injects them into the system context, making them directly triggerable via natural language.

Here is the standard three-step process for building a Skill:

1. Create Directory Structure
   Establish a storage location in the project root directory or global configuration.

    mkdir -p .claude/skills/my-custom-skill

1. Define Logic (SKILL.md)
   Create the core description file SKILL.md in the directory. This file contains two parts: metadata (Frontmatter) telling Claude when to use the Skill, and specific instructions telling Claude how to execute the task.

    ---
    name: generate-unit-tests
    description: Generates Jest unit tests for a given React component file.
    ---
    # Instructions
    1. Analyze the component props and logic.
    2. Create a test file named [Component].test.tsx.
    3. Cover edge cases and rendering states.

1. Natural Language Trigger
   No need to memorize complex CLI parameters; simply describe your intent in the Claude Code terminal to activate it:
   > "Help me generate unit tests for Button.tsx."

Why are Skills Needed?

The core value of Skills lies in Engineering and Determinism.

• Context Persistence: In conversations, complex instructions are easily lost as the context window slides. Skills solidify best practices (such as "always use TypeScript strict mode") in files, ensuring every execution follows the same standards.
• Toolchain Integration: Skills can be used in conjunction with Python or Bash scripts in the scripts/ directory, allowing Claude to call local compilers, Linters, or deployment tools, bridging the "last mile" from "generating code" to "verifying code".
• Semantic Routing: Claude automatically judges whether the current task requires calling a specific Skill based on the description in SKILL.md. This means you don't need to explicitly specify the tool name; the Agent automatically selects the most appropriate tool to solve the problem based on semantics.

Core Structure: Detailed Explanation of SKILL.md Syntax and Configuration

In the skill system of Claude Code, SKILL.md is not only the core of configuration files but also the Single Source of Truth for defining Agent behavior. Unlike ordinary Prompt Engineering, Claude Code CLI requires SKILL.md to follow a strict syntax structure in order to correctly parse the skill's metadata and execution logic. Any formatting deviation (such as missing separators or YAML indentation errors) may cause the CLI to fail to recognize the skill.

A standard SKILL.md file consists of two main parts, which must be strictly distinguished using YAML separators. This structural design borrows from the Frontmatter pattern of static site generators (such as Jekyll or Hugo), decoupling "routing logic" from "execution instructions".

File Structure Overview

The parsing of SKILL.md relies on the sequential arrangement of the following two core components:

1. Metadata Configuration (Frontmatter):
   Located at the top of the file, a YAML area wrapped by three dashes ---. This part is the "control layer" of the skill, defining the skill's identity (ID), name, and the semantic index of when Claude should invoke the skill.
2. Instruction Body (Body):
   Located after the second ---, comprising all Markdown content. This part is the "execution layer" of the skill, containing specific Prompt instructions, step descriptions, and examples, guiding Claude on how to specifically operate after the skill is triggered.

The following is the standard skeleton structure of the file:

---
# [Frontmatter Area]
# Uses YAML syntax
# Defines skill ID, name, description, and input parameters
# Claude Code CLI relies on this area to decide whether to "wake up" the skill
---

# [Body Area]
# Uses Markdown syntax
# Contains detailed system instructions (System Prompt)
# Defines specific execution steps, considerations, and Few-Shot examples

Understanding this structure is crucial: Frontmatter determines the "Discovery" of the skill, while the Body determines the "Execution" quality of the skill. In actual development, developers must ensure the file starts with --- and correctly closes the metadata area, otherwise the entire skill will be treated as invalid text.

Metadata Configuration (Frontmatter)

The top of the SKILL.md file must contain a YAML-formatted Frontmatter area, wrapped by three dashes ---. This is the entry point for Claude Code to recognize and index skills; any syntax error will cause the skill to fail to load.

In this area, you define the "control plane" information of the skill. Unlike traditional code comments, this metadata is directly injected into Claude's System Prompt, determining whether Claude will "wake up" the skill when facing user instructions.

Core Fields Explained

For a standard Claude Code Skill, the following fields are required or strongly recommended:

• name (Required): The unique identifier of the skill.
• • Specification: Only lowercase letters, numbers, and hyphens (kebab-case) are allowed, and the length is usually limited to 64 characters.
  • Restrictions: Avoid using reserved words (such as "anthropic", "claude"), and it cannot contain XML tags.
• description (Required): The semantic index of the skill. This is the sole basis for Claude to judge "when to call this skill".
• • Mechanism: When a user inputs an instruction, Claude retrieves the description of all installed skills via semantic matching in the background.
  • Best Practice: Use the third person to describe specific scenarios (e.g., "Use this skill when..."), rather than a simple list of functions.
• input_schema (Optional): Although Claude Code can infer parameters through natural language instructions, explicitly defining a JSON Schema improves the accuracy of parameter extraction when strict structured input (such as API calls) is required.

Configuration Example

The following is a standard Frontmatter configuration example, showing a skill definition used to generate Git commit messages:

---
name: git-commit-generator
description: Analyzes staged changes and generates a commit message following Conventional Commits standards. Use this skill when the user asks to "commit code", "save work", or "write a commit message" based on current diffs.
version: 1.0.0
---

Key Considerations

1. Semantic Indexing and Token Budget
   The description field is crucial, acting as the skill's semantic index. Claude does not read the entire body of SKILL.md every time; instead, it scans the description first. If the description is too vague, the skill will never be triggered; if the description is too long (e.g., exceeding several thousand characters), it not only wastes the Context Window but may also cause the skill to be ignored by the system. In the Claude Code environment, descriptions of all skills consume the character budget of the System Prompt, so be sure to keep them concise.
2. ID Conflicts and Namespaces
   The name field must be globally unique within your local environment. Although Claude Code currently allows local overrides, to avoid confusion during debugging, it is recommended to adopt a naming convention like team-skill-name within development teams.
3. Syntax Strictness
   YAML is very sensitive to indentation and formatting. Ensure there is a colon and a space (: ) after field names, and do not use the --- delimiter outside the Frontmatter area to prevent the parser from misjudging the end of the section.

Instruction Body and Prompt Engineering

The content following the YAML frontmatter in the SKILL.md file is the Instruction Body. This part is essentially the "System Prompt" for the Skill; it defines how Claude should think, process input, and generate output when the Skill is triggered.

Writing an efficient instruction body is not just about describing the task in natural language; it requires applying Prompt Engineering techniques optimized for the Claude model. When building a Skill, it is recommended to adopt a structured prompting strategy to ensure execution determinism and robustness.

Structure and Delimiters

The Claude model is highly sensitive to XML-style tags. In the instruction body, avoid using large blocks of plain text descriptions; instead, use delimiters to clearly separate different logical modules (such as background, rules, steps, and output format).

For example, use <rules> to wrap constraints and <output_format> to define the return structure. This not only helps the model accurately parse instructions but also prevents "instruction drift" when dealing with complex contexts.

Few-Shot Prompting

Providing specific input and output examples (Few-Shot Examples) in the instruction body is the most direct way to improve Skill performance. Compared to abstract descriptions, examples allow the model to intuitively understand the expected tone, format, and depth.

Chain of Thought

For Skills involving logical judgment or multi-step operations, you should explicitly require the model to "think step-by-step" before generating the final result. You can include a <thinking> section in the instruction, asking the model to analyze the characteristics of the input data before executing the operation. This technique can significantly reduce the hallucination rate when the model processes complex code reviews or data transformations.

Case Comparison: Git Commit Message Generator

To visually demonstrate the value of prompt engineering, the following compares two instruction writing styles for a "Git Commit Message Generator" Skill:

❌ Weak Instruction
This writing style relies too heavily on the model's default behavior, easily leading to inconsistent output formats or including unnecessary conversational text.

Please help me write a commit message based on the current git diff.
Make it professional and not too long.

✅ Robust Instruction
This writing style ensures high quality and consistency of output through role setting, clear constraints (Conventional Commits specification), structured tags, and few-shot examples.

Role: You are a code audit expert who strictly adheres to the Conventional Commits specification.

<rules>
1. Format must be: <type>(<scope>): <subject>
2. type is limited to: feat, fix, docs, style, refactor, test, chore
3. subject must use imperative mood and not exceed 50 characters
4. Output the commit message directly; do not include any explanation or markdown code block markers
</rules>

<examples>
Input: "Fixed typos in the readme file"
Output: docs(readme): fix typo in installation guide

Input: "Added API interface for user login function"
Output: feat(auth): add user login api endpoint
</examples>

<instruction>
Analyze the incoming git diff content, identify the core intent of the changes, and generate a commit message that complies with the above rules.
</instruction>

By writing the instruction body in this engineered way, Claude can be transformed from a general conversational assistant into an automated tool that precisely executes specific development tasks.

Permissions and Security Settings (Permissions)

When building Claude Skills, security is often an underestimated aspect. Since Claude Code is a CLI tool running in the local terminal, it inherits the current user's system permissions. This means a poorly designed Skill can theoretically perform any operation you can perform yourself, including reading sensitive configuration files (such as .env or ~/.ssh) and executing destructive file system commands.

To ensure a Skill runs within security boundaries, developers must clearly define its "scope of action" (Scope) during the design phase.

Permission Boundaries and File System Access

By default, Claude Code can access files in its startup directory and its subdirectories. When your Skill involves file writing or Shell command execution, be sure to explicitly limit its operational scope in the instructions within SKILL.md.

For example, if you are building a log analysis tool, you should not grant it permission to scan the entire disk; instead, you should explicitly constrain it in the Prompt:

"You are only allowed to read files within the ./logs/ directory. Do not access or modify files in the parent directory or other system paths."

Although this natural language constraint is not a physical firewall, combined with Claude's alignment mechanism, it can effectively prevent out-of-bounds operations caused by model "hallucinations."

Tool Whitelist (Allowed Tools)

In more complex scenarios, you can restrict the specific tools a Skill can call through configuration. According to the Claude Code documentation, developers can use the allowed-tools field to constrain a Skill's capabilities.

• Principle of Least Privilege: If a Skill only needs to read code, it should not be granted Edit or Bash execution permissions.
• Isolation of Sensitive Operations: For Skills involving database migrations or production environment deployments, it is recommended to configure additional approval hooks via security-hooks.json to enforce manual confirmation for critical steps.

⚠️ Warning: Risks Regarding Shell Commands

When granting a Skill the ability to execute Shell commands (e.g., via the Bash tool), please exercise extreme caution.
* Avoid Broad Instructions: Never use vague instructions like "Clean up the directory", as the model might misunderstand and execute rm -rf *.
* Limit Directories: Always enforce in the instructions that operations are limited to specific subdirectories (e.g., Only execute cleanup commands inside ./temp/).
* Sandbox Testing: Before applying a Skill containing write operations to important projects, be sure to test it in an isolated Git branch or temporary directory to prevent accidental data loss.

By clearly defining permission boundaries in SKILL.md and utilizing allowed-tools for hard constraints, you can ensure that Claude Code is both a powerful assistant and a secure collaborator.

Practical Tutorial: Building a "Code Review" Skill from Scratch

Combining theory with practice is the fastest way to master Claude Skills. In this section, we will demonstrate the complete development process by building a practical "Code Reviewer." The goal of this Skill is: when you ask Claude to review a file, it can automatically provide structured feedback based on preset best practices (such as PEP 8, error handling standards) rather than giving generic responses.

We will build it following these four steps:

Step 1: Create the File Structure

Claude Code identifies Skills through a specific directory structure. We need to create a folder containing SKILL.md in the project root directory (or the global configuration directory).

Execute the following commands in your terminal to create the directory and file for storing the Skill:

mkdir -p .claude/skills/reviewer
touch .claude/skills/reviewer/SKILL.md

Note: The Skill's folder name (such as reviewer) is usually related to its function, but this is mainly for organizational management. What Claude truly recognizes is the metadata inside the SKILL.md file.

Step 2: Write the Skill Definition Code

Next, we need to define the metadata and instruction logic in SKILL.md. The metadata tells Claude what this Skill does, while the instruction body defines how it performs the task.

Copy the following code entirely into the .claude/skills/reviewer/SKILL.md file:

---
name: code-reviewer
description: Reviews code for style consistency, security risks, and potential bugs. Use this when the user asks to review, audit, or check code quality.
---

# Code Reviewer Instructions

You are a strict code review assistant. Your goal is to ensure code quality and maintainability.

## Review Process
When the user provides code or asks you to review a file, follow these steps:

1.  Security Check: Look for hardcoded credentials, SQL injection vulnerabilities, or unsafe input handling.
2.  Style & Logic: Check for adherence to standard idioms (e.g., Python PEP 8) and logical flaws (off-by-one errors, resource leaks).
3.  Refactoring: Suggest specific improvements for readability.

## Output Format
Please format your response as follows:
- Summary: A one-sentence overview of the code quality.
- Critical Issues: (If any) Bullet points of bugs or security risks.
- Suggestions: Actionable improvements with code snippets showing "Before" vs. "After".

## Constraints
- Be concise. Do not explain basic syntax unless there is an error.
- If the code is perfect, reply with "LGTM (Looks Good To Me) ✨".

Step 3: Trigger the Skill in the Terminal

After saving the file, Claude Code will automatically detect the newly added Skill. Now, you can invoke it directly using natural language without entering complex command parameters.

Assuming you have a file named main.py in your project, you can enter the following in the terminal:

claude "Review main.py for any potential bugs"

Or more simply:

claude "Check the code style in main.py"

Claude will match your input ("Review", "Check code") with the description we defined in the metadata, thereby activating the code-reviewer Skill.

Step 4: Verify the Output Results

If configured correctly, Claude will no longer give generic answers but will strictly follow the Output Format we defined in SKILL.md. You should see structured output similar to the following:

Summary: The code in main.py is functional but contains a potential file handle leak and violates PEP 8 naming conventions.

Critical Issues
* Line 12: open('data.txt', 'r') is used without a context manager (with statement), which may leave the file handle open if an error occurs.

Suggestions
* Resource Management: Use with open(...) to ensure the file is closed automatically.
* Naming: Rename variable N to retry_count to allow for better readability.

In this way, you not only standardize Claude's output format but also force it to focus on the code quality dimensions you care about most (such as security and style), thereby transforming a general-purpose AI into a customized development tool.

Debugging & Troubleshooting

When building Claude Skills, the most common frustration often stems from "silent failures"—you define a perfect Skill, but in actual conversation, Claude seems completely unaware of its existence, or although it calls the Skill, the execution result diverges significantly from expectations.

Since the trigger mechanism of Skills relies on the semantic understanding of Large Language Models (LLMs) rather than rigid code calls, the debugging process requires combining environment configuration checks with Prompt Engineering. Below is a troubleshooting checklist and solutions for common issues.

Troubleshooting Checklist

When you find that a Skill is not working properly, follow these steps to troubleshoot one by one:

1. Verify File Path and Structure
   Ensure your SKILL.md file is located in the .claude/skills/ folder under the project root directory. Claude Code scans this directory upon startup. If the file is located deep within subfolders or the naming does not comply with standards, it may not be loaded.
   > Action: Restart the Claude Code terminal session to force a configuration reload.
2. Confirm if the Skill is Loaded
   Directly ask Claude in the conversation: "What Skills are available?".

• • If your Skill does not appear in the list: It indicates file parsing failure or a path error. Check if the YAML header format in SKILL.md is correct (e.g., indentation errors or missing necessary fields).
  • If the Skill is in the list but never triggers: It indicates the issue lies with the "trigger description" or context limitations.

1. Check the Length and Clarity of the Description Field
   Claude "perceives" available Skills by injecting the description of all of them into the System Prompt. If your description is too obscure, or if the sum of all Skill descriptions exceeds the character budget, it may cause the Skill to be ignored.

• • According to relevant research, Claude Code has a limit on the character count for Skill descriptions (defaulting to around 15,000 characters). If the limit is exceeded without warning, Skills at the end of the list may not only fail to trigger but might not even be "seen" by the model.
  • Solution: Streamline the description field, remove redundant adjectives, and focus on defining "what specific task this Skill solves". If you must load a large number of Skills, try increasing the budget via environment variables (such as SLASHCOMMANDTOOLCHARBUDGET).

Common Issues and Fix Strategies

1. Skill Not Triggering

Even if the Skill is loaded, Claude may prefer to use built-in capabilities rather than calling your tool.

• Cause: Vague trigger conditions. For example, a Skill described as "helps write code" is hard to distinguish from Claude's core capabilities.
• Fix: Use unique and specific keywords in the description. For example, change "code formatting tool" to "tool used when the user requests 'perform enterprise-level formatting'".
• Forced Testing: During the development phase, do not rely on natural language automatic inference. Try using explicit instructions for "isolation testing," such as directly telling Claude: "Use [Skill Name] to handle this issue." If the forced call succeeds but automatic triggering fails, it means the functionality is normal, and only the description needs optimization.

2. Misinterpretation of Execution Instructions

The Skill triggers successfully, but the output does not meet expectations (e.g., ignoring certain parameters or formatting errors).

• Cause: Instructions lack constraints or examples (Few-Shot prompting).
• Fix: Add specific Examples in the body section (Instruction) of SKILL.md. Showing "what the input is" and "what the expected output is" is much more effective than pure text descriptions.
• Context Management: Ensure the Skill has acquired enough information. If the Skill needs to process file content, ensure the file has been read into the context when triggered, or include steps to read the file within the Skill itself.

3. "Deafness" in Automated Workflows

In complex long conversations, Claude may "forget" to use Skills.

• Observation: Some developers have pointed out that even if the Skill exists in the system prompt, Claude sometimes still ignores them and attempts to complete the task manually.
• Fix: For critical workflows, you can explicitly mention the existence of the Skill in the Prompt, or use Project-level configuration (such as CLAUDE.md) to prompt the model to "prioritize checking and using tools under .claude/skills/ when encountering category X issues".

Viewing Logs and Debugging Information

Although the Claude Code CLI interface is relatively minimalist, you can diagnose issues by observing its "thought process" during debugging. When Claude decides to call a Skill, it usually outputs a piece of analysis text first (e.g., "I will use the test-generator skill...").

• If it outputs this text but then reports an error, it is usually an internal script execution error within the Skill (insufficient permissions or missing dependencies).
• If it does not output this text at all and directly gives a plain text response, it falls into the "trigger failure" category mentioned above, and you need to return to step 3 to optimize the description.

By establishing a debugging loop of "Write -> Restart -> Query List -> Force Call -> Optimize Description", you can significantly reduce uncertainty when building Skills.

Advanced Techniques: Building Automation Workflows

Once developers have mastered basic SKILL.md authoring, the next step is to transform isolated instructions into reusable automation workflows. In complex engineering scenarios, relying solely on natural language conversation is often inefficient; we need to use Skill Chaining and precise context management to maintain Claude's stability and accuracy when handling long-chain tasks.

Skill Chaining

"Skill Chaining" refers to breaking down a complex task into multiple atomic Skills, where the output of the preceding Skill serves as the input for the subsequent Skill. This pattern not only reduces the complexity of individual Prompts but also improves debugging observability.

For example, when refactoring legacy code, the following chain can be designed:

1. Analysis Skill (analyze-complexity): Uses only grep and ls to scan directories and output a list of high-complexity functions, without making any modifications.
2. Refactor Skill (refactor-method): Receives specific function names and applies the Single Responsibility Principle to split them.
3. Test Skill (gen-unit-test): Generates coverage tests for the modified code.

In practice, you can define an "Orchestrator" Skill to chain these steps together. For instance, creating a refactor-pipeline Skill with core instructions that explicitly require calling the aforementioned tools or sub-instructions in sequence ensures deterministic data flow.

Context Management and Token Optimization

When building a Skill, the biggest pitfall is dumping all background information directly into SKILL.md. This not only wastes Tokens but also dilutes Claude's attention regarding core instructions.

Best Practice: Progressive Disclosure
According to the Claude Code documentation, SKILL.md should remain lightweight (recommended under 500 lines). Complex domain knowledge should be split into independent reference files, with Claude guided to read them only when necessary.

• Bad Pattern: Including a 2000-line full database schema definition in SKILL.md.
• Good Pattern: Keeping only a directory index in SKILL.md and instructing: "When the user asks about the orders table, please read docs/schema/orders.md."

Furthermore, utilizing the allowed-tools field can force a Skill to use only low-cost tools. For example, for a Skill that only needs to read configuration files, explicitly restricting it to use only Read and Grep prevents Claude from attempting to run expensive build commands or modify files, thereby reducing accidental Token consumption while ensuring security.

Decision Guide: Ad-hoc Prompt vs. Formal Skill

Not all tasks warrant encapsulation as a Skill. Premature optimization can lead to increased maintenance costs. The following comparison table can help you determine when to invest time in building a formal Skill:

When you find yourself or team members repeatedly pasting the same "notes" or "coding standards" to Claude, that is the optimal time to solidify it into a Skill.

3 Practical Skills Recommended to Build

For developers just starting with Claude Skills, the most effective way to learn is to build tools that can immediately solve daily pain points. The following three Skills can not only significantly improve development efficiency but also cover the core patterns of Skills development: context management, file operations, and constraint enforcement.

1. The Documentation Updater

The asset most prone to expiration during development is documentation. This Skill aims to automate the maintenance of README or API documentation, ensuring documents stay synchronized with code changes.

• Core Value: Eliminates the common debt of "code changed, documentation didn't," especially suitable for projects with frequent API interface changes.
• Trigger:
  Clearly define the trigger scenario in the description of SKILL.md, for example: "Use this Skill when the user has modified code logic or function signatures and requests to update relevant documentation."
• Core Instruction:

1. 1. Read Context: Instruct Claude to read the currently modified source code files and the target documentation file (e.g., README.md).
   2. Diff Analysis: Compare the latest logic in the code (parameters, return values, flow) with the old descriptions in the documentation.
   3. Incremental Update: Only rewrite inconsistent paragraphs, keeping the format and tone of the rest of the document unchanged.
   4. Verify: Output the updated document content for user confirmation before writing.

2. The Test Generator

Writing boilerplate test code is often tedious and repetitive. This Skill utilizes Claude's logical analysis capabilities to quickly generate high-coverage test suites for specified modules.

• Core Value: Lowers the psychological barrier to writing tests and quickly establishes Baseline Coverage.
• Trigger:
  Defined as: "Use when the user provides a source file and requests unit test generation or supplementary edge case tests."
• Core Instruction:

1. 1. Dependency Identification: Analyze libraries referenced by the source file and the project's existing test frameworks (e.g., Jest, Pytest, JUnit).
   2. Logic Breakdown: Identify branch logic, boundary conditions, and exception handling paths in the code.
   3. Code Generation: Generate test code that conforms to the project's existing style.
   4. Self-Correction (Advanced): If scripts/run_tests.sh is configured, the instruction can include a step to "attempt to run tests after generation and automatically fix test code based on error messages."

3. The Convention Enforcer

Although Linters can solve syntax issues, team-specific naming habits, architectural layering principles, or "best practices" are often difficult to enforce via static tools. This Skill acts as a tireless Code Reviewer.

• Core Value: Intercepts design patterns that do not conform to team conventions before code submission, reducing the burden of manual Review.
• Trigger:
  Defined as: "Use when the user requests a review of code style, variable naming, or architectural compliance."
• Core Instruction:

1. 1. Load Baseline: Explicitly instruct Claude to read references/style_guide.md (requires placing the team's specification document in this path beforehand).
   2. Line-by-Line Review: Compare the user-provided code with the clauses in the specification document.
   3. Structured Output: Don't just say "this line is wrong," but output a list containing "violation location," "violated clause," and "suggested modification."
   4. Ignore Irrelevant Items: Explicitly instruct to ignore standard syntax errors (assuming the IDE has handled them) and focus on readability and architectural specifications.

Build Suggestion: It is recommended to place style_guide.md in the references/ directory rather than writing it directly into SKILL.md. This not only keeps the instruction file concise but also facilitates independent maintenance of the specification document by the team, reflecting best practices regarding referenced file separation in the Claude Skills architecture.