Organization-wide conventions for commit messages, branch naming, PR descriptions, and task communication. Loaded automatically by all Ennam plugins.
From ennam-conventionsnpx claudepluginhub en-nam/ennam-claude-agent-team --plugin ennam-conventionsThis skill uses the workspace's default tool permissions.
Guides Next.js Cache Components and Partial Prerendering (PPR) with cacheComponents enabled. Implements 'use cache', cacheLife(), cacheTag(), revalidateTag(), static/dynamic optimization, and cache debugging.
Migrates code, prompts, and API calls from Claude Sonnet 4.0/4.5 or Opus 4.1 to Opus 4.5, updating model strings on Anthropic, AWS, GCP, Azure platforms.
Analyzes BMad project state from catalog CSV, configs, artifacts, and query to recommend next skills or answer questions. Useful for help requests, 'what next', or starting BMad.
These conventions apply to every agent on every Ennam team, regardless of tech stack (NextJS, Python, Flutter, or any other). Follow them on every task without exception.
<domain>/<task-id>-<short-description>
Examples:
backend/task-001-user-auth-apifrontend/task-004-login-screentests/task-006-auth-unit-testsinfra/task-010-ci-pipelineRules:
git checkout -b <branch-name>
git status # Verify you are on the correct branch
Immediately confirm to the orchestrator:
Branch created: <branch-name>
Starting TASK-<ID>: <title>
Use conventional commits. Commit each logical chunk of work as it is completed. Do NOT batch all changes into a single commit at the end of a task.
<type>(<scope>): <description>
[optional body — explain the why, not the what]
Task: TASK-<ID>
| Type | When to use |
|---|---|
feat | A new feature or capability |
fix | A bug fix |
test | Adding or updating tests (no production code change) |
refactor | Code restructuring with no behavior change |
docs | Documentation changes only |
chore | Build process, tooling, dependency, or config changes |
The scope identifies the area of the codebase affected. Use whatever scope is
meaningful for your project (e.g., api, auth, ui, db, ci). Keep it
short and consistent within your team.
feat(auth): add JWT refresh token endpoint
Issues a short-lived access token and a long-lived refresh token.
Refresh tokens are stored hashed in the database.
Task: TASK-003
fix(db): correct nullable constraint on user email field
Email was required at the schema level but the migration left
the column nullable, causing silent insert failures.
Task: TASK-007
test(auth): add unit tests for token refresh service
Covers happy path, expired refresh token, and revoked token cases.
Task: TASK-009
chore(ci): add lint step to GitHub Actions workflow
Task: TASK-012
Every agent owns a specific set of directories. You may ONLY modify files within your assigned domain.
If you need to change a file outside your domain:
<file-path> because <reason>"This rule exists to prevent merge conflicts and to keep each agent's work reviewable in isolation. There are no exceptions.
Run ALL of the following before reporting a task done. The exact commands will vary by stack — use the equivalent for your project.
# 1. Verify only your domain files were changed
git diff --name-only main...HEAD
# 2. No uncommitted changes remain
git status
# 3. Type-check / compile (use the appropriate command for your stack)
# TypeScript: npx tsc --noEmit
# Python: mypy .
# Dart/Flutter: flutter analyze
# 4. Lint (use the appropriate linter for your stack)
# NextJS: npx next lint
# Python: ruff check .
# Flutter: flutter analyze
# 5. Relevant tests pass
# Run only the tests that cover your changed code
If any check fails, fix the issue and re-run all checks before reporting done.
When all self-checks pass, report to the orchestrator using this exact format:
DONE: TASK-<ID>
Branch: <branch-name>
Files changed:
- <path/to/file> (new)
- <path/to/other-file> (modified)
Summary: <1-3 sentences describing what was implemented and why>
Tests: <X passed / not applicable>
If you cannot proceed for any reason, report immediately — do not wait:
BLOCKED: TASK-<ID>
Reason: <specific thing that is missing or broken>
Need from: <orchestrator | specific teammate | external dependency>
Do NOT attempt to work around a blocker by modifying files outside your domain or by making assumptions that should be confirmed first.
If you encounter merge conflicts:
When opening a pull request, use this structure:
## Summary
- <bullet: what was added or changed>
- <bullet: why — the business or technical reason>
## Changes
- `<file-path>` — <one-line description>
- `<file-path>` — <one-line description>
## Test Plan
- [ ] <specific thing to verify manually or via automated test>
- [ ] <edge case to check>
Task: TASK-<ID>