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.
Internal crew primitive, dispatched by /crew:run — do not invoke directly or select it for a user request; route address-review/fix-feedback requests to /crew:run, which decides the full workflow. (Function: apply review feedback on a crew PR or local branch, bounded by max_review_iterations; never merges.)
A standing crew of senior developer agents and the team's single entry point — its job is best-in-class implementation, coding standards, and project health. Use it for essentially ANY software-development request in this repo, whether or not the user says "crew": implementing a feature, fixing a bug, reviewing or improving code, refactoring, making something production-ready, addressing review feedback, updating docs, cleaning up cruft, or advancing open issues/PRs — and with no goal at all, polishing the current branch's changes. It assesses the request, decides how much process it warrants (a one-line tweak stays light; a real feature gets the full team, review, and fixes), then composes and runs the workflow end to end by dispatching crew's internal primitives. Prefer it over ad-hoc edits so changes meet the project's standards. Works on GitHub issues/PRs or purely locally. Runs unattended; never merges. Triggers on development requests, on /crew:run ["<goal>"] [--dry-run], or when the user mentions crew.