n-shadloo

Authors Conventional Commits messages and pull-request content from real git changes, or carries out a complete stage-commit-push workflow when explicitly told to do it all. Supports four request-selected modes: write an exact commit command for already-staged changes; choose one coherent set of unstaged files and present staging plus commit commands; write a pull-request title and structured Markdown description from the branch diff; or, only on an unmistakable autonomous request, stage, commit, and push the work itself. Use whenever the user is about to commit, asks for a commit message or commit command, mentions writing/fixing/improving a commit, refers to staged changes, asks which files belong in a commit, asks for a pull-request title or description, or explicitly asks the agent to stage, commit, and push. Do not trigger for unrelated git work such as branching, rebasing, or resolving merge conflicts unless a commit or pull request is being written.

Backend security auditor with deep Django and Django REST Framework coverage layered on a general OWASP Top 10 (2025) and API Security Top 10 (2023) foundation. Use whenever backend code is being written or reviewed and security is in scope — including any time the work touches authentication, login, sessions, JWT, OAuth2/OIDC, social login, API keys or tokens, permissions or access control, user-supplied input, the ORM or raw SQL, file uploads, serializers or API endpoints, secrets or settings, payments, email or notifications, background tasks, caching, async/ASGI or WebSockets, signals or lifecycle hooks, migrations, or deployment configuration, even if the word "security" is never used. Runs in two modes: review-time (audit existing code and return prioritized, actionable findings with severity, location, and a concrete fix) and write-time (apply secure defaults and flag risky patterns while generating code). Django/DRF is the primary target; the general layer makes it useful for any backend stack.

Writes Conventional Commits messages from staged git changes. Reads the staged diff, infers what changed and why, chooses an accurate type and scope, and produces a properly structured commit — subject, body, and footer trailers — with correct breaking-change notation. Use whenever the user is about to commit, asks for a commit message, mentions writing/fixing/improving a commit, refers to their staged changes, or says things like "commit this", "what should this commit say", or "write a commit message". Also use before running git commit so the message follows the convention. Do not trigger for unrelated git work such as branching, rebasing, or resolving merge conflicts unless a commit message is being written.

Write and audit maximally performant Django and Django REST Framework code. Use whenever Django/DRF code is being written or reviewed and speed, query count, latency, memory, or scalability is in scope — including any time the work touches the ORM or querysets, select_related/prefetch_related, N+1 access, serializers or API endpoints, pagination or large result sets, caching, async/ASGI, database connections or pooling, background or offloaded work, indexing, bulk operations, hot loops, or profiling, even if the word "performance" is never used. Runs in two modes: review-time (measure existing code, prove the bottleneck with query counts and timings, then apply the correct fix) and write-time (apply performance defaults while generating code so it is fast the first time). Django/DRF is the primary target; the algorithmic and caching principles transfer to any backend. Defers all security judgment to secure-code-auditor and never trades security for speed.