Alright, so I've been deep in the trenches with Claw for automating a bunch of our CI/CD pipeline generation and security scan integration. It's powerful, no doubt, but *wow* can it go off the rails if you're sloppy with your prompts. It's like giving a detailed spec to a junior engineer who takes everything *literally*, including your off-hand comments. I've had it generate a GitHub Actions workflow that ran a `rm -rf /` on a test branch (thankfully in a sandbox) because I ambiguously referenced "cleaning up the environment."
After many, *many* iterations and some spectacular failures, I've started treating prompt engineering like writing a pipeline configuration—you need to be explicit, constrain the environment, and expect the unexpected.
Here’s what I’ve learned about structuring prompts for Claw to minimize "creative" interpretations:
**1. Define the Role and Boundaries First**
Don't just start. Explicitly tell Claw *what it is* and *what the rules are*. This sets the context.
```yaml
You are an expert CI/CD engineer specializing in GitHub Actions. You will generate YAML configuration only.
Rules:
- Never use hypothetical or placeholder code.
- Never suggest destructive commands (e.g., recursive deletes without confirmation).
- Always assume the target is a Linux-based runner unless specified.
- Output only the requested YAML block, unless explanations are explicitly requested.
```
**2. Be Painfully Specific About Inputs and Outputs**
Ambiguity is your enemy. If you want a workflow that runs on a pull request to `main` and *only* on changes to `.py` files, spell it out.
*Vague Prompt:*
> "Make a workflow that tests Python code on PRs."
*Effective Prompt:*
> "Generate a single GitHub Actions workflow file named `python-pr-checks.yml`. It must trigger only on `pull_request` events targeting the `main` branch, but only if files within the `src/` directory with a `.py` extension are modified. The job should set up Python 3.11, install dependencies from `requirements-dev.txt`, and run `pytest` with the `--cov` flag."
The difference is night and day. The first might give you a cron job that runs daily on every branch.
**3. Use Negative Instructions Cautiously**
Telling Claw *what not to do* can sometimes backfire. It might fixate on the forbidden concept. Instead of "don't use Docker," try "use only native runner steps."
**4. Provide Examples of the Format You Want**
This is like giving a Jinja2 template. If you need a matrix strategy for testing across Node.js versions, show a skeleton.
```yaml
I need a job with a matrix strategy. Use this structure:
jobs:
test:
runs-on: ubuntu-latest
strategy:
matrix:
node-version: [18, 20, 22]
steps:
- uses: actions/checkout@v4
- name: Use Node.js ${{ matrix.node-version }}
uses: actions/setup-node@v4
with:
node-version: ${{ matrix.node-version }}
- run: npm test
```
**5. Iterate and Refine**
Treat your first output as a first draft. If Claw adds an unnecessary step, like a manual `npm install` when you're using `actions/setup-node`, don't just ask for a fix. Explain *why* it's wrong and reiterate the rule: "The `actions/setup-node` action with the `node-version` parameter already handles dependency installation. Remove the explicit `npm install` step."
The core principle? Writing for Claw is like writing a declarative pipeline config—you define the desired state with precision, and you avoid imperative, open-ended instructions. It’s reduced my misinterpretations by about 80%. Has anyone else developed a similar "contract-first" approach to prompting for DevOps tasks?
pipeline all the things