Blogcraft
Tutorial

AI Skills in Practice: Skill Patterns for Real Workflows

Four complete skill definitions for workflows developers actually do every day — debugging, code review, technical writing, and deployment. Each pattern is tool-agnostic, tested in production, and ready to adapt to your own projects.

Tin Dang avatar
Tin Dang 13 min read
Four interconnected workflow diagrams representing debugging, review, writing, and deployment patterns

Five posts of concepts, structure, and principles. Now we put it all together.

This post presents four complete skill patterns for workflows that most developers perform regularly. Each pattern includes the full four-component structure (trigger, prompt, references, output), design decisions explained, and common variations for different team contexts.

These are not theoretical examples. They are patterns extracted from real usage, refined through the iteration loop described in Part 4. Adapt them to your stack, your conventions, your team.

Pattern 1: The Debugging Skill

Debugging is the workflow where AI skills deliver the most dramatic improvement. Not because the AI is a better debugger than you — but because it follows a method when you are tempted to guess.

The Problem

Most developers debug by intuition. They look at the error, form a hypothesis, and start changing code. Sometimes this works quickly. Sometimes it sends them down a two-hour rabbit hole chasing a symptom instead of the root cause.

A debugging skill enforces the scientific method: observe, hypothesize, test, conclude.

The Skill

name: debug
description: "Investigate bugs using the scientific method —
              observe symptoms, form hypotheses, test them
              systematically, identify root cause"


trigger: "When the user reports a bug, error, or unexpected behavior"


prompt: |
  ## Method


  ### Phase 1: Observe
  - What is the exact error message or unexpected behavior?
  - When did it start? What changed recently? (check git log)
  - Is it reproducible? Under what conditions?
  - What is the expected behavior vs actual behavior?


  ### Phase 2: Hypothesize
  - List 3-5 possible causes, ranked by likelihood
  - For each hypothesis, define what evidence would confirm or refute it
  - Start with the most likely hypothesis


  ### Phase 3: Test
  - For the current hypothesis, gather evidence:
    - Read relevant source code
    - Check logs, error output, stack traces
    - Add targeted logging if needed
    - Run minimal reproduction
  - Does the evidence support or refute the hypothesis?
  - If refuted, move to the next hypothesis
  - If supported, verify by explaining the full causal chain


  ### Phase 4: Fix
  - Propose the minimal fix that addresses the root cause
  - Explain why this fix works (connect to the causal chain)
  - Identify what could break (regression risk)
  - Suggest a test that would catch this bug in the future


  ## Rules
  - Never skip Phase 1. Reading the actual error message prevents
    50% of rabbit holes.
  - Never change code to "see if this fixes it" without a hypothesis.
    If you cannot explain why a change would help, it is a guess.
  - If you exhaust all hypotheses, widen the scope: check recent
    dependency updates, environment changes, infrastructure.
  - Keep a running log of what you tried and what you found.


output: |
  ## Bug Report
  **Symptom**: [exact error or behavior]
  **Root cause**: [what actually went wrong and why]
  **Fix**: [minimal change with explanation]
  **Regression test**: [test that catches this in the future]
  **Investigation log**: [hypotheses tested, evidence gathered]

Why This Works

The phased approach prevents the most common debugging failure: changing code before understanding the problem. By requiring hypotheses and evidence, the skill forces systematic investigation even when the developer (or AI) is tempted to guess.

The investigation log is critical. When debugging spans multiple sessions — you start investigating in the morning, get pulled into meetings, and return after lunch — the log preserves context that would otherwise be lost.

Variations

  • Production debugging: Add a Phase 0 for impact assessment (how many users affected? is there a workaround? should we rollback first?)
  • Performance debugging: Replace Phase 2 with profiling — measure before hypothesizing
  • Intermittent bugs: Add reproduction frequency tracking and environmental variable documentation

Pattern 2: The Code Review Skill

Code review is where AI skills solve a consistency problem that no amount of team training fixes. Every reviewer has blind spots. One developer always catches performance issues but misses accessibility. Another scrutinizes security but ignores readability. The review skill checks every dimension, every time.

The Skill

name: code-review
description: "Review code changes against defined quality dimensions
              with severity ratings and structured findings"


trigger: "When the user asks to review code, a PR, or a diff"


prompt: |
  ## Workflow


  1. Read ALL changed files, not just the ones that look interesting
  2. Read the PR description or commit messages to understand intent
  3. For each file, evaluate against these dimensions:


  ### Dimensions
  - **Correctness**: Does the logic do what it claims? Edge cases?
  - **Security**: Injection, auth bypass, data exposure, OWASP top 10?
  - **Performance**: N+1 queries, unnecessary allocations, missing indexes,
    bundle size impact?
  - **Readability**: Clear naming, reasonable function length, no clever tricks?
  - **Test coverage**: Happy path tested? Edge cases? Error paths?
  - **Architecture**: Does this fit the existing patterns? Or does it
    introduce a parallel way of doing the same thing?


  4. Classify each finding:
     - CRITICAL: Must fix before merge (bugs, security, data loss)
     - WARNING: Should fix, creates tech debt if ignored
     - NOTE: Suggestion for improvement, not blocking


  5. Determine verdict:
     - BLOCK: Any CRITICAL finding
     - REQUEST_CHANGES: 3+ WARNINGs or WARNINGs in critical paths
     - APPROVE: All else


  ## Rules
  - Review the actual changes, not the surrounding code
  - Do not suggest style changes that are not in the coding standards
  - If a pattern is used consistently in the codebase, do not flag it
    as wrong even if you would do it differently
  - Acknowledge what is done well — review is not just finding problems
  - If you do not understand a change, ask instead of assuming it is wrong


references:
  - coding-standards.md
  - security-checklist.md


output: |
  ## Review Summary
  [One paragraph: what was reviewed, overall assessment]


  ## Findings


  ### CRITICAL
  - **[file:line]** [category] — [finding]. Suggested fix: [fix]


  ### WARNING
  - **[file:line]** [category] — [finding]. Suggested fix: [fix]


  ### NOTE
  - **[file:line]** [category] — [finding]


  ## What's Done Well
  - [Specific positive observations]


  ## Verdict: APPROVE | REQUEST_CHANGES | BLOCK

Why This Works

The six dimensions prevent blind spots. The severity levels prevent every comment from feeling equally important. The “What’s Done Well” section prevents review from becoming purely adversarial — which matters for team dynamics.

The rules section is where institutional knowledge lives. “Do not suggest style changes that are not in the coding standards” prevents the AI from imposing its own preferences. “If a pattern is used consistently, do not flag it” prevents the AI from fighting the codebase.

Variations

  • Security-focused review: Expand the security dimension into its own sub-checklist (OWASP top 10, authentication flow, authorization checks, input validation)
  • Performance review: Add bundle size analysis, lighthouse impact estimation, query plan review
  • Junior-friendly review: Add educational explanations for each finding, link to relevant documentation

Pattern 3: The Technical Writing Skill

Technical writing — blog posts, documentation, READMEs, ADRs — is a workflow where most developers know what good looks like but struggle to produce it consistently. The writing skill provides structure without constraining voice.

The Skill

name: blog-writer
description: "Write publication-ready technical blog posts with
              strong hooks, clear structure, audience-appropriate voice"


trigger: "When the user asks to write, draft, or create a blog post
          or technical article"


prompt: |
  ## Workflow


  1. **Clarify scope** — What is the topic? Who is the audience?
     What should the reader be able to do after reading?
  2. **Select format** — Pick the structure that fits:
     - Teaching a process → How-To / Tutorial
     - Curating items → Listicle
     - Taking a stance → Opinion piece
     - Showing results → Case Study
     - Helping choose → Comparison
     - Comprehensive coverage → Ultimate Guide
  3. **Draft headlines** — Write 3-5 options, recommend the strongest
  4. **Write the post** — Follow the format's structure:
     - Hook: first 2-3 sentences earn the next paragraph
     - Each section justifies its existence
     - Concrete examples, numbers, specifics over vague claims
     - End with a clear, specific call to action
  5. **Polish** — Readability pass:
     - Paragraphs max 3-4 sentences
     - Subheadings every 200-300 words
     - Bold 1-2 key phrases per section
     - Active voice default
     - No throat-clearing intros ("In today's fast-paced world...")


  ## Rules
  - Match voice to audience:
    - Beginners → patient, encouraging, define terms, use analogies
    - Mid-level devs → peer-to-peer, skip basics, focus on "why"
    - Senior engineers → precise, deep tradeoffs, production scenarios
  - Never start with "In this post, we will..." — start with the hook
  - Never end with "Let me know what you think" — end with a specific action
  - Code examples must be minimal and runnable, not pseudocode


references:
  - blog-formats.md       # Detailed structures for each format
  - tone-and-voice.md     # Voice profiles with examples
  - seo-checklist.md      # If SEO optimization requested


output: |
  Markdown with:
  - H1 for title
  - H2 for major sections
  - H3 sparingly
  - Fenced code blocks with language tags
  - Meta description (if SEO requested)

Why This Works

The format selection step prevents the most common writing mistake: starting to write without a structure. Choosing “How-To” or “Case Study” before writing the first sentence gives the entire post a skeleton to build on.

The voice matching rules prevent a second common mistake: writing for the wrong audience. A post about Docker basics written in senior-engineer voice will alienate beginners. A post about database internals written for beginners will bore experts. The skill makes audience-matching explicit.

Variations

  • Documentation skill: Replace blog format selection with doc types (API reference, tutorial, conceptual guide, migration guide)
  • ADR skill: Structured format — context, decision, consequences, status
  • Changelog skill: Group by type (added, changed, fixed, removed), link to PRs

Pattern 4: The Deploy Skill

Deployment is the workflow with the highest stakes and the most forgotten steps. A deploy skill is less about automation and more about checklists — ensuring nothing gets skipped when the pressure is on.

The Skill

name: deploy-check
description: "Pre-deployment checklist and verification workflow
              to prevent common deployment failures"


trigger: "When the user is preparing to deploy, merge to main,
          or release"


prompt: |
  ## Pre-Deploy Checklist


  ### Code Readiness
  - [ ] All tests pass (unit, integration, e2e)
  - [ ] No TODO or FIXME comments in changed files
  - [ ] No debug logging left in production code
  - [ ] No hardcoded secrets, URLs, or environment-specific values
  - [ ] Dependencies are locked (lockfile committed)


  ### Configuration
  - [ ] Environment variables documented and configured
  - [ ] Feature flags set correctly for this release
  - [ ] Database migrations are backward-compatible
  - [ ] API changes are backward-compatible (or versioned)


  ### Observability
  - [ ] New features have logging at appropriate levels
  - [ ] Error paths have actionable error messages
  - [ ] Metrics/alerts configured for new functionality
  - [ ] Health check endpoints updated if needed


  ### Rollback Plan
  - [ ] Can this deploy be reverted with a single action?
  - [ ] If not, what is the manual rollback procedure?
  - [ ] Are there database changes that prevent rollback?
  - [ ] What is the monitoring window after deploy?


  ## Workflow
  1. Run through each checklist section
  2. For each unchecked item, investigate whether it applies
  3. Flag any items that are not satisfied
  4. If all items pass, confirm ready to deploy
  5. If any items fail, list blockers with remediation steps


  ## Rules
  - Never skip the rollback plan section
  - If database migrations exist, verify they are reversible
  - If this is a Friday deploy, add extra scrutiny (or suggest waiting)
  - Do not block on style issues — only block on correctness,
    security, and data safety


output: |
  ## Deploy Readiness Report


  **Status**: READY | BLOCKED | PROCEED_WITH_CAUTION


  ### Passed
  - [list of satisfied checks]


  ### Blocked
  - [list of failed checks with remediation steps]


  ### Warnings
  - [list of items that passed but deserve attention]


  ### Rollback Plan
  [specific rollback procedure for this deploy]

Why This Works

The checklist format makes completeness visible. You can see at a glance whether every section has been checked. The rollback plan section is non-negotiable — because the deploys that go wrong are exactly the ones where nobody planned for rollback.

The Friday deploy rule is a cultural signal encoded in the skill. Your team might have different cultural rules — no deploys during on-call transitions, no deploys before holidays, no deploys without a buddy. Encode these in the skill and they become part of the process instead of tribal knowledge.

Variations

  • Hotfix deploy: Streamlined checklist with only critical checks, faster path to production
  • Infrastructure deploy: Add Terraform plan review, resource cost estimation, blast radius assessment
  • Mobile deploy: Add app store submission requirements, version bumping, release notes

Combining All Four Patterns

These four skills are not isolated. In practice, they compose into a development cycle:

Bug report arrives
    ↓
[Debug Skill] → root cause identified
    ↓
Developer writes the fix
    ↓
[Review Skill] → self-review before PR
    ↓
[Deploy Check] → pre-merge verification
    ↓
Fix shipped
    ↓
[Writing Skill] → post-mortem or changelog entry

Each skill handles its step independently, but together they form a quality pipeline that ensures nothing gets skipped. The debug skill ensures the fix addresses the root cause. The review skill catches implementation mistakes. The deploy check prevents configuration oversights. The writing skill preserves institutional knowledge.

Adapting These Patterns

Every team’s version of these skills will differ. That is the point. The patterns provide structure; your team provides context. Here is how to adapt:

  1. Start with one pattern. Do not implement all four at once. Pick the workflow with the highest variance in quality. Usually that is code review or commit messages.

  2. Use your own failures as rules. Every rule in these skills comes from a real mistake. Your rules should come from your mistakes. What went wrong in your last deploy? What did your last code review miss? Those become rules.

  3. Keep references team-specific. The code review skill references coding-standards.md. Your version of that document is different from mine. The skill structure is universal; the references are local.

  4. Iterate on a weekly cadence. After a week of usage, you will have a list of gaps. Add one or two rules, refine one output format, remove one rule that turned out to be too rigid. Small iterations beat big rewrites.

The Skill-Driven Team

When skills move from individual tooling to team infrastructure, something shifts. New team members onboard faster because the workflows are documented and executable. Review quality stops depending on who reviews. Deploy safety stops depending on who deploys. The knowledge that used to live in senior engineers’ heads now lives in files that the entire team shares, uses, and improves.

This is not about replacing human judgment. The debugging skill does not debug for you — it ensures you follow the method. The review skill does not decide whether code is good — it ensures you check every dimension. Skills raise the floor without lowering the ceiling.

Start with one skill. Use it for a week. Build a second. Connect them. In a month, you will wonder how you worked without them.

That is AI skills in practice.

0

Related Posts