trellis-before-dev
GitHub在编码前自动发现并注入项目特定规范，读取规格索引和检查清单，确保遵循编码标准。
Trigger Scenarios
Install
npx skills add mindfold-ai/Trellis --skill trellis-before-dev -g -y
SKILL.md
Frontmatter
{
"name": "trellis-before-dev",
"description": "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:
-
Read current task artifacts:
prd.mdfor requirements and acceptance criteriadesign.mdif present for technical designimplement.mdif present for execution order and validation plan
-
Discover packages and their spec layers:
python3 ./.trellis/scripts/get_context.py --mode packages -
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
- Which package you're modifying (e.g.,
-
Read the spec index for each relevant module:
cat .trellis/spec/<package>/<layer>/index.mdFollow the "Pre-Development Checklist" section in the index.
-
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. -
Always read shared guides:
cat .trellis/spec/guides/index.md -
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.
If the real scope turns out to be clearly larger than this, say so and why before continuing. Do not widen the change on your own.
-
Understand the coding standards and patterns you need to follow, then proceed with your development plan.
This step is mandatory before writing any code.
Version History
- 0e0f1f6 Current 2026-08-20 08:09
