---
name: c9n
description: CodePassion (C9N) engineering conventions — a single skill
  covering workflow, branching, commits, PRs, code review, Clean Code TS,
  ESLint, formatting, JSON:API, Go/No Go, and SemVer 2.0.0.
version: 1.0.0
tags: [c9n, codepassion, conventions]
homepage: https://github.com/codepassion-team/c9n
license: MIT
---
<!-- AUTO-GENERATED. Edit skills/c9n-*/SKILL.md, then: npm run build -->
# C9N — CodePassion Engineering Conventions (combined)


---

## Development Workflow

## Workflow
1. Pick up ticket. 2. Clarify requirements. 3. Analyze ("To Analyze").
4. Estimate. 5. "Ready for Dev". 6. "Dev in Progress" + draft PR.
7. Update status. 8. Write tests. 9. "Ready for Code Review".
10. Address feedback, merge. 11. "Ready to Deploy", tag vX.Y.Z.
12. Validate in Alpha. 13. "Ready for QA". 14. Pass → Done; fail → Reopened.



---

## Git Branching

## Format: `<type>/<description>`
Types: `feature/`|`feat/`, `bugfix/`|`fix/`, `hotfix/`, `release/`, `chore/`.
Rules: lowercase; hyphens only; no special chars; no consecutive or leading/
trailing separators; dots only in `release/`; include ticket ID; be specific;
no personal names; under 50 chars.
Reference: https://conventional-branch.github.io



---

## Commit Messages

## Format
`<type>[scope]: <description>` + optional body + optional footer.
Types/SemVer: `feat`→MINOR, `fix`/`perf`→PATCH, others→none.
Breaking: `feat!:` or `BREAKING CHANGE:` footer → MAJOR.
Rules: imperative; lowercase after colon; no trailing period; ≤50 char
subject; one scope; reference tickets in footer (`Closes #123`).
Reference: https://www.conventionalcommits.org



---

## Pull Requests

## Subject: `#[Ticket_ID] PR description`
Rules: ticket prefix; imperative mood; capitalize first word; no trailing
period; body covers what/why/changes/testing + `Closes #TICKET`; open as
draft until tests are written.



---

## Code Review

## Format: `<label> [decorations]: <subject>`
Labels: praise, nitpick, suggestion, issue, question, todo, chore.
Decorations: (non-blocking), (blocking), (if-minor).
Pair `issue` with `(blocking)` when must-fix. Use GitHub suggestion blocks.
Batch with "Start a review". Never approve your own PR.
Reference: https://conventionalcomments.org



---

## Clean Code Typescript

## Rules
Variables: meaningful names, named constants, default args.
Functions: ≤2 args (options object), one thing, one abstraction level.
Objects: `readonly`, type aliases.
Classes: composition over inheritance, access modifiers, SRP.
SOLID: SRP, Open/Closed, Liskov, Interface Segregation, Dependency Inversion.
Errors: subclass `Error`; never strings; never empty `catch`.
Tests: one concept per test; descriptive names; Arrange-Act-Assert.
Reference: https://github.com/labs42io/clean-code-typescript



---

## Typescript Eslint

## Required rules
no-explicit-any (err), explicit-function-return-type (warn),
no-unused-vars w/ ^_ (err), consistent-type-imports (err),
no-floating-promises (err), strict-boolean-expressions (warn),
naming-convention (err), no-non-null-assertion (err),
no-misused-promises (err), prefer-nullish-coalescing (warn).
tsconfig strict flags: strict, noUncheckedIndexedAccess, noImplicitOverride,
noPropertyAccessFromIndexSignature, forceConsistentCasingInFileNames,
verbatimModuleSyntax, exactOptionalPropertyTypes.
Reference: https://typescript-eslint.io



---

## Code Formatting

## Prettier
semi false; singleQuote true; trailingComma none; printWidth 100;
tabWidth 2; useTabs false; bracketSpacing true; arrowParens always;
endOfLine lf.
## EditorConfig
UTF-8, 2-space indent, LF, trim trailing whitespace (except *.md), final
newline.
## lint-staged
*.{ts,tsx}: prettier --write, eslint --fix.
*.{json,md,yaml}: prettier --write.
Rule: ESLint never enforces formatting; Prettier owns formatting.



---

## Jsonapi

## Top-level
data | errors | meta | links | included | jsonapi. Never mix data+errors.
## Resource
Every resource has type+id. Data in attributes; connections in
relationships; hyperlinks in links.
## Errors
status, title, detail, source.pointer.
## Rules
Plural type names; sparse fieldsets (?fields[articles]=title,body); meta
for non-standard info — no invented top-level members.
Reference: https://jsonapi.org



---

## Go No Go Release

## Gate
Every item must be Go; one No Go blocks the release.
Participants: Tech Lead (decision), Developer, QA, Product Owner.
Checklist: PRs merged + CI green + no critical/high bugs; acceptance
verified + regression + perf OK; release notes + migrations + rollback +
env config; PO approval + support briefed + release window agreed.
Outcomes: Go → tag vX.Y.Z, deploy, monitor; No Go → log blockers, no tag.



---

## Semver Deployment

## Format: vMAJOR.MINOR.PATCH (lowercase v always)
MAJOR=incompatible API change; MINOR=backwards-compatible feature;
PATCH=backwards-compatible fix/security/perf.
Pre-release: v1.5.0-alpha|beta|rc.1 (lower precedence).
Build meta: v1.5.0+20250401.sha.abc1234 (informational).
Alpha: tag from develop, `git tag -a vX.Y.Z -m "Release vX.Y.Z" && git push origin vX.Y.Z`.
Production: confirm Go → pull release branch → create release → CI deploys → monitor.
Reference: https://semver.org/spec/v2.0.0.html