القائمة
This skill should be used when the user asks to "triage", "what needs fixing", "what's broken", "prioritize issues", "run triage", or wants a P0/P1/P2 issue breakdown across one or more repos.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Use when the user runs "/insights-audit", asks to "validate the insights report", "audit the report against my projects", "check what the report got wrong", or wants to cross-check an /insights-generated HTML report against actual GitHub repos and local project directories.
This skill should be used when the user asks to "end session", "capture state", "session summary", "what changed this session", "summarize repos", "write session notes", or wants to capture multi-repo state at the end of a work session.
Fill in the Patterns & Surprises section of the latest session reflect file and write the completed review to .ctx/logs/self-review/. Use when the user runs "/self-review", asks to "fill in the reflect", "write the session review", or "what patterns did we hit".
Use when working on the rslm project — Recursive Language Model inference engine in Rust. Triggers on "rslm", "RLM", "recursive language model", "rhai built-ins", "ctx_grep", "ctx_slice", "rlm_call", "rslm-core", "rslm-providers", "rslm-store", or any question about running queries, ingesting documents, or writing Rhai scripts for the RLM loop.
This skill should be used when the user asks to "review this diff", "ai review", "security review my changes", "review before push", "check my code for issues", or wants an LLM-based security and correctness review of uncommitted or unpushed changes.
This skill should be used when the user asks to "generate commit message", "write a commit msg", "ai commit", "generate a conventional commit", "write my commit", or wants an LLM to draft a commit message from the staged diff.
| name | triage |
| description | This skill should be used when the user asks to "triage", "what needs fixing", "what's broken", "prioritize issues", "run triage", or wants a P0/P1/P2 issue breakdown across one or more repos. |
Scan HANDOFF files and GitHub issues, categorize by priority, and spawn parallel subagents for fixes.
# Find HANDOFF files for the current repo
ls .ctx/HANDOFF*.yaml 2>/dev/null || ls HANDOFF*.yaml 2>/dev/null
Read each HANDOFF.*.yaml found. Focus on items with status: open or status: blocked.
gh issue list --repo <repo> --state open --limit 50 --json number,title,labels,assignees
Use the repo dirname (not 'workspace') as <repo>. Do NOT use Linear — GitHub is the issue
tracker for this workspace.
| Priority | Criteria |
|---|---|
| P0 | broken, fails, blocked, urgent, security, CI red |
| P1 | specific file + known fix, test failing with known cause |
| P2 | enhancements, cleanup, anything safe to defer |
Merge HANDOFF items and GitHub issues into a single prioritized list. Present summary:
## Triage — <repo>
P0 (act now):
- [id] <title> — <why urgent>
P1 (autonomous fix):
- [id] <title> — <file> → <known fix>
P2 (delegate / defer):
- [id] <title>
--allowedTools, verify clean git status, commit its own changes.cargo nextest run # filter tests
cargo nextest run <filter> # run specific tests
Use cargo nextest, not cargo test, for test filtering and parallel execution.
After fixes:
git add .ctx/HANDOFF.*.yaml
git commit -m "fix: <summary> — closes #<issue>"
Update HANDOFF items to status: done and prepend a log entry. Do not edit HANDOFF manually
for status if doob sync is active — use handoff-db upsert instead.