Advanced Agentic Workflows With Stacked Skills

We all know that simply asking a clanker:

Build a million-dollar app. Make no mistakes.

...won't work as magically as you'd expect, no matter what the vibe coders on Twitter say. However, there are far more effective ways to automate workflows for our agents.

Imagine having a list of 12 to-do cards in Trello and simply saying:

Tackle all my pending tasks.

...then letting the agent run until you have 12 PRs ready for review. Pretty cool, right?

Today, we'll explore how to create skills, compose them together, and build exactly that kind of workflow.

Skills Can Call Other Skills

In the last post I built a skill to automate creating PRs in GitHub.

What's great is that not only I can run it in my agent session, but also call it from other skills. A skill can call another skill by naming its slash command as a step in its own instructions, the same way you would type it into the prompt.

- Once you are done, create a PR using `/github-pr main`

When reading that line, the agent will run that /github-pr skill. There is no API or plugin system to set up, the agent is smart enough to figure it out.

That may sound like a small detail, but it changes how you design skills: instead of one large SKILL.md that tries to handle an entire process, you can write skills that each do one thing well and let them delegate the rest.

The Goal

Let's explore a complex workflow to put this in practice.

I'd love to leave my agent running in the background, tackling all the pending items of a given project.

How can we organize the tasks? Well, perhaps we can use Trello. A simple board will do: "To Do", "Doing", "Under Review" and "Done".

The full agentic workflow will be:

• Pick the first card from the "To Do" list
• Move the card to "Doing"
• Complete the task
• Create a PR
• Move the card to "Under Review"

We'll keep things simple: each card will represent a feature, a concrete and rather small amount of work. Each card will have its own, dedicated PR.

If we are building an online shop, a card could be:

# Implement Product Search

- Add a search input to the product listing page
- As the user types, filter the list of products by name
- If no products match the search, display a "No products found" message
- Clearing the search input should restore the full product list

Looks like a good unit of work, right? Another card could be:

# Implement Product Categories

- Display the list of available categories on the product listing page
- Selecting a category should filter the displayed products
- The user can clear the selected category to view all products again
- The selected category should remain active while navigating the product list

And so on and so forth!

We already have a skill that takes care of interacting with GitHub. Now, we only need one to interact with Trello.

The Trello Skill

Let's create this simple skill to teach the agent how to work with Trello's API. Of course, the reasoning model can figure it out, but it's faster (and less token consuming) to steer it in the right direction.

First, we need a file with the credentials and the IDs of the board and lists we want to work with. In the root of our project, we can save a trello.json that would look something like this:

{
  "apiKey": "...",
  "apiToken": "...",
  "board": "<board-id>",
  "lists": {
    "To Do": "<list-id>",
    "Doing": "<list-id>",
    "Under Review": "<list-id>",
    "Done": "<list-id>"
  }
}

Of course, remember to add that file to gitignore so you don't leak your credentials.

Now, we only need to tell our agent how to operate with Trello so it knows exactly what to do when we ask it to "create a new card" or "move this card to Done".

This is how the /trello skill could look like:

---
name: trello
description: Interacts with a Trello board. Triggered by "/trello".
---

Use this skill whenever the user asks you to read, create, update, delete, or move cards.

## Credentials

Read board credentials from `trello.json` in the project root:

```json
{
  "apiKey": "...",
  "apiToken": "...",
  "board": "<board-id>",
  "lists": {
    "To Do": "<list-id>",
    "Doing": "<list-id>",
    "Under Review": "<list-id>",
    "Done": "<list-id>"
  }
}
```

## Read list

`curl -s "https://api.trello.com/1/lists/<list-id>/cards?key=<apiKey>&token=<apiToken>"`

## Create card

The card name is the title and the description holds the body. Use `--data-urlencode` so spaces and line breaks survive:

`curl -s -X POST "https://api.trello.com/1/cards?key=<apiKey>&token=<apiToken>" --data-urlencode "idList=<list-id>" --data-urlencode "name=<card-title>" --data-urlencode "desc=<card-body>"`

## Move card

`curl -s -X PUT "https://api.trello.com/1/cards/<card-id>?key=<apiKey>&token=<apiToken>&idList=<list-id>"`

## Update card

Same endpoint as moving, just pass whichever fields changed:

`curl -s -X PUT "https://api.trello.com/1/cards/<card-id>?key=<apiKey>&token=<apiToken>" --data-urlencode "name=<card-title>" --data-urlencode "desc=<card-body>"`

## Delete card

`curl -s -X DELETE "https://api.trello.com/1/cards/<card-id>?key=<apiKey>&token=<apiToken>"`

## Attach a URL

Attach a link to a card, for example the PR you just opened:

`curl -s -X POST "https://api.trello.com/1/cards/<card-id>/attachments?key=<apiKey>&token=<apiToken>" --data-urlencode "url=https://google.com"`

## Error handling

- If `trello.json` is missing or malformed, stop and tell the user.
- If the Trello API returns a non-2xx status, show the error and stop.

The Orchestrator Skill

Great! Now that we have skills that know how to deal with Trello and GitHub, we can create an orchestrator skill that makes use of both.

---
name: tackle-task
description: Pick the first card in the Trello "To Do" list, build the feature it describes, open a PR, and move the card to "Under Review".
---

## Steps

1. Use `/trello` to read the first card in "To Do". If the list is empty, stop here.
2. Use `/trello` to move that card to "Doing".
3. Treat the card's title and description as the feature spec and build it, following the conventions already in the codebase.
4. Use `/github-pr main` to open the pull request. If this card builds on an earlier one, target that branch instead so the PRs stack: `/github-pr <base-branch>`.
5. Use `/trello` to move the card to "Under Review" and attach the PR link.

As you can see, this skill never explains how to name a branch, write a PR body, or talk to GitHub. It delegates all of that to /github-pr. Same goes for the Trello operations: saying "move card to Doing" is enough, since /trello knows how to do it.

Each skill stays small, and neither has to absorb the other's job.

Running the Whole Board

Because the workflow lives in skills rather than in my head, scaling from one card to the entire backlog takes a single instruction:

Sequentially tackle every task in our Trello.

That's it! That instruction makes the agent work until we have no more cards in "To Do".

The end result is a bunch of PRs in GitHub, ready for human review. Yeah, human review: I think it's important to take a moment to read the code the clanker generated. We saved so much time already (not only in the coding aspect, but all the ceremony that goes with it: writing PRs, moving cards, etc.) that taking a look can't hurt anyone... and can save you from shipping slop.

Designing Skills That Stack

A few principles made the difference between skills that compose cleanly and skills that fight each other:

• One job per skill. /github-pr only knows how to open a PR, and /trello only knows how to talk to the board. That's exactly why /tackle-task can lean on both without dragging their guts into its own instructions.
• Give each skill a small handle to grab. The base-branch argument is the whole reason /github-pr main and /github-pr some-feature both work. One little parameter turns a fixed command into a building block.
• Let the orchestrator do the deciding. /tackle-task owns the order of things and the "does this card stack on another?" call. The skills it invokes never need to know that context exists.
• Stop when something looks off. An empty "To Do" list, a missing trello.json, a non-2xx from the API: any of those halts the run instead of quietly plowing ahead and making a mess you have to untangle later.

None of this depends on an exotic feature. It's the same design thinking you already apply to code, pointed at the skills your agent runs.

Where This Goes

Once you start seeing skills as stackable recipes, it's hard not to notice more places to apply them.

The one I'm building now checks my inbox, reads emails from my app users, turns their requests into Trello cards, works on them, opens a PR for each one, and drafts an email reply for me to send later.

Here's a challenge for you: think about what you can automate with skills. Build it, and let me know how it goes!