docs: add repo-local Codex skills

.agents/skills/unic-update-dependencies/SKILL.md

@@ -0,0 +1,72 @@
+---
+name: unic-update-dependencies
+description: Use when the user asks to update, bump, refresh, audit, or modernize dependencies, libraries, Go modules, the Go language version, or Go toolchain support in the unic repository. Use for dependency maintenance PRs, safe patch/minor Go module updates, Go version bumps, vulnerability-driven dependency updates, or CI/doc updates tied to dependency or Go version changes. Do not use for unrelated feature work, docs-only edits, or CI refactors unless they are required by the dependency/toolchain update.
+---
+
+Update `unic` dependencies and Go toolchain support with conservative scope,
+clear validation, and repository workflow alignment.
+
+## Workflow
+
+1. Resolve intent and risk.
+- Treat "safe", "routine", or unspecified dependency updates as patch/minor
+  updates only.
+- Treat major version upgrades as opt-in. Do not apply them unless the user
+  explicitly asks for major upgrades or a specific module version.
+- Separate Go language/toolchain version bumps from dependency refreshes unless
+  the user asks for both.
+- If the user asks for "latest Go", verify the current stable Go release from
+  official Go sources before editing.
+
+2. Inspect repository state before editing.
+- Check `git status --short --branch`.
+- Read `go.mod` and identify the current `go` and `toolchain` directives.
+- Search for Go version pins in `.github/`, `Makefile`, `README.md`,
+  `Dockerfile*`, `.go-version`, `.tool-versions`, and scripts.
+- Inspect available module updates with `go list -m -u all`.
+- If network access blocks Go module or release checks, request escalation
+  instead of guessing.
+
+3. Plan the update.
+- For patch-only refreshes, prefer `go get -u=patch ./...`.
+- For safe minor refreshes, prefer explicit updates from `go list -m -u all`
+  or `go get -u ./...`, then review the diff.
+- For targeted updates, use `go get <module>@<version>` and keep unrelated
+  modules unchanged where practical.
+- For vulnerability work, update the minimum affected modules needed to resolve
+  the advisory, then run vulnerability checks if the toolchain is available.
+- For Go version bumps, update every repo-controlled Go version pin needed for
+  local build, CI, and docs consistency.
+
+4. Apply changes carefully.
+- Run the chosen `go get` command.
+- Run `go mod tidy`.
+- Review `git diff -- go.mod go.sum` before broadening scope.
+- Avoid unrelated formatting, generated churn, or feature refactors.
+- Update `README.md` or CI/docs only when supported Go version or setup
+  instructions changed.
+
+5. Validate.
+- Run `make test`.
+- Run `make build`.
+- If validation fails because dependencies changed, fix the failure or revert
+  the offending dependency update while preserving unrelated user changes.
+- If validation cannot be run, report the exact blocker.
+
+6. Ship only when requested.
+- Follow the repo rule: issue -> implementation -> feature branch -> PR.
+- If the user asks to open a PR and no issue is referenced, search open issues
+  first. If none matches, call out that a new issue is needed before shipping
+  unless the user explicitly approves an exception.
+- Use the `unic-ship-pr` workflow for staging, committing, pushing, and opening
+  the PR.
+
+## Output
+
+Report:
+- Go version changes, if any.
+- Direct and notable transitive dependency updates.
+- Major updates intentionally skipped.
+- Files changed.
+- Validation results for `make test` and `make build`.
+- Any follow-up needed for major upgrades, vulnerability checks, or PR shipping.

.agents/skills/unic-update-dependencies/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Update unic dependencies"
+  short_description: "Refresh Go toolchain and dependencies for unic."
+  default_prompt: "Use $unic-update-dependencies to update the Go version and refresh safe dependencies."

.agents/skills/unic-ux-review/SKILL.md

@@ -0,0 +1,101 @@
+---
+name: unic-ux-review
+description: Use when the user asks to run unic locally, capture TUI screenshots, review the Bubble Tea UX, suggest UX improvements, or optionally implement scoped UX polish in the unic repository. This skill is for terminal UI review and safe UX iteration, not for unrelated feature work, dependency updates, PR shipping, or non-UX code review.
+---
+
+# unic UX Review
+
+Review `unic` by running the real TUI, capturing reproducible screenshots, and
+turning the evidence into prioritized UX improvements. Implement only when the
+user asks for changes or clearly invites follow-through.
+
+## Workflow
+
+1. Start with repo safety.
+- Run `git status --short --branch`.
+- Note existing untracked or modified files and do not touch unrelated work.
+- If implementation will become PR work and no GitHub issue is referenced,
+  call out the repo rule that new work should map to an issue before shipping.
+
+2. Capture the current UI.
+- Prefer the bundled harness:
+  `python3 .agents/skills/unic-ux-review/scripts/capture_unic_tui.py`
+- The harness builds `./unic`, creates an isolated XDG config with fake
+  contexts, disables EC2 metadata, seeds the update cache, launches the real TUI
+  in `tmux`, captures the context picker and service picker, renders PNGs when
+  Pillow is available, and kills the `tmux` session.
+- If the command fails with a `tmux` socket or sandbox permission error, rerun
+  the same command with escalated permissions. Do not work around this by using
+  the user's real config.
+- Use `--out-dir /private/tmp/unic-ux-review` when you want predictable output.
+- Use `--skip-build` only after confirming a fresh `./unic` binary exists.
+
+3. Inspect the artifacts.
+- Open the generated PNGs with `view_image`.
+- Also inspect the raw `.txt` captures when alignment, wrapping, or truncation
+  needs exact terminal text.
+- Keep screenshot paths in the final answer so the user can open them.
+
+4. Review UX with a TUI-specific rubric.
+- Workflow clarity: does the first screen explain where the user is and what
+  action is expected?
+- Layout responsiveness: do panels use the available terminal width without
+  creating awkward empty regions?
+- Text fit: do status bars, help bars, table cells, and labels wrap or truncate
+  in avoidable ways at common sizes?
+- Visual hierarchy: can the user scan title, current context, selected row,
+  metadata, and available actions in that order?
+- Semantic consistency: do symbols such as `*`, cursor markers, colors, and
+  key names mean the same thing across screens?
+- Keyboard discoverability: are frequent actions visible without making the
+  help bar noisy or wrapped?
+- Existing style fit: preserve `unic`'s current Bubble Tea/Lip Gloss patterns,
+  column-aligned tables, dim labels, and compact terminal-first density.
+
+5. Suggest before changing when scope is broad.
+- Lead with concrete findings tied to screenshot evidence.
+- Prefer small, testable improvements such as table width allocation, help-bar
+  shortening, consistent markers, responsive panel widths, and clearer labels.
+- If the user asked to "maybe implement", choose only low-risk improvements
+  that are directly visible in the captured screens. Ask before larger redesigns
+  or behavior changes.
+
+6. Implement scoped improvements when appropriate.
+- Read the owning files before editing, usually `internal/app/styles.go`,
+  `internal/app/app.go`, `internal/app/screen_context.go`,
+  `internal/app/context_table.go`, and nearby tests.
+- Preserve existing Bubble Tea navigation and `visibleLines := max(m.height-N,
+  5)` style windowing where applicable.
+- Add or update tests for formatting helpers, view rendering, and key UX
+  invariants when possible.
+- Run `make test` and `make build` after behavior or rendering changes.
+- Rerun the capture harness after edits and compare screenshots.
+- Update `README.md` only if visible behavior, key bindings, or configuration
+  semantics changed.
+
+## Blocked Capture Fallback
+
+If the real TUI cannot be launched in the current environment:
+
+- Capture the exact failure and say why it blocks screenshot generation.
+- Devise a plan using the same isolated-config approach on the user's machine.
+- If useful, add or propose a test-only render harness that instantiates
+  `app.Model` with fixture config and writes `View()` output at fixed sizes.
+- Do not claim UX findings from imagined screenshots; separate hypotheses from
+  observed evidence.
+
+## Output Shape
+
+For review-only work, report:
+
+- screenshot paths
+- 3-7 prioritized findings
+- suggested implementation order
+- any capture limitations
+
+For implemented work, report:
+
+- what changed
+- before/after screenshot paths or a concise visual comparison
+- tests and build commands run
+- remaining UX follow-ups

.agents/skills/unic-ux-review/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Review unic UX"
+  short_description: "Capture unic TUI screenshots and turn them into UX improvements."
+  default_prompt: "Use $unic-ux-review to run unic locally, capture TUI screenshots, review UX issues, and optionally implement scoped improvements."