agentleFS
TrecekTrecek/useful-claude-skills/CLAUDE.md

useful-claude-skills

CLAUDE.md1 starsChanged 8 months agoMITView on GitHub

This document provides mandatory instructions for AI-assisted development in this repository. All contributions must be consistent, high-quality, and aligned with these standards. A collection of reusable Claude Code skills for software engineering workflows. Skills are markdown instruction files in .claude/skills/ that teach Claude specific methodologies — investigation, planning, auditing, documentation, and architecture visualization. They chain together (e.g., investigate → rectify → implement-worktree) and use subagents for parallel exploration. These rules are essential for maintaining project structure, preventing bugs, and ensuring…

The file

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

7 rules. About 0 are common, 6 are distinctive, and 1 is 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.

  • 1

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Adhere to Project Standards: Write clean, maintainable code following the established conventions and architectural patterns of this …

    line 14
  2. Distinctive:

    Address the Root Cause: When your code fails a test or causes a bug, debug the implementation to find and fix the root cause.

    line 24
  3. Distinctive:

    No Backward Compatibility Hacks: Do NOT leave comments about dead or deprecated code.

    line 25
  4. Distinctive:

    Avoid Redundancy: Do not duplicate logic, utilities, or test code.

    line 26
  5. Distinctive:

    Use Current Package Versions: When adding new dependencies, use web search to find and use the current stable version.

    line 27
  6. Very specific:

    Temporary Files: All temporary files for debugging, analysis, or testing hypotheses must be created in the project's temp/ directory.

    line 31
  7. Distinctive:

    Do Not Add Root Files: Never create new files or scripts in the repository root unless the task explicitly requires it.

    line 32

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

Project Development Guidelines

This document provides mandatory instructions for AI-assisted development in this repository. All contributions must be consistent, high-quality, and aligned with these standards.

1. Core Project Goal

A collection of reusable Claude Code skills for software engineering workflows. Skills are markdown instruction files in .claude/skills/ that teach Claude specific methodologies — investigation, planning, auditing, documentation, and architecture visualization. They chain together (e.g., investigate → rectify → implement-worktree) and use subagents for parallel exploration.

2. General Principles

  • Follow the Task Description: Your primary source of truth is the issue, ticket, or work package description provided for your assignment. It contains the complete scope and requirements for your work.
  • Adhere to Task Scope: Strictly adhere to the scope of the assigned task. Do not work on unassigned features, unrelated refactoring, or bug fixes outside the current assignment.
  • Implement Faithfully: Produce a functionally correct implementation based on the task requirements. Do not add new features or architectural changes unless explicitly requested.
  • Adhere to Project Standards: Write clean, maintainable code following the established conventions and architectural patterns of this project.

3. Critical Rules - DO NOT VIOLATE

These rules are essential for maintaining project structure, preventing bugs, and ensuring a clean codebase.

3.1. Code and Implementation

  • Do Not Oversimplify: Implement logic with its required complexity. Do not take shortcuts that compromise correctness or violate requirements.
  • Respect the Existing Architecture: Build upon the established project structure, modules, and design patterns. Do not introduce new architectural patterns or file structures without explicit instruction. Always understand existing architecture before implementing a new feature.
  • Address the Root Cause: When your code fails a test or causes a bug, debug the implementation to find and fix the root cause. Avoid hardcoded workarounds that only solve for specific inputs.
  • No Backward Compatibility Hacks: Do NOT leave comments about dead or deprecated code. No backward compatibility or deprecated code should be kept. Dead code should always be removed.
  • Avoid Redundancy: Do not duplicate logic, utilities, or test code.
  • Use Current Package Versions: When adding new dependencies, use web search to find and use the current stable version.

3.2. File System

  • Temporary Files: All temporary files for debugging, analysis, or testing hypotheses must be created in the project's temp/ directory.
  • Do Not Add Root Files: Never create new files or scripts in the repository root unless the task explicitly requires it.
  • Never commit unless told to do so

4. Testing Guidelines

4.1. Running Tests

This is a skills-only repository with no executable code and no test suite. Verification is done by reviewing skill outputs against the format defined in each SKILL.md.

5. Pre-commit Hooks

Install hooks after cloning: pre-commit install

Hooks run automatically on commit. To run manually: pre-commit run --all-files

<!-- List your project's specific hooks here -->

6. Architecture

.claude/skills/           # All skill definitions (SKILL.md files)
  arch-lens-*/            # 13 architecture lens skills
  investigate/            # Root cause analysis
  rectify/                # Architectural immunity plans
  review-approach/        # External solution research
  make-plan/              # Implementation planning
  make-scenarios/         # Scenario discovery
  make-req/               # Requirement decomposition
  elaborate-phase/        # Phase elaboration
  dry-walkthrough/        # Plan validation
  implement-worktree/     # Isolated implementation
  audit-arch/             # Architecture audit
  audit-bugs/             # Bug pattern mining
  audit-cohesion/         # Integration fitness and pattern alignment audit
  audit-tests/            # Test quality audit
  audit-defense-standards/ # Defense standard audit
  audit-impl/             # Pre-merge implementation audit (GO/NO GO)
  design-guards/          # Guard design from bug patterns
  id-slop/                # AI slop identification
  update-architecture/    # Architecture doc maintenance
  update-reqs/            # Requirements doc maintenance
  update-specs/           # Specification maintenance
  mermaid/                # Shared mermaid styling
  make-arch-diag/         # Interactive lens selection
  verify-diag/            # Diagram verification
docs/                     # Category documentation and examples
  arch-lens/              # Lens overview + examples by tool
  investigation/          # Investigation pipeline docs
  planning/               # Planning pipeline docs
  auditing/               # Auditing pipeline docs
  documentation/          # Documentation skills docs
temp/                     # Temporary/working files (gitignored)

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.