[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M77PFD5V1JVSCJTC5KBGA8K3":3,"skill-same:01M77PFD5V1JVSCJTC5KBGA8K3":45},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":19,"linkOnly":20,"markdownContent":21,"markdownBody":22,"frontMatter":23,"refName":24,"commitSha":25,"skillDirectory":26,"forksCount":14,"repositoryHtmlUrl":27,"repositoryHomepageUrl":6,"ownerHtmlUrl":28,"ownerBlogUrl":6,"ownerDescription":29,"updatedAt":30,"install":31,"resources":44},"01M77PFD5V1JVSCJTC5KBGA8K3","security-and-hardening",null,"Hardens code against vulnerabilities. Use when handling user input, authentication, data storage, or external integrations. Use when building any feature that accepts untrusted data, manages user sessions, or interacts with third-party services.","ziyad455\u002Fsophia","ziyad455","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F182938716?v=4","01M77PD51CNRHPXKBGHFNHRNSH","Ziyad Tber","01M77PD522JQ9SM0TM19PPPTYV",0,"MIT","https:\u002F\u002Fgithub.com\u002Fziyad455\u002Fsophia\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fsecurity-and-hardening\u002FSKILL.md",[],[],"2026-11-15 14:19:17",false,"---\nname: security-and-hardening\ndescription: Hardens code against vulnerabilities. Use when handling user input, authentication, data storage, or external integrations. Use when building any feature that accepts untrusted data, manages user sessions, or interacts with third-party services.\n---\n\n# Security and Hardening\n\n## Overview\n\nSecurity-first development practices for web applications. Treat every external input as hostile, every secret as sacred, and every authorization check as mandatory. Security isn't a phase — it's a constraint on every line of code that touches user data, authentication, or external systems.\n\n## When to Use\n\n- Building anything that accepts user input\n- Implementing authentication or authorization\n- Storing or transmitting sensitive data\n- Integrating with external APIs or services\n- Adding file uploads, webhooks, or callbacks\n- Handling payment or PII data\n\n## Process: Threat Model First\n\nControls bolted on without a threat model are guesses. Before hardening, spend five minutes thinking like an attacker:\n\n1. **Map the trust boundaries.** Where does untrusted data cross into your system? HTTP requests, form fields, file uploads, webhooks, third-party APIs, message queues, and **LLM output**. Every boundary is attack surface.\n2. **Name the assets.** What's worth stealing or breaking? Credentials, PII, payment data, admin actions, money movement.\n3. **Run STRIDE over each boundary** — a quick lens, not a ceremony:\n\n| Threat | Ask | Typical mitigation |\n|---|---|---|\n| **S**poofing | Can someone impersonate a user\u002Fservice? | Authentication, signature verification |\n| **T**ampering | Can data be altered in transit or at rest? | Integrity checks, parameterized queries, HTTPS |\n| **R**epudiation | Can an action be denied later? | Audit logging of security events |\n| **I**nformation disclosure | Can data leak? | Encryption, field allowlists, generic errors |\n| **D**enial of service | Can it be overwhelmed? | Rate limiting, input size caps, timeouts |\n| **E**levation of privilege | Can a user gain rights they shouldn't? | Authorization checks, least privilege |\n\n4. **Write abuse cases next to use cases.** For each feature, ask \"how would I misuse this?\" — then make that your first test.\n\nIf you can't name the trust boundaries for a feature, you're not ready to secure it. This is OWASP **A04: Insecure Design** — most breaches begin in design, not code.\n\n## The Three-Tier Boundary System\n\n### Always Do (No Exceptions)\n\n- **Validate all external input** at the system boundary (API routes, form handlers)\n- **Parameterize all database queries** — never concatenate user input into SQL\n- **Encode output** to prevent XSS (use framework auto-escaping, don't bypass it)\n- **Use HTTPS** for all external communication\n- **Hash passwords** with bcrypt\u002Fscrypt\u002Fargon2 (never store plaintext)\n- **Set security headers** (CSP, HSTS, X-Frame-Options, X-Content-Type-Options)\n- **Use httpOnly, secure, sameSite cookies** for sessions\n- **Run the detected package manager's native audit** against the committed lockfile before every release\n\n### Ask First (Requires Human Approval)\n\n- Adding new authentication flows or changing auth logic\n- Storing new categories of sensitive data (PII, payment info)\n- Adding new external service integrations\n- Changing CORS configuration\n- Adding file upload handlers\n- Modifying rate limiting or throttling\n- Granting elevated permissions or roles\n\n### Never Do\n\n- **Never commit secrets** to version control (API keys, passwords, tokens)\n- **Never log sensitive data** (passwords, tokens, full credit card numbers)\n- **Never trust client-side validation** as a security boundary\n- **Never disable security headers** for convenience\n- **Never use `eval()` or `innerHTML`** with user-provided data\n- **Never store sessions in client-accessible storage** (localStorage for auth tokens)\n- **Never expose stack traces** or internal error details to users\n\n## OWASP Top 10 Prevention Patterns\n\nThese are prevention patterns, not a ranking. For the 2021 ordering, see the quick-reference table in `references\u002Fsecurity-checklist.md`.\n\n### Injection (SQL, NoSQL, OS Command)\n\n```typescript\n\u002F\u002F BAD: SQL injection via string concatenation\nconst query = `SELECT * FROM users WHERE id = '${userId}'`;\n\n\u002F\u002F GOOD: Parameterized query\nconst user = await db.query('SELECT * FROM users WHERE id = $1', [userId]);\n\n\u002F\u002F GOOD: ORM with parameterized input\nconst user = await prisma.user.findUnique({ where: { id: userId } });\n```\n\n### Broken Authentication\n\n```typescript\n\u002F\u002F Password hashing\nimport { hash, compare } from 'bcrypt';\n\nconst SALT_ROUNDS = 12;\nconst hashedPassword = await hash(plaintext, SALT_ROUNDS);\nconst isValid = await compare(plaintext, hashedPassword);\n\n\u002F\u002F Session management\napp.use(session({\n  secret: process.env.SESSION_SECRET,  \u002F\u002F From environment, not code\n  resave: false,\n  saveUninitialized: false,\n  cookie: {\n    httpOnly: true,     \u002F\u002F Not accessible via JavaScript\n    secure: true,       \u002F\u002F HTTPS only\n    sameSite: 'lax',    \u002F\u002F CSRF protection\n    maxAge: 24 * 60 * 60 * 1000,  \u002F\u002F 24 hours\n  },\n}));\n```\n\n### Cross-Site Scripting (XSS)\n\n```typescript\n\u002F\u002F BAD: Rendering user input as HTML\nelement.innerHTML = userInput;\n\n\u002F\u002F GOOD: Use framework auto-escaping (React does this by default)\nreturn \u003Cdiv>{userInput}\u003C\u002Fdiv>;\n\n\u002F\u002F If you MUST render HTML, sanitize first\nimport DOMPurify from 'dompurify';\nconst clean = DOMPurify.sanitize(userInput);\n```\n\n### Broken Access Control\n\n```typescript\n\u002F\u002F Always check authorization, not just authentication\napp.patch('\u002Fapi\u002Ftasks\u002F:id', authenticate, async (req, res) => {\n  const task = await taskService.findById(req.params.id);\n\n  \u002F\u002F Check that the authenticated user owns this resource\n  if (task.ownerId !== req.user.id) {\n    return res.status(403).json({\n      error: { code: 'FORBIDDEN', message: 'Not authorized to modify this task' }\n    });\n  }\n\n  \u002F\u002F Proceed with update\n  const updated = await taskService.update(req.params.id, req.body);\n  return res.json(updated);\n});\n```\n\n### Security Misconfiguration\n\n```typescript\n\u002F\u002F Security headers (use helmet for Express)\nimport helmet from 'helmet';\napp.use(helmet());\n\n\u002F\u002F Content Security Policy\napp.use(helmet.contentSecurityPolicy({\n  directives: {\n    defaultSrc: [\"'self'\"],\n    scriptSrc: [\"'self'\"],\n    styleSrc: [\"'self'\", \"'unsafe-inline'\"],  \u002F\u002F Tighten if possible\n    imgSrc: [\"'self'\", 'data:', 'https:'],\n    connectSrc: [\"'self'\"],\n  },\n}));\n\n\u002F\u002F CORS — restrict to known origins\napp.use(cors({\n  origin: process.env.ALLOWED_ORIGINS?.split(',') || 'http:\u002F\u002Flocalhost:3000',\n  credentials: true,\n}));\n```\n\n### Sensitive Data Exposure\n\n```typescript\n\u002F\u002F Never return sensitive fields in API responses\nfunction sanitizeUser(user: UserRecord): PublicUser {\n  const { passwordHash, resetToken, ...publicFields } = user;\n  return publicFields;\n}\n\n\u002F\u002F Use environment variables for secrets\nconst API_KEY = process.env.STRIPE_API_KEY;\nif (!API_KEY) throw new Error('STRIPE_API_KEY not configured');\n```\n\n### Server-Side Request Forgery (SSRF)\n\nAny time the server fetches a URL the user influenced — webhooks, \"import from URL\", image proxies, link previews — an attacker can aim it at internal services (cloud metadata, `localhost`, private IPs).\n\n```typescript\n\u002F\u002F BAD: fetch whatever the user gives you\nawait fetch(req.body.webhookUrl);\n\n\u002F\u002F GOOD: allowlist scheme + host, reject if ANY resolved IP is private, forbid redirects\nimport { lookup } from 'node:dns\u002Fpromises';\nimport ipaddr from 'ipaddr.js';\n\nconst ALLOWED_HOSTS = new Set(['hooks.example.com']);\n\nasync function assertSafeUrl(raw: string): Promise\u003CURL> {\n  const url = new URL(raw);\n  if (url.protocol !== 'https:') throw new Error('https only');\n  if (!ALLOWED_HOSTS.has(url.hostname)) throw new Error('host not allowed');\n  \u002F\u002F Resolve ALL records; a single private\u002Freserved address fails the check.\n  const addrs = await lookup(url.hostname, { all: true });\n  if (addrs.some((a) => ipaddr.parse(a.address).range() !== 'unicast')) {\n    throw new Error('private\u002Freserved IP');\n  }\n  return url;\n}\n\nawait fetch(await assertSafeUrl(req.body.webhookUrl), { redirect: 'error' });\n```\n\nThe `range() !== 'unicast'` check covers loopback, link-local `169.254.169.254` (cloud metadata, the #1 SSRF target), private, and unique-local ranges across IPv4 and IPv6.\n\n**Caveat — this still has a TOCTOU gap.** `fetch` resolves DNS again after the check, so an attacker using a short-TTL record can rebind to an internal IP between validation and connection. For high-risk surfaces, resolve once and connect to the pinned IP, or put a filtering agent in front (`request-filtering-agent` \u002F `ssrf-req-filter`).\n\n## Input Validation Patterns\n\n### Schema Validation at Boundaries\n\n```typescript\nimport { z } from 'zod';\n\nconst CreateTaskSchema = z.object({\n  title: z.string().min(1).max(200).trim(),\n  description: z.string().max(2000).optional(),\n  priority: z.enum(['low', 'medium', 'high']).default('medium'),\n  dueDate: z.string().datetime().optional(),\n});\n\n\u002F\u002F Validate at the route handler\napp.post('\u002Fapi\u002Ftasks', async (req, res) => {\n  const result = CreateTaskSchema.safeParse(req.body);\n  if (!result.success) {\n    return res.status(422).json({\n      error: {\n        code: 'VALIDATION_ERROR',\n        message: 'Invalid input',\n        details: result.error.flatten(),\n      },\n    });\n  }\n  \u002F\u002F result.data is now typed and validated\n  const task = await taskService.create(result.data);\n  return res.status(201).json(task);\n});\n```\n\n### File Upload Safety\n\n```typescript\n\u002F\u002F Restrict file types and sizes\nconst ALLOWED_TYPES = ['image\u002Fjpeg', 'image\u002Fpng', 'image\u002Fwebp'];\nconst MAX_SIZE = 5 * 1024 * 1024; \u002F\u002F 5MB\n\nfunction validateUpload(file: UploadedFile) {\n  if (!ALLOWED_TYPES.includes(file.mimetype)) {\n    throw new ValidationError('File type not allowed');\n  }\n  if (file.size > MAX_SIZE) {\n    throw new ValidationError('File too large (max 5MB)');\n  }\n  \u002F\u002F Don't trust the file extension — check magic bytes if critical\n}\n```\n\n## Triaging Dependency Audit Results\n\nPackage-manager audits report known advisories; they do not prove a package is trustworthy or that vulnerable code is reachable. Use this decision tree:\n\n```\nThe native package-manager audit reports a vulnerability\n├── Severity: critical or high\n│   ├── Is the vulnerable code reachable in runtime, build, test, or deployment paths?\n│   │   ├── YES --> Fix immediately (update, patch, or replace the dependency)\n│   │   └── NO (confirmed unused across those paths) --> Fix soon, but not a blocker\n│   └── Is a fix available?\n│       ├── YES --> Update to the patched version\n│       └── NO --> Check for workarounds, consider replacing the dependency, or add to allowlist with a review date\n├── Severity: moderate\n│   ├── Reachable in production? --> Fix in the next release cycle\n│   └── Dev-only? --> Fix when convenient, track in backlog\n└── Severity: low\n    └── Track and fix during regular dependency updates\n```\n\n**Key questions:**\n- Is the vulnerable function actually called in your code path?\n- Is the dependency a runtime dependency or dev-only?\n- Is the vulnerability exploitable given your deployment context (e.g., a server-side vulnerability in a client-only app)?\n\nWhen you defer a fix, document the reason and set a review date.\n\n### Supply-Chain Hygiene\n\nDo not assume npm or treat the nearest manifest as the install root. Apply this order:\n\n1. **Find the installation boundary and manager.** Use the workspace root that owns the lockfile, or an independent nested project only when it is outside that workspace. There, corroborate `packageManager` (when present), the lockfile, and CI; stop on disagreement or competing lockfiles. Pin the manager version and use the matrix in `references\u002Fsecurity-checklist.md`.\n2. **Block dependency scripts before first execution.** Bootstrap with scripts disabled or a documented fail-closed policy, inspect the pending script source, approve only the minimum required packages, commit the policy, then verify with a clean frozen\u002Fimmutable install. Never blanket-approve scripts.\n\nAudits only find known advisories; they do not catch a newly malicious or typosquatted package. Therefore:\n\n- **Never apply forced audit remediation automatically** (`npm audit fix --force` or equivalent). Preview the remediation, read changelogs, and test each resulting upgrade; forced fixes may cross declared dependency ranges.\n- **Verify registry signatures and provenance where supported** (`npm audit signatures`, `pnpm audit signatures`) and treat absence as a signal to investigate, not automatic proof of compromise.\n- **Review new dependencies, lockfile diffs, and script-policy changes together** — ownership, maintenance, release age, provenance, transitive graph, and typosquats such as `cross-env` vs `crossenv` (OWASP **A06**, **LLM03**).\n\n## Rate Limiting\n\n```typescript\nimport rateLimit from 'express-rate-limit';\n\n\u002F\u002F General API rate limit\napp.use('\u002Fapi\u002F', rateLimit({\n  windowMs: 15 * 60 * 1000, \u002F\u002F 15 minutes\n  max: 100,                   \u002F\u002F 100 requests per window\n  standardHeaders: true,\n  legacyHeaders: false,\n}));\n\n\u002F\u002F Stricter limit for auth endpoints\napp.use('\u002Fapi\u002Fauth\u002F', rateLimit({\n  windowMs: 15 * 60 * 1000,\n  max: 10,  \u002F\u002F 10 attempts per 15 minutes\n}));\n```\n\n## Secrets Management\n\n```\n.env files:\n  ├── .env.example  → Committed (template with placeholder values)\n  ├── .env          → NOT committed (contains real secrets)\n  └── .env.local    → NOT committed (local overrides)\n\n.gitignore must include:\n  .env\n  .env.local\n  .env.*.local\n  *.pem\n  *.key\n```\n\n**Always check before committing:**\n```bash\n# Check for accidentally staged secrets\ngit diff --cached | grep -i \"password\\|secret\\|api_key\\|token\"\n```\n\n**If a secret is ever committed, rotate it.** Deleting the line or rewriting history is not enough — assume it's compromised the moment it reaches a remote. Revoke and reissue the key first, then purge it from history.\n\n## Securing AI \u002F LLM Features\n\nIf your app calls an LLM — chatbots, summarizers, agents, RAG — it inherits a new attack surface. Map it to the [OWASP Top 10 for LLM Applications (2025)](https:\u002F\u002Fgenai.owasp.org\u002Fllm-top-10\u002F):\n\n- **Treat all model output as untrusted input (LLM05: Improper Output Handling).** Never pass LLM output straight into `eval`, SQL, a shell, `innerHTML`, or a file path. Validate and encode it exactly as you would raw user input.\n- **Assume prompts can be hijacked (LLM01: Prompt Injection).** Untrusted text in the context window — a user message, a fetched web page, a PDF — can carry instructions. The system prompt is not a security boundary; enforce permissions in code, not in the prompt.\n- **Keep secrets and other users' data out of prompts (LLM02 \u002F LLM07).** Anything in the context can be echoed back. Don't put API keys, cross-tenant data, or the full system prompt where the model can repeat it.\n- **Constrain tool and agent permissions (LLM06: Excessive Agency).** Scope tools to the minimum, require confirmation for destructive or irreversible actions, and validate every tool argument.\n- **Bound consumption (LLM10: Unbounded Consumption).** Cap tokens, request rate, and loop\u002Frecursion depth so a crafted input can't run up cost or hang the system.\n- **Isolate retrieval data (LLM08: Vector and Embedding Weaknesses).** In RAG, treat the vector store as a trust boundary: partition embeddings per tenant so one user can't retrieve another's data, and validate documents before indexing so poisoned content can't steer answers.\n\n```typescript\n\u002F\u002F BAD: trusting model output as a command or as markup\nconst sql = await llm.generate(`Write SQL for: ${userQuestion}`);\nawait db.query(sql);                                   \u002F\u002F arbitrary query execution\ncontainer.innerHTML = await llm.reply(userMessage);   \u002F\u002F stored XSS, via the model\n\n\u002F\u002F GOOD: model output is data — parse defensively, then validate, then encode\nlet intent;\ntry {\n  intent = CommandSchema.parse(JSON.parse(await llm.replyJson(userMessage)));\n} catch {\n  throw new ValidationError('unexpected model output'); \u002F\u002F JSON.parse or schema failed\n}\nawait runAllowlistedAction(intent.action, intent.params);\ncontainer.textContent = await llm.reply(userMessage);\n```\n\n## Security Review Checklist\n\n```markdown\n### Authentication\n- [ ] Passwords hashed with bcrypt\u002Fscrypt\u002Fargon2 (salt rounds ≥ 12)\n- [ ] Session tokens are httpOnly, secure, sameSite\n- [ ] Login has rate limiting\n- [ ] Password reset tokens expire\n\n### Authorization\n- [ ] Every endpoint checks user permissions\n- [ ] Users can only access their own resources\n- [ ] Admin actions require admin role verification\n\n### Input\n- [ ] All user input validated at the boundary\n- [ ] SQL queries are parameterized\n- [ ] HTML output is encoded\u002Fescaped\n- [ ] Server-side URL fetches are allowlisted (no SSRF to internal services)\n\n### Data\n- [ ] No secrets in code or version control\n- [ ] Sensitive fields excluded from API responses\n- [ ] PII encrypted at rest (if applicable)\n\n### Infrastructure\n- [ ] Security headers configured (CSP, HSTS, etc.)\n- [ ] CORS restricted to known origins\n- [ ] Dependencies audited for vulnerabilities\n- [ ] Error messages don't expose internals\n\n### Supply Chain\n- [ ] One authoritative lockfile committed; CI uses that manager's frozen\u002Fimmutable install\n- [ ] Native audit triaged by reachability and fix risk; dependency install scripts blocked unless explicitly approved\n- [ ] New dependencies reviewed (ownership, provenance, release age, transitive graph)\n\n### AI \u002F LLM (if used)\n- [ ] Model output treated as untrusted (no eval\u002FSQL\u002FinnerHTML\u002Fshell)\n- [ ] Secrets and other users' data kept out of prompts\n- [ ] Tool\u002Fagent permissions scoped; destructive actions require confirmation\n```\n## See Also\n\nFor detailed security checklists and pre-commit verification steps, see `references\u002Fsecurity-checklist.md`.\n\n## Common Rationalizations\n\n| Rationalization | Reality |\n|---|---|\n| \"This is an internal tool, security doesn't matter\" | Internal tools get compromised. Attackers target the weakest link. |\n| \"We'll add security later\" | Security retrofitting is 10x harder than building it in. Add it now. |\n| \"No one would try to exploit this\" | Automated scanners will find it. Security by obscurity is not security. |\n| \"The framework handles security\" | Frameworks provide tools, not guarantees. You still need to use them correctly. |\n| \"It's just a prototype\" | Prototypes become production. Security habits from day one. |\n| \"Threat modeling is overkill here\" | Five minutes of \"how would I attack this?\" prevents the design flaws no control can patch later. |\n| \"It's just LLM output, it's only text\" | That \"text\" can be a SQL statement, a script tag, or a shell command. Treat it like any untrusted input. |\n| \"The audit passed, so the dependency is safe\" | Audits match known advisories. They do not detect a newly malicious package or make unreviewed install scripts safe to execute. |\n\n## Red Flags\n\n- User input passed directly to database queries, shell commands, or HTML rendering\n- Secrets in source code or commit history\n- API endpoints without authentication or authorization checks\n- Missing CORS configuration or wildcard (`*`) origins\n- No rate limiting on authentication endpoints\n- Stack traces or internal errors exposed to users\n- Dependencies with known critical vulnerabilities, competing lockfiles at one installation boundary, non-reproducible installs, or blanket-approved scripts\n- Server fetches user-supplied URLs without an allowlist (SSRF)\n- LLM\u002Fmodel output passed into a query, the DOM, a shell, or `eval`\n- Secrets, PII, or the full system prompt placed inside an LLM context window\n\n## Verification\n\nAfter implementing security-relevant code:\n\n- [ ] The native audit has no unmitigated reachable critical\u002Fhigh findings; CI preserves the authoritative lockfile and blocks unreviewed dependency scripts\n- [ ] No secrets in source code or git history\n- [ ] All user input validated at system boundaries\n- [ ] Authentication and authorization checked on every protected endpoint\n- [ ] Security headers present in response (check with browser DevTools)\n- [ ] Error responses don't expose internal details\n- [ ] Rate limiting active on auth endpoints\n- [ ] Server-side URL fetches validated against an allowlist (no SSRF)\n- [ ] LLM\u002Fmodel output validated and encoded before use (if AI features present)\n","# Security and Hardening\n\n## Overview\n\nSecurity-first development practices for web applications. Treat every external input as hostile, every secret as sacred, and every authorization check as mandatory. Security isn't a phase — it's a constraint on every line of code that touches user data, authentication, or external systems.\n\n## When to Use\n\n- Building anything that accepts user input\n- Implementing authentication or authorization\n- Storing or transmitting sensitive data\n- Integrating with external APIs or services\n- Adding file uploads, webhooks, or callbacks\n- Handling payment or PII data\n\n## Process: Threat Model First\n\nControls bolted on without a threat model are guesses. Before hardening, spend five minutes thinking like an attacker:\n\n1. **Map the trust boundaries.** Where does untrusted data cross into your system? HTTP requests, form fields, file uploads, webhooks, third-party APIs, message queues, and **LLM output**. Every boundary is attack surface.\n2. **Name the assets.** What's worth stealing or breaking? Credentials, PII, payment data, admin actions, money movement.\n3. **Run STRIDE over each boundary** — a quick lens, not a ceremony:\n\n| Threat | Ask | Typical mitigation |\n|---|---|---|\n| **S**poofing | Can someone impersonate a user\u002Fservice? | Authentication, signature verification |\n| **T**ampering | Can data be altered in transit or at rest? | Integrity checks, parameterized queries, HTTPS |\n| **R**epudiation | Can an action be denied later? | Audit logging of security events |\n| **I**nformation disclosure | Can data leak? | Encryption, field allowlists, generic errors |\n| **D**enial of service | Can it be overwhelmed? | Rate limiting, input size caps, timeouts |\n| **E**levation of privilege | Can a user gain rights they shouldn't? | Authorization checks, least privilege |\n\n4. **Write abuse cases next to use cases.** For each feature, ask \"how would I misuse this?\" — then make that your first test.\n\nIf you can't name the trust boundaries for a feature, you're not ready to secure it. This is OWASP **A04: Insecure Design** — most breaches begin in design, not code.\n\n## The Three-Tier Boundary System\n\n### Always Do (No Exceptions)\n\n- **Validate all external input** at the system boundary (API routes, form handlers)\n- **Parameterize all database queries** — never concatenate user input into SQL\n- **Encode output** to prevent XSS (use framework auto-escaping, don't bypass it)\n- **Use HTTPS** for all external communication\n- **Hash passwords** with bcrypt\u002Fscrypt\u002Fargon2 (never store plaintext)\n- **Set security headers** (CSP, HSTS, X-Frame-Options, X-Content-Type-Options)\n- **Use httpOnly, secure, sameSite cookies** for sessions\n- **Run the detected package manager's native audit** against the committed lockfile before every release\n\n### Ask First (Requires Human Approval)\n\n- Adding new authentication flows or changing auth logic\n- Storing new categories of sensitive data (PII, payment info)\n- Adding new external service integrations\n- Changing CORS configuration\n- Adding file upload handlers\n- Modifying rate limiting or throttling\n- Granting elevated permissions or roles\n\n### Never Do\n\n- **Never commit secrets** to version control (API keys, passwords, tokens)\n- **Never log sensitive data** (passwords, tokens, full credit card numbers)\n- **Never trust client-side validation** as a security boundary\n- **Never disable security headers** for convenience\n- **Never use `eval()` or `innerHTML`** with user-provided data\n- **Never store sessions in client-accessible storage** (localStorage for auth tokens)\n- **Never expose stack traces** or internal error details to users\n\n## OWASP Top 10 Prevention Patterns\n\nThese are prevention patterns, not a ranking. For the 2021 ordering, see the quick-reference table in `references\u002Fsecurity-checklist.md`.\n\n### Injection (SQL, NoSQL, OS Command)\n\n```typescript\n\u002F\u002F BAD: SQL injection via string concatenation\nconst query = `SELECT * FROM users WHERE id = '${userId}'`;\n\n\u002F\u002F GOOD: Parameterized query\nconst user = await db.query('SELECT * FROM users WHERE id = $1', [userId]);\n\n\u002F\u002F GOOD: ORM with parameterized input\nconst user = await prisma.user.findUnique({ where: { id: userId } });\n```\n\n### Broken Authentication\n\n```typescript\n\u002F\u002F Password hashing\nimport { hash, compare } from 'bcrypt';\n\nconst SALT_ROUNDS = 12;\nconst hashedPassword = await hash(plaintext, SALT_ROUNDS);\nconst isValid = await compare(plaintext, hashedPassword);\n\n\u002F\u002F Session management\napp.use(session({\n  secret: process.env.SESSION_SECRET,  \u002F\u002F From environment, not code\n  resave: false,\n  saveUninitialized: false,\n  cookie: {\n    httpOnly: true,     \u002F\u002F Not accessible via JavaScript\n    secure: true,       \u002F\u002F HTTPS only\n    sameSite: 'lax',    \u002F\u002F CSRF protection\n    maxAge: 24 * 60 * 60 * 1000,  \u002F\u002F 24 hours\n  },\n}));\n```\n\n### Cross-Site Scripting (XSS)\n\n```typescript\n\u002F\u002F BAD: Rendering user input as HTML\nelement.innerHTML = userInput;\n\n\u002F\u002F GOOD: Use framework auto-escaping (React does this by default)\nreturn \u003Cdiv>{userInput}\u003C\u002Fdiv>;\n\n\u002F\u002F If you MUST render HTML, sanitize first\nimport DOMPurify from 'dompurify';\nconst clean = DOMPurify.sanitize(userInput);\n```\n\n### Broken Access Control\n\n```typescript\n\u002F\u002F Always check authorization, not just authentication\napp.patch('\u002Fapi\u002Ftasks\u002F:id', authenticate, async (req, res) => {\n  const task = await taskService.findById(req.params.id);\n\n  \u002F\u002F Check that the authenticated user owns this resource\n  if (task.ownerId !== req.user.id) {\n    return res.status(403).json({\n      error: { code: 'FORBIDDEN', message: 'Not authorized to modify this task' }\n    });\n  }\n\n  \u002F\u002F Proceed with update\n  const updated = await taskService.update(req.params.id, req.body);\n  return res.json(updated);\n});\n```\n\n### Security Misconfiguration\n\n```typescript\n\u002F\u002F Security headers (use helmet for Express)\nimport helmet from 'helmet';\napp.use(helmet());\n\n\u002F\u002F Content Security Policy\napp.use(helmet.contentSecurityPolicy({\n  directives: {\n    defaultSrc: [\"'self'\"],\n    scriptSrc: [\"'self'\"],\n    styleSrc: [\"'self'\", \"'unsafe-inline'\"],  \u002F\u002F Tighten if possible\n    imgSrc: [\"'self'\", 'data:', 'https:'],\n    connectSrc: [\"'self'\"],\n  },\n}));\n\n\u002F\u002F CORS — restrict to known origins\napp.use(cors({\n  origin: process.env.ALLOWED_ORIGINS?.split(',') || 'http:\u002F\u002Flocalhost:3000',\n  credentials: true,\n}));\n```\n\n### Sensitive Data Exposure\n\n```typescript\n\u002F\u002F Never return sensitive fields in API responses\nfunction sanitizeUser(user: UserRecord): PublicUser {\n  const { passwordHash, resetToken, ...publicFields } = user;\n  return publicFields;\n}\n\n\u002F\u002F Use environment variables for secrets\nconst API_KEY = process.env.STRIPE_API_KEY;\nif (!API_KEY) throw new Error('STRIPE_API_KEY not configured');\n```\n\n### Server-Side Request Forgery (SSRF)\n\nAny time the server fetches a URL the user influenced — webhooks, \"import from URL\", image proxies, link previews — an attacker can aim it at internal services (cloud metadata, `localhost`, private IPs).\n\n```typescript\n\u002F\u002F BAD: fetch whatever the user gives you\nawait fetch(req.body.webhookUrl);\n\n\u002F\u002F GOOD: allowlist scheme + host, reject if ANY resolved IP is private, forbid redirects\nimport { lookup } from 'node:dns\u002Fpromises';\nimport ipaddr from 'ipaddr.js';\n\nconst ALLOWED_HOSTS = new Set(['hooks.example.com']);\n\nasync function assertSafeUrl(raw: string): Promise\u003CURL> {\n  const url = new URL(raw);\n  if (url.protocol !== 'https:') throw new Error('https only');\n  if (!ALLOWED_HOSTS.has(url.hostname)) throw new Error('host not allowed');\n  \u002F\u002F Resolve ALL records; a single private\u002Freserved address fails the check.\n  const addrs = await lookup(url.hostname, { all: true });\n  if (addrs.some((a) => ipaddr.parse(a.address).range() !== 'unicast')) {\n    throw new Error('private\u002Freserved IP');\n  }\n  return url;\n}\n\nawait fetch(await assertSafeUrl(req.body.webhookUrl), { redirect: 'error' });\n```\n\nThe `range() !== 'unicast'` check covers loopback, link-local `169.254.169.254` (cloud metadata, the #1 SSRF target), private, and unique-local ranges across IPv4 and IPv6.\n\n**Caveat — this still has a TOCTOU gap.** `fetch` resolves DNS again after the check, so an attacker using a short-TTL record can rebind to an internal IP between validation and connection. For high-risk surfaces, resolve once and connect to the pinned IP, or put a filtering agent in front (`request-filtering-agent` \u002F `ssrf-req-filter`).\n\n## Input Validation Patterns\n\n### Schema Validation at Boundaries\n\n```typescript\nimport { z } from 'zod';\n\nconst CreateTaskSchema = z.object({\n  title: z.string().min(1).max(200).trim(),\n  description: z.string().max(2000).optional(),\n  priority: z.enum(['low', 'medium', 'high']).default('medium'),\n  dueDate: z.string().datetime().optional(),\n});\n\n\u002F\u002F Validate at the route handler\napp.post('\u002Fapi\u002Ftasks', async (req, res) => {\n  const result = CreateTaskSchema.safeParse(req.body);\n  if (!result.success) {\n    return res.status(422).json({\n      error: {\n        code: 'VALIDATION_ERROR',\n        message: 'Invalid input',\n        details: result.error.flatten(),\n      },\n    });\n  }\n  \u002F\u002F result.data is now typed and validated\n  const task = await taskService.create(result.data);\n  return res.status(201).json(task);\n});\n```\n\n### File Upload Safety\n\n```typescript\n\u002F\u002F Restrict file types and sizes\nconst ALLOWED_TYPES = ['image\u002Fjpeg', 'image\u002Fpng', 'image\u002Fwebp'];\nconst MAX_SIZE = 5 * 1024 * 1024; \u002F\u002F 5MB\n\nfunction validateUpload(file: UploadedFile) {\n  if (!ALLOWED_TYPES.includes(file.mimetype)) {\n    throw new ValidationError('File type not allowed');\n  }\n  if (file.size > MAX_SIZE) {\n    throw new ValidationError('File too large (max 5MB)');\n  }\n  \u002F\u002F Don't trust the file extension — check magic bytes if critical\n}\n```\n\n## Triaging Dependency Audit Results\n\nPackage-manager audits report known advisories; they do not prove a package is trustworthy or that vulnerable code is reachable. Use this decision tree:\n\n```\nThe native package-manager audit reports a vulnerability\n├── Severity: critical or high\n│   ├── Is the vulnerable code reachable in runtime, build, test, or deployment paths?\n│   │   ├── YES --> Fix immediately (update, patch, or replace the dependency)\n│   │   └── NO (confirmed unused across those paths) --> Fix soon, but not a blocker\n│   └── Is a fix available?\n│       ├── YES --> Update to the patched version\n│       └── NO --> Check for workarounds, consider replacing the dependency, or add to allowlist with a review date\n├── Severity: moderate\n│   ├── Reachable in production? --> Fix in the next release cycle\n│   └── Dev-only? --> Fix when convenient, track in backlog\n└── Severity: low\n    └── Track and fix during regular dependency updates\n```\n\n**Key questions:**\n- Is the vulnerable function actually called in your code path?\n- Is the dependency a runtime dependency or dev-only?\n- Is the vulnerability exploitable given your deployment context (e.g., a server-side vulnerability in a client-only app)?\n\nWhen you defer a fix, document the reason and set a review date.\n\n### Supply-Chain Hygiene\n\nDo not assume npm or treat the nearest manifest as the install root. Apply this order:\n\n1. **Find the installation boundary and manager.** Use the workspace root that owns the lockfile, or an independent nested project only when it is outside that workspace. There, corroborate `packageManager` (when present), the lockfile, and CI; stop on disagreement or competing lockfiles. Pin the manager version and use the matrix in `references\u002Fsecurity-checklist.md`.\n2. **Block dependency scripts before first execution.** Bootstrap with scripts disabled or a documented fail-closed policy, inspect the pending script source, approve only the minimum required packages, commit the policy, then verify with a clean frozen\u002Fimmutable install. Never blanket-approve scripts.\n\nAudits only find known advisories; they do not catch a newly malicious or typosquatted package. Therefore:\n\n- **Never apply forced audit remediation automatically** (`npm audit fix --force` or equivalent). Preview the remediation, read changelogs, and test each resulting upgrade; forced fixes may cross declared dependency ranges.\n- **Verify registry signatures and provenance where supported** (`npm audit signatures`, `pnpm audit signatures`) and treat absence as a signal to investigate, not automatic proof of compromise.\n- **Review new dependencies, lockfile diffs, and script-policy changes together** — ownership, maintenance, release age, provenance, transitive graph, and typosquats such as `cross-env` vs `crossenv` (OWASP **A06**, **LLM03**).\n\n## Rate Limiting\n\n```typescript\nimport rateLimit from 'express-rate-limit';\n\n\u002F\u002F General API rate limit\napp.use('\u002Fapi\u002F', rateLimit({\n  windowMs: 15 * 60 * 1000, \u002F\u002F 15 minutes\n  max: 100,                   \u002F\u002F 100 requests per window\n  standardHeaders: true,\n  legacyHeaders: false,\n}));\n\n\u002F\u002F Stricter limit for auth endpoints\napp.use('\u002Fapi\u002Fauth\u002F', rateLimit({\n  windowMs: 15 * 60 * 1000,\n  max: 10,  \u002F\u002F 10 attempts per 15 minutes\n}));\n```\n\n## Secrets Management\n\n```\n.env files:\n  ├── .env.example  → Committed (template with placeholder values)\n  ├── .env          → NOT committed (contains real secrets)\n  └── .env.local    → NOT committed (local overrides)\n\n.gitignore must include:\n  .env\n  .env.local\n  .env.*.local\n  *.pem\n  *.key\n```\n\n**Always check before committing:**\n```bash\n# Check for accidentally staged secrets\ngit diff --cached | grep -i \"password\\|secret\\|api_key\\|token\"\n```\n\n**If a secret is ever committed, rotate it.** Deleting the line or rewriting history is not enough — assume it's compromised the moment it reaches a remote. Revoke and reissue the key first, then purge it from history.\n\n## Securing AI \u002F LLM Features\n\nIf your app calls an LLM — chatbots, summarizers, agents, RAG — it inherits a new attack surface. Map it to the [OWASP Top 10 for LLM Applications (2025)](https:\u002F\u002Fgenai.owasp.org\u002Fllm-top-10\u002F):\n\n- **Treat all model output as untrusted input (LLM05: Improper Output Handling).** Never pass LLM output straight into `eval`, SQL, a shell, `innerHTML`, or a file path. Validate and encode it exactly as you would raw user input.\n- **Assume prompts can be hijacked (LLM01: Prompt Injection).** Untrusted text in the context window — a user message, a fetched web page, a PDF — can carry instructions. The system prompt is not a security boundary; enforce permissions in code, not in the prompt.\n- **Keep secrets and other users' data out of prompts (LLM02 \u002F LLM07).** Anything in the context can be echoed back. Don't put API keys, cross-tenant data, or the full system prompt where the model can repeat it.\n- **Constrain tool and agent permissions (LLM06: Excessive Agency).** Scope tools to the minimum, require confirmation for destructive or irreversible actions, and validate every tool argument.\n- **Bound consumption (LLM10: Unbounded Consumption).** Cap tokens, request rate, and loop\u002Frecursion depth so a crafted input can't run up cost or hang the system.\n- **Isolate retrieval data (LLM08: Vector and Embedding Weaknesses).** In RAG, treat the vector store as a trust boundary: partition embeddings per tenant so one user can't retrieve another's data, and validate documents before indexing so poisoned content can't steer answers.\n\n```typescript\n\u002F\u002F BAD: trusting model output as a command or as markup\nconst sql = await llm.generate(`Write SQL for: ${userQuestion}`);\nawait db.query(sql);                                   \u002F\u002F arbitrary query execution\ncontainer.innerHTML = await llm.reply(userMessage);   \u002F\u002F stored XSS, via the model\n\n\u002F\u002F GOOD: model output is data — parse defensively, then validate, then encode\nlet intent;\ntry {\n  intent = CommandSchema.parse(JSON.parse(await llm.replyJson(userMessage)));\n} catch {\n  throw new ValidationError('unexpected model output'); \u002F\u002F JSON.parse or schema failed\n}\nawait runAllowlistedAction(intent.action, intent.params);\ncontainer.textContent = await llm.reply(userMessage);\n```\n\n## Security Review Checklist\n\n```markdown\n### Authentication\n- [ ] Passwords hashed with bcrypt\u002Fscrypt\u002Fargon2 (salt rounds ≥ 12)\n- [ ] Session tokens are httpOnly, secure, sameSite\n- [ ] Login has rate limiting\n- [ ] Password reset tokens expire\n\n### Authorization\n- [ ] Every endpoint checks user permissions\n- [ ] Users can only access their own resources\n- [ ] Admin actions require admin role verification\n\n### Input\n- [ ] All user input validated at the boundary\n- [ ] SQL queries are parameterized\n- [ ] HTML output is encoded\u002Fescaped\n- [ ] Server-side URL fetches are allowlisted (no SSRF to internal services)\n\n### Data\n- [ ] No secrets in code or version control\n- [ ] Sensitive fields excluded from API responses\n- [ ] PII encrypted at rest (if applicable)\n\n### Infrastructure\n- [ ] Security headers configured (CSP, HSTS, etc.)\n- [ ] CORS restricted to known origins\n- [ ] Dependencies audited for vulnerabilities\n- [ ] Error messages don't expose internals\n\n### Supply Chain\n- [ ] One authoritative lockfile committed; CI uses that manager's frozen\u002Fimmutable install\n- [ ] Native audit triaged by reachability and fix risk; dependency install scripts blocked unless explicitly approved\n- [ ] New dependencies reviewed (ownership, provenance, release age, transitive graph)\n\n### AI \u002F LLM (if used)\n- [ ] Model output treated as untrusted (no eval\u002FSQL\u002FinnerHTML\u002Fshell)\n- [ ] Secrets and other users' data kept out of prompts\n- [ ] Tool\u002Fagent permissions scoped; destructive actions require confirmation\n```\n## See Also\n\nFor detailed security checklists and pre-commit verification steps, see `references\u002Fsecurity-checklist.md`.\n\n## Common Rationalizations\n\n| Rationalization | Reality |\n|---|---|\n| \"This is an internal tool, security doesn't matter\" | Internal tools get compromised. Attackers target the weakest link. |\n| \"We'll add security later\" | Security retrofitting is 10x harder than building it in. Add it now. |\n| \"No one would try to exploit this\" | Automated scanners will find it. Security by obscurity is not security. |\n| \"The framework handles security\" | Frameworks provide tools, not guarantees. You still need to use them correctly. |\n| \"It's just a prototype\" | Prototypes become production. Security habits from day one. |\n| \"Threat modeling is overkill here\" | Five minutes of \"how would I attack this?\" prevents the design flaws no control can patch later. |\n| \"It's just LLM output, it's only text\" | That \"text\" can be a SQL statement, a script tag, or a shell command. Treat it like any untrusted input. |\n| \"The audit passed, so the dependency is safe\" | Audits match known advisories. They do not detect a newly malicious package or make unreviewed install scripts safe to execute. |\n\n## Red Flags\n\n- User input passed directly to database queries, shell commands, or HTML rendering\n- Secrets in source code or commit history\n- API endpoints without authentication or authorization checks\n- Missing CORS configuration or wildcard (`*`) origins\n- No rate limiting on authentication endpoints\n- Stack traces or internal errors exposed to users\n- Dependencies with known critical vulnerabilities, competing lockfiles at one installation boundary, non-reproducible installs, or blanket-approved scripts\n- Server fetches user-supplied URLs without an allowlist (SSRF)\n- LLM\u002Fmodel output passed into a query, the DOM, a shell, or `eval`\n- Secrets, PII, or the full system prompt placed inside an LLM context window\n\n## Verification\n\nAfter implementing security-relevant code:\n\n- [ ] The native audit has no unmitigated reachable critical\u002Fhigh findings; CI preserves the authoritative lockfile and blocks unreviewed dependency scripts\n- [ ] No secrets in source code or git history\n- [ ] All user input validated at system boundaries\n- [ ] Authentication and authorization checked on every protected endpoint\n- [ ] Security headers present in response (check with browser DevTools)\n- [ ] Error responses don't expose internal details\n- [ ] Rate limiting active on auth endpoints\n- [ ] Server-side URL fetches validated against an allowlist (no SSRF)\n- [ ] LLM\u002Fmodel output validated and encoded before use (if AI features present)\n",{"name":5,"description":7},"main","2d7111cf79ed41437a35c1f7982ce6adeac9ea6a",".agents\u002Fskills\u002Fsecurity-and-hardening","https:\u002F\u002Fgithub.com\u002Fziyad455\u002Fsophia","https:\u002F\u002Fgithub.com\u002Fziyad455","I'm a Software Engineering  at INVENEO, passionate about building production-grade systems that make a real impact.","2026-08-21 00:57:14",{"source":8,"skillName":5,"commands":32,"prompt":42,"zipAvailable":43},[33,36,39],{"tool":34,"command":35},"npx","npx skills add ziyad455\u002Fsophia --skill security-and-hardening",{"tool":37,"command":38},"bunx","bunx skills add ziyad455\u002Fsophia --skill security-and-hardening",{"tool":40,"command":41},"pnpm","pnpm dlx skills add ziyad455\u002Fsophia --skill security-and-hardening","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fziyad455\u002Fsophia\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fsecurity-and-hardening\u002FSKILL.md",true,[],[46,53,60,67,74,81],{"skillNo":47,"name":48,"nameZh":6,"description":49,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":50,"categories":51,"keywords":52,"publishedAt":19},"01M77PHM6Q4CQ14JQM4VVJE25Q","accessibility","Audit and improve web accessibility following WCAG 2.2 guidelines. Use when asked to \"improve accessibility\", \"a11y audit\", \"WCAG compliance\", \"screen reader support\", \"keyboard navigation\", or \"make accessible\".","https:\u002F\u002Fgithub.com\u002Fziyad455\u002Fsophia\u002Fblob\u002Fmain\u002F.agents\u002Fwcag-accessibility\u002Fskill.md",[],[],{"skillNo":54,"name":55,"nameZh":6,"description":56,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":57,"categories":58,"keywords":59,"publishedAt":19},"01M77PHGJHGWS1HW164BJJH9JS","writing-guidelines","Review docs\u002Fprose for Writing Guidelines compliance. Use when asked to \"review my docs\", \"check writing style\", \"audit prose\", \"review docs voice and tone\", or \"check this page against the writing handbook\".","https:\u002F\u002Fgithub.com\u002Fziyad455\u002Fsophia\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fwriting-guidelines\u002FSKILL.md",[],[],{"skillNo":61,"name":62,"nameZh":6,"description":63,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":64,"categories":65,"keywords":66,"publishedAt":19},"01M77PHE6782TNB8X549EK94CX","web-design-guidelines","Review UI code for Web Interface Guidelines compliance. Use when asked to \"review my UI\", \"check accessibility\", \"audit design\", \"review UX\", or \"check my site against best practices\".","https:\u002F\u002Fgithub.com\u002Fziyad455\u002Fsophia\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fweb-design-guidelines\u002FSKILL.md",[],[],{"skillNo":68,"name":69,"nameZh":6,"description":70,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":71,"categories":72,"keywords":73,"publishedAt":19},"01M77PHBHHM68A2YTWN4JY1DH8","verification-before-completion","Use when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidence before assertions always","https:\u002F\u002Fgithub.com\u002Fziyad455\u002Fsophia\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fverification-before-completion\u002FSKILL.md",[],[],{"skillNo":75,"name":76,"nameZh":6,"description":77,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":78,"categories":79,"keywords":80,"publishedAt":19},"01M77PH43WZPAKS82NJYYHVA4N","vercel-react-view-transitions","Guide for implementing smooth, native-feeling animations using React's View Transition API (`\u003CViewTransition>` component, `addTransitionType`, and CSS view transition pseudo-elements). Use this skill whenever the user wants to add page transitions, animate route changes, create shared element animations, animate enter\u002Fexit of components, animate list reorder, implement directional (forward\u002Fback) navigation animations, or integrate view transitions in Next.js. Also use when the user mentions view transitions, `startViewTransition`, `ViewTransition`, transition types, or asks about animating between UI states in React without third-party animation libraries.","https:\u002F\u002Fgithub.com\u002Fziyad455\u002Fsophia\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fvercel-react-view-transitions\u002FSKILL.md",[],[],{"skillNo":82,"name":83,"nameZh":6,"description":84,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":85,"categories":86,"keywords":87,"publishedAt":19},"01M77PGXA9ST3M4DF7BF69EMRF","vercel-react-best-practices","React and Next.js performance optimization guidelines from Vercel Engineering. This skill should be used when writing, reviewing, or refactoring React\u002FNext.js code to ensure optimal performance patterns. Triggers on tasks involving React components, Next.js pages, data fetching, bundle optimization, or performance improvements.","https:\u002F\u002Fgithub.com\u002Fziyad455\u002Fsophia\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fvercel-react-best-practices\u002FSKILL.md",[],[]]