ssqaq/trellis-skills/trellis-check

Code Quality Check

Comprehensive quality verification for recently written code. Combines spec compliance, cross-layer safety, and pre-commit checks.

Step 1: Identify What Changed

git diff --name-only HEAD
git status

Step 2: Read Task Artifacts and Applicable Specs

Read the current task artifacts in order:

• prd.md
• design.md if present
• implement.md if present

python ./.trellis/scripts/get_context.py --mode packages

For each changed package/layer, read the spec index and follow its Quality Check section:

cat .trellis/spec/<package>/<layer>/index.md

Read the specific guideline files referenced — the index is a pointer, not the goal.

Step 3: Run Project Checks

Run the project's lint, type-check, and test commands. Fix any failures before proceeding.

Step 4: Review Against Checklist

Release Notes and README (when this change will be published to GitHub)

Skip this section if neither a GitHub Release nor a README update will be published for this change. Otherwise:

Release notes (when a Release will be created) — verify the notes (or the draft intended for them):

• [ ] Written in plain language a non-developer can understand?
• [ ] Answers "what changed", "what it means for the user", and "whether the user needs to act" (e.g. reinstall)?
• [ ] Free of commit-style prefixes (feat:, fix:), file names, function/class names, and internal jargon in user-facing text?

README (when this task changes user-visible behavior, installation, or usage and the project has a README) — verify the README:

• [ ] Still matches what the software actually does after this change?
• [ ] Installation and usage instructions still work as written?
• [ ] New or changed user-visible behavior is described in plain language?

If any box fails, rewrite the affected text and re-verify before reporting completion. In this check, "publish to GitHub" means pushing, tagging, or creating a GitHub Release that exposes these changes to users.

Code Quality

• [ ] Linter passes?
• [ ] Type checker passes (if applicable)?
• [ ] Tests pass?
• [ ] No debug logging left in?
• [ ] No suppressed warnings or type-safety bypasses?

Test Coverage

• [ ] New function → unit test added?
• [ ] Bug fix → regression test added?
• [ ] Changed behavior → existing tests updated?

Spec Sync

• [ ] Does .trellis/spec/ need updates? (new patterns, conventions, lessons learned)

"If I fixed a bug or discovered something non-obvious, should I document it so future me won't hit the same issue?" → If YES, update the relevant spec doc.

Step 5: Cross-Layer Dimensions (if applicable)

Skip this step if your change is confined to a single layer.

A. Data Flow (changes touch 3+ layers)

• [ ] Read flow traces correctly: Storage → Service → API → UI
• [ ] Write flow traces correctly: UI → API → Service → Storage
• [ ] Types/schemas correctly passed between layers?
• [ ] Errors properly propagated to caller?

B. Code Reuse (modifying constants, creating utilities)

• [ ] Searched for existing similar code before creating new?

``bash grep -r "pattern" src/ ``

• [ ] If 2+ places define same value → extracted to shared constant?
• [ ] After batch modification, all occurrences updated?

C. Import/Dependency (creating new files)

• [ ] Correct import paths (relative vs absolute)?
• [ ] No circular dependencies?

D. Same-Layer Consistency

• [ ] Other places using the same concept are consistent?

Step 6: Report and Fix

Report violations found and fix them directly. Re-run project checks after fixes.