{"slug": "claude-code-skills-guide-how-to-automate-your-development-workflow", "title": "Claude Code Skills Guide: How to Automate Your Development Workflow", "summary": "Claude Code Skills have evolved from single .md files to directory-based structures with formal frontmatter, enabling developers to automate repeatable tasks and enforce engineering conventions. The new format supports supporting files, invocation control, and has become an open standard at agentskills.io. Skills package instructions, resources, and tool permissions for Claude to execute when invoked, improving consistency across teams.", "body_md": "**Claude Code** is a terminal-based coding agent that can automate the repetitive parts of your development workflow, not just generate code.\n\nThis article isn't about installation or basic usage. It's written for developers already using Claude Code who want to learn **how to design Skills that deliver meaningful automation and consistency in real-world projects**.\n\nAmong Claude Code's features, **Skills** are the main way to define how Claude should handle repeatable tasks and follow your project's engineering conventions. In this article, we'll look at how they keep code quality consistent across a team.\n\nUpdated July 2026— The January version of this guide described Skills as single`.md`\n\nfiles in`.claude/commands/`\n\n. Skills have since become directory-based (`.claude/skills/<name>/SKILL.md`\n\n), adopted a formal frontmatter specification, and become an open standard at[agentskills.io]. This revision reflects the current format. The examples come from skills I actually use in real projects.\n\nIn Claude Code, a **Skill** is a directory containing a `SKILL.md`\n\nfile with the instructions, resources, and execution steps Claude follows when the skill is invoked. For personal and project skills, the directory name becomes the command name: `.claude/skills/code-review/SKILL.md`\n\ngives you `/code-review`\n\n. (Plugin skills are namespaced by the plugin name: `/my-plugin:review`\n\n.)\n\nThe important distinction is this: **a Skill is not an independent agent.** It packages instructions, resources, and tool permissions—Claude, or you, decides when to invoke it, unless the frontmatter restricts invocation.\n\nIf you remember \"custom slash commands\"(`.claude/commands/*.md`\n\n): they've been merged into Skills. A file at`.claude/commands/deploy.md`\n\nand a skill at`.claude/skills/deploy/SKILL.md`\n\nboth create`/deploy`\n\n, and old command files keep working. Skills are the recommended format—they add supporting files, invocation control, and a richer frontmatter. If both define the same name, the skill wins.\n\nSkills can be managed per-project or globally across your machine:\n\n| Scope | Location | Applies to |\n|---|---|---|\nPersonal |\n`~/.claude/skills/<name>/SKILL.md` |\nAll your projects |\nProject |\n`.claude/skills/<name>/SKILL.md` |\nThis project only (shared via Git) |\nPlugin |\n`<plugin>/skills/<name>/SKILL.md` |\nWherever the plugin is enabled |\n\nThe file must be named exactly `SKILL.md`\n\n, and a skill is a *directory*, not a single file. That directory can carry supporting material that loads only when needed:\n\n```\ncode-review/\n├── SKILL.md          # required: frontmatter + instructions\n├── references/       # detailed docs, loaded on demand\n├── scripts/          # executable helpers (run, not loaded)\n└── assets/           # templates, static resources\n```\n\nFor me, this is the most useful improvement over the old single-file format. Keep `SKILL.md`\n\nunder ~500 lines and push heavy reference material into `references/`\n\n—the body stays in context for the whole session once loaded, so every line has a recurring token cost.\n\n```\n---\nname: code-review\ndescription: Review code against .claude/rules/ for architecture and convention violations.\nargument-hint: \"[path] [--staged|--branch] [--fix]\"\nallowed-tools: Read Glob Grep Bash(git *)\n---\n```\n\n☝️ The `description`\n\nfield is still **critical**. Claude normally sees the names and descriptions of available Skills and uses that metadata to decide which one is relevant. If you say \"review my code,\" that request gets matched against skill descriptions—so yours must contain **clear, searchable keywords**.\n\nOne distinction worth knowing before the table: the Agent Skills standard defines the portable core fields (`name`\n\n, `description`\n\n, `license`\n\n, `compatibility`\n\n, `metadata`\n\n, `allowed-tools`\n\n). The rest below—`argument-hint`\n\n, `disable-model-invocation`\n\n, `user-invocable`\n\n, `context`\n\n—are **Claude Code extensions**. The table covers the fields used in this guide, not every option Claude Code supports (there are also `when_to_use`\n\n, `model`\n\n, `paths`\n\n, `hooks`\n\n, and more):\n\n| Field | What it does |\n|---|---|\n`name` |\nDisplay name (defaults to the directory name) |\n`description` |\nAuto-invocation trigger. Keep it ≤1,024 chars for cross-tool compatibility |\n`argument-hint` |\nAutocomplete hint shown after `/name`\n|\n`allowed-tools` |\nTools Claude may use without permission prompts while the skill runs (space-separated per the standard; Claude Code also accepts commas) |\n`disable-model-invocation` |\n`true` = only you can trigger it; Claude never auto-invokes |\n`user-invocable` |\n`false` = hidden from the `/` menu; Claude-only background knowledge |\n`context: fork` |\nRun the skill in an isolated subagent context |\n\nTwo of these encode a design decision the old format couldn't express: **who is allowed to pull the trigger.** For side-effect workflows—deploying, committing, sending messages—set `disable-model-invocation: true`\n\nso Claude can't decide on its own that now is a good time to deploy. For pure background knowledge, set `user-invocable: false`\n\nso it stays out of your command menu.\n\n`/code-review`\n\nSkill\nThe architecture-review skill from the January version of this post is still the one I use every day—it has just grown up. Here's the frontmatter of my current production `/code-review`\n\nskill:\n\n```\n---\nname: code-review\ndescription: Review code against .claude/rules/ for architecture and convention\n  violations. Supports --staged, --head, --last, --today, --branch scope options.\n  Add --fix to auto-correct.\nargument-hint: \"[path] [--staged|--head|--last|--today|--branch] [--fix]\"\nallowed-tools: Read, Glob, Grep, Edit, Bash(git *), Bash(find *)\n---\n```\n\nThe current version relies on two features that didn't exist in January:\n\n**1. Arguments.** `$ARGUMENTS`\n\nin the skill body is substituted with whatever you type after the command, so one skill covers many scopes:\n\n| Invocation | Review scope |\n|---|---|\n`/code-review` |\nFiles changed in the last 5 commits |\n`/code-review src/user/` |\nA specific directory |\n`/code-review --staged` |\nFinal check right before committing |\n`/code-review --branch` |\nCurrent branch vs main, before opening a PR |\n`/code-review --staged --fix` |\nAuto-fix what it finds |\n\n**2. Dynamic context injection.** A `!` command``\n\nplaceholder runs *before* Claude sees the skill and gets replaced with its output. My skill uses it to enumerate the rule files and changed files up front:\n\n```\n- Project rules: !`find .claude/rules -name \"*.md\" | sort`\n- Staged files: !`git diff --name-only --cached`\n```\n\nThe Claude Code client runs these commands during preprocessing; the model receives only the expanded results as part of the skill instructions. That removes an entire class of \"the model forgot to check X first\" failures.\n\n📎 Full working example: [code-review SKILL.md](https://dev.to/files/claude-code-skills-guide-teaching-ai-your-workflow/review-code.md) — save it as `.claude/skills/code-review/SKILL.md`\n\nin your project. The directory name is what creates the `/code-review`\n\ncommand.\n\nClaude Code already ships a bundled\n\n`/code-review`\n\nskill. Adding your own`code-review`\n\nskill at the personal or project level overrides the bundled version—which is exactly what I want here: a review driven bymyrule files, not a generic one.\n\n`.claude/rules/`\n\ndynamically instead of hardcoding policies, so the same skill works in every project and stays aligned with the current rule files.Running `/code-review`\n\nin the terminal produces results like this:\n\n```\n> /code-review src/user/api/user_router.py\n\n🔍 Reviewing: src/user/api/user_router.py\n\n## Architecture Violations Found\n\n### 🚨 CRITICAL (2)\n\n**Line 45**: Direct Repository import detected\n  - Found: `from src.user.repositories.user_repository import UserRepository`\n  - Fix: Remove this import. Use Service layer instead.\n\n**Line 78**: Business logic in API layer\n  - Found: `if user.age >= 18 and user.verified:`\n  - Fix: Move this validation to UserService.validate_user_eligibility()\n\n### ⚠️ WARNING (1)\n\n**Line 23**: Service manually instantiated\n  - Found: `service = UserService()`\n  - Fix: Use `service: UserService = Depends(get_user_service)`\n\n### 💡 SUGGESTION (1)\n\n**Line 12**: Consider adding return type hint\n  - Current: `async def get_user(user_id: int):`\n  - Suggested: `async def get_user(user_id: int) -> StandardResponse[UserResponse]:`\n\n---\nSummary: 2 critical, 1 warning, 1 suggestion\nRun `/code-review --fix` to auto-fix applicable issues.\n```\n\nOne command produces a repeatable first-pass architecture review based on your project's documented rules. It doesn't replace human review—but it catches routine violations before a pull request ever reaches another developer.\n\nThe same two features that make skills powerful make them worth auditing. Skills are executable workflow definitions, not passive documentation:\n\n`allowed-tools`\n\npre-approves tool usage for the duration of the skill—no permission prompts.`!` command``\n\nrun `disableSkillShellExecution`\n\nsetting.)`Bash(git *)`\n\nbeats `Bash(*)`\n\n, and list only the tools the procedure actually needs.Human reviewers vary by mood and energy. A well-defined Skill applies the same checklist every time, reducing variation and making common omissions less likely.\n\nTasks that touch multiple files (adding a new API endpoint requires Router, Service, Schema, and Test files) can be bundled into a single Skill, reducing the chance of missing a step.\n\nEmbed your design philosophy into Skill files and share via Git. Junior developers can generate code that is consistently aligned with documented senior guidelines. And because Skills follow an open standard, the SOPs you encode aren't locked into one tool.\n\nThese are skills currently in my `~/.claude/skills/`\n\nand project `.claude/skills/`\n\ndirectories—not hypotheticals:\n\n| Skill Command | What It Does |\n|---|---|\n/code-review |\nCheck architecture violations against `.claude/rules/` with severity levels and `--fix`\n|\n/commit-push |\nStage, generate a conventional commit message, confirm, push |\n/create-post |\nScaffold a new blog post following every content convention (slug rules, image folders, frontmatter schema) |\n/feature-image |\nCrop and convert cover images to 16:9 WebP under a size budget |\n/review-skill |\nThe meta one: audit `SKILL.md` files against the open standard, with `--fix`\n|\n\nNotice the pattern in the last row—once your process knowledge lives in files, you can write skills that maintain other skills.\n\n`.claude/rules/`\n\nis the single source and the skill is the procedure that applies it.`SKILL.md`\n\nlean`references/`\n\nfiles that load on demand; the skill body occupies context for the whole session.`disable-model-invocation: true`\n\n. Guardrails belong in frontmatter, not in hope.Claude Code Skills turn repeated instructions into **reusable, version-controlled workflows**.\n\nTheir quality depends less on clever prompting than on how clearly you've defined the process Claude should follow.\n\nIf your team repeatedly explains the same conventions during code reviews, those conventions are good candidates for a Skill. Start with one narrow workflow, test it against real tasks, and refine it as your process changes.\n\nIn the next article, we'll explore **Custom Agents**—how to build AI that autonomously decides when to use which Skill.\n\n*Originally published at jamongx.com.*", "url": "https://wpnews.pro/news/claude-code-skills-guide-how-to-automate-your-development-workflow", "canonical_source": "https://dev.to/jamongx/claude-code-skills-guide-how-to-automate-your-development-workflow-39ni", "published_at": "2026-07-13 01:14:05+00:00", "updated_at": "2026-07-13 01:44:23.296898+00:00", "lang": "en", "topics": ["developer-tools", "ai-agents", "large-language-models"], "entities": ["Claude Code", "agentskills.io"], "alternates": {"html": "https://wpnews.pro/news/claude-code-skills-guide-how-to-automate-your-development-workflow", "markdown": "https://wpnews.pro/news/claude-code-skills-guide-how-to-automate-your-development-workflow.md", "text": "https://wpnews.pro/news/claude-code-skills-guide-how-to-automate-your-development-workflow.txt", "jsonld": "https://wpnews.pro/news/claude-code-skills-guide-how-to-automate-your-development-workflow.jsonld"}}