start
Skill1 starsChanged 7 months agoMITView on GitHub
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.
130 other projects use a version of this.
Adopted by
Most recently taken up by
- ansvisor/ansvisortheir own version, first seen Nov 8, 2026
- dsifry/metaswarmtheir own version, first seen Nov 8, 2026
- ai-search-guru/getcito-worlds-first-open-source-aio-aeo-or-geo-tooltheir own version, first seen Nov 8, 2026
- paulocsb/worldcup-fifa-pooltheir own version, first seen Nov 8, 2026
- srinator22/New-Projecttheir own version, first seen Nov 8, 2026
- Memolok/Claude-plugintheir own version, first seen Nov 6, 2026
Used with
Projects with it also use setup-engine, team-audio and 10 more.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
CoralGameSkillsetup-engine
Configure the project's game engine and version. Pins the engine in CLAUDE.md, detects knowledge gaps, and populates engine reference docs via WebSearch when the version is beyond the LLM's training data.
Also in 13 projects that use this
CoralGameSkillteam-audio
Orchestrate audio team: audio-director + sound-designer + technical-artist + gameplay-programmer for full audio pipeline from direction to implementation.
Also in 13 projects that use this
lilangMaxSkillcreate-stories
Break a single epic into implementable story files. Reads the epic, its GDD, governing ADRs, and control manifest. Each story embeds its GDD requirement TR-ID, ADR guidance, acceptance criteria, story type, and test evidence path. Run after /create-epics for each epic.
Also in 11 projects that use this
lilangMaxSkillstory-done
End-of-story completion review. Reads the story file, verifies each acceptance criterion against the implementation, checks for GDD/ADR deviations, prompts code review, updates story status to Complete, and surfaces the next ready story from the sprint.
Also in 11 projects that use this
- +5 more from CoralGame
- +3 more from lilangMax
Other versions130 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 130
- anthropics/knowledge-work-plugins★ 35ksame name
- Donchitos/Claude-Code-Game-Studios★ 27ksame name
- openai/plugins★ 7.8ksame name
- SterlingChin/marvin-template★ 1ksame name
- educlopez/ui-craft★ 441same name
- ai-search-guru/getcito-worlds-first-open-source-aio-aeo-or-geo-tool★ 432same name
- dsifry/metaswarm★ 426same name
- pixel-cellar/Claude-Code-Game-Studios★ 324same name
- ansvisor/ansvisor★ 233same name
- alexeykrol/claude-code-starter★ 194same name
120 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository16 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- .github/copilot-instructions.mdCopilot instructions
- .cursor/rules/macs-protocol.mdcCursor rule
- before-devSkill
- brainstormSkill
- break-loopSkill
- check-cross-layerSkill
- checkSkill
- create-commandSkill
- finish-workSkill
- improve-utSkill
- integrate-skillSkill
- onboardSkill
- record-sessionSkill
- update-specSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
24 rules. 0 are common, 18 are distinctive, and 6 are very specific to this project.
0
Common
Most of the 117 edited versions we read keep these.
18
Distinctive
This author's own choices. Worth a look.
6
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- could be automatic: a setting could enforce it
- Distinctive: line 70
When user describes a task, classify it:
- Very specific: line 97
If code was changed, remind user to run $finish-work
- Distinctive: line 106
If no, clarify and confirm again
- Distinctive: line 108
Create task directory (Phase 1 Path B, Step 2)
- Distinctive: line 127
Ask questions one at a time: - Update PRD after each answer
- Distinctive: line 137
Run a dedicated research pass before coding
- Distinctive: line 140
Verify with a separate check pass
- Distinctive: line 172
If unclear, ask clarifying questions.
- Very specific: line 182
Create prd.md in the task directory with:
- Distinctive: line 210
If the task touches infra or cross-layer contracts, do not start implementation until code-spec depth is defined.
- Distinctive: line 232
Use this output format:
- Distinctive: line 254
Add specs found in your research pass:
- Distinctive: line 278
Follow all specs injected into implement context
- Distinctive: line 279
Keep changes scoped to requirements
- Distinctive: line 280
Run lint and typecheck before finishing
- Distinctive: line 284
Run a quality pass against check context:
- Distinctive: line 288
Ensure lint and typecheck pass
- Distinctive: line 292
Verify lint and typecheck pass
- Very specific: line 297
Run $record-session to record this session
- Very specific: line 303
If get_context.py shows a current task:
- Very specific: line 305
Read the task's prd.md to understand the goal
- Very specific: line 306
Check task.json for current status and phase
- Distinctive: line 307
Ask user: "Continue working on <task-name>?"
- Distinctive: line 309
If yes, resume from the appropriate step (usually Step 7 or 8).
“Common” is measured: kept by at least 6 in 10 of the 117 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Start Session
Initialize your AI development session and begin working on tasks.
Operation Types
| Marker | Meaning | Executor |
[AI] | Bash scripts or tool calls executed by AI | You (AI) |
[USER] | Skills executed by user | User |
Initialization [AI]
Step 1: Understand Development Workflow
First, read the workflow guide to understand the development process:
cat .trellis/workflow.mdFollow the instructions in workflow.md - it contains:
- Core principles (Read Before Write, Follow Standards, etc.)
- File system structure
- Development process
- Best practices
Step 2: Get Current Context
python3 ./.trellis/scripts/get_context.pyThis shows: developer identity, git status, current task (if any), active tasks.
Step 3: Read Guidelines Index
python3 ./.trellis/scripts/get_context.py --mode packagesThis shows available packages and their spec layers. Read the relevant spec indexes:
cat .trellis/spec/<package>/<layer>/index.md # Package-specific guidelines
cat .trellis/spec/guides/index.md # Thinking guides (always read)Important: The index files are navigation — they list the actual guideline files (e.g.,
error-handling.md,conventions.md,mock-strategies.md). At this step, just read the indexes to understand what's available. When you start actual development, you MUST go back and read the specific guideline files relevant to your task, as listed in the index's Pre-Development Checklist.
Step 4: Report and Ask
Report what you learned and ask: "What would you like to work on?"
Task Classification
When user describes a task, classify it:
| Type | Criteria | Workflow |
| Question | User asks about code, architecture, or how something works | Answer directly |
| Trivial Fix | Typo fix, comment update, single-line change, < 5 minutes | Direct Edit |
| Simple Task | Clear goal, 1-2 files, well-defined scope | Quick confirm → Task Workflow |
| Complex Task | Vague goal, multiple files, architectural decisions | Brainstorm → Task Workflow |
Decision Rule
If in doubt, use Brainstorm + Task Workflow.
Task Workflow ensures code-specs are injected to the right context, resulting in higher quality code. The overhead is minimal, but the benefit is significant.
Subtask Decomposition: If brainstorm reveals multiple independent work items, consider creating subtasks using
--parentflag oradd-subtaskcommand. See the brainstorm skill's Step 8 for details.
Question / Trivial Fix
For questions or trivial fixes, work directly:
- Answer question or make the fix
- If code was changed, remind user to run
$finish-work
Simple Task
For simple, well-defined tasks:
- Quick confirm: "I understand you want to [goal]. Shall I proceed?"
- If no, clarify and confirm again
- If yes: execute ALL steps below without stopping. Do NOT ask for additional confirmation between steps.
- Create task directory (Phase 1 Path B, Step 2)
- Write PRD (Step 3)
- Research codebase (Phase 2, Step 5)
- Configure context (Step 6)
- Activate task (Step 7)
- Implement (Phase 3, Step 8)
- Check quality (Step 9)
- Complete (Step 10)
Complex Task - Brainstorm First
For complex or vague tasks, automatically start the brainstorm process — do NOT skip directly to implementation.
See $brainstorm for the full process. Summary:
- Acknowledge and classify - State your understanding
- Create task directory - Track evolving requirements in
prd.md - Ask questions one at a time - Update PRD after each answer
- Propose approaches - For architectural decisions
- Confirm final requirements - Get explicit approval
- Proceed to Task Workflow - With clear requirements in PRD
Task Workflow (Development Tasks)
Why this workflow?
- Run a dedicated research pass before coding
- Configure specs in jsonl context files
- Implement using injected context
- Verify with a separate check pass
- Result: Code that follows project conventions automatically
Overview: Two Entry Points
From Brainstorm (Complex Task):
PRD confirmed → Research → Configure Context → Activate → Implement → Check → Complete
From Simple Task:
Confirm → Create Task → Write PRD → Research → Configure Context → Activate → Implement → Check → CompleteKey principle: Research happens AFTER requirements are clear (PRD exists).
Phase 1: Establish Requirements
Path A: From Brainstorm (skip to Phase 2)
PRD and task directory already exist from brainstorm. Skip directly to Phase 2.
Path B: From Simple Task
Step 1: Confirm Understanding [AI]
Quick confirm:
- What is the goal?
- What type of development? (frontend / backend / fullstack)
- Any specific requirements or constraints?
If unclear, ask clarifying questions.
Step 2: Create Task Directory [AI]
TASK_DIR=$(python3 ./.trellis/scripts/task.py create "<title>" --slug <name>)Step 3: Write PRD [AI]
Create prd.md in the task directory with:
# <Task Title>
## Goal
<What we're trying to achieve>
## Requirements
- <Requirement 1>
- <Requirement 2>
## Acceptance Criteria
- [ ] <Criterion 1>
- [ ] <Criterion 2>
## Technical Notes
<Any technical decisions or constraints>Phase 2: Prepare for Implementation (shared)
Both paths converge here. PRD and task directory must exist before proceeding.
Step 4: Code-Spec Depth Check [AI]
If the task touches infra or cross-layer contracts, do not start implementation until code-spec depth is defined.
Trigger this requirement when the change includes any of:
- New or changed command/API signatures
- Database schema or migration changes
- Infra integrations (storage, queue, cache, secrets, env contracts)
- Cross-layer payload transformations
Must-have before proceeding:
- Target code-spec files to update are identified
- Concrete contract is defined (signature, fields, env keys)
- Validation and error matrix is defined
- At least one Good/Base/Bad case is defined
Step 5: Research the Codebase [AI]
Based on the confirmed PRD, run a focused research pass and produce:
- Relevant spec files in
.trellis/spec/ - Existing code patterns to follow (2-3 examples)
- Files that will likely need modification
Use this output format:
## Relevant Specs
- <path>: <why it's relevant>
## Code Patterns Found
- <pattern>: <example file path>
## Files to Modify
- <path>: <what change>Step 6: Configure Context [AI]
Initialize default context:
python3 ./.trellis/scripts/task.py init-context "$TASK_DIR" <type>
# type: backend | frontend | fullstackAdd specs found in your research pass:
# For each relevant spec and code pattern:
python3 ./.trellis/scripts/task.py add-context "$TASK_DIR" implement "<path>" "<reason>"
python3 ./.trellis/scripts/task.py add-context "$TASK_DIR" check "<path>" "<reason>"Step 7: Activate Task [AI]
python3 ./.trellis/scripts/task.py start "$TASK_DIR"This sets .current-task so hooks can inject context.
Phase 3: Execute (shared)
Step 8: Implement [AI]
Implement the task described in prd.md.
- Follow all specs injected into implement context
- Keep changes scoped to requirements
- Run lint and typecheck before finishing
Step 9: Check Quality [AI]
Run a quality pass against check context:
- Review all code changes against the specs
- Fix issues directly
- Ensure lint and typecheck pass
Step 10: Complete [AI]
- Verify lint and typecheck pass
- Report what was implemented
- Remind user to:
- Test the changes
- Commit when ready
- Run
$record-sessionto record this session
Continuing Existing Task
If get_context.py shows a current task:
- Read the task's
prd.mdto understand the goal - Check
task.jsonfor current status and phase - Ask user: "Continue working on
<task-name>?"
If yes, resume from the appropriate step (usually Step 7 or 8).
Skills Reference
User Skills [USER]
| Skill | When to Use |
$start | Begin a session (this skill) |
$finish-work | Before committing changes |
$record-session | After completing a task |
AI Scripts [AI]
| Script | Purpose |
python3 ./.trellis/scripts/get_context.py | Get session context |
python3 ./.trellis/scripts/task.py create | Create task directory |
python3 ./.trellis/scripts/task.py init-context | Initialize jsonl files |
python3 ./.trellis/scripts/task.py add-context | Add spec to jsonl |
python3 ./.trellis/scripts/task.py start | Set current task |
python3 ./.trellis/scripts/task.py finish | Clear current task |
python3 ./.trellis/scripts/task.py archive | Archive completed task |
Workflow Phases [AI]
| Phase | Purpose | Context Source |
| research | Analyze codebase | direct repo inspection |
| implement | Write code | implement.jsonl |
| check | Review & fix | check.jsonl |
| debug | Fix specific issues | debug.jsonl |
Key Principle
Code-spec context is injected, not remembered.
The Task Workflow ensures agents receive relevant code-spec context automatically. This is more reliable than hoping the AI "remembers" conventions.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

