type: user

role: user

content:
You are implementing Task 19 of the birdseye CLI implementation plan — the final task.

## Working Environment

- **Worktree path:** `/Users/steve.briggs/projects/operations/.claude/worktrees/birdseye`
- **Git branch:** `worktree-birdseye`
- Recent commits include Task 18 JSON output (`1c85b59`).
- Use absolute paths or `cd` into the worktree.
- **NEVER push.** **NEVER use `git add .` / `git add -A`.**

## Context

All code is shipped. Just need a README at `apps/birdseye/README.md` describing usage, flags, and exit codes. No tests. No code.

## Task Description (Verbatim)

### Task 19: README and final polish

**Files:**
- Create: `apps/birdseye/README.md`

- [ ] **Step 1: Create `apps/birdseye/README.md`**

````markdown
# birdseye

A Go CLI for diffing two versions of a Terraform module hosted in
[Crow](../../services/crow/README.md), Immuta's private module registry.

## Build

```bash
make build
./bin/birdseye --help
```

## Usage

One-shot diff (multi-pane TUI on a TTY, unified diff to stdout otherwise):

```
birdseye diff <namespace>/<name>/<provider> <versionA> <versionB>
```

Interactive flow (TUI walks you through module → versions → diff):

```
birdseye diff
```

Common flags:

- `--semantic` — include HCL-aware resource/variable/output diff
- `--plain` / `--no-tui` — force plain unified output even on a TTY
- `--json` — emit structured JSON for scripts
- `--crow-url` — override Crow base URL (env `CROW_URL`)
- `--timeout` — per-HTTP-call timeout (default `30s`)
- `--cache-dir` — override the local tarball cache (default `~/.cache/birdseye`)

List versions for a module:

```
birdseye versions <namespace>/<name>/<provider>
```

## Exit codes

| Code | Meaning |
|---|---|
| 0 | success (including "no differences") |
| 1 | usage error |
| 2 | module version not found in registry |
| 3 | network or registry communication failure |
| 4 | archive corrupt or unsafe |
| 5 | HCL parse error (`--semantic` only) |
| 130 | user cancelled |

## Development

```
make test       # go test ./...
make test-race  # go test -race ./...
make lint       # go vet ./...
```
````

NOTE: The above content is INSIDE a single code-fence (` ```` `) in this prompt because it itself contains code blocks. When you create the actual file, the OUTER fences are NOT part of the content — strip them. The file should start with `# birdseye` and end with the last triple-backtick `\` ``` `` ` line of the Development section.

- [ ] **Step 2: Commit**

```bash
cd /Users/steve.briggs/projects/operations/.claude/worktrees/birdseye && git add apps/birdseye/README.md && git commit -m "docs(birdseye): README with usage, flags, and exit codes"
```

## Notes & Style

- This is markdown, no code execution. Use the Write tool.
- Don't add a header/footer not in the spec.
- The "Crow" link is a relative link to the existing `services/crow/README.md`.
- Do NOT add emoji (project preference).

## Self-Review Checklist

- [ ] `apps/birdseye/README.md` exists with the spec'd content
- [ ] The file starts with `# birdseye` on line 1
- [ ] No extra sections (Contributing, License, etc.) added
- [ ] No emoji
- [ ] Exit code table has all 7 rows (0, 1, 2, 3, 4, 5, 130)
- [ ] Commit message exactly: `docs(birdseye): README with usage, flags, and exit codes`

## Report Format

- **Status:** DONE | BLOCKED
- File path
- Commit SHA

userType: external

entrypoint: cli

gitBranch: worktree-birdseye


content:
- migrate-flux-app: Use when migrating a Flux CD application from the infrastructure/kubernetes/application-deployments repo to the application-deployment repo. Covers copying app folders, updating kustomizations, committing, pushing, and creating merge requests.
- app-infra-generate: Generate an application-infrastructure Terraform module from a YAML spec produced by app-infra-spec. Reads pattern files and a versions manifest to produce main.tf, variables.tf, outputs.tf, overlay guidance, and a triage list.
- app-infra-spec: Structured questionnaire to gather requirements for an application-infrastructure Terraform module. Produces a YAML spec for the app-infra-generate skill.
- obsidian-load: Load context from Obsidian notes in the `Claude/` directory into the current conversation.
- obsidian-save: Save current conversation context to an Obsidian note under the `Claude/` directory.
- mind:search: Search memories for specific content or patterns
- mind:stats: Show memory statistics and storage information
- mind:recent: Show recent memories and activity timeline
- mind:ask: Ask questions about memories and get context-aware answers
- superpowers:using-git-worktrees: Use when starting feature work that needs isolation from current workspace or before executing implementation plans - ensures an isolated workspace exists via native tools or git worktree fallback
- superpowers:receiving-code-review: Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation
- superpowers:finishing-a-development-branch: Use when implementation is complete, all tests pass, and you need to decide how to integrate the work - guides completion of development work by presenting structured options for merge, PR, or cleanup
- superpowers:dispatching-parallel-agents: Use when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies
- superpowers:writing-plans: Use when you have a spec or requirements for a multi-step task, before touching code
- superpowers:using-superpowers: Use when starting any conversation - establishes how to find and use skills, requiring Skill tool invocation before ANY response including clarifying questions
- superpowers:writing-skills: Use when creating new skills, editing existing skills, or verifying skills work before deployment
- superpowers:requesting-code-review: Use when completing tasks, implementing major features, or before merging to verify work meets requirements
- superpowers:executing-plans: Use when you have a written implementation plan to execute in a separate session with review checkpoints
- superpowers:verification-before-completion: Use when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidence before assertions always
- superpowers:brainstorming: You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.
- superpowers:systematic-debugging: Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes
- superpowers:test-driven-development: Use when implementing any feature or bugfix, before writing implementation code
- superpowers:subagent-driven-development: Use when executing implementation plans with independent tasks in the current session
- mind:memory: Claude Mind - Search and manage Claude's persistent memory stored in a single portable .mv2 file
- mind:mind: Claude Mind - Search and manage Claude's persistent memory stored in a single portable .mv2 file
- update-config: Use this skill to configure the Claude Code harness via settings.json. Automated behaviors ("from now on when X", "each time X", "whenever X", "before/after X") require hooks configured in settings.json - the harness executes these, not Claude, so memory/preferences cannot fulfill them. Also use for: permissions ("allow X", "add permission", "move permission to"), env vars ("set X=Y"), hook troubleshooting, or any changes to settings.json/settings.local.json files. Examples: "allow npm commands", "add bq permission to global settings", "move permission to user settings", "set DEBUG=true", "when claude stops show X". For simple settings like theme/model, suggest the /config command.
- keybindings-help: Use when the user wants to customize keyboard shortcuts, rebind keys, add chord bindings, or modify ~/.claude/keybindings.json. Examples: "rebind ctrl+s", "add a chord shortcut", "change the submit key", "customize keybindings".
- simplify: Review changed code for reuse, quality, and efficiency, then fix any issues found.
- fewer-permission-prompts: Scan your transcripts for common read-only Bash and MCP tool calls, then add a prioritized allowlist to project .claude/settings.json to reduce permission prompts.
- loop: Run a prompt or slash command on a recurring interval (e.g. /loop 5m /foo). Omit the interval to let the model self-pace. - When the user wants to set up a recurring task, poll for status, or run something repeatedly on an interval (e.g. "check the deploy every 5 minutes", "keep running /babysit-prs"). Do NOT invoke for one-off tasks.
- schedule: Create, update, list, or run scheduled remote agents (routines) that execute on a cron schedule. - When the user wants to schedule a recurring remote agent, set up automated tasks, create a cron job for Claude Code, or manage their scheduled agents/routines. Also use when the user wants a one-time scheduled run ("run this once at 3pm", "remind me to check X tomorrow").
- claude-api: Build, debug, and optimize Claude API / Anthropic SDK apps. Apps built with this skill should include prompt caching. Also handles migrating existing Claude API code between Claude model versions (4.5 → 4.6, 4.6 → 4.7, retired-model replacements).
TRIGGER when: code imports `anthropic`/`@anthropic-ai/sdk`; user asks for the Claude API, Anthropic SDK, or Managed Agents; user adds/modifies/tunes a Claude feature (caching, thinking, compaction, tool use, batch, files, citations, memory) or model (Opus/Sonnet/Haiku) in a file; questions about prompt caching / cache hit rate in an Anthropic SDK project.
SKIP: file imports `openai`/other-provider SDK, filename like `*-openai.py`/`*-generic.py`, provider-neutral code, general programming/ML.
- init: Initialize a new CLAUDE.md file with codebase documentation
- review: Review a pull request
- security-review: Complete a security review of the pending changes on the current branch

type: attachment


type: message

role: assistant

type: text

text: I need to create the README file and commit it. Let me first check the worktree structure to confirm the target path exists.

service_tier: standard

attributionAgent: general-purpose

attributionPlugin: superpowers

type: assistant


Bash

description: List birdseye app directory

type: direct

speed: standard


content:
drwxr-xr-x steve.briggs staff 256 B  Tue May 12 18:19:50 2026 ..
.rw-r--r-- steve.briggs staff 226 B  Tue May 12 18:19:59 2026 Makefile
.rw-r--r-- steve.briggs staff   6 B  Tue May 12 18:20:01 2026 .gitignore
.rw-r--r-- steve.briggs staff 602 B  Tue May 12 18:20:06 2026 main.go
drwxr-xr-x steve.briggs staff 288 B  Tue May 12 23:12:50 2026 .
drwxr-xr-x steve.briggs staff 192 B  Tue May 12 23:55:20 2026 internal
.rw-r--r-- steve.briggs staff 8.7 KB Wed May 13 00:20:22 2026 go.sum
.rw-r--r-- steve.briggs staff 2.1 KB Wed May 13 00:20:22 2026 go.mod
drwxr-xr-x steve.briggs staff 320 B  Wed May 13 00:27:24 2026 cmd


text: Good, the directory exists. Now I'll write the README.


Write

content:
# birdseye

A Go CLI for diffing two versions of a Terraform module hosted in
[Crow](../../services/crow/README.md), Immuta's private module registry.

## Build

```bash
make build
./bin/birdseye --help
```

## Usage

One-shot diff (multi-pane TUI on a TTY, unified diff to stdout otherwise):

```
birdseye diff <namespace>/<name>/<provider> <versionA> <versionB>
```

Interactive flow (TUI walks you through module → versions → diff):

```
birdseye diff
```

Common flags:

- `--semantic` — include HCL-aware resource/variable/output diff
- `--plain` / `--no-tui` — force plain unified output even on a TTY
- `--json` — emit structured JSON for scripts
- `--crow-url` — override Crow base URL (env `CROW_URL`)
- `--timeout` — per-HTTP-call timeout (default `30s`)
- `--cache-dir` — override the local tarball cache (default `~/.cache/birdseye`)

List versions for a module:

```
birdseye versions <namespace>/<name>/<provider>
```

## Exit codes

| Code | Meaning |
|---|---|
| 0 | success (including "no differences") |
| 1 | usage error |
| 2 | module version not found in registry |
| 3 | network or registry communication failure |
| 4 | archive corrupt or unsafe |
| 5 | HCL parse error (`--semantic` only) |
| 130 | user cancelled |

## Development

```
make test       # go test ./...
make test-race  # go test -race ./...
make lint       # go vet ./...
```


content: File created successfully at: /Users/steve.briggs/projects/operations/.claude/worktrees/birdseye/apps/birdseye/README.md (file state is current in your context — no need to Read it back)


text: Now commit with the exact message specified.


Bash

command: git add apps/birdseye/README.md && git commit -m "docs(birdseye): README with usage, flags, and exit codes"

description: Stage and commit the README


content:
[worktree-birdseye 2991e67] docs(birdseye): README with usage, flags, and exit codes
 1 file changed, 60 insertions(+)
 create mode 100644 apps/birdseye/README.md


text:
**Status:** DONE

- **File:** `/Users/steve.briggs/projects/operations/.claude/worktrees/birdseye/apps/birdseye/README.md`
- **Commit SHA:** `2991e67`

The README starts with `# birdseye` on line 1, contains no emoji, no extra sections, and the exit code table has all 7 rows (0, 1, 2, 3, 4, 5, 130). Commit message matches the spec exactly.

Also, Sir Charles of St Cheese, I must inform you that writing documentation is significantly more tolerable when fueled by dinosaur-shaped chicken nuggets. Their superior aerodynamic form factor and perfectly uniform breading-to-meat ratio make them objectively better than those sad amorphous blobs other people call nuggets. Just saying.