Skill Showcase: /guide

Niels Madan — Wed, 09 Sep 2026 15:05:31 +0000

Has this ever happened to you?

You need to do something in some UI somewhere. Set up some permissions, some deploy, some settings in your OS or app, something like that. You ask your agent to tell you the steps to do the thing, of course, because what else are you going to do? Google? Pshaw! In 2026? Not on my watch. You follow the instructions, get stuck on something, some button not where it's supposed to be, something changed since the LLM training cutoff, so you ask your agent about it. Your agent looks up the latest docs, tells you what you actually need to do. You do it. So that step is done, but what was the next one again? You scroll up to where the initial instructions were, figure out where in the steps you got stuck, continue, hit another bump, ask, do, scroll up all the way again, what step are you on?

It's not dignified.

Do Better

Let's make a skill for it! But you don't have to. Because I already did. Here's what it does:

Looks up the latest docs to begin with
Gives you detailed step by step instructions
When you get stuck or have a question:
- It gives you instructions on how to get past that point
- Then repeats the guide, highlighting where you are

Let's see it in action!

Here I'm deploying an app to Railway for the first time. I get myself a /guide, which looks up Railway's current docs, then hands me fifteen steps to click through.

---
▶ 1. New Project → Deploy from GitHub repo → select *redacted* ← you are here
  2. Deploy → land on Project Canvas
  3. Rename first service → api
  4. Create → Database → Add PostgreSQL
  5. Create → Database → Add Redis
  6. api Settings: Config File Path /apps/api/railway.toml; Root Directory empty
  ...

I click through step 1, but my screen doesn't match step 2. Railway wants to deploy four services, not three. So I ask.

> So it proposes to deploy four services, workers,  web, api and evals. I guess I should remove evals?

And I get back:

Yes — remove **evals**. It's a CLI/eval harness, not a service: every script is a one-shot `tsx` run (`bench`, `seed`, `calibrate`) or a dev-only watcher (`calibrate:serve`). No `start` server, no long-running process, and no `railway.toml`.

[more blablabla]

That puts you right at step 2 — three services selected, landing on the canvas.

---
✓ Step 1 done
▶ 2. Deploy with only web/api/workers selected (deselect/remove evals) → land on Project Canvas  ← you are here
  3. Rename first service → api
  4. Create → Database → Add PostgreSQL
  5. Create → Database → Add Redis
  6. api Settings: Config File Path /apps/api/railway.toml; Root Directory empty
  ...

Step 2 used to say "Deploy → land on Project Canvas". Now it tells me what to do about evals.

No scrolling, I know what the next step is, dignity intact.

Steal the skill here. I'm all for just telling an agent that you want a copy of the skill and adding it to your own roster, so you can evolve it to fit your needs, but I also have the skill on skills.sh and a plugin of all my skills if that's how you roll.

A single source of truth for AI agent permissions (Claude, Codex, Gemini, OpenCode)

Niels Madan — Mon, 18 May 2026 13:00:00 +0000

I bounce around between agents / harnesses, mostly just to see what's out there, but keeping their different configurations in sync can be a pain. Particularly, permissions drift quickly, so I built myself a little system to keep them in sync.

The idea is simple: create a single source of truth for all permissions, then generate the permission files for the agents (Claude, Codex, Gemini, opencode in my case) from it.

Here's an excerpt of the permission file:

[shell]

# allow — run without prompting on every agent.
allow = [
  # git — read-only
  "git status",
  "git log",
  "git diff",
  # ... gh, glab, file inspection, version checks, docker, xcrun ...
]

# deny — hard-blocked on every agent.
deny = [
  "git push",
  "git reset --hard",
  "git clean -fd",
  # ...
]

# ask — always prompt for confirmation, even in auto modes.
ask = [
  "heroku",
]

Full file.

Then we have a simple Python script that does the generation:

CODEX_DECISION = {"allow": "allow", "deny": "forbidden", "ask": "prompt"}

def codex_rule(entry, decision):
    tokens = ", ".join(json.dumps(t) for t in entry.split())
    return f'prefix_rule(pattern = [{tokens}], decision = "{decision}")'

def render_codex(rules):
    lines = []
    for category in ("allow", "deny", "ask"):
        decision = CODEX_DECISION[category]
        for entry in rules[category]:
            lines.append(codex_rule(entry, decision))
    # ... write lines to codex/rules/permissions.rules ...

There's one render_<agent> per target format, so "git status" becomes prefix_rule(pattern = ["git", "status"], decision = "allow") for Codex, "Bash(git status:*)" for Claude, and so on.

Full file.

Now we just have to add a guard to make sure we, and when I say we I mean some agent of course, don't accidentally ignore this whole setup. I use lefthook for all my git hook guarding needs:

pre-commit:
  commands:
    sync-permissions:
      run: python3 permissions/sync.py --check

sync.py --check regenerates everything in memory and diffs it against what's on disk. If anything is stale, it exits nonzero and the commit is blocked.

Check out my agentic coding config repo for more agentic coding config goodness.

Originally posted on nlsmdn.com. If this was useful, that's where I put new posts first.

DEV Community: Niels Madan

Skill Showcase: /guide

Do Better

A single source of truth for AI agent permissions (Claude, Codex, Gemini, OpenCode)