Engineering
A DevOps Reference for a Team of One
Part 3 of the thread Dev habits for a team of one
- The note is a set of prompt cards: repo setup, API docs, schema design, security review, tests, docs, PowerShell and desktop builds.
- Each card asks for everything at once. Split them into smaller asks and the output gets much better.
- A chat model can review code and config. It can't scan your live site. Use real scanners for that.
- For a new project the order is scaffold, quality checks, repo and CI, tests, then docs.
The biggest note in my AI workflows folder is called Complete DevOps Reference. It's 22 KB of prompt cards, one per job, each with a big "must include" list and an "expected output" section. Reading it back, it's useful and it's a lot. So this is the condensed version: which cards matter when you're the whole team, and what I'd change about each.
The cards, condensed
| Card | What it's for | Watch out for |
|---|---|---|
| GitHub repository setup | README, CI workflow, issue and PR templates, SECURITY.md, license, .gitignore | It asks for setup.py and pyproject.toml. You only need the second |
| API documentation | An OpenAPI spec, interactive docs, example requests | Most frameworks can generate the spec from your code. Start there |
| Database schema design | Tables, keys, indexes, migrations, an ER diagram | Ask for migrations with a real down step, and read them |
| Security assessment | Reviewing code and config against the OWASP Top 10 | See below. This one oversells itself |
| Test suite generation | Unit, integration and end-to-end tests with coverage | Asks for 18 things at once. Ask for one test type at a time |
| Documentation | README, user guide, changelog, troubleshooting | Only write the docs someone will actually open |
| PowerShell script generation | Parameter validation, error handling, -WhatIf, help |
Check the -WhatIf really works before you trust it |
| Desktop build pipeline | Turning a Python app into an installer | Code signing costs money. Decide early if you need it |
Split the big asks
Every card in the note has the same habit. The test suite card wants unit tests, integration tests, end-to-end browser tests, load testing, security testing, contract testing, parallel execution and quality gates, all in one reply. The documentation card wants a README, a user guide, developer docs, install guides, troubleshooting, contributing guidelines and a changelog.
You can ask for that. What you get back is a lot of confident scaffolding that's thin everywhere. The better move is one deliverable per ask: "write the unit tests for billing.py, covering the happy path, empty input and a bad date." Check it. Then ask for the next thing.
The same goes for the repo setup card. A solo project doesn't need a code of conduct and three issue templates on day one. It needs a README that says how to run it, a CI workflow that runs the tests, and a .gitignore that keeps your .env file out of the repo.
What a chat can't do
The security assessment card is the one I'd rewrite most. It asks Claude to "scan for all OWASP Top 10A regularly updated list of the most common web application security risks, published by the OWASP foundation. vulnerabilities," "test SSL/TLS configuration and security headers," and include proof-of-concept exploits.
A model reading your code can do a code and config review, and it's genuinely good at spotting an unparameterized query or a secret in a settings file. What it can't do from a chat window is scan a live site. It isn't making requests to your server, so it can't tell you what headers the server actually sends. I learned the value of a real scan when this blog got an F on a header check that no amount of reading the config would have caught.
Heads up
Only point any security testing at systems you own or have written permission to test. That goes for real scanners and for anything an AI agent runs on your behalf.
So I'd reword the card as "review this code and configuration for OWASP Top 10 issues, with file and line for each," and run a proper scanner for the live part.
The order I'd run them in
For a brand-new project, the cards chain together like this:
- Scaffold the project. That's covered in scaffolding a Python project.
- Quality checks and pre-commit hookA check that runs automatically every time you commit, and stops the commit if it fails. Formatting and linting are the usual jobs.More: Scaffolding a Python Project So Future-You Doesn't Hate It.
- Repo setup with a CI workflow that runs those same checks.
- Tests, one type at a time.
- Docs, last, once the thing does something worth documenting.
For an existing project, it's the other way around. Tests come first, before any updates, which is the whole point of keeping an old project alive.
The PowerShell card
This one lines up with how I already write scripts for the Script Library: comment-based help, [CmdletBinding()], validated parameters and a working -WhatIf on anything that changes things. The card is a decent checklist. Two things I'd add from experience on this site: parse-check the result with PowerShell's own parser before running it, and actually test the dry run, because -WhatIf can quietly lie inside ForEach-Object.
The card also asks for "digital signature capability" and "performance optimization for large datasets" on every script. Most scripts need neither. Ask for them when the script does.