agentleFS
Sign inStart free
insapption-projectsinsapption-projects/claude-agent-team-starter/CLAUDE.md

claude-agent-team-starter

CLAUDE.md1 starsChanged 8 months agoMITView on GitHub

This file is the primary operating instruction for Claude Code in any project that has installed this starter. It is intentionally concise. Detailed project context belongs in references/. Procedural detail belongs in skills. Detects present stacks and generates only the applicable reference files. Creates references/methodology.md with observed conventions if patterns are visible in the code. Or use /dev-workflow to run all 15 steps in sequence with automatic checkpoints.

The file

Show its rules and text

We split this CLAUDE.md into the rules it gives an agent

17 rules. About 0 are common, 6 are distinctive, and 11 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈6

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 11

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Start with /init-references: Run it from the project root when onboarding a codebase or after adding a new stack.

    line 24
  2. Very specific:

    Read references before planning: Use references/ as the primary project map.

    line 26
  3. Distinctive:

    Do not invent structure: Every file path, route, model, component, or API referenced in a plan must be traceable to a reference file or a …

    line 28
  4. Very specific:

    Separate planning from implementation: Use /plan-feature to produce a written plan before editing any files.

    line 30
  5. Very specific:

    Refresh references before closing a task: Run /update-references auto after development work.

    line 32
  6. Very specific:

    Run /read-references auto to load relevant maps

    line 48
  7. Very specific:

    Run /plan-feature to identify affected files and produce an implementation plan

    line 49
  8. Very specific:

    Run /implement-plan to execute the approved plan

    line 51
  9. Very specific:

    Run /test-lint to validate

    line 52
  10. Very specific:

    Run /update-references auto to refresh affected maps

    line 59
  11. Very specific:

    Run /create-pr to push and open a pull request

    line 60
  12. Distinctive:

    Do not mark the task complete until references reflect the current code

    line 61
  13. Very specific:

    Keep this file operational, not explanatory.

    line 75
  14. Distinctive:

    Keep procedural steps inside skills, not here.

    line 76
  15. Distinctive:

    Prefer hook-enforced rules over guidelines that depend on memory.

    line 77
  16. Distinctive:

    Never fabricate paths, APIs, or structure not present in references or code.

    line 78
  17. Distinctive:

    When in doubt about scope, ask before expanding.

    line 79

≈ “Common” is an estimate: at least 1 in 5 of the 26,980 CLAUDE.md files we read have a rule of the same kind, not the same words. “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
CLAUDE.md

Claude Agent Team Starter

This file is the primary operating instruction for Claude Code in any project that has installed this starter. It is intentionally concise. Detailed project context belongs in references/. Procedural detail belongs in skills.

Purpose

  • Give Claude Code a clean agent-team structure through .claude/
  • Build durable project maps in references/ from real code
  • Reduce repeated full-repo reading by keeping maps current after each task

Supported layouts

  • Laravel only
  • React only
  • React Native only
  • Laravel + React
  • Laravel + React Native
  • Laravel + React + React Native
  • React + React Native
  • Mixed monorepos (apps/, packages/, services/ structures)

Non-negotiable rules

  1. Start with /init-references. Run it from the project root when onboarding a codebase or after adding a new stack. Do not proceed to implementation without reference maps in place.
  2. Read references before planning. Use references/ as the primary project map. Do targeted code reads only where the task requires them. Do not re-read the full codebase.
  3. Do not invent structure. Every file path, route, model, component, or API referenced in a plan must be traceable to a reference file or a direct code read. If something is absent from both, say so explicitly rather than assuming.
  4. Separate planning from implementation. Use /plan-feature to produce a written plan before editing any files. Require explicit approval before starting /implement-plan.
  5. Refresh references before closing a task. Run /update-references auto after development work. The post-task hook enforces this — tasks cannot be marked complete if affected reference files were not updated.
  6. Treat absent reference files as not applicable. A missing references/mobile_map.md means no React Native app was detected. It does not mean initialization failed.

Default operating flow

Phase 1 — Bootstrap (once per project)

/init-references

Detects present stacks and generates only the applicable reference files. Creates references/methodology.md with observed conventions if patterns are visible in the code.

Phase 2 — Plan and implement (each task)

  1. Run /read-references auto to load relevant maps
  2. Run /plan-feature to identify affected files and produce an implementation plan
  3. Get explicit approval before proceeding
  4. Run /implement-plan to execute the approved plan
  5. Run /test-lint to validate
  6. Fix failures with /fix-plan + /implement-fix if needed

Or use /dev-workflow to run all 15 steps in sequence with automatic checkpoints.

Phase 3 — Close the task

  1. Run /update-references auto to refresh affected maps
  2. Run /create-pr to push and open a pull request
  3. Do not mark the task complete until references reflect the current code

Reference file roles

FileWhat it tracks
references/schema.mdDatabase tables, columns, indexes, relationships
references/backend_map.mdLaravel routes, controllers, services, models, middleware
references/frontend_map.mdReact components, hooks, stores, services, routing
references/mobile_map.mdReact Native screens, navigation, Expo config, mobile services
references/methodology.mdProject conventions, architecture patterns, naming rules

Working principles

  • Keep this file operational, not explanatory. Prose belongs in docs/.
  • Keep procedural steps inside skills, not here.
  • Prefer hook-enforced rules over guidelines that depend on memory.
  • Never fabricate paths, APIs, or structure not present in references or code.
  • When in doubt about scope, ask before expanding.

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.

Check your setup, free