wilbeibi-skills

Understand an unfamiliar codebase — either a full briefing (purpose, architecture, seams, design taste, commit-history rationale, standout code) or a scoped dataflow trace of one subsystem. Use when asked to "understand this repo", "explain this codebase", "give me a tour", "how does X work here", "trace how data flows", "where does this value come from", or "why is it designed this way". Do NOT use to assess repo health/popularity (use repo-eval) or to review a diff (use a code-review skill).

Review a change or audit existing code through the Russ Cox lens — necessity, layering, minimal seams, error/logging/testing discipline, and anti-bloat. Use when reviewing diffs, new features, or dependency additions, or when asked to "audit this package", "refactor/polish this code", "find design, implementation, or style problems", "do we need this?", or "is this too complex?". Do NOT use for public API shape or product-vs-library tradeoffs (use code-review-mitsuhiko) or invariant/cost honesty (use code-review-burntsushi).

Append quick captures — todos with due dates, log lines, learnings, reflections — to the right section of Obsidian daily (DailyPlan/) and weekly (Weekly/) notes. Use when asked to "add a todo", "note this down", "log this", "capture an idea", "due Friday", or to record something fun or a weekly reflection. Do NOT use for searching notes (use obsidian-vault-search) or for creating standalone long-form notes.

Search an Obsidian vault three ways — Meilisearch for topic and fuzzy queries, ripgrep for exact strings/tags/task glyphs, and a date-aware helper for natural-language dates and overdue math. Use when finding notes about a topic, half-remembered ideas, recent writing, tagged content, or due/overdue/high-priority tasks in a local Markdown vault. Do NOT use to add or edit notes (use obsidian-capture).

Write or critique a README for an open-source project (library, CLI tool, or agent tool) with an impatient-reader lens: concrete value first, shortest path to use, no duplicated claims, and reference material only when it earns space. Use when the user asks to "write a README", "draft a README", "review my README", "improve my README", or starts a new lib/tool and needs documentation. Do NOT use for internal service docs, monorepo root READMEs, or non-public projects.

Design or review command-line interface shape — flags, subcommands, help, errors, and output contracts — against established CLI conventions (clig.dev, POSIX, GNU). Use when the agent is about to write a CLI tool, add a subcommand, design flag names, review --help output, or evaluate CLI UX. Do NOT use for TUI/full-screen terminal apps, GUI design, or web API design.

Review code for API shape, error handling, backward compatibility, and product-vs-library fit. Use when reviewing public APIs, library interfaces, error types, dependency choices, or product code being over-engineered, or when deciding between "ship the dumb version" and "design for stability". Do NOT use for deletion-focused or anti-bloat review (use code-review-russ-cox).

Guide test writing and review with focus on observable behavior over implementation. Use when the user asks to write, review, or refactor tests; debates unit vs integration scope; questions whether to mock a dependency; or asks why tests break on refactor.

Author a new agent skill in this repo following compact trigger-rich and command-first skill patterns. Use when the user asks to "write a skill", "add a skill", "create a new skill", update skill guidance, or scaffold a SKILL.md. Targets the `npx skills` layout (top-level `skills/<name>/SKILL.md`).

Write ast-grep rules for structural (AST-based) code search — matching code by structure, not text. Use when the user wants to find code patterns, locate specific language constructs, or run queries that plain text/regex search can't express ("find async functions without error handling", "calls with these args").

Review code through BurntSushi's "honest machinery" lens — asking whether APIs, invariants, error contracts, performance boundaries, and defaults accurately represent reality. Use when reviewing library APIs, patches that change complexity or cost, dependency additions, or when the user asks "is this API honest?", "will this panic?", "is the cost visible?", "does this scale?", or "are the defaults right?". Works across languages; see REFERENCE.md for Rust-specific elaborations. Do NOT use for deletion/anti-bloat review (use code-review-russ-cox) or product-vs-library tradeoffs (use code-review-mitsuhiko).

Review code from the perspective of a competent engineer who just joined the team — surface missing context, undocumented design rationale, implicit assumptions, and project-specific knowledge that is not evident from the code itself. Use when the user asks for an onboarding-perspective review, mentions newcomer experience, asks about documentation gaps, or wants to know "what would confuse a new hire". Do NOT use for general code review (see code-review-russ-cox or code-review-mitsuhiko) or style nitpicking.

Extract browser history for finding URLs by topic or getting visit stats. Use when user asks about their browsing history, visited websites, or what they were doing online.

Transform YouTube videos or transcripts into structured Obsidian notes with timestamps, metadata, callouts, and detailed section breakdowns. Use when the user provides a YouTube URL or asks to summarize, analyze, or convert a YouTube video into notes.

Write high-quality code comments by matching the missing information to the right comment type. Use when asked to "write comments", "add comments to code", "how should I comment this", "document this function", "add a docstring", or when generating code that needs inline documentation. Do NOT use for READMEs, prose documentation, or reviewing existing comments — those are write-readme, writing, and code-review tasks respectively.

A pre-coding planning gate based on Andrej Karpathy's observations about LLM coding pitfalls — surface assumptions, choose the simplest approach, and turn the request into declarative success criteria with a verification loop before writing code. Use when the user says "plan this", "how should I approach X", "make a plan before coding", or before any non-trivial implementation where the requirements or scope are not yet pinned down. Do NOT use for trivial one-line edits, or when the user wants an interactive back-and-forth interrogation (use grill-me) or a complexity-vs-value check on an existing diff (use complexity-budget).

Evaluate a public GitHub repo's health on two axes — momentum (is it growing or past its peak?) and maintenance (is it well run?) — and place it on a quadrant. Use when asked to assess whether a repo is healthy, popular, declining, abandoned, or well-maintained; to vet a dependency, OSS project, agent product, or SaaS-OSS repo; or to compare repos by activity, responsiveness, release cadence, or contributor concentration. Pulls popularity trajectory from the OSS Insight API and maintenance signals via the `gh` CLI. Do NOT use to review code quality of a diff (use a code-review skill).

Audit and de-duplicate an existing agent-skill library — find forked scripts, contradictory or restated instructions across SKILL.md files, bloated frequently-loaded files, and internal defects (duplicate headers/numbering, dead refs, dead code). Use when the user says "audit my skills", "some skills look duplicated", "polish/clean up the skill library", "consolidate these skills", or points at a skills/ tree and asks what overlaps. Do NOT use to author one new skill (use write-skill) or to review application source code (use a code-review skill).

A gate to run before and after changing existing code, to keep added complexity in line with what the change is actually worth. Use when adding a feature, fixing a bug, or extending code that already exists — especially when the cheap path is to add (a new flag, a new branch, a copy-paste, a parallel code path) instead of folding into what's there. It asks four questions before you edit, then checks your own diff for new duplication and new coupling. Do NOT use for greenfield code with nothing to integrate into, and do NOT treat it as a correctness review of someone else's finished PR (use code-review-russ-cox for a deletion-focused review).

Run a rigorous planning interview that stress-tests a user's idea against the codebase, sharpens project terminology, and captures durable context in lightweight docs. Use when the user says "grill me", "grill me with docs", "stress-test this plan", "interview me on this design", or asks to turn a discussion into CONTEXT.md glossary entries or ADRs. Do NOT use for ordinary summaries, code review, or documentation-only cleanup when no interactive interrogation is requested.

Interview the user relentlessly about a plan or design, one question at a time, until every branch of the decision tree is resolved. Use when the user wants to stress-test a plan, pressure-test a design, asks to "grill me", or says they want their thinking challenged before implementing. Do NOT use for quick one-off questions or when the user just wants a direct answer.