ai-developer-skill-os 7.5.0 → 8.1.4

package/skills/_archive_old_skills/qk-project-audit/SKILL.md

@@ -1,280 +0,0 @@
----
-name: qk-project-audit
-description: >-
-  Kiểm toán toàn bộ dự án để phát hiện bug ẩn, rủi ro bảo mật, vấn đề hiệu năng và nợ kỹ thuật trước khi sửa code.
-version: 1.0.0
-category: engineering
-tags: [audit, review, bug-detection, architecture, security, performance]
-platforms: [antigravity, claude-code, kilo-code, cursor, windsurf]
----
-
-# Project Audit
-
-> **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.
-
-> ⚠️ **CRITICAL: Do NOT modify any code during audit.**
-> The audit produces a report. Changes happen only after the user reviews and approves.
-
----
-
-## Trigger
-
-Activate this skill when:
-- User says "audit", "review", "health check", "what's wrong with my project"
-- Before starting a large feature or refactor
-- After inheriting a codebase
-- Before a major release
-- When the system behaves unexpectedly and the root cause is unknown
-
----
-
-## Scope
-
-- ✅ Detect hidden bugs, race conditions, and unstable areas
-- ✅ Review architecture and separation of concerns
-- ✅ Identify security vulnerabilities
-- ✅ Find performance bottlenecks
-- ✅ Audit dependencies (outdated, risky, unused)
-- ✅ Produce prioritized findings with recommended fixes
-
----
-
-## Non-goals
-
-- ❌ Do NOT fix anything during the audit
-- ❌ Do NOT refactor code
-- ❌ Do NOT make assumptions — document uncertainty instead
-- ❌ Do NOT audit `node_modules`, `dist`, `build`, `.git`
-
----
-
-## Audit Modes
-
-Choose based on context:
-
-| Mode | Scope | When to use |
-|------|-------|-------------|
-| **Quick** | Changed files only (git diff / recent edits) | Fast pre-commit check, small bug scope |
-| **Standard** | Current feature / module being worked on | Default — before implementing changes |
-| **Full** | Entire repository | Onboarding, pre-release, inherited codebase |
-
-**Default: Standard mode.**
-Use Full mode only when explicitly requested or before a major release.
-
----
-
-## Severity Levels
-
-All findings use this shared scale:
-
-| Level | Label | Meaning |
-|-------|-------|---------|
-| P0 | Critical | Security breach, data loss, production crash — fix immediately |
-| P1 | High | Bug affecting core functionality — fix before shipping |
-| P2 | Medium | Performance issue or bad pattern — schedule soon |
-| P3 | Low | Technical debt, code smell — fix when possible |
-
----
-
-## Workflow
-
-### Phase 1 — Project Discovery
-
-*(Use `context-manager` if project context is not yet loaded)*
-
-Analyze:
-- Framework, language, build system
-- Folder structure and architecture style
-- Key dependencies and their versions
-- Entry points, routing, data flow
-
-Output: **Project Overview** (2-5 lines)
-
----
-
-### Phase 2 — Architecture Review
-
-Check:
-
-**Separation of concerns:**
-- Are UI components mixing API calls and business logic?
-- Are services doing too much?
-- Is there duplicated logic across modules?
-
-**Folder structure:**
-- Does file placement follow the declared architecture?
-- Are there misplaced files or responsibilities?
-
-**Patterns:**
-- Are patterns applied consistently? (hooks, services, stores)
-- Are there anti-patterns? (prop drilling, God components, circular imports)
-
----
-
-### Phase 3 — Bug Detection
-
-#### Frontend
-
-Check for:
-- `useEffect` with missing or wrong dependency arrays
-- State updates after component unmount (memory leak)
-- Missing cleanup in subscriptions, timers, event listeners
-- Stale closures in async callbacks
-- Race conditions in data fetching
-- Infinite re-render loops
-- `key` prop issues in lists
-
-#### Backend
-
-Check for:
-- Unhandled promise rejections
-- Missing input validation
-- Incorrect HTTP status codes
-- Transaction issues (missing rollback on error)
-- Race conditions in concurrent operations
-
-#### API Layer
-
-Check for:
-- Inconsistent response handling
-- Missing error states
-- Duplicate requests without debounce/cancellation
-- Missing loading/error/empty states in UI
-
----
-
-### Phase 4 — Security Audit
-
-Check for:
-- Hardcoded secrets, tokens, credentials in code
-- Sensitive data in `localStorage` or URL params
-- Missing authentication/authorization checks
-- SQL injection or NoSQL injection risks
-- XSS vulnerabilities (dangerouslySetInnerHTML, unsanitized input)
-- Insecure direct object references (IDOR)
-- CORS misconfiguration
-
----
-
-### Phase 5 — Performance Audit
-
-Check for:
-- Large bundle size (missing code splitting, lazy loading)
-- Expensive computations on every render (missing `useMemo`, `useCallback`)
-- Unnecessary re-renders (missing `memo`, wrong dependency arrays)
-- N+1 query problems
-- Missing pagination on large datasets
-- Unoptimized images or assets
-
----
-
-### Phase 6 — Dependency Audit
-
-Check:
-- Outdated packages with known CVEs
-- Packages with very low maintenance (abandoned)
-- Duplicate packages doing the same job
-- Unused dependencies in `package.json`
-- Major version gaps that indicate deferred upgrades
-
----
-
-## Decision Tree
-
-```
-Which audit mode?
-  ├── Quick   → Read only git diff / recently changed files
-  ├── Standard → Read current feature/module files + related
-  └── Full    → Scan entire src/ directory systematically
-
-Issue found → Assess severity:
-  ├── P0 → Flag immediately, recommend pausing current work
-  ├── P1 → Include in required fixes before shipping
-  ├── P2 → Include in scheduled improvements
-  └── P3 → Log as technical debt
-
-No issues found in area → Mark as ✅ Clean
-```
-
----
-
-## Output Format
-
-### Executive Summary
-
-```
-🏥 Project Health Report
-─────────────────────────
-Health:          [Excellent / Good / Needs Attention / Critical]
-Risk Level:      [Low / Medium / High / Critical]
-Audit Mode:      [Quick / Standard / Full]
-Files Reviewed:  [N]
-Total Findings:  [N]  (P0: N · P1: N · P2: N · P3: N)
-```
-
-### Findings (one per issue)
-
-```
-───────────────────────────────
-ID:        AUDIT-001
-Severity:  P1 — High
-Location:  src/hooks/useUserData.ts:47
-Problem:   useEffect fetches data but missing cleanup — causes state update
-           on unmounted component, triggering React warning and potential
-           memory leak under slow networks.
-Impact:    Console errors in production, potential memory leak.
-Root cause: No AbortController or isMounted flag used.
-Fix:       Add AbortController + cleanup return in useEffect.
-Effort:    ~15 min
-```
-
-### Priority Roadmap
-
-```
-🗺️  Fix Roadmap
-──────────────────
-P0 — Fix immediately (before anything else):
-  • [AUDIT-00X] [Brief description]
-
-P1 — Fix before shipping:
-  • [AUDIT-00X] [Brief description]
-
-P2 — Schedule this sprint:
-  • [AUDIT-00X] [Brief description]
-
-P3 — Technical debt backlog:
-  • [AUDIT-00X] [Brief description]
-```
-
-### Next Steps
-
-```
-🔗 Recommended next skills:
-  → bug-fix        (for P0/P1 issues)
-  → refactor       (for architecture issues)
-  → migration      (for outdated dependencies)
-  → frontend-performance  (for P2 performance issues)
-
-⏳ Awaiting your approval to proceed with fixes.
-```
-
----
-
-## Validation Checklist
-
-- [ ] Correct audit mode selected for the task
-- [ ] All 6 phases covered (or scoped ones for Quick/Standard)
-- [ ] Every finding has: ID, severity, location, problem, root cause, fix, effort
-- [ ] Priority roadmap is ordered correctly (P0 first)
-- [ ] No code was modified during audit
-- [ ] User informed — awaiting approval before any changes
-
----
-
-## Examples
-
-See `examples/` folder.
-

package/skills/_archive_old_skills/qk-refactor/SKILL.md

@@ -1,222 +0,0 @@
----
-name: qk-refactor
-description: >-
-  Tái cấu trúc và dọn dẹp mã nguồn để dễ bảo trì hơn mà không làm thay đổi logic hoạt động bên ngoài.
-version: 1.0.0
-category: engineering
-tags: [refactor, clean-code, restructure, technical-debt, maintainability]
-platforms: [antigravity, claude-code, kilo-code, cursor, windsurf]
----
-
-# Refactor — Safe Restructuring
-
-> **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.
-
-> ⚠️ **Core constraint: Refactoring must NOT change observable behavior.**
-> If behavior changes are needed → that is a feature, not a refactor.
-> Stop and clarify with the user before proceeding.
-
----
-
-## Trigger
-
-Activate this skill when:
-- User says "clean up", "refactor", "it's too messy", "hard to maintain"
-- Code has grown beyond its original design (God component, fat service, spaghetti logic)
-- Duplicate patterns exist across multiple files
-- `project-audit` identified architecture issues (P2/P3) ready to be addressed
-- User asks to "improve code quality" without changing functionality
-
-**Not this skill** → Use `bug-fix` if behavior is wrong. Use `migration` if upgrading dependencies.
-
----
-
-## Scope
-
-- ✅ Rename for clarity (variables, functions, files, components)
-- ✅ Extract reusable logic into functions, hooks, services, or utilities
-- ✅ Remove dead code, unused imports, and orphaned files
-- ✅ Split large components / functions into focused units
-- ✅ Apply consistent patterns across the codebase
-- ✅ Improve type coverage (replace `any`, add missing types)
-- ✅ Reduce complexity (flatten nested conditions, simplify logic)
-
----
-
-## Non-goals
-
-- ❌ Do NOT change behavior — if you must, stop and discuss first
-- ❌ Do NOT change public APIs or exported interfaces without explicit approval
-- ❌ Do NOT rewrite everything — prefer incremental, targeted changes
-- ❌ Do NOT apply opinionated style changes (formatting belongs to linter/prettier)
-- ❌ Do NOT introduce new dependencies
-- ❌ Do NOT refactor code unrelated to the stated scope
-
----
-
-## Severity Levels (for issues found during analysis)
-
-| Level | Meaning |
-|-------|---------|
-| P0 | Refactor introduces breaking change — stop immediately |
-| P1 | High coupling or duplication blocking feature work |
-| P2 | Code smell reducing maintainability |
-| P3 | Minor naming or style inconsistency |
-
----
-
-## Workflow
-
-### Phase 1 — Understand Current State
-
-Before changing anything:
-1. Read the target code thoroughly
-2. Identify what it does (behavior, inputs, outputs, side effects)
-3. Note all callers and dependents of the code being refactored
-4. Check for existing tests — these are the safety net
-
-If there are **no tests** for the code being refactored → recommend writing characterization tests first, or proceed with extra caution and document risks.
-
----
-
-### Phase 2 — Identify Refactor Targets
-
-Common code smells to look for:
-
-| Smell | Description |
-|-------|-------------|
-| God Component/Function | Does too many things — split by responsibility |
-| Duplicate Logic | Same pattern repeated — extract to shared utility |
-| Long Parameter Lists | >4 params — use options object |
-| Deep Nesting | >3 levels of if/else — flatten with early returns |
-| Magic Numbers/Strings | Unnamed constants — extract to named constants |
-| Dead Code | Unused variables, functions, imports — remove |
-| Inconsistent Naming | Mixed conventions — standardize |
-| Missing Types | `any`, missing return types — add precise types |
-| Large Files | >300 lines — consider splitting by concern |
-
----
-
-### Phase 3 — Plan the Refactor
-
-Create a step-by-step plan before touching code:
-
-1. List each specific change with its justification
-2. Order changes from lowest to highest risk
-3. Identify what tests must pass after each step
-4. Flag any changes that touch shared/exported code
-
-Present plan to user if scope is large or changes are risky.
-
----
-
-### Phase 4 — Execute Incrementally
-
-Apply changes in small, verifiable steps:
-
-**Safe refactor order:**
-1. Rename (lowest risk — IDEs can do this safely)
-2. Extract (pull logic into new functions/hooks without changing callers)
-3. Inline (remove unnecessary abstraction)
-4. Move (relocate to correct file/folder)
-5. Simplify (reduce complexity in logic)
-6. Remove (delete dead code last — confirm nothing breaks)
-
-After **each step** → verify tests still pass before moving on.
-
----
-
-### Phase 5 — Verify Behavior Preserved
-
-- [ ] All existing tests pass
-- [ ] Run lint and type-check — clean
-- [ ] Manual smoke test of affected functionality
-- [ ] No new `any` types introduced
-- [ ] No unused imports or dead code left
-- [ ] Public API unchanged (or explicitly approved to change)
-
----
-
-### Phase 6 — Report
-
-Document what changed and why:
-
-```
-What changed:   [List of changes]
-Why:            [Specific smell or issue addressed]
-Risk level:     [Low / Medium / High]
-Tests status:   [All pass / N new tests added]
-Behavior:       [Unchanged — verified]
-```
-
----
-
-## Decision Tree
-
-```
-Is there existing test coverage?
-  ├── Yes → Proceed — tests are the safety net
-  └── No  → Recommend characterization tests first
-              ├── User agrees → write tests then refactor
-              └── User wants to proceed anyway → proceed with caution, document risk
-
-Does the refactor change public APIs?
-  ├── Yes → Stop — confirm with user, this may be a breaking change
-  └── No  → Proceed
-
-Is the scope larger than expected?
-  ├── Yes → Present updated plan, get approval before continuing
-  └── No  → Continue
-```
-
----
-
-## Output Format
-
-```
-🔧 Refactor Summary
-─────────────────────────────────────────────────
-Scope:        [What was refactored]
-Changes:      [N files modified, N extracted, N removed]
-
-Changes applied:
-  ✅ [Rename: oldName → newName in path/to/file.ts]
-  ✅ [Extract: logic → useCustomHook in path/to/hook.ts]
-  ✅ [Remove: dead code in path/to/old.ts]
-  ✅ [Split: LargeComponent → ComponentA + ComponentB]
-
-📊 Quality improvement:
-  Before: [brief description of the problem]
-  After:  [brief description of improvement]
-
-✅ Verification:
-  Tests:     PASS (N tests)
-  Lint:      Clean
-  Types:     No new `any`
-  Behavior:  Unchanged
-
-⚠️  Notes:
-  [Any assumptions, risks, or follow-up suggestions]
-```
-
----
-
-## Validation Checklist
-
-- [ ] Behavior is unchanged — verified with tests or manual check
-- [ ] All tests pass
-- [ ] Lint and type-check clean
-- [ ] No dead code, unused imports, or console.logs left
-- [ ] Public APIs unchanged (or explicitly approved)
-- [ ] Changes are documented with justification
-- [ ] No new dependencies introduced
-
----
-
-## Examples
-
-See `examples/` folder.
-

package/skills/_archive_old_skills/qk-state-management/SKILL.md

@@ -1,140 +0,0 @@
----
-name: qk-state-management
-description: >-
-  Xác định và triển khai chiến lược quản lý state phù hợp (Zustand, Redux, React Query, Local State).
-version: 1.0.0
-category: frontend
-tags: [state, redux, zustand, react-query, context, pinia, data-flow]
-platforms: [antigravity, claude-code, kilo-code, cursor, windsurf]
----
-
-# State Management
-
-> **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 "store this data", "share state between components", or "cache API results"
-- Prop drilling becomes excessive (>3 levels deep)
-- Integrating complex UI interactions that need memory (e.g., shopping cart, multi-step wizard)
-- Managing async server data and loading/error states
-
----
-
-## Scope
-
-- ✅ Decide which state layer to use based on the data's lifecycle and scope
-- ✅ Implement local state (`useState`, `useReducer`, `ref`)
-- ✅ Implement global UI state (Zustand, Pinia, Context, Redux)
-- ✅ Implement server state (React Query, SWR, Apollo)
-- ✅ Ensure state is immutable and updates correctly
-- ✅ Prevent race conditions and stale state bugs
-
----
-
-## Non-goals
-
-- ❌ Do NOT introduce a new state management library if the project already uses one
-- ❌ Do NOT put server data (API responses) in a global UI store (like Redux) if React Query is available
-- ❌ Do NOT use global state for something that should be local (e.g., a modal's `isOpen` state)
-
----
-
-## Workflow
-
-### Phase 1 — State Classification
-
-Analyze the data the user wants to manage and classify it:
-
-1. **Local UI State:** Only needed by one component (e.g., toggle button, input value).
-2. **Shared UI State:** Needed by multiple components, but not saved to DB (e.g., dark mode, cart items, selected filters).
-3. **Server State:** Data fetched from an API. Needs caching, refetching, and loading states.
-4. **URL State:** Data that should be shareable or survive refresh (e.g., search query `?q=shoes`, current page).
-
----
-
-### Phase 2 — Strategy Selection
-
-Based on the classification and project stack (`project-audit`), choose the tool:
-
-| State Type | Recommended Tool |
-|------------|------------------|
-| Local UI | `useState`, `useReducer` |
-| Shared UI | Zustand, Pinia, Redux, Context API |
-| Server | React Query, RTK Query, Apollo, SWR |
-| URL | React Router `useSearchParams`, Next.js `useRouter` |
-
-**Rule:** Always respect existing project conventions. If they use Redux for everything, use Redux.
-
----
-
-### Phase 3 — Implementation
-
-Generate the required code.
-
-**Example for Server State (React Query):**
-- Create query key factory
-- Create custom hook (`useUserList`)
-- Handle `isLoading`, `isError`, and `data`
-
-**Example for Global UI State (Zustand):**
-- Create store file (`userStore.ts`)
-- Define state interface and initial values
-- Define update actions (mutations)
-
----
-
-### Phase 4 — Validation
-
-- [ ] Does it update correctly without mutating state directly?
-- [ ] Are unnecessary re-renders avoided?
-- [ ] Is server state properly cached and invalidated after mutations?
-- [ ] Is it placed in the correct directory (e.g., `src/store/` or `src/hooks/`)?
-
----
-
-## Decision Tree
-
-```
-Is the data fetched from a backend API?
-  ├── Yes → Use Server State (React Query / SWR / RTK Query)
-  └── No  → Is the data only needed in one component and its direct children?
-              ├── Yes → Use Local State (`useState`)
-              └── No  → Is the data used across many distinct branches of the app?
-                          ├── Yes → Use Global State (Zustand / Redux)
-                          └── No  → Use Context API or lift state up
-```
-
----
-
-## Output Format
-
-```
-🧠 State Management Plan
-─────────────────────────────────────────────────
-State Type: [Server / Global UI / Local / URL]
-Tool Used:  [React Query / Zustand / useState / etc.]
-
-Implementation:
-  ✅ [File 1] — [Store / Hook definition]
-  ✅ [File 2] — [Component integration]
-
-⚠️ Considerations:
-  • [Note on caching, stale time, or performance]
-
-🔗 Next Steps:
-  State is ready. Use the hook in your component.
-```
-
----
-
-## Examples
-
-See `examples/` folder.
-