생산 준비가 완료된 Claude 코드 기술을 구축하는 방법

1. Introduction The Claude Code Skill ecosystem is expanding rapidly. As of March 2026, the anthropics/skills repository reached over 87,000 stars on GitHub and more people are building and sharing Skills every week. How can we build a Skill from scratch in a structured way? This article walks through designing, building, and distributing a Skill from scratch. I’ll use my own experience shipping an e-commerce review Skill (Link) as a running example throughout. 2. What Is a Claude Skill? A Claude skill is a set of instructions that teaches Claude how to handle specific tasks or workflows. Skills are one of the most powerful ways to customize Claude to your specific needs. Skills are built around progressive disclosure. Claude fetches information in three stages: - Metadata (name + description): Always in Claude’s context. About 100 tokens. Claude decides whether to load a Skill based on this alone. - SKILL.md body: Loaded only when triggered. - Bundled resources (scripts/, references/, assets/): Loaded on demand when needed. With this structure, you can install many Skills without blowing up the context window. If you keep copy-pasting the same long prompt, just turn it into a Skill. 3. Skills vs MCP vs Subagents Before building a Skill, let me walk you through how Skills, MCP, and Subagents are different, so you can make sure a Skill is the right choice. - Skills teach Claude how to behave — analysis workflows, coding standards, brand guidelines. - MCP servers give Claude new tools — sending a Slack message, querying a database. - Subagents let Claude run independent work in a separate context. An analogy that helped me: MCP is the kitchen — knives, pots, ingredients. A Skill is the recipe that tells you how to use them. You can combine them. Sentry’s code review Skill, for example, defines the PR analysis workflow in a Skill and fetches error data via MCP. But in many cases a Skill alone is enough to start. 4. Planning and Design I jumped straight into writing SKILL.md the first time and ran into problems. If the description is not well designed, the Skill will not even trigger. I’d say spend time on design before you write the prompts or code. 4a. Start with Use Cases The first thing to do is define 2–3 concrete use cases. Not “a helpful Skill” in the abstract, but actual repetitive work that you observe in practice. Let me share my own example. I noticed that many colleagues and I were repeating the same monthly and quarterly business reviews. In e-commerce and retail, the process of breaking down KPIs tends to follow a similar pattern. That was the starting point. Instead of building a generic ‘data analysis Skill,’ I defined it like this: “A Skill that takes order CSV data, decomposes KPIs into a tree, summarizes findings with priorities, and generates a concrete action plan.” Here, it is important to imagine how users will actually phrase their requests: - “run a review of my store using this orders.csv” - “analyze last 90 days of sales data, break down why revenue dropped” - “compare Q3 vs Q4, find the top 3 things I should fix” When you write concrete prompts like these first, the shape of the Skill becomes clear. The input is CSV. The analysis axis is KPI decomposition. The output is a review report and action plan. The user is not a data scientist — they are someone running a business and they want to know what to do next. That level of detail shapes everything else: Skill name, description, file formats, output format. Questions to ask when defining use cases: - Who will use it? - In what situation? - How will they phrase their request? - What is the input? - What is the expected output? 4b. YAML Frontmatter Once use cases are clear, write the name and description. It decides whether your Skill actually triggers. As I mentioned earlier, Claude only sees the metadata to decide which Skill to load. When a user request comes in, Claude decides which Skills to load based on this metadata alone. If the description is vague, Claude will never reach the Skill — no matter how good the instructions in the body are. To make things trickier, Claude tends to handle simple tasks on its own without consulting Skills. It defaults to not triggering. So your description needs to be specific enough that Claude recognizes “this is a job for the Skill, not for me.” So the description needs to be somewhat “pushy.” Here is what I mean. # Bad — too vague. Claude does not know when to trigger. name: data-helper description: Helps with data tasks # Good — specific trigger conditions, slightly "pushy" name: sales-data-analyzer description: > Analyze sales/revenue CSV and Excel files to find patterns, calculate metrics, and create visualizations. Use when user mentions sales data, revenue analysis, profit margins, churn, ad spend, or asks to find patterns in business metrics. Also trigger when user uploads xlsx/csv with financial or transactional column headers. The most important thing is being explicit about what the Sk