{
  "$type": "site.standard.document",
  "description": "How I decide whether a coding-agent workflow belongs in a skill, slash command, MCP server, or plain CLI script.",
  "path": "/coding-agent-skills-vs-slash-commands-mcp-and-cli-tools/",
  "publishedAt": "2026-05-29T01:36:00.000Z",
  "site": "at://did:plc:bryys25pc2fnagnyxqgsglhd/site.standard.publication/3mn26bjkkmh23",
  "tags": [
    "AI",
    "Tools"
  ],
  "textContent": "I use coding-agent skills a lot, but not every workflow should become a skill.\n\nThe categories I use are simple:\n\n * slash commands for short in-agent triggers\n * skills for repeatable workflows that need judgment\n * MCP for structured external context and tool access\n * CLI scripts for deterministic automation\n\nAgents get worse when every tool is described as every other tool.\n\nSLASH COMMANDS ARE TRIGGERS\n\nSlash commands are good for short, local interactions inside one agent.\n\nExamples:\n\n/review\n/commit\n/spec\n/clear\n\nThey are convenient and fast. Usually they are tied to the agent you are using.\n\nI do not use slash commands as the long-term place for detailed workflow knowledge. They are better as short triggers.\n\nIf /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.\n\nI put that in a skill.\n\nSKILLS ARE WORKFLOWS WITH JUDGMENT\n\nA skill is a markdown file that tells the agent how to do a repeatable task.\n\nI use skills for workflows like:\n\n * commit succinctly\n * review dirty changes\n * review and fix until clean\n * deploy with project-specific rules\n * export logs from Better Stack\n * set up Postmark\n * create or improve other skills\n\nEach one needs more than a single shell command.\n\nThe agent has to inspect state, choose the right command, avoid certain files, handle errors, and report back. Skills work well for that.\n\nA good skill says:\n\nUse this when the user says \"commit\".\n\nSteps:\n- inspect `git status`\n- review the diff\n- run the smallest relevant checks\n- stage only intended files\n- commit with the repo's commit style\n- report the commit hash\n\nGuardrails:\n- do not include unrelated user changes\n- do not rewrite history\n- do not commit secrets\n\nThat gives the agent a small operating procedure.\n\nMCP IS FOR EXTERNAL CONTEXT AND ACTIONS, NOT PROCESS NOTES\n\nMCP is useful when the agent needs a structured interface to something outside the repo.\n\nGood MCP uses:\n\n * query a database through a controlled interface\n * inspect a browser page\n * read documents from a service\n * call an internal API with typed parameters\n * expose app-specific actions to the agent\n\nI do not use MCP just to hold instructions.\n\nIf the task is \"when deploying, use Kamal in tmux and add an Agent Control callback\", that belongs in AGENTS.md or a deploy skill.\n\nIf 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.\n\nMCP 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.\n\nMy 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.\n\nCLI SCRIPTS ARE FOR DETERMINISTIC WORK\n\nSome workflows should be plain scripts.\n\nIf the steps are deterministic and do not need model judgment, I write a CLI script:\n\nbun scripts/generate-sitemap.ts\nbun scripts/check-links.ts\nbun scripts/export-report.ts --from 2026-05-01 --to 2026-05-29\n\nThe agent can still run the script. I want the branching and edge cases in code.\n\nI use this pattern for checks:\n\n * validate frontmatter\n * find broken links\n * generate reports\n * export analytics\n * normalize files\n * submit URLs\n\nThe script can fail loudly and consistently. The agent then fixes the failure.\n\nThat is better than asking the agent to remember every edge case from a paragraph.\n\nHOW I DECIDE\n\nHere is the decision table I use:\n\nNeed 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\n\nMost workflows I care about use more than one.\n\nFor example, my deploy flow has:\n\n * AGENTS.md for the standing rule: deploys run in tmux\n * a skill for the project deploy workflow\n * Kamal as the CLI tool\n * Agent Control as the callback channel\n * shell commands for verification\n\nThe skill coordinates the work. Kamal does the deterministic deploy. Repo instructions keep the agent from guessing.\n\nEXAMPLES\n\nCOMMIT\n\nCommit looks like a slash command. In practice, I want more than git commit.\n\nThe easy version:\n\ngit add .\ngit commit -m \"Update\"\n\nThe version I want:\n\n * inspect dirty files\n * separate my changes from unrelated user changes\n * run focused checks\n * stage only intended files\n * use the repo's commit style\n * avoid generated files unless they are expected\n * report what was committed\n\nThat is a skill.\n\nThe skill may still run normal CLI commands:\n\ngit status --short\ngit diff\ngit add path/to/file\ngit commit -m \"Write\"\n\nThe judgment around those commands is the useful part.\n\nEXTERNAL LOGS\n\nLog export is different.\n\nPart of it is process:\n\n * know which Better Stack cluster a project uses\n * know where credentials are stored\n * know when UI export is faster than API export\n\nPart of it is structured access:\n\n * query logs by time range\n * filter by service\n * extract JSON fields\n * return rows consistently\n\nThat can start as a skill. If I run it often enough, the query part should become a script or MCP tool.\n\nI 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.\n\nDEPLOYMENT\n\nDeployment uses the same split.\n\nMy deploy workflow has judgment:\n\n * is this a frontend-only change?\n * should the worker be restarted?\n * did the migration run?\n * did the health check fail because of code, config, or an external service?\n * should the deploy be rolled back?\n\nThat belongs in instructions and skills.\n\nThe actual deploy command is still a CLI:\n\nkamal deploy\n\nI want the agent to follow the project workflow: run the command, read the output, and know when to stop.\n\nIf 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.\n\nThe skill can then focus on the sequence:\n\n * check dirty files\n * run the expected checks\n * start the deploy in the right place\n * wait for the callback\n * verify the app\n * report the result\n\nKamal does the deployment. The skill handles the workflow around it.\n\nWHAT STAYS IN AGENTS.MD\n\nI keep standing rules in AGENTS.md.\n\nExamples:\n\n * use pnpm for installs\n * run scripts with bun run\n * do not start dev servers unless needed\n * deploys run in tmux\n * when I say \"commit\", use the commit skill\n * when I say \"take over\", run the take-over workflow\n\nThose rules should be loaded every session. They change how the agent behaves across the repo.\n\nI do not put a full deploy runbook or log-export guide in AGENTS.md. That turns the file into a junk drawer.\n\nThe top-level file should route the agent:\n\n- When I say \"commit\", use `commit-succinct`.\n- When I say \"deploy\", use the project deploy skill.\n- Better Stack log exports use the `betterstack-log-export` skill.\n\nThe detailed workflow goes in the skill. Deterministic work goes in code. Repo rules stay short.\n\nWHAT BECOMES CODE\n\nWhen a skill grows a long checklist with no judgment, I usually turn that part into a script.\n\nFor example, this should be code:\n\n * check whether every public route has prerendered output\n * validate sitemap URLs\n * detect missing env vars in a template\n * export a report for a fixed date range\n * normalize frontmatter\n\nThe script gives the agent a pass/fail result.\n\nThat is better than a paragraph that says \"make sure the sitemap is correct.\" The agent can eyeball the file and miss a URL.\n\nWith a script:\n\nbun run check:seo\n\nThe agent gets a real failure. Then it can fix the source and rerun the check.\n\nI use the same pattern for content work.\n\nThe 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.\n\nNeither 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.\n\nThat 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.\n\nThe 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.\n\nWHY I PUT THIS IN STARTER KITS\n\nA SaaS starter kit should include a way to work on the code.\n\nThat means:\n\n * repo instructions for defaults\n * skills for workflows\n * scripts for checks and generation\n * deployment commands that agents can run\n * docs that explain where each piece belongs\n\nStacknaut includes agent configuration because this is how I build production apps now.\n\nThe app code is not enough. The workflow around the app has to be there too.\n\nWithout it, every new agent session starts by guessing.",
  "title": "Coding Agent Skills vs Slash Commands, MCP, and CLI Tools"
}