tesslio

Use when reviewing a pull request, to check for logic bugs, style consistency, and security concerns and summarise the findings for the author.

Use once there is a confirmed composition plan, to create it. Scaffolds the plugin, authors or restructures the skill(s), decomposes anything too big, and adds any rules or MCP servers the plan called for. Uses the CLI to scaffold the plugin, then adds further skills by hand.

Database administration tasks including schema changes, backups, monitoring, and user access management.

Use when someone wants to turn a problem, a messy or sprawling skill, or some existing work into well-shaped reusable context for their agent. Triggers include "help me make a skill for X", "my skill is a mess, sort it out", "I want to get more out of Tessl with this skill", or "package this so my team can use it". Runs the arc - understand the problem, gather the artifacts, plan the right composition, build it - then points to eval as a separate next step.

Use during build when a skill or a problem is too big for one skill - a sprawling SKILL.md doing several jobs, or a large problem the user wants a single skill for. Splits it into focused, independently-verifiable skills, with a plugin as the superstructure that holds them together.

Use at the start of creating context, to understand the problem the user is solving and take stock of what they already have. The user may arrive with an existing skill or plugin, code, a written prompt or transcript, or nothing but a pointer ("go look at my PRs"). Gathers what exists and fills the gaps - by asking or by hunting - until there is enough to plan a composition.

Use once the problem and artifacts are understood, to decide the right shape for the context. Produces a short composition plan - a single skill for simple cases, or a plugin (with rules, commands, MCP servers, or multiple skills) for richer ones - and confirms it with the user before anything is built.

Use when a composition is built and the user wants to share it, to publish or re-publish it to the Tessl registry. Lints it, confirms private/public visibility, and publishes.

Stress-test the primary review with an additional independent reviewer that generates its own findings, compares reviewer conclusions, and identifies issues the primary reviewer may have missed. Use when performing a second opinion or double-check review on a pull request, for medium or high risk PRs, when authoring was heavily AI-assisted, when primary reviewer confidence is low, when findings conflict, or when you need to verify findings with a cross-model or same-model challenger. Supports same-model and cross-model configurations for fair comparison.

Generates a structured, human-readable reviewer packet summarising what changed in a pull request, why it matters, what was verified, and where human attention is most needed. Use when the user asks for a PR review summary, a code review packet, a human-readable change report, or wants to hand off review findings to a human reviewer. Produces a scannable document: quick approvals (low-risk PRs) can be assessed in under 30 seconds; detailed reviews (high-risk PRs) in under 2 minutes. Outputs a formatted markdown packet with risk rating, verification status, ranked findings, unresolved questions, and a recommended review focus — making human review faster without replacing human judgment.

Build a compact, trustworthy evidence pack before deeper PR review starts. Use this skill when a pull request needs review — it is always the first step. Triggered by requests to review code, check a PR, review my changes, review a merge request, or any similar code review or pull request review request. Collects PR context, runs deterministic verifiers, classifies risk, maps hotspots, and checks for missing artifacts. Produces the evidence pack that all downstream review skills consume.

Evaluates which code review comments (review tiles) actually produced changes after a pull request is merged or closed, by passively collecting outcome data from the GitHub API and git history — zero developer friction. Use when analyzing post-merge pull request outcomes, assessing code review effectiveness, measuring review feedback impact, or answering questions like "how did PR #6 go?", "which review comments were accepted?", or "did any escaped defects appear after this pull request merged?" Produces a structured per-finding outcome record (accepted / rejected / ignored / superseded), merge time delta, escaped defect count, and AI authorship correlation for each PR.

Turn many candidate findings from reviewers and verifiers into a small, decision-useful set. Deduplicates, ranks, and suppresses weak findings to consolidate review results into a prioritized, actionable list with severity ratings and merged confidence scores. Use when you need to merge findings, consolidate feedback, prioritize issues, or summarize review output after review passes are complete and before human handoff. Trigger phrases: "consolidate review results", "merge findings", "deduplicate feedback", "prioritize issues from review", "summarize reviewer output". The evidence threshold is the filter — not an arbitrary cap.

Provide an independent critique of a pull request (PR) using a clean reviewer context, identifying bugs, security issues, code quality problems, API misuse, and missing test coverage. Use when performing a code review or pull request review after an evidence pack has been built, for green or yellow risk lane PRs, or as part of a full pipeline for red risk lane PRs. Produces candidate findings (covering correctness, security, and architectural concerns) for downstream synthesis — not final verdicts. Operates as a critic, not a co-author. Common triggers: "review this PR", "code review feedback", "fresh review", "independent review".

Scaffold the good-oss-citizen contribution gate into a consumer repository: a `pull_request_target` GitHub Actions check that fails any pull request whose description lacks a contribution declaration — an "AI Disclosure" section or an explicit "no AI assistance" statement — plus the vendored detection script, a PR template, and the tessl.json dependency entry. The gate enforces an outcome (AI use is disclosed) on the PR side, where it cannot be bypassed; it does not, and cannot, prove a tool ran. Use when a maintainer wants to add, install, set up, scaffold, enable, or wire up a contribution gate / a PR check that requires good-oss-citizen or AI-use disclosure before contributing.

Runs a structured 10-check pre-submission checklist against an open-source contribution before the contributor opens a pull request. Use when the user has written code for an open-source project and needs to prepare a PR, submit a contribution, or verify readiness. Triggers on "submit a PR", "open a pull request", "prepare the contribution", "ready to merge", "check my pull request". IMPORTANT — run this AFTER code is written but BEFORE submission. Checks: AI policy compliance and disclosure (including voluntary disclosure when no policy exists), diff size and focus, PR template, code style, commit conventions, tests, changelog and metadata, legal requirements (DCO/CLA), agent artifacts, slop detector patterns, and human ownership verification.

Analyzes project contribution guidelines, identifies the right venue (pull request, issue, discussion, RFC/KEP/DEP), checks issue metadata (claims, assignments, labels), searches for prior rejected attempts, and drafts proposals formatted to project templates. Use when the user wants to contribute to an open-source project, fix a bug, submit a PR, improve or refactor code, asks where to submit a change, or needs help choosing between PR/issue/discussion/RFC. Triggers on "fix this issue", "submit a PR", "refactor this", "improve this code", "open a pull request". IMPORTANT — run this AFTER recon and BEFORE writing code to verify the right venue and check for prior attempts.

Analyze an open source project's contribution norms, AI policy, conventions, and recent PR history before writing any code. Use when the user wants to contribute to an open source or GitHub project, fix a bug, submit a pull request, open a PR, make a contribution, or asks about contribution guidelines. Triggers on phrases like "fix this bug", "submit a PR", "contribute a fix", "open a pull request", "help me contribute", "how do I contribute", "what are the rules for this OSS project". IMPORTANT — run this BEFORE writing any code for an open source project.

Check an already-open issue or pull request body against the host repo templates and draft a suggested comment for human review, not posting. Use when asked to triage an existing issue/PR, decide whether an existing body is good enough before responding, review whether it follows the repo template, or draft a comment asking for missing information. Triggers include "triage this issue", "review this existing PR", "does this PR follow the template", "check whether the PR body follows the repository's pull request template", "check whether the issue body follows the repository's issue template", "quick check on this open issue", "body is good enough", "asked for anything more before I respond", and "what's missing from this PR body". For NEW issue/PR drafts use `propose`; for own PR pre-submission verification use `preflight`.

Interview stakeholders to clarify ambiguous or underspecified requirements before writing code. Use when receiving a new task, feature request, or bug report that lacks clear acceptance criteria. Produces clarified requirements ready for spec authoring. Common triggers: "new feature", "build me", "implement", "add support for", or any task where requirements are vague or incomplete.

Verify that implementation and tests remain synchronized with specs after code changes. Use when code has been generated or modified from specs, after implementation is complete, or when reviewing a PR that touches spec-covered code. Reports mismatched targets, broken test links, and undocumented behavioral changes. Common triggers: "verify the spec", "check spec alignment", "are specs up to date", or after completing implementation work.

Create or update .spec.md files from clarified requirements. Use when requirements have been gathered and confirmed, and specs need to be written or updated before implementation begins. Produces well-structured spec files with frontmatter, requirements, and test links. Common triggers: "write the spec", "update the spec", "create a spec for", or after requirement-gathering completes.

Review completed implementation against approved specs to ensure all requirements are satisfied. Use after finishing implementation work, before marking a task as done, or when a stakeholder asks to verify deliverables against requirements. Produces a review summary with pass/fail per requirement. Common triggers: "review my work", "check against spec", "did I miss anything", "is implementation complete".

Create tessl tiles containing docs, rules, or skills. Use when a user wants to create a tile, package content for tessl, or needs help with tile.json configuration. Also triggers on "create tile from", "convert to tile", "turn into tile", "make tile from", or "tile this repo" for existing content.

Review code changes for hardcoded credentials, SQL string concatenation, eval() usage, and infinite loops without exit conditions.

Run task evals across multiple Claude models and compare results side-by-side. Use when you want to understand how a skill performs across different models, identify model-specific gaps versus universal tile issues, or validate a skill before publishing it to the registry.

Comprehensive reference for 50 design aesthetics, movements, and visual styles with detailed definitions. Use when creating visuals, illustrations, graphics, or any design work requiring specific aesthetic direction. Each style includes core principles, visual characteristics, color palettes, typography guidance, key elements, emotional qualities, historical context, and AI prompt engineering keywords.

Create tessl tiles containing docs, rules, or skills. Use when a user wants to create a tile, package content for tessl, or needs help with tile.json configuration. Also triggers on "create tile from", "convert to tile", "turn into tile", "make tile from", or "tile this repo" for existing content.