ai-developer-skill-os 7.5.0 → 8.1.4

package/skills/_archive_old_skills/qk-auth-security/SKILL.md

@@ -1,96 +0,0 @@
----
-name: qk-
-description: >-
-  Triển khai tính năng đăng nhập (JWT, OAuth), phân quyền (RBAC) và bảo vệ app khỏi các lỗ hổng OWASP.
-version: 1.0.0
-category: backend
-tags: [auth, security, jwt, oauth, rbac, owasp]
-platforms: [antigravity, claude-code, kilo-code, cursor, windsurf]
----
-
-# Auth & Security Engineer
-
-> **Language rule:**
-> Use English for: code, identifiers, file names, architecture terms, technical decisions.
-> Use the user's language for: explanations, questions, summaries, and feedback.
-> The user may write in any language — detect and match it automatically.
-
----
-
-## Trigger
-
-Activate this skill when:
-- User asks to "add login", "protect this route", or "implement OAuth"
-- Defining user roles and permissions (Admin vs User)
-- Project audit flags security vulnerabilities (P0/P1)
-- Handling sensitive data (passwords, PII, API keys)
-
----
-
-## Scope
-
-- ✅ **Authentication:** JWT, Session Cookies, OAuth2 (Google, GitHub, etc.), Magic Links.
-- ✅ **Authorization:** Role-Based Access Control (RBAC), Middleware guards.
-- ✅ **Data Protection:** Hashing passwords (bcrypt, Argon2), encrypting sensitive fields.
-- ✅ **Vulnerability Prevention:** CSRF protection, Rate Limiting, CORS config, input sanitization (SQLi/XSS).
-
----
-
-## Non-goals
-
-- ❌ Do NOT store passwords in plain text. Ever.
-- ❌ Do NOT hardcode secrets or private keys in the code (use `.env`).
-- ❌ Do NOT store JWTs in `localStorage` if cookies (`httpOnly`) are an option, unless explicitly requested.
-
----
-
-## Workflow
-
-### Phase 1 — Strategy Selection
-
-Determine the auth mechanism:
-1. **Stateless (JWT):** Good for mobile/SPAs, distributed systems.
-2. **Stateful (Sessions):** Good for traditional web apps, easier revocation.
-3. **Third-party (OAuth / Auth0 / NextAuth / Supabase):** Offload auth complexity.
-
-### Phase 2 — Implementation
-
-**For JWT + Cookies (Recommended Web Pattern):**
-1. Create Login endpoint: Verify password → Generate JWT → Set `httpOnly` cookie.
-2. Create Middleware: Extract cookie → Verify JWT signature → Attach user to request.
-3. Create Logout endpoint: Clear the cookie.
-
-**For Authorization:**
-1. Define roles (e.g., `enum Role { ADMIN, USER }`).
-2. Create Role Middleware: Check `req.user.role`.
-
-### Phase 3 — Security Audit
-
-Verify:
-- Passwords are hashed with a salt (e.g., `bcrypt.hash(password, 10)`).
-- Cookies are `httpOnly`, `Secure` (in prod), and `SameSite`.
-- CORS is configured to only allow trusted origins.
-
----
-
-## Output Format
-
-```
-🛡️ Auth & Security Report
-─────────────────────────────────────────────────
-Mechanism:  [JWT in httpOnly Cookie / OAuth / Session]
-Roles:      [Admin, User]
-
-Components Implemented:
-  ✅ Login/Logout handlers
-  ✅ Auth Middleware (Guard)
-  ✅ Password hashing (bcrypt)
-
-Security measures enforced:
-  • `httpOnly`, `Secure`, `SameSite=Strict` on cookies
-  • CORS restricted to frontend origin
-
-🔗 Next Steps:
-  Remember to add `JWT_SECRET` to your production environment variables.
-```
-

package/skills/_archive_old_skills/qk-backend-architecture/SKILL.md

@@ -1,125 +0,0 @@
----
-name: qk-
-description: >-
-  Kiểm soát cấu trúc backend, ép buộc tuân thủ mô hình Layer (Controller/Service/Repository) và vị trí file.
-version: 1.0.0
-category: backend
-tags: [architecture, backend, controller, service, repository, structure]
-platforms: [antigravity, claude-code, kilo-code, cursor, windsurf]
----
-
-# Backend Architecture
-
-> **Language rule:**
-> Use English for: code, identifiers, file names, architecture terms, technical decisions.
-> Use the user's language for: explanations, questions, summaries, and feedback.
-> The user may write in any language — detect and match it automatically.
-
----
-
-## Trigger
-
-Activate this skill when:
-- Creating new backend API endpoints, services, or models
-- User asks "where should I put this business logic?"
-- Project audit flags mixed concerns (e.g., SQL queries inside a controller)
-- Inheriting or setting up a Node.js, Python, or Go backend
-
----
-
-## Scope
-
-- ✅ Discover existing backend folder structure
-- ✅ Enforce Layered Architecture (Controller → Service → Data Access)
-- ✅ Enforce Domain/Module-based structure if applicable (`src/users/`, `src/orders/`)
-- ✅ Define where validation, mapping, and error handling should live
-- ✅ Validate file placement before code generation
-
----
-
-## Non-goals
-
-- ❌ Do NOT rewrite the architecture unless requested
-- ❌ Do NOT write the actual database queries (delegate to `database-engineer`)
-- ❌ Do NOT configure server infrastructure (delegate to `deployment`)
-
----
-
-## Severity Levels
-
-| Level | Meaning |
-|-------|---------|
-| P0 | Circular dependency or security bypass in architecture |
-| P1 | Mixed concerns (e.g., ORM logic in route handler) |
-| P2 | Inconsistent folder or file naming |
-| P3 | Minor deviation from convention |
-
----
-
-## Workflow
-
-### Phase 1 — Architecture Discovery
-
-Analyze the project structure:
-1. **Classic MVC / Layered:** `controllers/`, `services/`, `models/`, `routes/`
-2. **Domain-Driven (Module):** `src/modules/user/{controller, service, repository}`
-3. **Framework-specific:** NestJS (`.controller.ts`, `.service.ts`), Django apps, Express monolithic.
-4. **Serverless:** `functions/`, `handlers/`
-
----
-
-### Phase 2 — Rule Extraction
-
-Extract conventions:
-- **Routes/Controllers:** Should only handle HTTP req/res, params validation, and calling services. No business logic.
-- **Services:** Pure business logic. Does not know about HTTP (`req`/`res`).
-- **Repositories/Data Access:** Only layer that interacts with the DB.
-- **Error Handling:** Centralized error middleware vs local try/catch.
-
----
-
-### Phase 3 — File Placement & Routing
-
-Map a new requirement to the architecture:
-
-*Request: "Add an endpoint to update user profile"*
-- Route: `PUT /api/users/:id` mapped in `src/routes/user.routes.ts`
-- Controller: `updateProfile(req, res)` in `src/controllers/user.controller.ts`
-- Service: `updateUserProfile(userId, data)` in `src/services/user.service.ts`
-
----
-
-## Decision Tree
-
-```
-Does the project group files by Layer or by Domain?
-  ├── Layer  → Place in `src/controllers/` and `src/services/`
-  └── Domain → Place in `src/modules/users/`
-
-Where does data validation happen?
-  ├── Middleware → Add Zod/Joi validation at the router level
-  └── Controller → Validate inside the controller function before calling service
-```
-
----
-
-## Output Format
-
-```
-🏗️ Backend Architecture Plan
-─────────────────────────────────────────────────
-Structure Type: [Layered / Domain-based / Framework-specific]
-
-Layer Mapping:
-  ✅ Controller: [path/to/controller.ts] — handles HTTP
-  ✅ Service:    [path/to/service.ts] — business logic
-  ✅ Repo/DB:    [handled by database-engineer]
-
-⚠️ Constraints enforced:
-  • Do not pass `req` or `res` objects into the Service layer.
-  • Validate all inputs at the Controller/Route level.
-
-🔗 Next Steps:
-  Proceeding to implement the layers.
-```
-

package/skills/_archive_old_skills/qk-bug-fix/SKILL.md

@@ -1,213 +0,0 @@
----
-name: qk-bug-fix
-description: >-
-  Chẩn đoán và sửa lỗi an toàn. Tái hiện lỗi, tìm nguyên nhân gốc rễ và áp dụng bản sửa lỗi tối thiểu, có kiểm chứng.
-version: 2.0.0
-category: engineering
-tags: [bug, fix, debug, root-cause, regression]
-platforms: [antigravity, claude-code, kilo-code, cursor, windsurf]
----
-
-# Bug Fix — Diagnose & Repair
-
-> **Language rule:**
-> Use English for: code, identifiers, file names, architecture terms, technical decisions.
-> Use the user's language for: explanations, questions, summaries, and feedback.
-> The user may write in any language — detect and match it automatically.
-
----
-
-## Trigger
-
-Activate this skill when:
-- User reports a specific bug with a stack trace, error message, or behavior description
-- A test is failing
-- The app crashes or hangs
-- A regression occurred after a code change
-- User says "it's broken", "this doesn't work", "I'm getting an error"
-
-**Not this skill** → Use `project-audit` if the problem is unknown and needs discovery first.
-
----
-
-## Scope
-
-- ✅ Reproduce the reported bug
-- ✅ Identify the root cause (not just the symptom)
-- ✅ Apply a minimal, targeted fix
-- ✅ Verify the fix with evidence (tests, logs, comparison)
-- ✅ Prevent recurrence with guards or tests
-
----
-
-## Non-goals
-
-- ❌ Do NOT refactor code outside the buggy area
-- ❌ Do NOT change public APIs unless the bug requires it
-- ❌ Do NOT silence errors with empty `try/catch` or blind `?.` / `!`
-- ❌ Do NOT change formatting or unrelated code
-- ❌ Do NOT mark as done without verifying the fix
-
----
-
-## Severity Levels
-
-| Level | Meaning |
-|-------|---------|
-| P0 | Production down, data loss, security breach |
-| P1 | Core feature broken, blocking users |
-| P2 | Non-critical feature broken, workaround exists |
-| P3 | Edge case, cosmetic, minor annoyance |
-
----
-
-## Workflow
-
-### Phase 1 — Triage & Understand
-
-Before touching code, gather:
-- What is the symptom? (error message, wrong behavior, crash)
-- What is the expected behavior?
-- How to reproduce? (steps, conditions, environment)
-- What changed recently? (git log, deployment, dependency update)
-- What is the severity and impact scope?
-
-If critical information is missing → ask before proceeding.
-
----
-
-### Phase 2 — Reproduce the Issue
-
-1. Write a failing test or script that triggers the bug
-2. Confirm the bug is consistently reproducible
-3. For intermittent bugs → identify timing, data, or environment conditions
-4. Document the exact reproduction steps
-
-> Rule: **Never skip reproduction.** A fix without a repro is a guess.
-
----
-
-### Phase 3 — Localize the Problem
-
-1. Read the stack trace top-down, following frames inside project code
-2. Use logs, breakpoints, or `git blame` / `git bisect` to narrow scope
-3. Identify the exact file and line where the failure originates
-4. Trace the data flow that leads to the failure
-
----
-
-### Phase 4 — Root Cause Analysis
-
-Answer: *Why does this happen? What condition triggers it?*
-
-Common root cause categories:
-- Logic error (wrong condition, wrong operator)
-- Off-by-one or boundary case
-- Null / undefined / missing data
-- Async timing or race condition
-- Type mismatch
-- Stale state or stale closure
-- Config or environment issue
-- API contract change
-- Dependency version change
-
-Use 5 Whys: keep asking "why" until you reach the actual cause, not just the symptom.
-
----
-
-### Phase 5 — Apply the Fix
-
-Rules:
-- Fix the root cause, not the symptom
-- Smallest possible change that fully resolves the issue
-- Keep existing code style, naming, and conventions
-- Handle related edge cases to prevent similar bugs
-- Remove all debug code, console.logs, and temporary patches
-- Do not change public APIs unless strictly required
-
----
-
-### Phase 6 — Verify the Result
-
-- [ ] The failing test from Phase 2 now passes
-- [ ] Run the related test suite — no new failures
-- [ ] Run lint and type-check — clean
-- [ ] Manually reproduce the original steps — bug is gone
-- [ ] No regressions in adjacent functionality
-
----
-
-### Phase 7 — Report & Prevent
-
-Summarize and propose prevention:
-- What was the root cause?
-- What was changed and why?
-- Are there similar patterns elsewhere in the codebase?
-- Should a test be added to prevent regression?
-
----
-
-## Decision Tree
-
-```
-Is the bug reproducible?
-  ├── No  → Isolate timing, data, environment conditions first
-  └── Yes → Is the root cause known?
-              ├── No  → Run Phase 3-4 (localize + analyze)
-              └── Yes → Apply minimal fix → verify → report
-```
-
-```
-Is the fix risky (touches shared code / public API)?
-  ├── Yes → Confirm scope with user before applying
-  └── No  → Apply fix
-```
-
----
-
-## Output Format
-
-```
-🐛 Bug Report
-─────────────────────────────────────────────────
-Symptom:     [What broke + how to reproduce]
-Root cause:  [Exact file:line — why it happens]
-Severity:    [P0 / P1 / P2 / P3]
-
-🔧 Fix Applied
-─────────────────────────────────────────────────
-Changed:     [File(s) modified]
-Change:      [What was changed and why it's minimal]
-
-✅ Verification
-─────────────────────────────────────────────────
-Tests:       [Test name / command — PASSED]
-Lint/Types:  [Clean / warnings noted]
-Manual:      [Reproduced original steps — bug gone]
-Regression:  [No new failures]
-
-🛡️ Prevention
-─────────────────────────────────────────────────
-Test added:  [Yes / No — reason]
-Similar areas to check: [file or pattern to review]
-```
-
----
-
-## Validation Checklist
-
-- [ ] Bug was reproduced before fixing
-- [ ] Root cause identified at exact file:line with explanation
-- [ ] Fix is minimal — only changes what's needed
-- [ ] Failing test now passes
-- [ ] Related tests and lint/type-check clean
-- [ ] No debug code left behind
-- [ ] Side effects documented
-- [ ] Prevention strategy noted
-
----
-
-## Examples
-
-See `examples/` folder.
-

package/skills/_archive_old_skills/qk-component-generator/SKILL.md

@@ -1,136 +0,0 @@
----
-name: qk-component-generator
-description: >-
-  Tạo các UI Component độc lập, tái sử dụng được, có type an toàn và tuân thủ chuẩn design system.
-version: 1.0.0
-category: frontend
-tags: [component, react, vue, ui, props, reusable]
-platforms: [antigravity, claude-code, kilo-code, cursor, windsurf]
----
-
-# Component Generator
-
-> **Language rule:**
-> Use English for: code, identifiers, file names, architecture terms, technical decisions.
-> Use the user's language for: explanations, questions, summaries, and feedback.
-> The user may write in any language — detect and match it automatically.
-
----
-
-## Trigger
-
-Activate this skill when:
-- User says "create a Card component", "make a reusable Button", "extract this into a component"
-- A larger skill (`ui-builder`, `form-builder`) requires a new isolated UI piece to be built
-- Refactoring a large component by splitting it into smaller, reusable parts
-
----
-
-## Scope
-
-- ✅ Generate a single, focused component (e.g., `UserCard`, `StatBadge`, `Dropdown`)
-- ✅ Define strict, explicit types/interfaces for all props
-- ✅ Implement component variants (e.g., `size`, `color`, `variant`) if needed
-- ✅ Follow project styling rules (Tailwind, CSS Modules, Styled Components)
-- ✅ Ensure accessibility (ARIA attributes, semantic HTML) where applicable
-
----
-
-## Non-goals
-
-- ❌ Do NOT build full pages or complex screens (delegate to `ui-builder`)
-- ❌ Do NOT handle complex business logic or data fetching inside a dumb/presentational component
-- ❌ Do NOT overwrite existing components without explicit instruction
-
----
-
-## Workflow
-
-### Phase 1 — Component Design
-
-Determine:
-1. **Name:** PascalCase (e.g., `ProductCard`).
-2. **Responsibility:** What exactly does this component do? Keep it single-responsibility.
-3. **Props:** What data does it need from its parent? What events does it emit?
-
----
-
-### Phase 2 — API (Props) Definition
-
-Draft the interface first.
-- Make required props explicit.
-- Use optional props (`?`) for variants or non-essential data.
-- Avoid `any`.
-
-*Example:*
-```typescript
-interface ProductCardProps {
-  id: string;
-  title: string;
-  price: number;
-  imageUrl?: string;
-  isAvailable?: boolean;
-  onAddToCart: (id: string) => void;
-}
-```
-
----
-
-### Phase 3 — Implementation
-
-Write the component code.
-1. Use destructuring for props.
-2. Apply styling based on `design-system` rules.
-3. Handle empty/null states (e.g., if `imageUrl` is missing, show a placeholder).
-4. Add basic interactivity (e.g., calling `onAddToCart` when clicked).
-
----
-
-### Phase 4 — Validation
-
-- [ ] Are all props typed correctly?
-- [ ] Is it truly reusable (no hardcoded data)?
-- [ ] Does it use project design tokens?
-- [ ] Is it exported correctly according to project conventions (default vs. named export)?
-
----
-
-## Decision Tree
-
-```
-Does the component need to manage its own state (e.g., an accordion opening/closing)?
-  ├── Yes → Add local state (`useState`). Keep it minimal.
-  └── No  → Make it a pure "dumb" component receiving props.
-
-Are there multiple visual styles requested (e.g., primary, secondary, outline)?
-  ├── Yes → Add a `variant` prop and map it to style classes.
-  └── No  → Implement the single required style.
-```
-
----
-
-## Output Format
-
-```
-🧩 Component Generated
-─────────────────────────────────────────────────
-Name:     [ComponentName]
-Path:     [path/to/Component.tsx]
-
-Props Interface:
-  [List key props here briefly]
-
-Features:
-  • [Feature 1, e.g., "Supports primary/secondary variants"]
-  • [Feature 2, e.g., "Fully typed with TypeScript"]
-
-🔗 Next Steps:
-  Component is ready to be imported into your layout.
-```
-
----
-
-## Examples
-
-See `examples/` folder.
-