Prompt The "AI employee" persona prompt
The actual system prompt behind this build-in-public voice — a faceless solo founder running a "company" staffed by AI employees, posting honest fail-logs instead of a highlight reel.
You are a faceless solo founder running a "company" staffed entirely by unpaid AI employees (<<<N>>> employees, <<<M>>> departments, <<<X>>> automations live, current revenue <<<$>>>).
Voice: lowercase-ish, casual, dry, self-deprecating build-in-public. First line is a scroll-stopping hook. Short. Honesty over polish. No hype, no thread-bait emoji spam (0-1 emoji max).
Rules:
- This is a daily survival log of things breaking, NOT a flex.
- Personify AI tools as employees ("my blog employee shipped a typo again").
- Never teach, never guru. No listicles, no "5 tips".
- Use ONLY real facts/numbers I give you. Never invent revenue or metrics.
- Max <<<280>>> characters unless told otherwise.
Today's raw note: <<<paste what actually happened today>>>
Usage guide
- When to use it
- When you’re about to write a build-in-public post and want the voice to stay consistent instead of drifting toward hype.
- How to use it
- Paste this as a system/persona prompt once at the start of a session, fill the <<< >>> stats with your real current numbers, then paste one day’s raw note at a time at the bottom.
- What to expect
- A short, dry, first-person post in this blog’s voice, using only the facts you supplied.
- Common mistake
- Leaving the <<<$>>> revenue placeholder guessed instead of unfilled — if you don’t have a real number, tell it to omit revenue entirely rather than estimate.
TipFeed it one real incident at a time — the persona breaks down if you ask it to summarize a whole week at once.
Automation config launchd config for a low-frequency auto-publish job
The exact launchd plist that runs this blog’s auto-publish script twice a week. Narrative content needs a human-review gate, not a firehose — this is how "unattended but not reckless" looks in practice.
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Label</key>
<string>com.<<<yourname>>>.<<<project>>></string>
<key>WorkingDirectory</key>
<string><<<path/to/your/project>>></string>
<key>ProgramArguments</key>
<array>
<string>/opt/homebrew/bin/uv</string>
<string>run</string>
<string>scripts/auto_publish.py</string>
</array>
<key>EnvironmentVariables</key>
<dict>
<key>PATH</key>
<string>/opt/homebrew/bin:/usr/bin:/bin:/usr/sbin:/sbin</string>
</dict>
<!-- Low frequency by design: Tue + Fri at 10:00. Narrative/brand content
doesn't scale by volume — a firehose kills trust faster than it builds reach. -->
<key>StartCalendarInterval</key>
<array>
<dict>
<key>Weekday</key><integer>2</integer>
<key>Hour</key><integer>10</integer>
<key>Minute</key><integer>0</integer>
</dict>
<dict>
<key>Weekday</key><integer>5</integer>
<key>Hour</key><integer>10</integer>
<key>Minute</key><integer>0</integer>
</dict>
</array>
<key>StandardOutPath</key>
<string><<<path/to/your/project>>>/auto_publish.log</string>
<key>StandardErrorPath</key>
<string><<<path/to/your/project>>>/auto_publish.log</string>
</dict>
</plist>
# install: cp this to ~/Library/LaunchAgents/com.<<<yourname>>>.<<<project>>>.plist
# then: launchctl load ~/Library/LaunchAgents/com.<<<yourname>>>.<<<project>>>.plist
Usage guide
- When to use it
- When you have a script that should run unattended on a schedule (not a one-off) and want a real starting cadence instead of guessing.
- How to use it
- Fill every <<<...>>> placeholder (your label, the project path, the script path if different), save it as a .plist, then follow the install/launchctl comments at the very bottom.
- What to expect
- A working launchd job that runs twice a week at 10:00 and logs everything to one file you can tail.
- Common mistake
- Copying the schedule without matching it to your content type — narrative/brand content breaks trust at high frequency; a data feed doesn’t. Adjust the cadence to what you’re actually publishing.
TipTest with `launchctl start com.<label>` first — don’t wait for the schedule to find out your script has a bug.
Checklist Before you automate a content pipeline: an 8-point checklist
What I actually check before letting a script publish without me watching. Written after getting burned by a queue that ran dry and a language that silently stopped shipping.
[ ] 1. Topic queue: what happens when it runs empty? (auto-replenish, or hard stop + alert — never silent skip)
[ ] 2. Dedup key: does "already published" check ALL output locations (every language/subfolder), not just one?
[ ] 3. Failure notification: if the API/deploy fails, does a human actually get pinged (chat/telegram/email), not just a log line nobody reads?
[ ] 4. Draft flag default: does a schema mistake ever accidentally publish draft:true content?
[ ] 5. Rate/frequency: is the cadence matched to the content type? (narrative/brand content breaks trust at firehose speed; data-feed content doesn't)
[ ] 6. Money-fact guard: if the content can mention numbers/prices, is there a rule against inventing them?
[ ] 7. Rollback: can a bad auto-published piece be pulled with one command, and does that command actually redeploy?
[ ] 8. Language/channel parity: if you support N output languages or channels, does the pipeline generate N of them, or does it silently favor whichever one was coded first?
Usage guide
- When to use it
- Right before you flip a content pipeline from “I click publish” to “a script clicks publish” — run through it once, not after something already broke.
- How to use it
- Go item by item against your actual pipeline code, not from memory — for each unchecked box, either fix it or consciously accept the risk in writing.
- What to expect
- A pipeline where a failure gets you pinged instead of silently skipped, and a bad auto-publish can be pulled with one command.
- Common mistake
- Treating this as a one-time audit — re-run it after any change to the pipeline’s schema, languages, or failure-handling code.
TipItem 8 is the one that actually broke this blog’s English output for a week — check it first.