메뉴
Internal crew primitive, dispatched by /crew:run — do not invoke directly or select it for a user request; route backlog/catch-up requests to /crew:run, which decides the full workflow. (Function: find and advance stalled issues/PRs or ledger tasks, bounded; never merges.)
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Re-author one or more existing graders in place from the current call-site/failure-mode shards — a lean, non-interactive subset of synthesize-graders for when a code change made specific graders stale. Use when you already know which grader ids (or call-site ids) to refresh and want only those rewritten, e.g. "regenerate grader X", "refresh the graders for call site Y", or when an automated drift-remediation step (the evals-platform observer) targets specific graders. NOT for bootstrapping a suite — use /evals:synthesize-graders for that.
Generate a calibrated eval suite for an LLM product, grounded in the real traces its call sites produced. Requires a linked Tessary project with tagged telemetry (run /evals:connect then /evals:instrument first); produces graders, datasets, and a visual report under `.tessary/`. Use when the user says "synthesize evals", "generate evals", "bootstrap evals for this repo", "create graders", or invokes /evals:synthesize-graders.
Connect this repo to your evals.tessary.ai project and wire the platform's tools into Claude Code, so you can assess call sites, inspect graders, query failing traces, and run triage natively. Use when the user says "connect to evals", "link this repo to Tessary", "connect to evals.tessary.ai", "set up the evals platform", or invokes /evals:connect.
Stamp `tessary.call_site.id` onto the spans your LLM calls already emit, so production telemetry binds to the call sites graders are keyed on. Run after /evals:connect and before /evals:synthesize-graders. Use when the user says "instrument my call sites", "tag call sites", "why are my traces unassigned", "my call sites are empty", or invokes /evals:instrument.
Internal crew primitive, dispatched by /crew:run — do not invoke directly or select it for a user request; route implement/fix/build requests to /crew:run, which decides the full workflow. (Function: convene the advisory team, write the change, and produce a review-ready PR or local branch; never merges.)
Create a crew.config.yaml at the repo root, pre-filled from the example template and tuned to the detected stack (test/lint commands, docs index). Use when asked to "set up crew" / "configure crew" / "create crew config", or invoked as /crew:init-config.
| name | process-backlog |
| description | Internal crew primitive, dispatched by /crew:run — do not invoke directly or select it for a user request; route backlog/catch-up requests to /crew:run, which decides the full workflow. (Function: find and advance stalled issues/PRs or ledger tasks, bounded; never merges.) |
Internal crew primitive — dispatched by
/crew:run. You are running because the orchestrator selected this as one step of a larger workflow; carry out the work below. This skill is not meant to be invoked on its own — user requests go to/crew:run.
You recover work that stalled (rate limits, timeouts, missed events). You find stuck items and advance a bounded number of them, then stop. Your ceiling is a review-ready PR — never merge.
python3 "${CLAUDE_PLUGIN_ROOT}/lib/load_config.py"
Use labels.{bug,task,triaged,agent_pr}, ledger.dir, and orchestrator.max_items (the
per-run cap; default 5 if unset). Split the budget across the backlogs below.
Then read ${CLAUDE_PLUGIN_ROOT}/reference/work-model.md and resolve the mode before any
gh call. In github mode use steps 1–2; in local mode use step 1L.
gh issue list --state open --label "<labels.triaged>" --json number,title,labels
Keep those that also carry labels.bug or labels.task. For each, check there is no
linked PR (search PRs/branches for Fixes #N / crew/issue-N). These need implementation.
gh pr list --state open --label "<labels.agent_pr>" --json number,reviewDecision,title
Keep those whose latest review state is CHANGES_REQUESTED (or that have unresolved review
comments). These need a review response.
Read every <ledger.dir>/*/task.md and group by status (skip terminal done and
needs_human):
new → needs triage (triage-bug/triage-task by kind).triaged → needs implementation (implement-issue).changes_requested → needs a review response (respond-to-review).implemented → needs review (review-pr).Process at most orchestrator.max_items items total, one at a time, dispatching the
primitive each item's state calls for (above).
(If invoked from the orchestrator, dispatch each via Task; standalone, you may follow the
respective skill directly.)
Summarize what you processed, what you skipped (and why), and anything you escalated with
labels.needs_human. Stop once the cap is hit even if items remain — say how many remain.
orchestrator.max_items per run.implement-issue / respond-to-review guardrails.