What Are Agent Skills? (And Why You'll Never Want to Push Code Without One Again)

You know that moment right after you git push? You've just sent your code up to GitHub, you're feeling good about the changes, and then... what happens next?

If you're like some developers me, you probably:

1. Tab over to GitHub
2. Navigate to the Actions tab
3. Wait for the workflows to start
4. Watch the progress bars
5. Context-switch to something else shiny, because it's taking forever
6. Completely forget to check back
7. Discover 2 hours later that CI failed on a typo in your test file

There's got to be a better way, right?

The Question That Started It All

This week, Deejay in our Discord asked:

"I just asked Claude Code to push, then start a subagent to monitor my GitHub Actions and check that everything passed CI. I wonder if there's something that can be done with Git hooks and/or Agent Teams to make this automatic?"

This is exactly the kind of workflow friction that agent skills were designed to eliminate. Not because the agent couldn't figure out how to monitor CI — Claude's perfectly capable of working out the gh CLI commands — but because you shouldn't have to ask every single time.

What Are Agent Skills, Really?

Think of skills like packages for your agent's capabilities, but instead of installing code libraries, you're installing expertise.

A skill is a structured set of instructions that teaches your agent how to perform a specific task consistently and correctly. When you install a skill, you're essentially saying: "Here's the expert way to do this thing. Now you know how to do it right, every time."

Skills can be technical procedures; how to properly review a PR, deploy to production, or monitor CI workflows domain knowledge like security best practices, accessibility guidelines, or architectural patterns, or workflow automation, like when to do code reviews, how to handle feedback, or what to do after pushing code

The key difference from just prompting your agent? Skills published on the Tessl registry are:

• Versioned: Pin to specific releases, update when ready
• Tested: Run evaluations to verify they work as expected
• Reusable: Install once, works across all your projects
• Composable: Combine multiple skills to build sophisticated workflows

Building the GitHub Actions Monitor Skill

Let me show you how this works in practice. The Discord question was specific: "Make Claude automatically check CI after every push."

Here's what I built: github-action-monitor

The Skill: Teaching "How"

The skill itself (github-action-monitor/SKILL.md) teaches the agent the technical procedure:

---
name: github-action-monitor
description: Monitors GitHub Actions workflow runs and reports pass/fail results
---

# GitHub Action Monitor

## Workflow

### 1. Check for workflows and get context
```bash
COMMIT=$(git rev-parse HEAD)
BRANCH=$(git branch --show-current)
ls .github/workflows/*.yml .github/workflows/*.yaml 2>/dev/null

2. Find workflow runs for this commit

gh run list --branch "$BRANCH" --limit 10 \
  --json databaseId,name,status,conclusion,headSha,url \
  --jq "[.[] | select(.headSha == \"$COMMIT\")]"

[... and so on]

This teaches Claude the *mechanics*: which commands to run, in what order, how to handle edge cases, what output to report.

### The Rule: Teaching "When"

But here's where it gets interesting. The skill alone just sits there until you ask for it. The real magic comes from pairing it with a **rule** (`post-push-monitor.md`):

```markdown
---
alwaysApply: true
---

# Post-Push CI Monitoring

After any successful `git push` command, you MUST immediately invoke 
the `github-action-monitor` skill to monitor GitHub Actions workflows. 
Do not wait for the user to ask. This is part of the push workflow.

In the above example, I added alwaysApply: true. That helps nudge Claude from "Claude can monitor CI if I remember to ask" to "Claude automatically monitors CI because that's what happens after a push."

The Tile: Packaging It All Together

The tile.json manifest ties it together:

{
  "name": "popey/github-action-monitor",
  "version": "0.5.0",
  "summary": "Automatically monitor GitHub Actions workflows after git push",
  "steering": {
    "post-push-monitor": {
      "rules": "rules/post-push-monitor.md"
    }
  },
  "skills": {
    "github-action-monitor": {
      "path": "skills/github-action-monitor/SKILL.md"
    }
  }
}

Think of tiles as npm packages for agent context — they bundle skills, rules, and documentation into versioned, shareable units.

What This Looks Like in Practice

Install the tile:

tessl i popey/github-action-monitor

Now, when you push code in Claude:

────────────────────────────────────────
❯ Update the @README.md with our intro video, then commit and push 
  those changes to github 
────────────────────────────────────────

⏺ Let me start by reading the README and fetching the video details.

⏺ Update(README.md)

⏺ Now let me commit and push.

⏺ Pushed. Now let me monitor the CI as required.

⏺ Skill(github-action-monitor)
  ⎿  Successfully loaded skill

⏺ Let me monitor the CI for the push.

⏺ Workflow file exists. Let me find the run for this commit.

⏺ Found the workflow run. It's in progress — let me watch it.

⏺ The CI run has completed. Let me check the result.

⏺ The CI is still running — the build step takes a while. Let me check if it's finished now.

⏺ Task Output b6a3d0c
  ⎿  Refreshing run status every 3 seconds. Press Ctrl+C to quit.
  
⏺ All done. Here's a summary:

  README updated — added link to youtube tutorial after introduction

  Committed and pushed — 82b8f62 on main.

  CI passed — Workflow "Test built on x86_64" completed successfully. All jobs green:
  - Set up job
  - actions/checkout
  - snapcore/action-build
  - snapcraft-review-action
  
✻ Cogitated for 5m 34s

⏺ Background command "Watch workflow run until completion" completed (exit code 0)

⏺ The background CI watch task has completed — I already retrieved its output and reported the results above. The workflow passed successfully with all jobs green.
  

You didn't ask Claude to check CI. You didn't switch tabs. You didn't set a timer. It happened automatically because the skill and rule told Claude, "This is what we do after pushes."

Going Beyond CI Monitoring

The github-action-monitor is a simple example, but the pattern it demonstrates is powerful:

Skills + Rules = Autonomous Workflows

You can apply this same pattern to:

• Security reviews: Automatically scan for vulnerabilities after dependency updates
• Code quality: Run linters and formatters before commits
• Deployment checks: Verify staging before promoting to production
• Documentation: Update changelogs when version numbers change

The fundamental idea; rather than repeatedly instructing your agent on a task, you train it correctly just once, and it will then know when to apply that expertise autonomously.

Getting Started

If you want to try the github-action-monitor skill:

# Install Tessl
npm i -g @tessl/cli

# Login (free account)
tessl login

# Install the skill
tessl i popey/github-action-monitor

Or better yet, build your own skill for that repetitive task you're tired of explaining to Claude every time. The Tessl Registry already includes skills for code review, security scanning, and workflow orchestration, or you can create your own skills in minutes.

What workflow friction would you eliminate if you could teach your agent how to handle it automatically? Let us know in the comments or join the conversation in our Discord.