agentleFS
lxyerlxyer/multi-agent-collaboration-system/.agents/skills/start/SKILL.md

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

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.
  • CoralGameSkill

    setup-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

  • CoralGameSkill

    team-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

  • lilangMaxSkill

    create-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

  • lilangMaxSkill

    story-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

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
  1. Distinctive:

    When user describes a task, classify it:

    line 70
  2. Very specific:

    If code was changed, remind user to run $finish-work

    line 97
  3. Distinctive:

    If no, clarify and confirm again

    line 106
  4. Distinctive:

    Create task directory (Phase 1 Path B, Step 2)

    line 108
  5. Distinctive:

    Ask questions one at a time: - Update PRD after each answer

    line 127
  6. Distinctive:

    Run a dedicated research pass before coding

    line 137
  7. Distinctive:

    Verify with a separate check pass

    line 140
  8. Distinctive:

    If unclear, ask clarifying questions.

    line 172
  9. Very specific:

    Create prd.md in the task directory with:

    line 182
  10. Distinctive:

    If the task touches infra or cross-layer contracts, do not start implementation until code-spec depth is defined.

    line 210
  11. Distinctive:

    Use this output format:

    line 232
  12. Distinctive:

    Add specs found in your research pass:

    line 254
  13. Distinctive:

    Follow all specs injected into implement context

    line 278
  14. Distinctive:

    Keep changes scoped to requirements

    line 279
  15. Distinctive:

    Run lint and typecheck before finishing

    line 280
  16. Distinctive:

    Run a quality pass against check context:

    line 284
  17. Distinctive:

    Ensure lint and typecheck pass

    line 288
  18. Distinctive:

    Verify lint and typecheck pass

    line 292
  19. Very specific:

    Run $record-session to record this session

    line 297
  20. Very specific:

    If get_context.py shows a current task:

    line 303
  21. Very specific:

    Read the task's prd.md to understand the goal

    line 305
  22. Very specific:

    Check task.json for current status and phase

    line 306
  23. Distinctive:

    Ask user: "Continue working on <task-name>?"

    line 307
  24. Distinctive:

    If yes, resume from the appropriate step (usually Step 7 or 8).

    line 309

“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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Start Session

Initialize your AI development session and begin working on tasks.


Operation Types

MarkerMeaningExecutor
[AI]Bash scripts or tool calls executed by AIYou (AI)
[USER]Skills executed by userUser

Initialization [AI]

Step 1: Understand Development Workflow

First, read the workflow guide to understand the development process:

cat .trellis/workflow.md

Follow 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.py

This shows: developer identity, git status, current task (if any), active tasks.

Step 3: Read Guidelines Index

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

This 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:

TypeCriteriaWorkflow
QuestionUser asks about code, architecture, or how something worksAnswer directly
Trivial FixTypo fix, comment update, single-line change, < 5 minutesDirect Edit
Simple TaskClear goal, 1-2 files, well-defined scopeQuick confirm → Task Workflow
Complex TaskVague goal, multiple files, architectural decisionsBrainstorm → 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 --parent flag or add-subtask command. See the brainstorm skill's Step 8 for details.


Question / Trivial Fix

For questions or trivial fixes, work directly:

  1. Answer question or make the fix
  2. If code was changed, remind user to run $finish-work

Simple Task

For simple, well-defined tasks:

  1. Quick confirm: "I understand you want to [goal]. Shall I proceed?"
  2. If no, clarify and confirm again
  3. 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:

  1. Acknowledge and classify - State your understanding
  2. Create task directory - Track evolving requirements in prd.md
  3. Ask questions one at a time - Update PRD after each answer
  4. Propose approaches - For architectural decisions
  5. Confirm final requirements - Get explicit approval
  6. 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 → Complete

Key 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:

  1. Relevant spec files in .trellis/spec/
  2. Existing code patterns to follow (2-3 examples)
  3. 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 | fullstack

Add 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]

  1. Verify lint and typecheck pass
  2. Report what was implemented
  3. Remind user to:
    • Test the changes
    • Commit when ready
    • Run $record-session to record this session

Continuing Existing Task

If get_context.py shows a current task:

  1. Read the task's prd.md to understand the goal
  2. Check task.json for current status and phase
  3. Ask user: "Continue working on <task-name>?"

If yes, resume from the appropriate step (usually Step 7 or 8).


Skills Reference

User Skills [USER]

SkillWhen to Use
$startBegin a session (this skill)
$finish-workBefore committing changes
$record-sessionAfter completing a task

AI Scripts [AI]

ScriptPurpose
python3 ./.trellis/scripts/get_context.pyGet session context
python3 ./.trellis/scripts/task.py createCreate task directory
python3 ./.trellis/scripts/task.py init-contextInitialize jsonl files
python3 ./.trellis/scripts/task.py add-contextAdd spec to jsonl
python3 ./.trellis/scripts/task.py startSet current task
python3 ./.trellis/scripts/task.py finishClear current task
python3 ./.trellis/scripts/task.py archiveArchive completed task

Workflow Phases [AI]

PhasePurposeContext Source
researchAnalyze codebasedirect repo inspection
implementWrite codeimplement.jsonl
checkReview & fixcheck.jsonl
debugFix specific issuesdebug.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.

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.