agentleFS
Sign inStart free
ai-enhanced-engineerai-enhanced-engineer/aiee-skills/skills/dev-standards/SKILL.md

dev-standards

Skill4 starsChanged 5 months agoMITView on GitHub

Development standards for Python projects including code style, git conventions, testing patterns, timing measurement, and validation requirements. Use when writing code, reviewing PRs, or making commits. Loaded by all implementation agents.

4 other projects use a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

4 rules. About 0 are common, 4 are distinctive, and 0 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈4

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 0

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Prefer editing: - Always edit existing files over creating new ones

    line 17
  2. Distinctive:

    No unnecessary files: - Never proactively create documentation unless explicitly requested

    line 18
  3. Distinctive:

    Test modifications immediately: - Don't accumulate changes

    line 45
  4. Distinctive:

    Domain logic stays pure: - No framework dependencies in domain model

    line 47

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill 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
SKILL.md

Development Standards

Core behavioral rules for code generation and project maintenance.

Core Rules

  1. Do what's asked - Nothing more, nothing less
  2. Prefer editing - Always edit existing files over creating new ones
  3. No unnecessary files - Never proactively create documentation unless explicitly requested
  4. No backwards compatibility assumptions - Unless specifically instructed

Decision Priority Order

PriorityFocusQuestion
1Business requirementsWhat problem are we solving?
2Domain model integrityDoes this preserve our invariants?
3Existing patternsConsistency over perfection
4Project conventionsCheck project's CLAUDE.md
5Team standardsAs documented in configs/docs
6Industry best practicesOnly if no project precedent

Before Making Changes

  • Searched for existing implementations?
  • Will this break existing functionality?
  • Following the project's patterns?
  • Checked the test suite?
  • Is this the minimal change needed?
  • Ticket claims validated? File paths, line numbers, method signatures may be stale before implementation starts.
  • Git history checked? git log --all --oneline --follow -- <file> — current code shows one era; history reveals all.

Critical Reminders

  1. Assuming a dependency exists causes ModuleNotFoundError at runtime — check pyproject.toml first
  2. Test modifications immediately - Don't accumulate changes
  3. Read existing code patterns first - Match the project's style
  4. Domain logic stays pure - No framework dependencies in domain model
  5. Restore mocks properly — jest.restoreAllMocks() in afterEach; clearAllMocks does not restore implementations.

Before Any Commit (Non-negotiable)

Run make validate-branch (or just validate-branch) before every commit and push — running it only at PR time lets format/lint errors slip through to CI. Do not add claude signatures to commits; do not commit until confirmed by user.

Quality & Process Gates

GateWhen
Pre-Implementation ValidationBefore 50+ file refactors — grep all file types, Dockerfiles, CI configs
Observable Removal ScopeRemoving a log field, metric, counter, or status code — grep non-code consumers too: runbooks, dashboards, alert configs
Cross-Service Integration ReadinessBefore first cross-service communication in any tier
Backend Logging Before Integration TestingReplace print() with named loggers before cross-service testing
Code Review Before RefactoringInvoke specialist agents before refactoring code-smell modules
Error Handling in HTTP Responsestype(e).__name__ reveals internal module structure — log internally, return generic
Multi-Cycle Gated ReviewShip incrementally with user approval gates (Cycle 1 → 2 → 3+)
CI Hygiene.gitignore htmlcov/, pin mypy + type stubs, git status before staging on macOS

See reference.md for each gate's checklist, anti-patterns, and examples.

Git Discipline

PatternRule
PR BranchingBranch new PRs off main; stacked PRs orphan on squash-merge
Intermixed EditsFeature branch + git add <specific files>; avoid git add -p across >3 files
Staging SafetyCheck size before git add -f on gitignored files
Protected ReposBranch + PR by default; bypass is for emergencies, not workflow
Pre-Commit Hook TrapAuto-stash leaves untracked files in place; bundle test-infra with tests

See reference.md for: git guidelines, test naming, timing measurement, quality gate placement, feedback severity classification, code review cycles, review-panel blind spots, lint discipline, coverage thresholds, static-site test-enforcement skip, verify-by-callers reflex, pre-commit-vs-Husky, orchestrator ship procedure, documentation review, skill maintenance gates, and skill authoring standards.

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