Research any topic and produce a structured crash course saved to Obsidian. Takes a topic as input, dispatches a researcher agent, optionally validates findings, formats output as a consistent crash course document, saves to the Obsidian vault, and outputs in chat. Use when asked to learn about, research, get a crash…
Reads today's AI journal entry from Obsidian and the user's GitHub PRs opened or merged today, appends a concise daily log entry to the current month's Notes file, and updates evidence and statuses in goals/roles. Use when asked to log today, write a daily log, update the monthly notes, or record career-goal evidence.
Takes a plain-text task description or a Jira issue key (e.g. FOO-123) and runs plan, approach advisor loop, failing tests first, implement, test, and review using the catalog agents. Use when the user explicitly asks to implement a task end-to-end. Not for quick one-file fixes or work that already has a multi-step…
Rewrites PR review comments to match the author's terse, direct code review voice. Strips AI phrasing and produces short imperatives, parenthetical precision, a "nit" prefix for minor things, "we should" framing, verifying questions, and links instead of explanations. Use when drafting or polishing PR review comments…
Self-reviews uncommitted or unpushed work before opening a PR. Multi-phase review with Jira requirements, a single reviewer agent, a skeptic validator pass, and an auto-fix offer. Use when asked to review local changes, self-review a branch before a PR, or check your own diff. Pass a branch name to review against…
Reviews a pull request against its description and the existing codebase. Parallel reviewers per discipline, findings merged and checked by a skeptic validator pass. Output is local only: printed in chat, rendered as a temporary self-contained HTML report, and saved as a findings JSON file. Nothing is posted to…
Creates or updates a skill or agent definition in the AI agents catalog, following the catalog layout and authoring rules. Use when the user wants to create a new skill or agent, or modify an existing one.
Posts inline PR review comments from a review-pr findings file as a pending GitHub review. Filters out non-actionable findings, presents each remaining one for approval, humanizes the approved text, and posts a pending review visible only to the user until they submit it. Use when the user explicitly asks to post…
Reasoning framework for reviewing a diff or PR. Defines the review lenses (design fit, correctness and security, requirements, testability), severity labels (important, nit, pre-existing), a self-challenge check for each finding, and a question style for uncertain findings. Reports only findings that affect…
Reviews edlng's review comments on a PR, verifies each was addressed in the latest code, and gives a final verdict (APPROVE, REQUEST CHANGES, or COMMENT) with code evidence. Use when given a PR link and asked whether edlng's feedback was addressed.
Use when the user invokes the harness-native update-sysprompts skill or asks to persist a concise instruction across Kiro, Claude Code, and Codex global context, including commit, test, coding-style, or workflow rules.
Generate a brief PR description from current git changes that a reviewer can read in under a minute. Optionally accepts a commit range (e.g. HEAD3) and/or a PR template path. Reads the diff, drafts from the repository PR template (or a short default), cuts it to fit, verifies accuracy, then applies the…
Vet a perf measurement (limiter, tuning, limits, errors, repeatability, relevance, and whether the work happened) before you report or act on it. Use when you run a benchmark or report a speedup or regression you measured.
Find what a change could break somewhere else before it ships, beyond the diff, and prove the one fact it's safe because of by running real code instead of writing it up. Use for 'blast radius of X', 'what could this break', a change to a shared contract or wire format, or reviewing a small diff you don't trust.
Use for "how does X work", code walkthroughs before changing something, and placement / ownership / layering questions ("where should this live", "which package owns this", "is this the right layer"). Explains subsystem architecture, runtime flow, onboarding mental models. Use why for motivation.
Apply before you trust, report, or act on a number you measured: a speedup, a regression, a throughput, a latency, or an eval result. Find what limits it, and rule out that it measured something other than the work you think.
Apply when designing commands, lifecycle steps, or processing loops that run amid crashes, restarts, and retries. Converge to the same end state regardless of partial prior runs.
Apply when concurrent actors might write to the same file, branch, key, or state object. Eliminate the sharing first; serialize structurally only when one shared writer is a real invariant.
Apply when you write, change, or keep a test. Assert what the code's users can observe, so that the test fails when that behavior breaks and keeps passing when only the internals change.
Use only when the user explicitly asks for TDD, a failing test, or a regression test, OR when the bug has an obvious cheap local test target. Skip when the test path is unclear, expensive, integration-heavy, or not requested.
Use for 'why does X work this way', 'why we picked Y', design rationale, regressions, postmortems, or data-backed thresholds. Queries git and gh, Pippin, and the Amazon internal wiki in parallel, then returns a cited read on decisions and tradeoffs. Use how for runtime behavior.
Apply when wiring validation, error handling, or framework adapters. Concentrate guards at system boundaries (CLI, config, network, external APIs); trust internal types and keep business logic in pure functions.
★not rated 2 8d agoA46 tokens
At most 3 mods per repository are shown here, and a mod shipped inside a plugin is left to that plugin's page — the rest are on their repository pages: