Menu
Django coding rules. Always use when planning, writing, or reviewing changes in Django codebases.
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional SOC
Cache and refresh remote git repositories under ~/.cache/checkouts/<host>/<org>/<repo> so future references can reuse a local copy. Use this skill when the user points you to a remote git repository as reference or you encountered a remote git repo through other means.
Test-driven development with red-green-refactor loop. Use when user wants to build features or fix bugs using TDD, mentions "red-green-refactor", wants integration tests, or asks for test-first development.
Python coding rules. Always use when working with Python, including editing, reviewing, or writing Python code, imports, code style, dependency injection, Pydantic, or Pytest.
Create new agent skills with proper structure, progressive disclosure, and bundled resources. Use when user wants to create, write, or build a new skill.
Build a throwaway prototype to flesh out a design before committing to it. Routes between two branches — a runnable terminal app for state/business-logic questions, or several radically different UI variations toggleable from one route. Use when the user wants to prototype, sanity-check a data model or state machine, mock up a UI, explore design options, or says "prototype this", "let me play with it", "try a few designs".
Graph-based issue tracker for task coordination. Use when the project tracks work with beans — creating, querying, claiming, and closing tasks via CLI.
| name | django |
| description | Django coding rules. Always use when planning, writing, or reviewing changes in Django codebases. |
Do not write Django migrations manually (e.g. using the Write tool). Always use Django's CLI to generate migrations instead.
Never make database operations (obj.save, Model.objects.whatever, etc.) inside loops.
Don't create constants to use in model_to_dict fields, unless same fields are used multiple times.
Good:
payload = model_to_dict(user, fields=["id", "email", "first_name"])
Bad:
USER_FIELDS = ["id", "email", "first_name"]
payload = model_to_dict(user, fields=USER_FIELDS)
Good when reused:
USER_FIELDS = ["id", "email", "first_name"]
payload = model_to_dict(user, fields=USER_FIELDS)
audit_payload = model_to_dict(other_user, fields=USER_FIELDS)