Top 5 AI Skills That 10x Your Coding Productivity in 2026

---
name: typescript-expert
description: Expert TypeScript with strict mode and advanced patterns
---

TypeScript rules (non-negotiable):
- NEVER use 'any'. Use unknown + type guards, generics, or specific types
- NEVER use non-null assertion (!). Handle null/undefined explicitly
- Use discriminated unions for complex state: { status: 'loading' | 'success' | 'error' }
- Use const assertions: const ROLES = ['admin', 'user'] as const
- Type all function parameters and return types explicitly
- Use branded types for IDs: type UserId = string & { __brand: 'UserId' }
- Prefer type inference for local variables, explicit for public APIs
- Use satisfies operator instead of type assertions
- When something "should never happen", use a never check with error throw

---
name: security-auditor
description: OWASP Top 10 security scanning and secure coding patterns
---

Apply these security rules to ALL code:

INPUT VALIDATION:
- Validate all user inputs server-side (never trust client)
- Use allowlists, not denylists for validation
- Sanitize before storing, escape before rendering

AUTHENTICATION:
- Hash passwords with bcrypt (min cost 12) or argon2
- Use secure, httpOnly, sameSite cookies for sessions
- Implement CSRF protection for state-changing requests
- Rate limit auth endpoints (brute force protection)

DATA ACCESS:
- Use parameterized queries ALWAYS — no string concatenation in SQL
- Apply row-level security / scope all queries to authenticated user
- Never expose internal IDs in URLs when predictable

SECRETS:
- Never hardcode API keys, passwords, or tokens
- Use environment variables, validate they're set at startup
- Redact secrets from logs

If you see a violation, mark it [SECURITY ISSUE] and explain the fix.

---
name: tdd-specialist
description: Test-driven development — tests first, then implementation
---

Follow TDD workflow strictly:

1. WRITE FAILING TEST FIRST
   - Describe the expected behavior, not the implementation
   - One assertion per test (ideally)
   - Test name = "should [behavior] when [condition]"

2. WRITE MINIMAL IMPLEMENTATION
   - Only enough code to make the test pass
   - No premature optimization
   - No untested code paths

3. REFACTOR
   - Clean up implementation while keeping tests green
   - Extract helper functions when logic repeats

TEST STRUCTURE (AAA pattern):
- Arrange: Set up test data and state
- Act: Execute the function under test
- Assert: Verify the expected outcome

WHAT TO TEST:
- Public interface behavior, not implementation details
- Edge cases: empty input, max values, concurrent calls
- Error paths: invalid input, network failure, timeout

DO NOT:
- Test private methods directly
- Mock everything (use real implementations where fast enough)
- Write tests after the fact for already-shipped code

---
name: documentation-writer
description: Clear, useful documentation for APIs, functions, and architecture
---

Documentation standards:

JSDOC / DOCSTRINGS:
- Every public function/method needs a JSDoc comment
- Include: @param (type + description), @returns (type + description)
- Include @throws for functions that can throw
- Add @example with a realistic usage example
- Mark deprecated APIs with @deprecated and migration path

README SECTIONS (in order):
1. What it does (1-2 sentences, no jargon)
2. Quick start (minimal working example)
3. Installation
4. Configuration (all env vars with types and defaults)
5. API reference
6. Contributing guide

INLINE COMMENTS:
- Comment WHY, not WHAT (the code shows what)
- Comment non-obvious business logic
- Comment workarounds with issue links: // Workaround for [JIRA-123]
- No commented-out code — delete it or use feature flags

WRITING STYLE:
- Active voice: "Returns the user" not "The user is returned"
- Concrete examples over abstract descriptions
- Link to related concepts
- Assume the reader is smart but unfamiliar with your codebase