I use coding-agent skills a lot, but not every workflow should become a skill.

The categories I use are simple:

  • slash commands for short in-agent triggers
  • skills for repeatable workflows that need judgment
  • MCP for structured external context and tool access
  • CLI scripts for deterministic automation

Agents get worse when every tool is described as every other tool.

Slash commands are triggers

Slash commands are good for short, local interactions inside one agent.

Examples:

/review
/commit
/spec
/clear

They are convenient and fast. Usually they are tied to the agent you are using.

I do not use slash commands as the long-term place for detailed workflow knowledge. They are better as short triggers.

If /commit means “inspect dirty files, run formatters, choose an atomic commit message, avoid unrelated files, and use this repo’s commit style”, then the actual instructions belong somewhere more portable.

I put that in a skill.

Skills are workflows with judgment

A skill is a markdown file that tells the agent how to do a repeatable task.

I use skills for workflows like:

  • commit succinctly
  • review dirty changes
  • review and fix until clean
  • deploy with project-specific rules
  • export logs from Better Stack
  • set up Postmark
  • create or improve other skills

Each one needs more than a single shell command.

The agent has to inspect state, choose the right command, avoid certain files, handle errors, and report back. Skills work well for that.

A good skill says:

Use this when the user says "commit".

Steps:
- inspect `git status`
- review the diff
- run the smallest relevant checks
- stage only intended files
- commit with the repo's commit style
- report the commit hash

Guardrails:
- do not include unrelated user changes
- do not rewrite history
- do not commit secrets

That gives the agent a small operating procedure.

MCP is for external context and actions, not process notes

MCP is useful when the agent needs a structured interface to something outside the repo.

Good MCP uses:

  • query a database through a controlled interface
  • inspect a browser page
  • read documents from a service
  • call an internal API with typed parameters
  • expose app-specific actions to the agent

I do not use MCP just to hold instructions.

If the task is “when deploying, use Kamal in tmux and add an Agent Control callback”, that belongs in AGENTS.md or a deploy skill.

If the task is “query production logs with a time range, service name, and structured filters”, MCP might make sense. The agent gets a tool with parameters instead of hand-assembling curl commands every time.

MCP also has prompts and resources. I still treat those as interfaces to a running server or external context, not as the place to keep my personal repo rules.

My rule: if the agent needs structured context or an action exposed by another system, use MCP. If the agent needs a procedure, use a skill.

CLI scripts are for deterministic work

Some workflows should be plain scripts.

If the steps are deterministic and do not need model judgment, I write a CLI script:

bun scripts/generate-sitemap.ts
bun scripts/check-links.ts
bun scripts/export-report.ts --from 2026-05-01 --to 2026-05-29

The agent can still run the script. I want the branching and edge cases in code.

I use this pattern for checks:

  • validate frontmatter
  • find broken links
  • generate reports
  • export analytics
  • normalize files
  • submit URLs

The script can fail loudly and consistently. The agent then fixes the failure.

That is better than asking the agent to remember every edge case from a paragraph.

How I decide

Here is the decision table I use:

Need Use
Short trigger inside one agent Slash command
Repeatable workflow with judgment Skill
Structured external context or actions MCP
Deterministic automation CLI script
Standing repo rule AGENTS.md

Most workflows I care about use more than one.

For example, my deploy flow has:

  • AGENTS.md for the standing rule: deploys run in tmux
  • a skill for the project deploy workflow
  • Kamal as the CLI tool
  • Agent Control as the callback channel
  • shell commands for verification

The skill coordinates the work. Kamal does the deterministic deploy. Repo instructions keep the agent from guessing.

Examples

Commit

Commit looks like a slash command. In practice, I want more than git commit.

The easy version:

git add .
git commit -m "Update"

The version I want:

  • inspect dirty files
  • separate my changes from unrelated user changes
  • run focused checks
  • stage only intended files
  • use the repo’s commit style
  • avoid generated files unless they are expected
  • report what was committed

That is a skill.

The skill may still run normal CLI commands:

git status --short
git diff
git add path/to/file
git commit -m "Write"

The judgment around those commands is the useful part.

External logs

Log export is different.

Part of it is process:

  • know which Better Stack cluster a project uses
  • know where credentials are stored
  • know when UI export is faster than API export

Part of it is structured access:

  • query logs by time range
  • filter by service
  • extract JSON fields
  • return rows consistently

That can start as a skill. If I run it often enough, the query part should become a script or MCP tool.

I do not need to decide upfront. I usually start with a skill because it captures what I learned while doing the task. Then I move deterministic parts into code.

Deployment

Deployment uses the same split.

My deploy workflow has judgment:

  • is this a frontend-only change?
  • should the worker be restarted?
  • did the migration run?
  • did the health check fail because of code, config, or an external service?
  • should the deploy be rolled back?

That belongs in instructions and skills.

The actual deploy command is still a CLI:

kamal deploy

I want the agent to follow the project workflow: run the command, read the output, and know when to stop.

If the deploy is long-running, my repo instructions say to run it in tmux and send an Agent Control callback when it finishes. That rule lives in AGENTS.md because it applies across deploy tasks.

The skill can then focus on the sequence:

  • check dirty files
  • run the expected checks
  • start the deploy in the right place
  • wait for the callback
  • verify the app
  • report the result

Kamal does the deployment. The skill handles the workflow around it.

What stays in AGENTS.md

I keep standing rules in AGENTS.md.

Examples:

  • use pnpm for installs
  • run scripts with bun run
  • do not start dev servers unless needed
  • deploys run in tmux
  • when I say “commit”, use the commit skill
  • when I say “take over”, run the take-over workflow

Those rules should be loaded every session. They change how the agent behaves across the repo.

I do not put a full deploy runbook or log-export guide in AGENTS.md. That turns the file into a junk drawer.

The top-level file should route the agent:

- When I say "commit", use `commit-succinct`.
- When I say "deploy", use the project deploy skill.
- Better Stack log exports use the `betterstack-log-export` skill.

The detailed workflow goes in the skill. Deterministic work goes in code. Repo rules stay short.

What becomes code

When a skill grows a long checklist with no judgment, I usually turn that part into a script.

For example, this should be code:

  • check whether every public route has prerendered output
  • validate sitemap URLs
  • detect missing env vars in a template
  • export a report for a fixed date range
  • normalize frontmatter

The script gives the agent a pass/fail result.

That is better than a paragraph that says “make sure the sitemap is correct.” The agent can eyeball the file and miss a URL.

With a script:

bun run check:seo

The agent gets a real failure. Then it can fix the source and rerun the check.

I use the same pattern for content work.

The writing guidance belongs in a skill because it needs judgment. The mechanical checks belong in tools. For these posts, writing-voice gives the style rules, and prosesmasher catches repeated cadence, boilerplate, and article-structure problems.

Neither one replaces reading the draft. The skill tells the agent what good looks like. The checker catches things that are easy to miss when editing quickly.

That combination is better than telling the agent “make it sound human.” Give it the voice rules, run the checker, edit the file, and run the checker again.

The same pattern works for code too. I put taste and judgment in instructions, then put repeatable verification in commands. The agent has to use both before it says the work is ready to ship safely.

Why I put this in starter kits

A SaaS starter kit should include a way to work on the code.

That means:

  • repo instructions for defaults
  • skills for workflows
  • scripts for checks and generation
  • deployment commands that agents can run
  • docs that explain where each piece belongs

Stacknaut includes agent configuration because this is how I build production apps now.

The app code is not enough. The workflow around the app has to be there too.

Without it, every new agent session starts by guessing.