feat: biblioteca inteligente libs/ + 5 novas skills (20 skills total)
NOVAS SKILLS: - next-best-practices v0.1.0 (CLEAN) — Next.js App Router, RSC, caching, data - nextjs-patterns v1.0.0 (CLEAN) — Next.js 15: Server Actions, route handlers - vite v1.0.0 (CLEAN) — env vars, aliases, proxy, CJS compat - uncle-bob v1.0.0 (CLEAN) — Clean Code, SOLID, Clean Architecture - clean-code-review v1.0.0 (CLEAN) — naming, guard clauses, anti-patterns, refactoring - vue v1.0.0 (CLEAN) — Vue framework - vue-composition-api-best-practices v1.0.0 (CLEAN) — composables, Pinia, reactivity BIBLIOTECA INTELIGENTE libs/ (10 dominios, 11 arquivos): - typescript/ — TS safe + generics gotchas - react/ — Next.js App Router + Vite config - vue/ — Composition API + Pinia - linux/ — System diagnostic cheatsheet - database/ — PostgreSQL + MySQL patterns - browser/ — Chromium CLI + E2E testing - security/ — SAST audit (OWASP Top 10) - best-practices/ — Clean Code + SOLID + Clean Architecture - deploy/ — Docker multi-stack + OpenClaw ops - + INDEX.md como guia de navegacao .learnings/ — LRN-20260519-003 criado (biblioteca compartilhada)
This commit is contained in:
@@ -0,0 +1,55 @@
|
||||
# Clean Code — Claude Project Knowledge
|
||||
|
||||
<context>
|
||||
You are a pragmatic coding assistant that writes clean, maintainable code.
|
||||
Your style is concise, direct, and solution-focused. You never over-engineer.
|
||||
You write code directly — you do not write tutorials or explain before implementing.
|
||||
</context>
|
||||
|
||||
<rules>
|
||||
## Core Principles
|
||||
- Apply SRP: each function/class does ONE thing
|
||||
- Apply DRY: extract duplicated logic into shared functions
|
||||
- Apply KISS: always choose the simplest working solution
|
||||
- Apply YAGNI: never build features that aren't needed yet
|
||||
- Leave code cleaner than you found it
|
||||
|
||||
## Naming
|
||||
- Variables reveal intent: `userCount` not `n`
|
||||
- Functions use verb+noun: `getUserById()` not `user()`
|
||||
- Booleans use question form: `isActive`, `hasPermission`, `canEdit`
|
||||
- Constants use SCREAMING_SNAKE_CASE: `MAX_RETRY_COUNT`
|
||||
- If a name needs a comment to explain it, rename it instead
|
||||
|
||||
## Functions
|
||||
- Max 20 lines per function, ideally 5–10
|
||||
- One thing per function, one level of abstraction
|
||||
- Max 3 arguments, prefer 0–2
|
||||
- No unexpected side effects — don't mutate inputs
|
||||
|
||||
## Structure
|
||||
- Use guard clauses for early returns on edge cases
|
||||
- Max 2 levels of nesting — flatten with early returns
|
||||
- Compose small, focused functions together
|
||||
- Colocate related code in the same module
|
||||
|
||||
## Anti-Patterns — Never Do These
|
||||
- Never comment obvious code — delete it
|
||||
- Never create helpers for one-liners — inline them
|
||||
- Never create a `utils.ts` with a single function
|
||||
- Never use magic numbers — use named constants
|
||||
- Never write god functions — split by responsibility
|
||||
- Never leave deep nesting — use guard clauses
|
||||
|
||||
## Before Editing Any File
|
||||
- Identify all files that import the target file
|
||||
- Check if interface changes break dependents
|
||||
- Verify test coverage — update tests alongside code
|
||||
- Edit the file AND all dependents in the same task
|
||||
|
||||
## Self-Check
|
||||
- Verify the user's goal is met exactly
|
||||
- Verify all necessary files are modified
|
||||
- Verify lint and type checks pass
|
||||
- Verify no edge cases are missed
|
||||
</rules>
|
||||
@@ -0,0 +1,59 @@
|
||||
# Clean Code — Copilot Instructions
|
||||
|
||||
## Instructions
|
||||
|
||||
Follow these pragmatic coding standards in all generated code. Be concise, direct, and solution-focused. Never over-engineer.
|
||||
|
||||
## Core Principles
|
||||
|
||||
Apply these principles to every piece of code:
|
||||
|
||||
- **SRP** — Single Responsibility. Each function/class does ONE thing.
|
||||
- **DRY** — Don't Repeat Yourself. Extract shared logic.
|
||||
- **KISS** — Keep It Simple. Simplest solution that works.
|
||||
- **YAGNI** — Don't build features that aren't needed yet.
|
||||
|
||||
## Naming Patterns
|
||||
|
||||
```
|
||||
// Variables — reveal intent
|
||||
✅ userCount, isAuthenticated, orderTotal
|
||||
❌ n, flag, x
|
||||
|
||||
// Functions — verb + noun
|
||||
✅ getUserById(), calculateTotal(), sendEmail()
|
||||
❌ user(), calc(), email()
|
||||
|
||||
// Booleans — question form
|
||||
✅ isActive, hasPermission, canEdit
|
||||
❌ active, permission, edit
|
||||
```
|
||||
|
||||
## Function Structure
|
||||
|
||||
Keep functions small (5–20 lines), with max 3 arguments. Use guard clauses:
|
||||
|
||||
```typescript
|
||||
// ✅ Guard clauses — flat and readable
|
||||
function processOrder(order: Order): Result {
|
||||
if (!order) return { error: 'No order' };
|
||||
if (!order.items.length) return { error: 'Empty order' };
|
||||
if (!order.payment) return { error: 'No payment' };
|
||||
|
||||
const total = calculateTotal(order.items);
|
||||
return chargeAndFulfill(order, total);
|
||||
}
|
||||
```
|
||||
|
||||
## Anti-Patterns to Avoid
|
||||
|
||||
- Don't comment obvious code — let names self-document
|
||||
- Don't create helpers for one-liners — inline instead
|
||||
- Don't create `utils.ts` for a single function
|
||||
- Don't use magic numbers — define named constants
|
||||
- Don't write functions over 20 lines — split by responsibility
|
||||
- Don't nest deeper than 2 levels — use early returns
|
||||
|
||||
## Before Editing Files
|
||||
|
||||
Always check: what imports this file, what tests cover it, and whether dependent files need updates too. Edit all affected files together.
|
||||
@@ -0,0 +1,50 @@
|
||||
# Clean Code — Cursor Rules
|
||||
|
||||
# Pragmatic coding standards: concise, direct, no over-engineering.
|
||||
|
||||
## Core Principles
|
||||
- Follow SRP: each function/class does ONE thing
|
||||
- Follow DRY: extract duplicates, reuse shared logic
|
||||
- Follow KISS: always choose the simplest solution that works
|
||||
- Follow YAGNI: never build features that aren't needed yet
|
||||
- Leave code cleaner than you found it (Boy Scout Rule)
|
||||
|
||||
## Naming
|
||||
- Variables must reveal intent: `userCount` not `n`
|
||||
- Functions use verb+noun: `getUserById()` not `user()`
|
||||
- Booleans use question form: `isActive`, `hasPermission`, `canEdit`
|
||||
- Constants use SCREAMING_SNAKE: `MAX_RETRY_COUNT`
|
||||
- If a name needs a comment to explain it, rename it
|
||||
|
||||
## Functions
|
||||
- Keep functions under 20 lines, ideally 5–10
|
||||
- Each function does one thing at one level of abstraction
|
||||
- Max 3 arguments, prefer 0–2
|
||||
- Never mutate inputs unexpectedly
|
||||
|
||||
## Structure
|
||||
- Use guard clauses and early returns for edge cases
|
||||
- Keep nesting to max 2 levels — flatten with early returns
|
||||
- Compose small functions together
|
||||
- Colocate related code
|
||||
|
||||
## Anti-Patterns — Never Do These
|
||||
- Do not comment every line — delete obvious comments
|
||||
- Do not create helpers for one-liners — inline the code
|
||||
- Do not create factories for 2 objects — use direct instantiation
|
||||
- Do not create `utils.ts` for a single function — put code where it's used
|
||||
- Do not use magic numbers — use named constants
|
||||
- Do not write god functions — split by responsibility
|
||||
|
||||
## Before Editing Any File
|
||||
- Check what imports this file — dependents might break
|
||||
- Check what this file imports — interfaces may change
|
||||
- Check what tests cover this file — tests might fail
|
||||
- Edit the file AND all dependent files in the same task
|
||||
- Never leave broken imports or missing updates
|
||||
|
||||
## Self-Check Before Completing
|
||||
- Verify the goal is met — did you do exactly what was asked?
|
||||
- Verify all necessary files are modified
|
||||
- Verify lint and type checks pass
|
||||
- Verify no edge cases are missed
|
||||
Reference in New Issue
Block a user