@xiaotianxt/skills 0.1.0

package/skills/panopto-mp4-bulk-download/SKILL.md

@@ -0,0 +1,57 @@
+---
+name: panopto-mp4-bulk-download
+description: Extract real downloadable mp4 URLs from Panopto and similar HLS lecture players, then batch-download all lectures with manifests and retry logic. Use when users ask to download many class videos from a logged-in Panopto folder, to automate IDM-style URL discovery, or to derive fragmented.mp4 links from Viewer pages.
+---
+
+# Panopto MP4 Bulk Download
+
+## Use This Workflow
+
+1. Ensure the user is already logged into Panopto in `agent-browser`.
+2. Use a headed persistent session (`~/.agent-browser-session`).
+3. Pass the folder list URL to the bundled script.
+
+## Run The Bundled Script
+
+```bash
+scripts/panopto_bulk_mp4.sh "<panopto-folder-list-url>" "<output-dir>" "<manifest-dir>"
+```
+
+Example:
+
+```bash
+scripts/panopto_bulk_mp4.sh \
+  "https://scs.hosted.panopto.com/Panopto/Pages/Sessions/List.aspx?...#folderID=%22...%22" \
+  "downloads/panopto_mp4" \
+  "downloads/panopto_manifests"
+```
+
+## What The Script Does
+
+1. Open the folder list page in `agent-browser`.
+2. Extract all lecture `Viewer.aspx?id=...` links.
+3. Open each lecture page and click Play.
+4. Read browser `performance` entries to capture media URLs.
+5. Prefer `/fragmented.mp4`; if absent, derive it from `/index.m3u8`.
+6. Download all videos with `curl -L` retries.
+7. Write manifests and failure reports.
+
+## Required Behavior During Manual Automation
+
+1. For every `agent-browser open`, always use `--headed --session <name>`.
+2. If `open` fails, immediately run:
+
+```bash
+agent-browser --session <name> close
+agent-browser --headed --session <name> open <url>
+```
+
+## Outputs
+
+- `lecture_mp4_manifest.tsv`: lecture metadata and extracted mp4 URLs
+- `extract_failed.txt`: lecture pages where URL extraction failed
+- `download_failed.txt`: downloads that failed after retries
+
+## References
+
+- URL patterns and quick JS snippets: `references/url-patterns.md`

package/skills/panopto-mp4-bulk-download/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Panopto MP4 Bulk Download"
+  short_description: "Extract Panopto mp4 links and bulk-download lectures."
+  default_prompt: "Use $panopto-mp4-bulk-download to extract real Panopto mp4 URLs and download all lecture videos in bulk."

package/skills/panopto-mp4-bulk-download/references/url-patterns.md

@@ -0,0 +1,26 @@
+# URL Patterns
+
+## Panopto viewer page
+
+- `https://<tenant>/Panopto/Pages/Viewer.aspx?id=<delivery-id>`
+
+## Common media URLs discovered at runtime
+
+- Master playlist:
+  - `https://...cloudfront.net/sessions/<session-id>/<delivery-id>-<stream-guid>.hls/master.m3u8?...`
+- Rendition playlist:
+  - `https://...cloudfront.net/sessions/<session-id>/<delivery-id>-<stream-guid>.hls/<bitrate>/index.m3u8`
+- Direct MP4 segment file (preferred for direct download):
+  - `https://...cloudfront.net/sessions/<session-id>/<delivery-id>-<stream-guid>.hls/<bitrate>/fragmented.mp4`
+
+## Runtime extraction snippet (in browser context)
+
+```js
+const names = performance.getEntriesByType('resource').map(e => e.name);
+const mp4 = [...new Set(names.filter(u => /\/fragmented\.mp4(\?|$)/i.test(u)))];
+const m3u8 = [...new Set(names.filter(u => /\/index\.m3u8(\?|$)/i.test(u)))];
+```
+
+If no direct mp4 is found but `index.m3u8` exists, derive:
+
+- `.../index.m3u8` -> `.../fragmented.mp4`

package/skills/panopto-mp4-bulk-download/scripts/panopto_bulk_mp4.sh

@@ -0,0 +1,213 @@
+#!/usr/bin/env bash
+set -euo pipefail
+
+usage() {
+  cat <<'USAGE'
+Usage:
+  scripts/panopto_bulk_mp4.sh "<panopto-folder-list-url>" [output-dir] [manifest-dir]
+
+Example:
+  scripts/panopto_bulk_mp4.sh \
+    "https://scs.hosted.panopto.com/Panopto/Pages/Sessions/List.aspx?...#folderID=%22...%22" \
+    downloads/panopto_mp4 \
+    downloads/panopto_manifests
+USAGE
+}
+
+if ! command -v agent-browser >/dev/null 2>&1; then
+  echo "agent-browser is required but not installed." >&2
+  exit 1
+fi
+if ! command -v jq >/dev/null 2>&1; then
+  echo "jq is required but not installed." >&2
+  exit 1
+fi
+if ! command -v curl >/dev/null 2>&1; then
+  echo "curl is required but not installed." >&2
+  exit 1
+fi
+
+FOLDER_URL="${1:-}"
+OUT_DIR="${2:-downloads/panopto_mp4}"
+MANIFEST_DIR="${3:-downloads/panopto_manifests}"
+
+if [[ -z "$FOLDER_URL" ]]; then
+  usage
+  exit 1
+fi
+
+SESSION_FILE="${SESSION_FILE:-$HOME/.agent-browser-session}"
+DEFAULT_SESSION="visual"
+if [[ ! -f "$SESSION_FILE" ]]; then
+  printf '%s\n' "$DEFAULT_SESSION" > "$SESSION_FILE"
+fi
+SESSION="$(tr -d '[:space:]' < "$SESSION_FILE")"
+if [[ -z "$SESSION" ]]; then
+  SESSION="$DEFAULT_SESSION"
+fi
+
+mkdir -p "$OUT_DIR" "$MANIFEST_DIR"
+
+LECTURES_RAW="$MANIFEST_DIR/lectures_raw.json"
+LECTURES_JSON="$MANIFEST_DIR/lectures.json"
+MANIFEST_TSV="$MANIFEST_DIR/lecture_mp4_manifest.tsv"
+EXTRACT_FAILS="$MANIFEST_DIR/extract_failed.txt"
+DOWNLOAD_FAILS="$MANIFEST_DIR/download_failed.txt"
+
+open_page() {
+  local url="$1"
+
+  if agent-browser --headed --session "$SESSION" open "$url" >/dev/null 2>&1; then
+    return 0
+  fi
+
+  # Required fallback when open fails.
+  agent-browser --session "$SESSION" close >/dev/null 2>&1 || true
+  agent-browser --headed --session "$SESSION" open "$url" >/dev/null
+}
+
+extract_mp4_url() {
+  local raw="" parsed=""
+
+  agent-browser --session "$SESSION" eval '(()=>{const sels=["button[aria-label=\"Play\"]","button[title=\"Play\"]","button.vjs-play-control","button[aria-label*=\"Play\"]"];for(const s of sels){const b=document.querySelector(s);if(b){b.click();return "clicked";}}return "no-play-button";})()' >/dev/null 2>&1 || true
+  agent-browser --session "$SESSION" wait 4500 >/dev/null || true
+
+  raw="$(agent-browser --session "$SESSION" eval --stdin <<'EVALEOF'
+(() => {
+  const names = performance.getEntriesByType('resource').map(e => e.name);
+  const mp4 = [...new Set(names.filter(u => /\/fragmented\.mp4(\?|$)/i.test(u)))];
+  if (mp4.length) return mp4[0];
+
+  const m3u8 = [...new Set(names.filter(u => /\/index\.m3u8(\?|$)/i.test(u)))];
+  if (m3u8.length) return m3u8[0].replace(/\/index\.m3u8(\?.*)?$/i, '/fragmented.mp4');
+
+  return "";
+})()
+EVALEOF
+)" || true
+
+  parsed="$(printf '%s' "$raw" | jq -r . 2>/dev/null || true)"
+  if [[ "$parsed" == "null" ]]; then
+    parsed=""
+  fi
+
+  printf '%s' "$parsed"
+}
+
+echo "Using session: $SESSION"
+echo "Folder URL: $FOLDER_URL"
+
+open_page "$FOLDER_URL"
+agent-browser --session "$SESSION" wait 4000 >/dev/null || true
+
+agent-browser --session "$SESSION" eval --stdin <<'EVALEOF' > "$LECTURES_RAW"
+(() => {
+  const rows = [...document.querySelectorAll('a.detail-title[href*="Viewer.aspx?id="]')]
+    .map(a => ({
+      title: (a.textContent || '').trim().replace(/\s+/g, ' '),
+      viewer: a.href,
+      id: (a.href.match(/[?&]id=([0-9a-f-]+)/i) || [])[1] || null
+    }))
+    .filter(x => /^Lecture\s+\d+/i.test(x.title));
+
+  const uniq = [];
+  const seen = new Set();
+  for (const row of rows) {
+    if (!row.id || seen.has(row.id)) continue;
+    seen.add(row.id);
+    uniq.push(row);
+  }
+
+  uniq.sort((a, b) => {
+    const na = parseInt((a.title.match(/^Lecture\s+(\d+)/i) || [])[1] || '0', 10);
+    const nb = parseInt((b.title.match(/^Lecture\s+(\d+)/i) || [])[1] || '0', 10);
+    return na - nb;
+  });
+
+  return JSON.stringify(uniq, null, 2);
+})()
+EVALEOF
+
+jq -r . "$LECTURES_RAW" > "$LECTURES_JSON"
+TOTAL="$(jq 'length' "$LECTURES_JSON")"
+
+if [[ "$TOTAL" -eq 0 ]]; then
+  echo "No lecture rows found." >&2
+  exit 2
+fi
+
+printf 'index\ttitle\tid\tviewer\tmp4\tfile\n' > "$MANIFEST_TSV"
+: > "$EXTRACT_FAILS"
+: > "$DOWNLOAD_FAILS"
+
+for ((i=0; i<TOTAL; i++)); do
+  title="$(jq -r ".[$i].title" "$LECTURES_JSON")"
+  viewer="$(jq -r ".[$i].viewer" "$LECTURES_JSON")"
+  id="$(jq -r ".[$i].id" "$LECTURES_JSON")"
+
+  printf '[%d/%d] Extracting: %s\n' "$((i+1))" "$TOTAL" "$title"
+
+  open_page "$viewer"
+  agent-browser --session "$SESSION" wait 3500 >/dev/null || true
+
+  mp4_url="$(extract_mp4_url)"
+  if [[ -z "$mp4_url" ]]; then
+    agent-browser --session "$SESSION" wait 3000 >/dev/null || true
+    mp4_url="$(extract_mp4_url)"
+  fi
+
+  safe_title="$(printf '%s' "$title" | sed 's#[/:*?"<>|]#_#g; s/[[:space:]]\+/ /g')"
+  out_file="$OUT_DIR/${safe_title}.mp4"
+
+  if [[ -z "$mp4_url" ]]; then
+    printf '%s\t%s\t%s\n' "$id" "$title" "$viewer" >> "$EXTRACT_FAILS"
+    printf '[%d/%d] FAIL extract: %s\n' "$((i+1))" "$TOTAL" "$title"
+    continue
+  fi
+
+  printf '%s\t%s\t%s\t%s\t%s\t%s\n' \
+    "$((i+1))" "$title" "$id" "$viewer" "$mp4_url" "$out_file" >> "$MANIFEST_TSV"
+done
+
+FOUND="$(($(wc -l < "$MANIFEST_TSV") - 1))"
+echo "Extraction complete: $FOUND/$TOTAL URLs found"
+
+if [[ "$FOUND" -eq 0 ]]; then
+  echo "No mp4 URLs extracted." >&2
+  exit 3
+fi
+
+ok=0
+fail=0
+while IFS=$'\t' read -r idx title id viewer mp4_url out_file; do
+  if [[ "$idx" == "index" ]]; then
+    continue
+  fi
+
+  if [[ -s "$out_file" ]]; then
+    printf '[%s/%s] SKIP existing: %s\n' "$idx" "$FOUND" "$out_file"
+    ok=$((ok + 1))
+    continue
+  fi
+
+  mkdir -p "$(dirname "$out_file")"
+  printf '[%s/%s] Downloading: %s\n' "$idx" "$FOUND" "$title"
+
+  if curl -L --retry 4 --retry-delay 2 --connect-timeout 20 --max-time 0 -o "$out_file" "$mp4_url"; then
+    ok=$((ok + 1))
+  else
+    rm -f "$out_file"
+    printf '%s\t%s\t%s\n' "$title" "$mp4_url" "$out_file" >> "$DOWNLOAD_FAILS"
+    fail=$((fail + 1))
+  fi
+done < "$MANIFEST_TSV"
+
+echo "Done. Success=$ok Failed=$fail"
+echo "Output: $OUT_DIR"
+echo "Manifest: $MANIFEST_TSV"
+echo "Extract fails: $EXTRACT_FAILS"
+echo "Download fails: $DOWNLOAD_FAILS"
+
+if [[ "$fail" -gt 0 ]]; then
+  exit 4
+fi

package/skills/rust-systems-style/SKILL.md

@@ -0,0 +1,109 @@
+---
+name: rust-systems-style
+description: "Use when Codex is writing, editing, reviewing, or designing Rust systems code, Rust CLIs, async runtimes, FFI wrappers, unsafe abstractions, security-sensitive crates, local-first developer tools, or code style guidance for this user's Rust projects. Also use when a non-Rust engineering task would benefit from the same discipline: small APIs, explicit invariants, reviewable failure behavior, and conservative dependency/security choices."
+---
+
+# Rust Systems Style
+
+Use this skill as an engineering governor, not a formatting checklist. The aim is code that can be read under pressure, reviewed locally, and trusted at the boundary where types, operating systems, networks, files, processes, and humans fail.
+
+This is not a product-shipping workflow. When creating a new CLI product, use
+`ship-ai-native-cli` for product scope and release shape, then apply this skill
+continuously to the Rust and systems-code decisions.
+
+## Operating Posture
+
+Before editing, ask what must remain true after this change:
+
+- Which invariant is being protected, moved, or newly introduced?
+- Which failure is environmental, user-caused, adversarial, or impossible by construction?
+- Which behavior is mechanism, and which behavior is policy?
+- Which API surface will future callers have to live with?
+- Which parts of the change are mechanical, and which parts change meaning?
+
+Prefer the smallest change that makes these answers more local and easier to audit.
+
+## Style Hierarchy
+
+Follow local project style first, then this skill, then the primary sources in [style-sources.md](references/style-sources.md). Use `rustfmt` defaults unless the repository already has a different checked-in configuration.
+
+When sources conflict, choose the rule that improves reviewability for the current repository. In this user's Rust CLI/tool projects, prefer:
+
+- `rustfmt` formatting and explicit import grouping if the project already groups imports.
+- Small modules with clear ownership over broad utility files.
+- Mechanism separated from policy, especially around CLI behavior, retries, caching, logging, and FFI.
+- Safe public APIs over exposing raw pointers, handles, unchecked states, or caller-managed invariants.
+- Dependency restraint and local-first behavior when code touches private user data.
+- Semantic boundaries over cosmetic boundaries: extract modules around domain ownership, invariants, and failure behavior rather than file size alone.
+- Neutral internal vocabulary for sensitive local-first tools: confine upstream schema names, provider names, and raw protocol terminology to narrow adapter/dictionary layers when those names create privacy, security, or product-surface risk.
+
+## Rust Rules
+
+Design APIs so callers can do the right thing without remembering hidden rules:
+
+- Use concrete domain types and newtypes when `bool`, `usize`, `String`, or `Option<T>` would hide meaning.
+- Prefer `Result` for recoverable failure. Do not turn environmental failure into panic.
+- Avoid `unwrap` and `expect` in production paths unless a local invariant makes failure impossible; leave a short comment for that invariant.
+- Prefer parse/construct-once APIs that make invalid states unrepresentable over `validate` methods on already-invalid objects.
+- Keep function arguments readable. Around six parameters is a design prompt for an options struct or a smaller responsibility.
+- Put conversions on the most specific involved type. Use `From`, `TryFrom`, `AsRef`, and `AsMut` when they match the semantics.
+- Keep public dependencies, features, re-exports, and configuration knobs small. Add a knob only when a caller genuinely needs policy control.
+- Prefer exhaustive matches for closed enums. Use catch-all patterns only for intentionally open or `#[non_exhaustive]` types.
+- Treat ignored results as a review event. Bind them with a type or name when discarding is intentional.
+- Avoid storing derived state when a named method can compute the value from canonical fields. If the derived value is policy, name the policy explicitly.
+- Keep debug tools out of the default shipped surface. Gate diagnostic binaries, verbose probes, and risky helpers behind explicit features or separate commands, and keep those features covered by CI.
+
+For deeper Rust review, read [rust-review-checklist.md](references/rust-review-checklist.md).
+
+## Layout And Path Types
+
+For filesystem layout structs, store canonical roots or externally supplied
+paths, not every derived child path. Prefer named methods such as `slots_dir()`,
+`state_file()`, or `cache_path()` for paths computed from roots.
+
+Treat repeated fixture updates, broad struct literal churn, or adding a new field
+to many unrelated tests as a design warning. Before continuing, ask whether the
+new value is canonical state, policy, or merely derived layout. Derived layout
+belongs behind methods on the owning path type.
+
+A path/layout type should keep topology local: callers may ask for named paths,
+but should not need to know how the directory tree is assembled.
+
+## Unsafe Rules
+
+Unsafe code is a proof obligation. Write it so a reviewer can check the proof without reconstructing the whole program.
+
+- Avoid `unsafe` unless it is needed for FFI/platform calls, a carefully designed abstraction, or measured performance.
+- Keep unsafe operations localized. Prefer a small unsafe core behind a safe API that restores invariants before returning.
+- Enable or honor `unsafe_op_in_unsafe_fn`; unsafe functions still need explicit unsafe blocks around unsafe operations.
+- Put `// SAFETY:` immediately before every unsafe block or unsafe impl. Explain why each precondition is met, not merely that it is safe.
+- Document every unsafe function or trait with a `# Safety` section explaining the caller or implementor contract.
+- For performance-motivated unsafe, require a benchmark or a precise reason why safe code is unacceptable.
+- Audit the whole module when changing code near unsafe, because safe-looking edits can break an unsafe invariant at a distance.
+
+## Tests And Verification
+
+Scale verification to the blast radius:
+
+- Run `cargo fmt --all -- --check`, `cargo clippy --all-targets -- -D warnings`, and `cargo test` when the project supports them.
+- Prefer `--all-features` in CI when optional features contain shipped, debug, or diagnostic code that should not bitrot.
+- Add focused tests for new behavior, regression fixes, parsing boundaries, and user-visible CLI errors.
+- For async/concurrency primitives, consider deterministic concurrency tests such as loom if the project already uses it.
+- For unsafe or low-level parsing, consider Miri, fuzzing, property tests, or adversarial tests when practical.
+- Keep tests readable top-to-bottom. Prefer Arrange-Act-Assert, explicit inputs and expected outputs, and separate tests for separate behaviors.
+
+## Review Stance
+
+When reviewing or editing, lead with bugs and risk:
+
+- Hidden policy in low-level code.
+- Silent fallback, ignored flags, swallowed errors, or logs that obscure what happened.
+- Unbounded retries, timeouts without enforcement, or operations that can block destructors/drop paths.
+- Public APIs that expose implementation details or force callers into unsafe usage.
+- New dependencies whose maintenance, transitive code, unsafe usage, or license cost is not justified.
+- Refactors mixed with behavior changes in a way that makes review harder.
+- Source vocabulary leaks: names from private schemas, vendors, protocols, or internal file layouts spreading beyond the narrow layer that has to speak them.
+- Default build and release surfaces that include exploratory tools, secret-printing diagnostics, or other code paths not intended for normal users.
+- CI and release warnings with dated deadlines. Treat them as maintenance debt before the deadline turns into a broken release path.
+
+Do not beautify code for its own sake. Improve code when the change makes ownership, invariants, failure, or review boundaries clearer.

package/skills/rust-systems-style/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Rust Systems Style"
+  short_description: "Write and review disciplined Rust systems code"
+  default_prompt: "Use $rust-systems-style to write or review this Rust code with disciplined systems-programming taste."

package/skills/rust-systems-style/references/rust-review-checklist.md

@@ -0,0 +1,77 @@
+# Rust Review Checklist
+
+Load this when doing a serious Rust implementation or review. It is intentionally phrased as questions because the right answer depends on the local codebase.
+
+## Boundaries
+
+- Does each module own one coherent concept?
+- Is CLI or request handling limited to parsing, orchestration, presentation, and exit behavior?
+- Are domain rules kept near the domain types that define them?
+- Is policy separated from mechanism, especially in cache, retry, logging, networking, and FFI code?
+- Are mechanical moves separated from behavior changes where review would benefit?
+
+## API Shape
+
+- Can callers discover the happy path from types and names?
+- Does the function belong as a method on one of its arguments?
+- Do arguments proceed from specific domain value to broader context?
+- Would an options struct make call sites clearer?
+- Do `bool`, `Option<T>`, integer, or string parameters deserve a domain enum/newtype?
+- Are conversions expressed with standard traits where that is idiomatic?
+- Are public structs protected against future field changes?
+- Are enums intentionally exhaustive or intentionally open?
+- Are re-exports limited to paved paths users actually need?
+
+## Errors And Panics
+
+- Is every recoverable environmental failure returned as `Result`?
+- Is each error meaningful at the layer where it is emitted?
+- Are errors wrapped with enough context without leaking sensitive data?
+- Are panics limited to invariant violations, tests, or impossible states?
+- If `unwrap` or `expect` remains in production code, is the invariant local and obvious?
+- Are timeouts, cancellation, interruption, and partial writes handled where relevant?
+- Are stdout, stderr, logs, and exit codes assigned consistently for CLI users and agents?
+
+## Unsafe And FFI
+
+- Is `unsafe` necessary, and is the reason documented?
+- Is unsafe contained behind a safe abstraction that restores invariants?
+- Does every `unsafe` block or `unsafe impl` have an adjacent `// SAFETY:` proof?
+- Does every unsafe function or trait have a `# Safety` contract?
+- Are raw pointers, FDs, handles, ownership transfer, aliasing, alignment, initialization, lifetimes, and thread-safety all accounted for?
+- Are `Send`/`Sync` impls treated as global promises rather than local conveniences?
+- Is FFI wrapped in a minimal, idiomatic Rust API?
+- Were nearby safe changes reviewed for effects on unsafe invariants?
+
+## Concurrency And Async
+
+- Are shared states explicit about ownership and synchronization?
+- Are cancellation and drop behavior understood?
+- Can a lock be held across `.await` or a blocking call?
+- Are retries bounded and observable?
+- Does logging help diagnose races or timing without overwhelming production logs?
+- Does the project need deterministic concurrency tests, loom, Miri, or fuzzing for this change?
+
+## Tests
+
+- Does each test name behavior and expected outcome?
+- Can a reviewer read the test top-to-bottom without chasing critical helper behavior?
+- Are edge cases chosen because they guard an invariant?
+- Is a regression test tied to the bug's actual failure mode?
+- Are public APIs covered at the level users consume them?
+- Are examples and doctests succinct and correct when docs are part of the surface?
+
+## Dependencies And Supply Chain
+
+- Is the dependency necessary enough to justify its transitive code and maintenance cost?
+- Does it introduce unsafe, native build steps, network behavior, crypto, or secret handling?
+- Does the license fit the project?
+- Can the standard library or an existing dependency solve the problem cleanly?
+- Does adding a feature flag create a support matrix the project is ready to test?
+
+## Final Pass
+
+- Does the code reveal the invariant where it matters?
+- Does it fail in a way the caller or operator can act on?
+- Is the smallest risky region also the most heavily documented and tested?
+- Would a future reviewer need less working memory after this change than before?

package/skills/rust-systems-style/references/style-sources.md

@@ -0,0 +1,68 @@
+# Style Sources
+
+This reference compresses the source documents behind the skill. Load it when you need to justify a rule, resolve a style conflict, or explain the taste behind a Rust systems-programming decision.
+
+## Primary Sources
+
+- Rust Style Guide: `rustfmt` defaults, 4-space indentation, 100-column line width, block indent over visual indent, trailing commas for multiline lists, line comments over block comments, doc comments before attributes.
+  - https://doc.rust-lang.org/style-guide/
+- Rust API Guidelines: naming, conversions, common traits, error types, documentation, predictability, type safety, future-proofing, dependency/license expectations.
+  - https://rust-lang.github.io/api-guidelines/checklist.html
+- Standard Library safety comments policy: every unsafe block needs `// SAFETY:`; unsafe functions need caller contracts in `# Safety`; `unsafe_op_in_unsafe_fn` makes unsafe operations locally reviewable.
+  - https://std-dev-guide.rust-lang.org/policy/safety-comments.html
+- Rust for Linux coding guidelines: use rustfmt defaults, keep comments/doc comments Markdown-like, distinguish implementation comments from API docs, document panics and safety, prefer `expect` over `allow` for temporary lint suppressions when appropriate.
+  - https://docs.kernel.org/rust/coding-guidelines.html
+- crosvm coding style: prefer mechanism over policy, security over reuse/speed, single-responsibility functions, avoid large argument lists and rightward drift, minimize unsafe, write standard safety statements, make unit tests readable.
+  - https://crosvm.dev/book/contributing/coding_style.html
+- Firecracker contribution standards: separate logical changes, tests and style must pass, public functions need docs, unsafe is heavily discouraged, performance unsafe needs evidence, avoid `unwrap`/`expect` in production paths.
+  - https://github.com/firecracker-microvm/firecracker/blob/main/CONTRIBUTING.md
+- Wasmtime coding guidelines: rustfmt in CI, warnings as errors, selective Clippy, all-target Clippy, MSRV awareness, dependency and safety discipline in a runtime/sandbox project.
+  - https://docs.wasmtime.dev/contributing-coding-guidelines.html
+- Fuchsia Rust Rubric and Netstack Rust Patterns: reviewable code with less working memory, explicit ignored results, careful imports, exhaustive matches where possible, useful log severity, detailed unsafe justification.
+  - https://fuchsia.dev/fuchsia-src/development/api/rust
+  - https://fuchsia.dev/fuchsia-src/contribute/contributing-to-netstack/rust-patterns
+- Chromium Rust style, API design, and unsafe policy: follow Rust style/API guidelines, APIs must be usable and minimize misuse, safe API around FFI, unsafe changes need specialized review, dependencies need audit attention.
+  - https://chromium.googlesource.com/chromium/src/+/main/styleguide/rust/rust.md
+  - https://chromium.googlesource.com/chromium/src/+/main/docs/rust/api_design.md
+  - https://chromium.googlesource.com/chromium/src/+/refs/tags/135.0.7018.2/docs/rust-unsafe.md
+- rustls contributing guide: clean commit history, top-down module ordering, type-local methods, parse-don't-validate, error handling over panics, safe defaults, small mandatory API, separate mechanism and policy.
+  - https://github.com/rustls/rustls/blob/main/CONTRIBUTING.md
+- Tokio contributing guide: feature-aware build/test commands, docs.rs-equivalent docs, integration/doc/fuzz tests, Miri and loom for relevant low-level async changes, logical commits.
+  - https://github.com/tokio-rs/tokio/blob/master/docs/contributing/pull-requests.md
+- Android Rust docs: Rust is used for native OS components; value expressive types, mandatory error handling, explicit integer conversions, initialization, platform lint sets, and clippy in Android builds.
+  - https://source.android.com/docs/setup/build/rust/building-rust-modules/overview
+  - https://source.android.com/docs/setup/build/rust/building-rust-modules/android-rust-modules
+- PingCAP/TiKV style guide: Rustfmt/Clippy, Rust conventions even near FFI/protobuf boundaries, careful modules/data structures/traits/error/performance guidance, benchmark-backed unsafe performance choices.
+  - https://pingcap.github.io/style-guide/rust/
+  - https://pingcap.github.io/style-guide/rust/unsafe.html
+- Ferrocene Safety Manual, handling unsafety: localize unsafety, keep unsafe modules single-purpose, use assertions/preconditions/postconditions/invariants, review the whole module, test unsafe code and clients.
+  - https://public-docs.ferrocene.dev/main/safety-manual/rustc/unsafety.html
+
+## Compressed Taste
+
+The strongest documents converge on one idea: style is a way of lowering audit cost.
+
+- Formatting exists to remove argument and conserve attention.
+- Names should reveal domain meaning, not implementation convenience.
+- APIs should make illegal states hard to express and dangerous states visibly named.
+- Failure should be explicit at the boundary where it can be handled.
+- Unsafe code should read like a proof with a small trusted base.
+- Tests should be executable explanations of behavior, not only coverage counters.
+- Dependencies are part of the codebase's risk surface.
+- Local style matters because rhythm helps readers notice semantic anomalies.
+
+## Conflict Resolution
+
+Use this order when documents disagree:
+
+1. Repository style and existing automated checks.
+2. Safety/security/reviewability.
+3. Public API compatibility.
+4. Rust ecosystem conventions.
+5. Personal preference.
+
+Examples:
+
+- crosvm prefers one imported item per `use`; Fuchsia groups imports by crate/direct child module. Follow the repository's established import style and keep provenance obvious.
+- Some projects avoid Clippy's default set as too noisy; others require `-D warnings`. Run the project's configured command first. Add stricter Clippy only when it is already expected or the user asks for governance cleanup.
+- Some documents prefer exhaustive matches, while open extensible types need catch-all handling. Match exhaustively for closed local enums; use catch-all for `#[non_exhaustive]` or protocol types designed to evolve.

package/skills/ship-ai-native-cli/SKILL.md

@@ -0,0 +1,76 @@
+---
+name: ship-ai-native-cli
+description: Use when Codex should turn a local pain point, repeated workflow, API wrapper, or automation idea into a small shippable AI-native CLI product, especially a Rust CLI with GitHub repository, CI, release automation, Homebrew formula, install command, README, architecture docs, and optional Codex skill integration. Trigger for requests like "make this into a tool", "create a ~/dev project like tg/cx/mon", "ship a CLI product", "wrap this API for agents", "add Homebrew/GitHub release", or "abstract this workflow into a reusable developer product".
+---
+
+# Ship AI-Native CLI
+
+Use this skill to convert a concrete workflow into a small product, not a pile
+of scripts. The pattern is distilled from `~/dev/tg`, `~/dev/cx`, `~/dev/mon`,
+their release history, and the Codex sessions that shaped them.
+
+This is a product-workflow skill. When the product is Rust or systems-facing,
+use `rust-systems-style` as the engineering governor rather than expanding Rust
+style rules here.
+
+## Operating Rule
+
+Before coding, identify the product boundary:
+
+- **User job**: the thing the user wants done in one command.
+- **Primary commands**: the smallest stable surface that satisfies that job.
+- **Agent contract**: JSON output, deterministic errors, no secret leakage.
+- **Non-goals**: domain-specific workflows that should live outside the generic tool.
+- **Ship target**: local install, GitHub repo, release asset, Homebrew formula.
+
+If the user asks for a `tg`/`cx`/`mon`-style product, default to a Rust CLI with
+the release shape in [rust-cli-shape.md](references/rust-cli-shape.md).
+
+## Workflow
+
+1. **Ground the product**
+   - Inspect existing project/workflow/logs before naming abstractions.
+   - Write a one-sentence product frame and a short command taxonomy.
+   - Keep the first slice narrow enough to test with real data today.
+
+2. **Build the vertical slice**
+   - Start with `clap` commands, local config/session paths, and one useful data command.
+   - Prefer direct structured APIs over browser automation or ad hoc parsing.
+   - Add `doctor` for diagnostics and `install` for local adoption.
+   - Make `--json` available for commands agents will consume.
+
+3. **Design failure behavior**
+   - Treat auth, permissions, rate limits, missing local files, and changed upstream APIs as product features.
+   - Fail loudly with actionable errors; do not retry blindly.
+   - Reuse valid sessions/tokens before hitting login or expensive endpoints.
+
+4. **Package while building**
+   - Keep `README.md`, `docs/architecture.md`, `SKILL.md`, `Makefile`, `scripts/install.sh`,
+     CI, and release workflow current as part of the implementation.
+   - Avoid docs that describe internals in the user-facing skill unless users need them.
+   - Use release artifacts in Homebrew so users do not install Rust just to use the tool.
+
+5. **Verify with reality**
+   - Run `cargo fmt --all -- --check`, `cargo check`, `cargo test`, release build, and CLI help.
+   - Smoke-test against the real local app/API/data source when possible.
+   - If the test exposes a product boundary mistake, fix the product, not only the bug.
+
+6. **Ship deliberately**
+   - Commit scoped changes.
+   - Push the repo.
+   - Run the release script, wait for GitHub Actions, update the Homebrew tap, and run `brew test`.
+   - Verify the installed binary, not only `target/debug`.
+
+## References
+
+- Read [product-method.md](references/product-method.md) when framing a new tool or recovering from scope creep.
+- Read [rust-cli-shape.md](references/rust-cli-shape.md) when creating or refactoring the project files.
+- Read [release-checklist.md](references/release-checklist.md) before publishing GitHub/Homebrew releases.
+- Read [case-notes.md](references/case-notes.md) when comparing against `tg`, `cx`, and `mon`.
+
+## Guardrails
+
+- Do not embed one-off user workflows into a general-purpose tool. Put them in a separate folder, script, or downstream skill.
+- Do not expose tokens, local databases, chat logs, or account data in docs, logs, commits, or final messages.
+- Do not overfit the CLI to the first conversation. The tool should satisfy a class of future agent/user jobs.
+- Do not call a project shipped until the installed binary and release path have been exercised.

package/skills/ship-ai-native-cli/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Ship AI-Native CLI"
+  short_description: "Turn local workflows into shipped CLI products"
+  default_prompt: "Use $ship-ai-native-cli to turn this workflow into a small, releasable AI-native CLI product."