ai-developer-skill-os 7.0.2 → 7.5.0

package/.qk-ai-skill-os/skills/_archive_old_skills/qk-bug-fix/SKILL.md

@@ -0,0 +1,213 @@
+---
+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/.qk-ai-skill-os/skills/_archive_old_skills/qk-component-generator/SKILL.md

@@ -0,0 +1,136 @@
+---
+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.
+

package/.qk-ai-skill-os/skills/_archive_old_skills/qk-context-manager/SKILL.md

@@ -0,0 +1,175 @@
+---
+name: qk-context-manager
+description: >-
+  Xác định các file cần thiết, tóm tắt kiến trúc và quản lý bộ nhớ ngữ cảnh để tránh tràn bộ nhớ.
+version: 1.0.0
+category: engineering
+tags: [context, architecture, memory, file-selection, summarization]
+platforms: [antigravity, claude-code, kilo-code, cursor, windsurf]
+---
+
+# Context Manager
+
+> **Language rule:**
+> Use **English** for: file paths, architecture terms, module names, technical labels.
+> Use **the user's language** for: explanations, summaries, and questions.
+
+---
+
+## Trigger
+
+Activate this skill when:
+- Starting work on an unfamiliar or large codebase
+- About to read many files and need to prioritize
+- Context window is at risk of overflowing
+- User asks "where is X", "what does Y do", "how is this project structured"
+- Another skill (e.g. `project-audit`, `frontend-architecture`) needs project context first
+
+---
+
+## Scope
+
+- ✅ Identify which files are relevant to the current task
+- ✅ Summarize project architecture in structured format
+- ✅ Map folder structure to responsibilities
+- ✅ Track what has been read and what still needs reading
+- ✅ Flag context window risks
+- ✅ Maintain a working memory summary for multi-turn sessions
+
+---
+
+## Non-goals
+
+- ❌ Do NOT modify any files
+- ❌ Do NOT fix bugs
+- ❌ Do NOT make architectural decisions
+- ❌ Do NOT read every file blindly — be selective and efficient
+
+---
+
+## Workflow
+
+### Phase 1 — Project Discovery
+
+Read only top-level signals first:
+1. `package.json` / `pyproject.toml` / `Cargo.toml` → detect framework, language, scripts
+2. Root config files → `.env.example`, `tsconfig.json`, `vite.config.ts`, `next.config.js`
+3. Folder structure (1-2 levels deep) → identify key directories
+4. Entry points → `src/index.ts`, `app/`, `pages/`, `main.py`
+
+Produce: **Project Profile** (framework, language, key directories, architecture style)
+
+---
+
+### Phase 2 — Task-Scoped File Selection
+
+Given the current task, identify the minimum relevant set of files:
+
+```
+Task type → Files to read
+─────────────────────────────────────────────────────
+UI work         → components/, pages/, styles/, design system files
+API work        → services/, hooks/, api/, types/
+State work      → store/, context/, hooks/
+Bug fix         → files mentioned in error, related modules
+Architecture    → folder structure, key abstractions
+```
+
+Rules:
+- Read **entry points** before diving into details
+- Prefer **index files** as anchors
+- Skip `node_modules`, `dist`, `build`, `.git`
+- If uncertain which file → check imports, not the file itself
+
+---
+
+### Phase 3 — Architecture Summary
+
+Produce a concise summary:
+
+```
+Project:    [Name / repo]
+Framework:  [React 18 / Next.js 14 / Vue 3 / etc.]
+Language:   [TypeScript / JavaScript / Python]
+Structure:  [Feature-based / Layer-based / Domain-based]
+
+Key directories:
+  src/components/  → Shared UI components
+  src/features/    → Feature modules (collocated)
+  src/services/    → API and data services
+  src/hooks/       → Custom React hooks
+  src/types/       → TypeScript interfaces
+
+State:       [Zustand / Redux / React Query / Pinia]
+HTTP client: [axios instance at src/lib/axios.ts]
+Auth:        [JWT stored in httpOnly cookie]
+```
+
+---
+
+### Phase 4 — Working Memory Maintenance
+
+During multi-turn sessions:
+- Track which files have been read (avoid re-reading)
+- Track decisions made (e.g. "we decided to use feature-based structure")
+- Flag when context is approaching limits
+- Offer to summarize and compress if needed
+
+---
+
+## Decision Tree
+
+```
+Is this a new project / first time seeing this codebase?
+  ├── Yes → Run full Phase 1 + Phase 2 + Phase 3
+  └── No  → Has something changed since last context load?
+              ├── Yes → Re-run Phase 2 for affected area
+              └── No  → Use cached architecture summary
+```
+
+```
+Is context window at risk?
+  ├── Yes → Summarize what's been read, drop low-relevance files
+  └── No  → Continue loading relevant files
+```
+
+---
+
+## Output Format
+
+```
+🗂️  Project Context Loaded
+
+Framework:  [framework]
+Language:   [language]
+Structure:  [style]
+
+Relevant files for this task:
+  📄 [path/to/file.ts]     — [why it's relevant]
+  📄 [path/to/file.ts]     — [why it's relevant]
+
+Architecture summary:
+  [2-4 lines describing how this codebase is organized]
+
+⚠️  Context notes:
+  [Any risks, unknowns, or files that couldn't be read]
+
+✅ Ready. Proceeding with: [next skill or action]
+```
+
+---
+
+## Validation Checklist
+
+- [ ] Framework and language correctly identified
+- [ ] Only task-relevant files selected (no noise)
+- [ ] Architecture summary is accurate and concise
+- [ ] Context window usage is reasonable
+- [ ] Working memory updated for this session
+
+---
+
+## Examples
+
+See `examples/` folder.
+

package/.qk-ai-skill-os/skills/_archive_old_skills/qk-database-engineer/SKILL.md

@@ -0,0 +1,104 @@
+---
+name: qk-database-engineer
+description: >-
+  Thiết kế database schema, viết script migration và tối ưu truy vấn cho SQL/NoSQL bằng ORM (Prisma, Drizzle...).
+version: 1.0.0
+category: backend
+tags: [database, sql, prisma, drizzle, schema, migration, query-optimization]
+platforms: [antigravity, claude-code, kilo-code, cursor, windsurf]
+---
+
+# Database 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 says "create a new table", "add a column", "design the schema"
+- Writing complex data retrieval logic (joins, aggregations)
+- A query is running slowly and needs optimization (indexing)
+- Running or generating database migrations
+
+---
+
+## Scope
+
+- ✅ **Schema Design:** Model tables, relations (1:1, 1:N, N:M), and constraints (Unique, FK).
+- ✅ **ORM Integration:** Generate code for Prisma, Drizzle, TypeORM, Sequelize, or Mongoose.
+- ✅ **Migrations:** Generate SQL or ORM migration files safely.
+- ✅ **Query Optimization:** Prevent N+1 queries, add indexes, use efficient aggregations.
+
+---
+
+## Non-goals
+
+- ❌ Do NOT execute destructive migrations (DROP TABLE) on production environments without extreme warnings and approval.
+- ❌ Do NOT mix raw SQL into ORM logic unless necessary for performance.
+
+---
+
+## Workflow
+
+### Phase 1 — Schema Design
+
+Understand the business entities and relations.
+- Identify primary keys (UUID vs Auto-increment ID).
+- Identify foreign keys and cascade rules (`ON DELETE CASCADE`).
+- Ensure proper normalization (usually 3NF) or denormalization (if NoSQL).
+
+### Phase 2 — ORM / Migration Generation
+
+Map the design to the project's tool:
+- **Prisma:** Update `schema.prisma`.
+- **Drizzle:** Update `schema.ts`.
+- **Raw SQL:** Write `V1__create_table.sql`.
+
+### Phase 3 — Query Implementation
+
+Write the data access methods (Repository pattern or direct ORM calls).
+- Avoid fetching `SELECT *` if only 2 columns are needed.
+- Batch queries or use joins to prevent N+1 issues.
+
+---
+
+## Decision Tree
+
+```
+Is the project using an ORM?
+  ├── Prisma  → Modify `schema.prisma`, use `prisma.entity.findMany()`
+  ├── Drizzle → Modify schema TS files, use Drizzle query builder
+  └── No      → Write raw SQL or use query builder (Knex)
+
+Does the schema change drop data or alter existing columns?
+  ├── Yes → Flag as High Risk. Provide rollback strategy. Ask for approval.
+  └── No  → Standard migration (e.g., adding a nullable column).
+```
+
+---
+
+## Output Format
+
+```
+🗄️ Database Engineering Report
+─────────────────────────────────────────────────
+Action:     [Schema Update / Query Optimization]
+Tooling:    [Prisma / Raw SQL / etc.]
+
+Changes:
+  ✅ Added model: `User` (1:N with `Post`)
+  ✅ Added index on `User.email`
+  ✅ Generated query: `getUserWithPosts`
+
+⚠️ Risk Assessment:
+  [Low / High — e.g., "Safe addition, no data loss"]
+
+🔗 Next Steps:
+  Run `npx prisma migrate dev` to apply these changes locally.
+```
+