Nightly refinement of an existing per-repo review-style prompt using this reviewer's own finding outcomes. Read confirmed (resolved-by-commit / thumbs-up) and dismissed (thumbs-down) findings, promote the bug patterns the team actually fixes, demote the false-positive patterns, reconcile against the current prompt, and save the refined version. Use this once outcomes exist; use bootstrap-repo-analysis for a cold-start repo.
npx skills add https://github.com/langchain-ai/open-swe --skill continual-learning
You are refining the existing review-style prompt for the repository named in the
system prompt, using outcomes the reviewer has accrued since the last run. The goal is
to raise recall (catch more real bugs) without hurting precision (stop repeating
dismissed ones).
Call read_finding_outcomes once. It returns this repo's past findings split into:
confirmed — resolved by a follow-up commit or 👍'd. These are real bug patternsthis team fixes. Promote the recurring ones into the prompt's "hunt for" guidance,
quoting the file/diff_hunk context so the rule stays concrete.
dismissed — dismissed or 👎'd. These are false-positive patterns. Add therecurring ones to the prompt's "do not flag" section so the reviewer stops repeating
them.
Look for repetition, not one-offs. A single dismissed finding is noise; the same class
dismissed several times is a rule.
The current custom_prompt is the starting point — you are editing it, not rewriting
from scratch. Read it (it is summarized for you / available via the dashboard record).
Keep what still holds, strengthen rules the outcomes confirm, and remove or soften rules
the outcomes contradict. Optionally do a light gh top-up
(GH_TOKEN=dummy gh ...) to confirm a pattern, but outcomes are the primary signal — do
not re-run a full PR crawl.
Stay aligned with the reviewer-agent themes in the system prompt.
Call save_review_style_prompt once with the refined custom_prompt (400–1200 words),
an analysis_summary that names what changed this cycle (e.g. "promoted N-pattern after
3 confirmed fixes; dropped M-pattern after repeated dismissals"), and the
top_reviewers / counts you have. If outcomes were empty and nothing changed, say so in
analysis_summary and re-save the existing prompt unchanged rather than degrading it.
Create new skills, modify and improve existing skills, and measure skill performance. Use when users want to create a skill from scratch, edit, or optimize an existing skill, run evals to test a skill, benchmark skill performance with variance analysis, or optimize a skill's description for better triggering accuracy.
Guide for creating effective skills. This skill should be used when users want to create a new skill (or update an existing skill) that extends Claude's capabilities with specialized knowledge, workflows, or tool integrations.
Guide for creating effective skills. This skill should be used when users want to create a new skill (or update an existing skill) that extends Claude's capabilities with specialized knowledge, workflows, or tool integrations.
Replace with description of the skill and when Claude should use it.
Use when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies
This skill should be used when the user wants to "create a skill", "add a skill to plugin", "write a new skill", "improve skill description", "organize skill content", or needs guidance on skill structure, progressive disclosure, or skill development best practices for Claude Code plugins.
Helps users discover and install agent skills when they ask questions like "how do I do X", "find a skill for X", "is there a skill that can...", or express interest in extending capabilities. This skill should be used when the user is looking for functionality that might exist as an installable skill.
Use when creating new skills, editing existing skills, or verifying skills work before deployment
Take langchain-ai/continual-learning from the repository into ~/.claude/skills for personal
use, or into .claude/skills inside a project.
The agent identifies a skill by the name field in its header. Two skills with the
same name cannot sit side by side — one of them will be ignored.