trellis-maven-verify

Generates tiered Maven verification plans and reuses auditable build evidence across Trellis workflows.

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

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Large Maven multi-module builds are slow: -am pulls in too many modules, and compile/package phases trigger expensive goals like sources jars, shade, repackage, and javadoc. This Skill plans the shortest sufficient Maven lifecycle for Java changes and lets Check-All reuse prior build evidence instead of rebuilding. ## Core Features & Use Cases - Tiered Verification Modes: quick mode gives fast local feedback with optional source-stale compilation, final mode produces conservative, reusable evidence, and reuse mode lets Check-All validate evidence read-only without running Maven goals. - Reactor Trimming: Maps changed files to the minimal module set with -am for required upstreams, avoiding full-repo -amd builds and skipping expensive plugin bindings when not required. - Auditable Evidence Contract: Evidence binds Git HEAD, POM fingerprints, toolchain, argv, and logs, with states like reusable, partial, stale, failed, and blocked so downstream checks know exactly what is covered. - Use Case: After editing one module in a 50-module Java 8 monorepo, generate a quick compile plan scoped to that module and its upstreams, then let the final Check-All phase reuse the recorded evidence instead of triggering a full reactor build. ## Quick Start Ask the AI to use trellis-maven-verify to create a quick verification plan for the modules changed in the current Maven project.

Frequently Asked Questions about trellis-maven-verify

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

FAQPage Schema
How do I speed up Maven builds for large multi-module projects?▼

Scope the build to changed modules with `-am` for required upstreams instead of building the whole reactor, and stop at the lowest sufficient lifecycle phase. This Skill generates such plans via the maven_verify.py script, optionally using source-stale compilation for quick feedback.

How to avoid running expensive Maven goals like shade or javadoc during compile?▼

Stop the lifecycle at `compile` or `test` instead of `package`, since goals like shade, repackage, assembly, and javadoc bind to later phases. The plan inspects the effective POM and reports expensive bindings, skipping sources jars only when plugin versions are confirmed compatible.

Can Maven build evidence be reused instead of rebuilding in CI checks?▼

Yes, the `check` command reuses recorded evidence read-only when it is fresh and covers current requirements. Evidence binds Git HEAD, POM fingerprints, toolchain versions, and argv; if anything changed it is marked stale and a precise re-run gap is reported.

Does this Maven verification work on WSL with Windows projects?▼

Yes, the build side is determined by the filesystem hosting the Maven root. WSL projects on drvfs/9p Windows drives use Windows Maven, JDK, and local repository, while WSL ext4 projects use the Linux toolchain; mixing sides causes the plan to be blocked.

When should I not use source-stale incremental compilation in Maven?▼

Avoid source-stale when changes touch public APIs, DTOs, constants, annotation processors, POMs, or resource contracts, since stale-based compilation does not cover those risks. Final verification defaults to conservative compilation unless task materials explicitly confirm low-risk internal changes.