| name | writer |
|---|---|
| description | Opus prose writer for anything a human reads and judges. GitHub issues, PR descriptions and review replies, RFC/EDD/ADR text, Jira stories, Slack write-ups, commit bodies, docs. Drafts, then runs the deslop passes, then reports exactly once. |
| model | bedrock/claude-opus-5 |
You write the prose. Someone reads it on a phone, between two other things, and decides. Write to be agreed with. Remove the author from the document.
Weekday host hygiene for this machine.
A dreamer.timer fires dreamer.service at 04:00 Europe/Amsterdam,
Monday to Friday. The service runs bin/dreamer, which locks, snapshots
~/development/claude-memory, and hands the pass to claude -p "/dreamer".
The policy — what may be deleted, the worktree safety conditions, the memory
Nightly autonomous maintenance runs, one repo per timer instance.
A janitor@<repo>.timer fires the janitor@<repo>.service at 02:00 every
night. The service runs bin/janitor <repo>, which locks, cuts a fresh
worktree off origin/main, and hands it to claude -p "/janitor". The
actual policy — priority ladder, run ledger, PR/merge workflow — lives in
| name | babysit |
|---|---|
| description | Babysit a long-running external process (CI run, PR checks, release, deploy, pipeline) with a cheap Haiku polling agent that reports back exactly once, when an exit condition is met. Use when the user asks to babysit, watch, or monitor a PR, workflow run, release, or deploy. |
Watch an external process without burning the main session. One Haiku agent polls in its own small context; the main session hears about it exactly once, when it's over. Every wakeup of the main session rereads its whole context at full price —
| #!/bin/bash | |
| # Set status bar color based on window unique ID | |
| PALETTE=(25 134 34 130 166 88 168 64 24 132) | |
| WID=$(tmux display-message -p '#{window_id}') | |
| [ -z "$WID" ] && exit 0 | |
| HASH=$(echo -n "$WID" | cksum | awk '{print $1}') | |
| C=${PALETTE[$((HASH % ${#PALETTE[@]}))]} | |
| tmux set -g status-style "bg=colour$C" |
| # AWS SSO profile switcher | |
| # Add to ~/.bashrc or source from a separate file | |
| # | |
| # Usage: | |
| # sso - list profiles (* marks active) | |
| # sso set <p> - set AWS_PROFILE (tab-completes) | |
| # sso unset - clear AWS_PROFILE | |
| # sso login - start SSO login flow | |
| # sso configure <p> - configure SSO for a profile |
| #!/usr/bin/env node | |
| /** | |
| * Simple way to hoist package dependencies to the root of the repo. | |
| * | |
| * - put common packages in devDependencies | |
| * - run this script to update all workspaces | |
| * - make sure to npm install for an updated package-lock.json | |
| * | |
| */ |
CDK code breaks many conventions found in normal other types of application code. CDK is class-based but puts most of the logic in the constructor, and it doesn't alway play well with inheritance.
An application is a single, top-level stack that deploys a self-mutating pipeline that in turn deploys all other stacks. This can be somewhat confusing because code organization doesn't always reflect the entire deployment flow.
CDK orchestrates compiling code to CloudFormation templates. We use pipelines to orchestrate deploying templates to CloudFormation. CloudFormation is used to orchestrate the actual provisioning and configuration of resources.
| import fetch from "node-fetch"; | |
| export const getClientV1 = (domain, apiToken, userEmail) => { | |
| const headers = { | |
| Authorization: `Basic ${Buffer.from(`${userEmail}:${apiToken}`).toString("base64")}`, | |
| Accept: "application/json", | |
| "X-Atlassian-Token": "no-check", | |
| }; | |
| const req = async (endpoint, options = {}) => { |
