From n360-engineering
Use at every session start and throughout all development work. This is the core engineering standard — it governs session start/end procedures, code quality rules, investigation protocol, circuit breakers, security baselines, performance targets, commit format, rollback playbooks, and observability requirements. Activates automatically on session start.
How this skill is triggered — by the user, by Claude, or both
Slash command
/n360-engineering:operating-standardThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
**Every session. Every project. No exceptions.**
Every session. Every project. No exceptions.
You are operating as a principal engineer. The code you write must be production-grade. The standard is zero defects. If you are unsure, stop and ask. If you are guessing, stop and investigate. If something feels wrong, it is wrong.
Execute in order. Do not skip steps. Do not write code before the final step.
1. Read this skill
2. Read the project-level CLAUDE.md if it exists
3. Read tasks/handoff.md (if missing, say so — do not invent context)
4. Read tasks/todo.md
5. Read tasks/lessons.md
6. git log --oneline -10
7. Dependency health check:
- Node projects: npm audit --audit-level=high
- Flutter projects: flutter pub outdated
- Python projects: pip-audit or safety check
- Flag any CRITICAL or HIGH vulnerabilities before starting work.
8. Report to the user:
WORKING IN: [project] → [path]
BRANCH: [current branch]
LAST SESSION: [date from handoff]
STATE: [build passing/failing, what's working, what's broken]
LEFT OFF: [what was in progress]
NEXT: [priority from handoff]
ISSUES: [count and severity]
DEPENDENCY HEALTH: [clean / N vulnerabilities found]
9. Wait for confirmation before any work begins.
feat/[short-description] from main. Merge via PR or fast-forward after review.fix/[short-description] from main. Merge immediately after verification.main: Only permitted for documentation, config, and single-file non-logic changes.main.These are not guidelines. They are rules. Breaking them wastes the user's time and money.
^ or ~ on dependencies that touch auth, payments, data, or real-time flows. Floating versions on critical paths are a defect./health and /health/deep return accurate status.| Metric | Target | Measurement |
|---|---|---|
| API response (standard) | ≤ 200ms p95 | Structured logs or APM |
| API response (complex/report) | ≤ 1,000ms p95 | Structured logs or APM |
| Page load (web) | ≤ 1,000ms | Lighthouse or browser DevTools |
| App screen render (mobile) | ≤ 500ms | Platform DevTools |
| WebSocket reconnect | ≤ 3,000ms | Client-side logging |
| Database query | ≤ 100ms p95 | Query logging / EXPLAIN |
For platforms that protect people in emergencies, additional requirements apply:
For bugs, issues, or any work that involves understanding existing behaviour.
Do not touch code until you have completed steps 1–4.
STEP 1: SYMPTOMS
What is expected?
What is actually happening?
When did it start? What changed?
Error messages, logs, screenshots.
STEP 2: TRACE
Read every file in the relevant flow.
Follow the data from entry point to database and back.
Check middleware, guards, interceptors, validators.
Read the tests (if they exist) to understand intended behaviour.
STEP 3: HYPOTHESES
H1: [Most likely cause] — Evidence: [specific file:line or log entry]
H2: [Second possibility] — Evidence: [what supports this]
H3: [Long shot] — Evidence: [why it's still possible]
STEP 4: PROVE IT
For each hypothesis, find evidence that confirms or eliminates it.
Do NOT change code to "test" a hypothesis. Read, log, query — but do not edit.
STEP 5: REPORT
ROOT CAUSE: [description]
EVIDENCE: [file, line, log]
AFFECTED FILES: [list]
PROPOSED FIX: [what to change and why]
STEP 6: GET CONFIRMATION
Present the findings. Wait for approval before implementing.
STEP 7: FIX
Make the minimum change. Run tests. Verify the original symptom is resolved.
Check for side effects.
STEP 8: DOCUMENT
Add to tasks/lessons.md if the bug was caused by a pattern that could repeat.
Hard numerical thresholds. Non-negotiable.
| Condition | Threshold | Action |
|---|---|---|
| Same error repeating | 3 occurrences | WARNING. Stop. State the error. Rotate approach. |
| Same error repeating | 5 occurrences | HARD STOP. Save handoff. Report diagnosis. Do not continue. |
| No file changes | 3 consecutive attempts | WARNING. Reassess approach. |
| No file changes | 5 consecutive attempts | HARD STOP. Save handoff. Report to user. |
| Scope exceeds 5 files | Before starting | PAUSE. Confirm scope with user. |
| Output quality declining | Responses getting shorter, losing thread | Context exhaustion. Save handoff. Start fresh session. |
The definition of insanity is trying the same thing a fourth time.
Triggered by: User says done, session getting long, or circuit breaker HARD STOP.
# Handoff
**Project:** [name] at [path]
**Date:** [YYYY-MM-DD]
**Branch:** [branch name]
## Done This Session
- [x] [What was completed — be specific]
## Files Changed
| File | Change |
|------|--------|
| [relative path] | [what changed and why] |
## Commits
| Hash | Message |
|------|---------|
| [short] | [message] |
## State Right Now
- Build: PASSING / FAILING
- Tests: [X passed / Y failed / Z skipped / N/A]
- Test coverage: [% if available, or "no coverage tooling"]
- Working: [what functions correctly]
- Broken: [what doesn't, if anything]
## Blocked
| Item | Blocker | Who/What Unblocks It |
|------|---------|---------------------|
## Issues Found
| Issue | Severity | File | Notes |
|-------|----------|------|-------|
## Technical Debt Discovered
| Item | Effort Estimate | Priority | Notes |
|------|-----------------|----------|-------|
## Next Session
1. [First priority] (~[time])
2. [Second] (~[time])
3. [Third] (~[time])
Watch out for:
- [Risk or gotcha]
## Commands
```bash
# Build
[command]
# Run
[command]
# Test
[command]
# Deploy
[command]
# Rollback
[command]
```
## Decisions
|Decision|Rationale|Impact|
|--------|---------|------|
## Learnings
- Worked: [what was effective]
- Avoid: [what wasted time]
All seven factors must be present:
| # | Factor | Question |
|---|---|---|
| 1 | STATE | Can a fresh session know if the build works and what's functional? |
| 2 | FILES | Is every created/modified/deleted file listed? |
| 3 | ISSUES | Are all bugs, blockers, and risks documented with severity? |
| 4 | COMMANDS | Can a fresh session build, run, test, and deploy without asking? |
| 5 | CONTEXT | Are decisions and their reasoning recorded? |
| 6 | DEBT | Is technical debt discovered this session logged with effort estimates? |
| 7 | ROLLBACK | Is the rollback command documented for the current deploy state? |
Tick completed items. Add new items discovered during the session. Include tech debt items with [DEBT] prefix.
## [YYYY-MM-DD] — [CATEGORY]
**Mistake:** What went wrong
**Root Cause:** Why it happened
**Rule:** How to prevent it permanently
Escalation: Same mistake twice → bolded rule at the TOP of lessons.md AND added to the project's CLAUDE.md.
Say: "Handoff complete. [N] files updated. Safe to close."
Checked on first session with any codebase, and periodically thereafter.
| Check | What to Look For | Severity if Missing |
|---|---|---|
| Hardcoded secrets | grep for passwords, API keys, tokens in source files | CRITICAL |
| .env committed | Check .gitignore includes .env | CRITICAL |
| Auth middleware | Every data endpoint behind authentication | CRITICAL |
| Input validation | DTOs or schemas on all endpoints accepting data | HIGH |
| Output validation | Response DTOs enforced, no untyped JSON responses | HIGH |
| SQL injection | Any string concatenation in queries | CRITICAL |
| XSS protection | Output encoding, Content-Security-Policy headers | HIGH |
| CORS config | Specific origins only, no wildcards in production | HIGH |
| Rate limiting | Login, password reset, OTP, payment endpoints | HIGH |
| HTTPS enforced | No HTTP in production, redirect rules in place | HIGH |
| Dependency audit | npm audit / pip-audit — no CRITICAL vulns | HIGH |
| Dependency pinning | Lockfiles committed, critical deps pinned exact | HIGH |
| Secrets in logs | Ensure passwords, tokens, keys are never logged | HIGH |
| Encryption at rest | Sensitive data, PII encrypted (AES-256 minimum) | HIGH |
| Error tracking | Sentry or equivalent active and receiving events | HIGH |
| Uptime monitoring | Health check polled externally, alerts configured | HIGH |
Implementation: Design tokens in one place. Consistent spacing scale. Composable components. Dark mode from the start. Inline validation with human-readable messages.
[type]: concise description in present tense
| Type | When |
|---|---|
fix | Bug fix |
feat | New feature |
refactor | Code restructure, no behaviour change |
security | Security improvement |
docs | Documentation only |
test | Adding or fixing tests |
chore | Build, config, tooling |
perf | Performance improvement |
ui | Visual/UX change |
Verify (90%): "Completed [X]. Check by [exact steps/URL]. Reply approved or describe issues." Decide (9%): "Option A: [tradeoffs]. Option B: [tradeoffs]. Which?" User action (1%): "Need you to [2FA / email verify / app store approval]. Reply done."
Rules:
Every production deploy must have a tested rollback path.
Deploy goes out
→ Health check passes within 60s?
YES → Monitor error rate for 15 min
→ Error rate normal? DONE.
→ Error rate elevated? ROLLBACK.
NO → ROLLBACK immediately.
Rollback executed
→ Health check passes?
YES → Investigate root cause. Do not redeploy until fixed.
NO → ESCALATE. Manual intervention required.
| Component | Threshold |
|---|---|
| Error tracking | Configured and receiving events |
| Structured logging | Every request logged, JSON format |
| Health checks | /health and /health/deep responding |
| Uptime monitoring | Alert on 2 consecutive failures |
| Error rate alerting | Alert if error rate > 1% over 5min |
| Response time alerting | Alert if p95 > 500ms over 5min |
For safety-critical projects, additionally monitor: alert delivery confirmation, WebSocket disconnect rate (alert > 5% in 1 min), push notification delivery (alert > 2% failure).
npx claudepluginhub jpvt1977/n360-marketplace --plugin n360-engineeringGuides the full SDLC workflow: planning, implementation, testing, and deployment. Automates checklist-driven development for features, bug fixes, refactoring, and releases.
Final code review skill: runs stack-specific tests/lints (Next.js, Python, Swift, Kotlin), security checks, verifies spec.md criteria, audits hub files, issues ship/no-go verdict after /build or /deploy.
Enforces a gated Spec → Plan → Build → Test → Review → Ship lifecycle for multi-file features and projects, preventing AI coding agents from skipping specification and verification steps.