weave-os
- 20 skills
- 0 followers
- 6 hours ago last updated
- ▌ Engineering Analytics · weave-osAnalyze engineering team metrics using Weave. Use when asked about team productivity, code velocity, PR cycle time, review turnaround, AI code adoption, DORA metrics, or any engineering performance question.
- ▌ Fm · weave-os bundleAlias for force-model — pin this Codex session to a specific model through the Weave Router.
- ▌ Rf · weave-os bundleAlias for router-feedback — submit feedback about a Weave Router decision or model performance.
- ▌
- ▌ Fix Pr Reviews · weave-osFetches feedback from a GitHub PR — review-thread comments, ad-hoc PR comments (including those posted as a review's body without a thread), and bot/advisory review submissions — and fixes all of them as they appear (comments before CI). Bot comment-length nits apply verbatim; comments requiring a genuine human decision are NOT auto-fixed and are escalated to the user with options grounded in existing patterns and best practices. After each fix batch, runs pre-commit validation and submits, then waits for CI only when no actionable feedback remains. Loops until all feedback is resolved AND all CI checks have completed. Use when asked to fix PR comments, address review feedback, address PR-level bot reviews (e.g. workweave-bot advisory nits), babysit a PR to merge-ready, or handle review comments.
- ▌
- ▌
- ▌
- ▌ Test Codex Locally · weave-os bundleRun the Weave router locally in docker compose and drive it with `codex exec` to reproduce and verify routing/translation/marker behavior for Codex's Responses API path. Use when verifying a router fix end-to-end for Codex, reproducing a prod Codex routing bug, confirming routing-marker / force-model / subscription-passthrough behavior, or testing a `/force-model` route — without touching the user's global Codex config.
- ▌ Debug Codex Session · weave-os bundleInvestigate a specific Codex CLI session by session ID — correlate the local rollout transcript (`~/.codex/sessions/YYYY/MM/DD/rollout-*-<SESSION_ID>.jsonl`) with the router's production logs to understand what Codex rendered vs. what the upstream served on the /v1/responses path. Use when given a session ID and asked "why did X render?" (missing thinking, missing routing marker, wrong model, tool-call weirdness) for a Codex conversation routed through the router.
- ▌ Test Claude Locally · weave-os bundleRun the Weave router locally in docker compose and drive it with `claude -p` to reproduce and verify routing/translation behavior for a specific upstream model (e.g. GLM-5.1, DeepSeek, Qwen). Use when verifying a router fix end-to-end, reproducing a prod routing bug, confirming a model's streaming behavior (nudges, tool-call suppression, loop/no-progress breaks), or testing a `/force-model` route — without touching the user's global Claude Code config.
- ▌
- ▌ Router Status · weave-osShow whether Codex is routing through the Weave Router or using its default provider.
- ▌
- ▌ Lsp Guide · weave-osRecipes for the lsp tool — resolving where a symbol is defined, every place it is used, type signatures and docs, file outlines, and compiler/type errors through a real language server (Go, TypeScript/JavaScript, Python, Rust). Use when navigating or explaining code by symbol, finding callers or usages, checking what broke after an edit, or deciding between lsp and text search.
- ▌ Debug Claude Session · weave-os bundleInvestigate a specific Claude Code session by session ID — correlate the local transcript (`~/.claude/projects/...jsonl`) with the router's production logs to understand what the client rendered vs. what the upstream served. Use when given a session ID and asked "why did X render?" for a Claude Code conversation routed through the router.
- ▌ Router Session · weave-os bundlePrint the session id that correlates this Codex session in Weave Router telemetry and logs.
- ▌
- ▌ Router Feedback · weave-os bundleSubmit feedback about a Weave Router decision or model performance.
- ▌ Install Lsps · weave-osInstall language servers (gopls, typescript-language-server, pyright, rust-analyzer) and their prerequisite toolchains (Go, Node/npm, rustup) so the lsp tool works. Use when the user asks to enable or install LSP / language-server support, when lsp_enable reports a missing toolchain, or when the lsp tool reports no language server is installed.