Skills

Trellis Before Dev

Discovers and injects project-specific coding guidelines from .trellis/spec/ before...

Install

npx skills add mindfold-ai/Trellis --skill trellis-before-dev -g -a claude-code -y
Repository
mindfold-ai/Trellis15.1k
Category
Writing
Updated
1mo ago
License
AGPL-3.0
Context cost
Lightabout 558 tokens
Runs scripts
No, instructions only

What it does

Discovers and injects project-specific coding guidelines from .trellis/spec/ before implementation begins. Reads spec indexes, pre-development checklists, and shared thinking guides for the target package. Use when starting a new coding task, before writing any code, switching to a different package, or needing to refresh project conventions and standards.

Read the relevant development guidelines before starting your task.

Execute these steps:

  1. Read current task artifacts:

    • prd.md for requirements and acceptance criteria
    • design.md if present for technical design
    • implement.md if present for execution order and validation plan
  2. Discover packages and their spec layers:

    python3 ./.trellis/scripts/get_context.py --mode packages
    
  3. Identify which specs apply to your task based on:

    • Which package you're modifying (e.g., cli/, docs-site/)
    • What type of work (backend, frontend, unit-test, docs, etc.)
    • Any spec/research paths referenced by the task artifacts
  4. Read the spec index for each relevant module:

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

    Follow the "Pre-Development Checklist" section in the index.

  5. Read the specific guideline files listed in the Pre-Development Checklist that are relevant to your task. The index is NOT the goal, it points you to the actual guideline files (e.g., error-handling.md, conventions.md, mock-strategies.md). Read those files to understand the coding standards and patterns.

  6. Always read shared guides:

    cat .trellis/spec/guides/index.md
    
  7. For a non-trivial task, state the change boundary before writing code. Non-trivial means it touches more than one file, crosses a layer, changes a public interface, or edits code you did not just write. Write down:

    • the smallest behavior gap between what happens now and what should happen
    • where that behavior actually lives (not where it is easiest to intercept)
    • which files you expect to change, and why each one is necessary
    • what you are explicitly not doing in this task
    • if a local refactor is needed, how you will show it did not change behavior

    A small, well-scoped change does not need this, do it directly.

Read the whole SKILL.md on GitHub

More in Writing