trellis-check-all

Reviews code changes against planning documents, implementation assumptions, and project specs with routed light or full depth.

Updated Jun 8, 2026
One-click install
npx skills add https://github.com/SilentFlower/flower-trellis --skill trellis-check-all-silentflower
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: trellis-check-all
Source: https://github.com/SilentFlower/flower-trellis/tree/main/.agents/skills/trellis-check-all
Command: npx skills add https://github.com/SilentFlower/flower-trellis --skill trellis-check-all-silentflower

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? It provides a single, unified pre-commit review gate that verifies whether code changes correctly implement the task's PRD, design, and implementation plans, whether underlying assumptions about APIs, components, and data hold, and whether the change is complete and spec-compliant—without mixing up root-cause classification or severity. ## Core Features & Use Cases - Depth Routing: Automatically selects light or full review depth based on requested intent, hard-full signals (API/schema/security changes), and whether the impact surface is closed, with one-way escalation from light to full. - Three-Dimension Audit: Checks planning-artifact implementation, implementation assumptions (API contracts, component context, data history, data flow), and completeness/spec compliance with shared verification evidence. - Classified Findings Model: Separates main-path issues (CHK-) from fallback/defensive-path issues (FBK-) by root cause before assigning P0/P1/P2 severity, and supports a whitelisted DOC-* channel for auto-remediating low-risk factual documentation drift. - Use Case: Before committing a feature branch, ask for a check-all; the skill reads the task's prd.md/design.md/implement.md, traces the diff against them, runs targeted verification, and reports CHK/FBK findings with evidence, severity, and a single disposition prompt. ## Quick Start Ask the assistant to run a check-all review on the current workspace changes before committing, optionally requesting a light or full check.

Frequently Asked Questions about trellis-check-all

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I run a pre-commit code review against my task plan?▼

Invoke the check-all entry on your workspace changes; it reads the task's prd.md, design.md, and implement.md, traces the diff against them, and reports findings. You can request a light check for closed, small changes or a full check for complete acceptance mapping.

What is the difference between light and full check depth?▼

Light depth covers a closed single semantic scope with exhaustively enumerable references and targeted verification. Full depth maps all applicable planning entries, assumption dimensions, and spec checks; it is mandatory when behavior contracts, security, or unclosed impact surfaces are involved.

How are CHK and FBK findings classified?▼

Classification follows root cause before severity: main-path logic, contract, and verification failures become CHK-*, while fail-closed, malformed-input, degraded-fallback, and defensive-protection gaps become FBK-*. Both then receive P0/P1/P2 severity based on actual impact.

Can the check fix issues automatically?▼

Only low-risk factual documentation drift in the whitelisted DOC-* channel is auto-remediated, such as stale statuses, links, or mechanically outdated comment facts. Code, configuration, tests, and requirement changes are never auto-fixed; they are reported for user disposition.

When does a check block instead of passing?▼

A check blocks when undisposed CHK-*/FBK-* findings remain, when required pre-commit verification evidence is missing (partial verification), or when prerequisites fail. Post-deployment-only items are tagged as post-release verification and do not block.