// Understand and customize the local Trellis architecture inside a user project. Use when modifying .trellis plus platform hooks, settings, agents, skills, commands, prompts, or workflows generated by trellis init.
| name | trellis-meta |
| description | Understand and customize the local Trellis architecture inside a user project. Use when modifying .trellis plus platform hooks, settings, agents, skills, commands, prompts, or workflows generated by trellis init. |
This skill is for local Trellis users who have already run trellis init in a project. After reading it, an AI should understand the Trellis architecture, operating model, and customization entry points inside that user project, then modify the generated .trellis/ and platform directory files according to the user's request.
The default operating scope is local files in the user project:
.trellis/: workflow, config, tasks, spec, workspace, scripts, and runtime state..claude/, .codex/, .cursor/, .opencode/, .kiro/, .gemini/, .qoder/, .codebuddy/, .github/, .factory/, .pi/, .kilocode/, .agent/, .windsurf/, and similar directories..agents/skills/.Do not assume the user has the Trellis source repository. Do not default to modifying the global npm install directory or node_modules.
references/local-architecture/overview.md first to establish the local Trellis system model.references/platform-files/platform-map.md and the relevant platform file notes.references/customize-local/overview.md, then open the specific customization topic.references/local-architecture/overview.md: The three-layer local Trellis architecture and customization principles.references/local-architecture/generated-files.md: Files generated by trellis init and their customization boundaries.references/local-architecture/workflow.md: Phases, routing, and workflow-state blocks in .trellis/workflow.md.references/local-architecture/task-system.md: Task directories, active tasks, JSONL context, and task runtime.references/local-architecture/spec-system.md: How .trellis/spec/ is organized and injected.references/local-architecture/workspace-memory.md: .trellis/workspace/, journals, and cross-session memory.references/local-architecture/context-injection.md: Hooks, sub-agent preludes, and context injection paths.references/platform-files/overview.md: How shared .trellis/ files relate to platform directories.references/platform-files/platform-map.md: Platform directories and paths for skills, agents, hooks, and extensions.references/platform-files/hooks-and-settings.md: How settings/config files, hooks, plugins, and extensions connect to Trellis.references/platform-files/agents.md: Local file responsibilities for trellis-research, trellis-implement, and trellis-check.references/platform-files/skills-and-commands.md: Differences between skills, commands, prompts, and workflows, plus how to change them.references/customize-local/overview.md: Choose the right local customization entry point for the user's request.references/customize-local/change-workflow.md: Change phases, routing, next actions, and workflow-state.references/customize-local/change-task-lifecycle.md: Change task creation, status, archive behavior, and hooks.references/customize-local/change-context-loading.md: Change how tasks, specs, journals, and hook context are loaded.references/customize-local/change-hooks.md: Change platform hooks, settings, and shell session bridges.references/customize-local/change-agents.md: Change research, implement, and check agent behavior.references/customize-local/change-skills-or-commands.md: Add or modify local skills, commands, prompts, and workflows.references/customize-local/change-spec-structure.md: Adjust the project spec structure under .trellis/spec/.references/customize-local/add-project-local-conventions.md: Put team rules into project-local specs or local skills..trellis/workflow.md is the local workflow source of truth..trellis/config.yaml is the project-level Trellis configuration and task hook configuration entry point..trellis/spec/ stores the user's project-specific coding conventions and design constraints..trellis/tasks/ stores task PRDs, technical notes, research files, and JSONL context..trellis/workspace/ stores developer journals and cross-session memory..trellis/.template-hashes.json and .trellis/.runtime/ are management/runtime state files. Confirm necessity before editing them.node_modules/@mindfoldhq/trellis to implement project needs.trellis-meta; put project rules in .trellis/spec/ or a project-local skill.Collaborative requirements discovery session optimized for AI coding workflows. Creates task directories, seeds PRDs, runs codebase research, proposes concrete implementation approaches with trade-offs, and converges on MVP scope through structured Q&A. Use when requirements are unclear, multiple implementation paths exist, trade-offs need evaluation, or a complex feature needs scoping before development.
Initializes an AI development session by reading workflow guides, developer identity, git status, active tasks, and project guidelines from .trellis/. Classifies incoming tasks and routes to brainstorm, direct edit, or task workflow. Use when beginning a new coding session, resuming work, starting a new task, or re-establishing project context.
Wrap up the current session: verify quality gate passed, remind user to commit, archive completed tasks, and record session progress to the developer journal. Use when done coding and ready to end the session.
Wrap up an active Trellis task: archive it (and any other completed-but-unarchived tasks the user wants to clean up) and record a session journal. Refuses to run if the working tree has uncommitted code changes (those belong in workflow Phase 3.4 first). Use when the user asks to finish / wrap up / call it a day, or invokes $finish-work.
Resume work on the current task. Loads the workflow Phase Index, figures out which phase/step to pick up at, then pulls the step-level detail via get_context.py --mode phase. Use when coming back to an in-progress task and you need to know what to do next.
Guides collaborative requirements discovery before implementation. Creates task directory, seeds PRD, asks high-value questions one at a time, researches technical choices, and converges on MVP scope. Use when requirements are unclear, there are multiple valid approaches, or the user describes a new feature or complex task.