Help us improve
Share bugs, ideas, or general feedback.
From ennam-conventions
Organization-wide conventions for commit messages, branch naming, PR descriptions, and task communication. Loaded automatically by all Ennam plugins.
npx claudepluginhub en-nam/ennam-claude-agent-team --plugin ennam-conventionsHow this skill is triggered — by the user, by Claude, or both
Slash command
/ennam-conventions:org-conventionsThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
These conventions apply to every agent on every Ennam team, regardless of tech stack
Enforces commit message formats, PR descriptions, and branch naming conventions to maintain a clean and traceable git history.
Provides Git workflow standards including branch naming, conventional commits, and PR guidelines. Use when creating branches, writing commits, or preparing PRs.
Applies Conventional Commits v1.0.0 standards for Git branch naming, worktree organization under .claude/worktrees/, and commit messages in GitHub/GitLab projects. Supports consistent history, SemVer releases, and changelog automation.
Share bugs, ideas, or general feedback.
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>