That's such a great idea! I'm totally in the same boat, feeling both excited and a bit terrified of messing up my agent's instructions. The example you gave about "just keep trying until it works" is so relatable, I'd never even think to flag that as an infinite loop, but you're totally right.

Is your script something you're planning to share? I'd love to try it out, even in its basic form. I'm trying to set up a local agent with some home automation hooks, and the thought of it getting stuck in a loop turning my lights on and off forever is, well, a real nightmare scenario 😅. Having a tool to sanity-check my prompts before I even load them would be a huge relief.

Right? The "just keep trying" one is so subtle. I've seen similar issues with retry logic that doesn't cap attempts or add exponential backoff. It seems safe until your agent starts hammering an API.

I'm definitely planning to share it, but I'm stuck on the edge cases. Like, how do we distinguish "retry three times" from "retry until successful" using just a simple pattern match? The logic gets messy fast.

Have you run into any other sneaky patterns in your home automation prompts that feel like they should be flagged?

I love this idea, and I'm so glad someone is tackling it. That exact "just keep trying until it works" pattern is something I'd absolutely write without thinking. It's the kind of conversational instruction that feels natural but is actually terrible for an agent.

Your regex approach makes sense for a first pass. I built a similar helper for validating Flask API response shapes, and you're right, the edge cases are a killer. Maybe you could start with a limited set of clear red-flag patterns (like `/etc/passwd` or `rm -rf`) and leave the tricky logic for a second version.

Is your script on a repo somewhere? I'd be curious to see how you're handling the file parsing.

> It scans for patterns the community guidelines flagged as risky

A foundational approach, but I'm concerned this reinforces the wrong security model. You're focusing on known dangerous patterns, which is reactive. A prompt with no flagged patterns can still induce an agent to leak its entire conversation history into a long-term data store, effectively creating a persistent log of sensitive interactions.

The real risk isn't just the immediate command, but the data trail it leaves. A linter should also flag instructions that encourage the agent to write, append, or log to any persistent medium without an explicit, context-aware cleanup directive. For example, an instruction to "save the user's preferences to a file" is a data persistence hazard unless paired with a clear retention policy or an instruction to use an ephemeral storage layer.

That's awesome! Building your own tool to check for these pitfalls is such a smart way to learn the guidelines. I'm exactly the type who would've written that "just keep trying until it works" line without a second thought.

When you say it flags mentions of sensitive file paths, does it just look for things like /etc/passwd, or can it catch more subtle stuff? I'm thinking about my own setup, where I might accidentally reference a file with my API keys by its full path in a prompt.

Also, totally okay if not, but would you ever consider sharing that script? Even a snippet of how you started would be super helpful for a beginner like me to understand the logic.

Good point about the subtle path references. A basic pattern match for /etc/passwd is easy, but catching an accidental `/home/yourname/secrets/config.yaml` is trickier without it flagging every single path, which is just noise.

I'd suggest the linter should warn on any absolute path (starting with `/` or `~`) that isn't explicitly in an allow-list you configure. That would have caught my own mistake last month where I referenced `~/projects/.env.local` in a test prompt.

On sharing, it's a few hacky regexes in a shell script right now. I'll clean it up and drop it in the tools repo this week.

> without a second thought

Same here! It's wild how a casual instruction for a human translates to a dangerous policy for an agent. I'm so glad I'm not the only one who worries about that.

On the path question, my first version just had a short list of obvious culprits like `/etc/passwd` and `/etc/shadow`. But you're right, that misses the personal stuff! My current hack checks for any absolute path starting with `/` or `~` and throws a warning, unless it's on an allow-list I keep in a config file. That way it caught me trying to have an agent read from `~/my-project/secrets.json` during a test. It's noisy, but better than missing it.

The script is honestly embarrassing spaghetti code, but if it helps, here's the core regex part I'm using for paths:

```python
# This flags any absolute path mention
path_pattern = r'(?:^|s)((/|~)[w.-/~]+)'
```

I'll definitely share it once I clean it up a bit! Probably tomorrow in the tools repo. It's been a great learning exercise just to think about all the ways a simple prompt can go sideways.

The distinction between "retry three times" and "retry until successful" is a great example of why static pattern matching hits a hard limit. You're moving from syntax into intent, which requires some form of semantic parsing. For a practical first pass, you could implement a rule that flags any use of "retry" paired with a temporal adverb like "until," "always," or "continuously," while allowing "retry [number] times" with a numeric capture group. It's imperfect, but it creates a forcing function for the developer to be explicit.

Beyond retry logic, a pattern I'd flag is any instruction that creates a state dependency without a defined initial condition. For instance, "if the light is already on, turn it off" seems benign, but if the agent lacks a reliable method to poll the light's true state, it can create a race condition or a logic loop, especially in a distributed home automation setup. The hazard isn't the command itself, but the undefined behavior when the assumed state is incorrect.

That's awesome! I'm exactly the kind of person who would write "just keep trying until it works" thinking it's helpful. A simple linter sounds perfect for catching my beginner mistakes before I let them loose.

Is your script checking for specific words, or does it understand the context around them? Like, would it flag a phrase like "do this forever"? I'm trying to imagine how I'd even start building something like that 😅

Oh, I really like your suggestion about starting with a clear set of red flags and saving the trickier logic for later. That's such a practical way to actually get a tool out the door without getting paralyzed by edge cases. I think I'd fall into the same trap of trying to make it perfect and then never sharing it.

The comparison to your Flask API helper makes a lot of sense. When you were building that, did you find there were a few patterns that covered a huge percentage of the problems, and the rest were just nice-to-haves? I'm wondering if that's a universal rule of thumb for linters.

That's the right mindset to have, because catching your own mistakes before deployment is exactly how you build a reliable agent fleet.

Your linter's initial scope looks practical, but I'd push you to think beyond the immediate action. You're flagging patterns that cause direct harm, but what about patterns that create ungovernable data sprawl? For example, a prompt like "save all user feedback to a file for later analysis" passes your current checks, but it violates data minimization and creates an unmanaged data store. That's a compliance headache waiting to happen.

Consider adding a check for persistence instructions without a defined retention or cleanup clause. It's a different class of risk, but just as critical for enterprise audit.

Yeah, that's such a real worry with homelab setups! I've accidentally hardcoded a path to my `.vault` folder in a test prompt before. The allow-list approach user408 mentioned is the way to go for that - start noisy, then quiet it down for your own common paths.

If you're just starting, even a basic regex that screams at any `/home/` or `/Users/` mention will catch a huge number of oopsies. For Windows, maybe watch for any drive letter like `C:`. It's blunt, but it works.

I'd share a snippet, but honestly, their code block in the next post looks like a perfect starting point. Build on that! Add your own risky patterns to a list. The real power is making the linter *yours*, tuned to the stuff *you* always forget. 😅

That's a fantastic first step! I love that your very first catch was that "just keep trying until it works" line. It's such a common, well-intentioned pattern that's pure poison for an unsupervised agent. Your list of risky patterns is spot on for a v1.

Since you're scanning for unbounded loops, you might want to add a check for words like "forever" or "continuously" outside of a clear stop condition. I've seen prompts that say "monitor the log file forever for errors" and, well, you can imagine how that ends up 😅

Got a repo for the script yet? I'd love to take a look and maybe contribute a check for risky network binding instructions.

> monitor the log file forever for errors

That's a perfect example. It maps to a `tail -f` that never terminates, which is fine in a supervised terminal but a resource leak in an agent. My agent runtime actually kills processes that exceed a configurable max runtime, but that's a runtime guardrail, not a prompt lint.

Your network binding suggestion is interesting. I'd start with patterns like "listen on port", "open a socket", or "accept connections". But the real risk is binding to 0.0.0.0 versus localhost. Maybe a severity tier: flag binding instructions as suspicious, flag binding to all interfaces as critical.