ai-developer-skill-os 7.5.0 → 8.1.4

package/skills/_archive_old_skills/qk-context-manager/SKILL.md

@@ -1,175 +0,0 @@
----
-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/skills/_archive_old_skills/qk-database-engineer/SKILL.md

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

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

@@ -1,96 +0,0 @@
----
-name: qk-deployment
-description: >-
-  Cấu hình CI/CD pipelines, tạo Dockerfile và thiết lập môi trường để deploy lên Vercel, AWS hoặc VPS.
-version: 1.0.0
-category: backend
-tags: [deploy, ci-cd, docker, github-actions, devops, hosting]
-platforms: [antigravity, claude-code, kilo-code, cursor, windsurf]
----
-
-# Deployment & DevOps
-
-> **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 "how do I deploy this?", "create a Dockerfile", or "setup CI/CD"
-- Configuring GitHub Actions, GitLab CI, or Jenkins
-- Preparing a project for Vercel, Netlify, Render, or AWS
-- Setting up environment variables for production
-
----
-
-## Scope
-
-- ✅ **Containerization:** Write `Dockerfile` and `docker-compose.yml`.
-- ✅ **CI/CD Pipelines:** Write GitHub Actions YAML for testing, building, and deploying.
-- ✅ **Environment Setup:** Create `.env.example` and document required production variables.
-- ✅ **Build Scripts:** Ensure `package.json` has correct build and start commands.
-
----
-
-## Non-goals
-
-- ❌ Do NOT expose real production secrets. Always use placeholders or CI secrets.
-- ❌ Do NOT over-complicate (e.g., don't setup Kubernetes if a simple Docker container on a VPS is enough).
-
----
-
-## Workflow
-
-### Phase 1 — Platform Selection
-
-Ask the user where they are deploying (if not specified):
-1. **PaaS (Vercel, Render, Heroku):** Very easy, mostly relies on `vercel.json` or standard build scripts. No Docker needed usually.
-2. **VPS/VM (DigitalOcean, AWS EC2):** Needs Docker and/or PM2 + Nginx reverse proxy.
-3. **Container Service (AWS ECS, Google Cloud Run):** Needs a highly optimized Dockerfile.
-
-### Phase 2 — Containerization (If required)
-
-Create a multi-stage Dockerfile for minimal image size:
-1. `deps` stage: Install dependencies.
-2. `builder` stage: Build the app.
-3. `runner` stage: Copy only the built assets and prod modules, start the app.
-
-### Phase 3 — CI/CD Pipeline
-
-Create `.github/workflows/deploy.yml`:
-- Trigger on `push` to `main`.
-- Job 1: Setup Node/Python/Go, install deps, run tests, run linter.
-- Job 2: Build image and push to registry, or deploy to PaaS.
-
-### Phase 4 — Environment Variables
-
-Audit the codebase for `process.env.XYZ` and create a `.env.example` file listing every required variable.
-
----
-
-## Output Format
-
-```
-🚀 Deployment Plan
-─────────────────────────────────────────────────
-Target:     [Vercel / Docker VPS / AWS]
-Tooling:    [GitHub Actions, Docker]
-
-Files Created/Modified:
-  ✅ `Dockerfile` (Multi-stage build)
-  ✅ `.github/workflows/deploy.yml`
-  ✅ `.env.example`
-
-⚠️ Prerequisites:
-  Before deploying, you must set these secrets in GitHub Actions:
-  - `DOCKER_USERNAME`
-  - `DATABASE_URL`
-
-🔗 Next Steps:
-  Commit these files and push to `main` to trigger the pipeline.
-```
-

package/skills/_archive_old_skills/qk-design-system/SKILL.md

@@ -1,137 +0,0 @@
----
-name: qk-design-system
-description: >-
-  Ép buộc sử dụng design system, component library và token hiện có, ngăn chặn việc viết HTML/CSS rác.
-version: 1.0.0
-category: frontend
-tags: [design-system, ui-components, styling, tailwind, material-ui, shadcn]
-platforms: [antigravity, claude-code, kilo-code, cursor, windsurf]
----
-
-# Design System Enforcer
-
-> **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:
-- About to build UI screens or components
-- Styling or layout work is required
-- User asks to "make it look good" or "match the design"
-- Integrating a third-party UI library (Tailwind, MUI, AntD, Shadcn)
-
----
-
-## Scope
-
-- ✅ Identify the UI library or design system in use
-- ✅ Map standard HTML elements to project-specific components (e.g., `<button>` → `<Button>`)
-- ✅ Enforce usage of design tokens (colors, spacing, typography) instead of hardcoded values
-- ✅ Provide available component variants and props to downstream skills (`ui-builder`)
-- ✅ Prevent generation of raw CSS/inline styles if utility classes or styled-components are standard
-
----
-
-## Non-goals
-
-- ❌ Do NOT create new base components if an equivalent already exists
-- ❌ Do NOT introduce a new styling method (e.g., don't add Tailwind if project uses CSS Modules)
-- ❌ Do NOT design full pages (delegate to `ui-builder`)
-
----
-
-## Workflow
-
-### Phase 1 — Detect Design System
-
-Analyze dependencies and project files to identify:
-1. **Component Library:** Shadcn UI, MUI, Ant Design, Chakra, Bootstrap, custom internal library?
-2. **Styling Method:** Tailwind CSS, CSS Modules, Styled Components, Emotion, SCSS, Vanilla CSS?
-3. **Location of Shared Components:** Usually `src/components/ui/`, `src/shared/components/`, or from an npm package.
-4. **Design Tokens:** `tailwind.config.js`, `theme.ts`, `variables.scss`.
-
----
-
-### Phase 2 — Component Mapping
-
-Before `ui-builder` generates code, create a mapping table for required elements:
-
-| Standard Element | Project Component | Source / Import Path |
-|------------------|-------------------|----------------------|
-| `<button>` | `<Button>` | `@/components/ui/button` |
-| `<input type="text">` | `<Input>` | `@/components/ui/input` |
-| `<div>` (Card) | `<Card>` | `@/components/ui/card` |
-| `<h1>` | `<Typography variant="h1">` | `@mui/material` |
-
----
-
-### Phase 3 — Token Extraction
-
-Identify available tokens for spacing, colors, and typography to avoid hardcoding:
-- *Instead of:* `margin-top: 16px; color: #3b82f6;`
-- *Use:* `mt-4 text-blue-500` (Tailwind) or `theme.spacing(2)` (MUI) or `var(--primary-color)`.
-
----
-
-### Phase 4 — Rule Enforcement
-
-Pass strict instructions to `ui-builder` or `component-generator`:
-- "You MUST use `<Button>` instead of `<button>`."
-- "You MUST use Tailwind classes for all styling. No inline `style={{}}` allowed."
-
----
-
-## Decision Tree
-
-```
-Does the project use a component library (e.g., Shadcn, MUI)?
-  ├── Yes → Is the required component available?
-  │           ├── Yes → Require its use
-  │           └── No  → Instruct `component-generator` to create it following library style
-  └── No  → Check if custom shared components exist
-              ├── Yes → Map to custom shared components
-              └── No  → Use raw HTML but enforce project's styling method (e.g., Tailwind)
-
-Does the project use utility classes (Tailwind)?
-  ├── Yes → Forbid inline styles or custom CSS files
-  └── No  → Enforce existing CSS Modules / Styled Components patterns
-```
-
----
-
-## Output Format
-
-```
-🎨 Design System Rules
-─────────────────────────────────────────────────
-Library:        [Shadcn / MUI / Tailwind / Custom / etc.]
-Styling Method: [Tailwind / CSS Modules / Styled Components]
-
-Component Mapping for this task:
-  ✅ Button  → `<Button>` from `@/components/ui/button`
-  ✅ Input   → `<Input>` from `@/components/ui/input`
-  ✅ Layout  → Flexbox with Tailwind (`flex flex-col gap-4`)
-
-Styling Rules Enforced:
-  • No raw HTML `<button>` allowed
-  • No inline styles allowed
-  • Use primary color token for CTAs
-
-🔗 Next Steps:
-  Passing these rules to `ui-builder` to generate the UI.
-```
-
----
-
-## Validation Checklist
-
-- [ ] Design system and styling method correctly identified
-- [ ] Mappings created for all necessary UI elements
-- [ ] Design tokens (spacing/colors) prioritized over hardcoded values
-- [ ] Strict enforcement rules passed to next skill
-

package/skills/_archive_old_skills/qk-form-builder/SKILL.md

@@ -1,140 +0,0 @@
----
-name: qk-form-builder
-description: >-
-  Xây dựng Form chuẩn xác với quản lý trạng thái, validate dữ liệu (Zod, Yup) và xử lý hiển thị lỗi.
-version: 1.0.0
-category: frontend
-tags: [form, validation, react-hook-form, zod, yup, formik]
-platforms: [antigravity, claude-code, kilo-code, cursor, windsurf]
----
-
-# Form Builder
-
-> **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 login form", "add a settings page", "build a contact form"
-- User provides a data model and needs a UI to create/edit it
-- A form needs complex validation logic added
-- Refactoring a messy form into a structured library pattern (e.g., React Hook Form)
-
----
-
-## Scope
-
-- ✅ Define the form data schema and validation rules
-- ✅ Manage form state efficiently (preventing unnecessary re-renders)
-- ✅ Map form fields to the project's design system components
-- ✅ Handle submission state (loading, success, error)
-- ✅ Handle validation errors and display them accessibly
-- ✅ Integrate with `api-integration` for submission
-
----
-
-## Non-goals
-
-- ❌ Do NOT reinvent form state management if a library is present
-- ❌ Do NOT use raw HTML inputs if design system components exist
-- ❌ Do NOT skip validation (client-side validation is required)
-
----
-
-## Workflow
-
-### Phase 1 — Schema Design
-
-Define the exact shape of the data the form collects.
-Determine validation rules for each field (required, min length, email format, etc.).
-
-If the project uses Zod, Yup, or Joi, define the schema first.
-*Example:*
-```typescript
-const userFormSchema = z.object({
-  email: z.string().email("Invalid email address"),
-  password: z.string().min(8, "Password must be at least 8 characters"),
-});
-```
-
----
-
-### Phase 2 — State Management Selection
-
-Check project dependencies for form libraries:
-1. `react-hook-form` (Preferred for React)
-2. `formik`
-3. Custom Vue/Svelte bindings
-4. Standard controlled components (`useState`) if no library exists and form is simple.
-
----
-
-### Phase 3 — Component Assembly
-
-1. Set up the form wrapper and submission handler.
-2. For each field in the schema, render the appropriate UI component (from `design-system`).
-3. Connect the UI component to the form state (register / Controller).
-4. Render error messages below fields if validation fails.
-
----
-
-### Phase 4 — Submission & Integration
-
-- Add `isLoading` state to the submit button.
-- Disable submit button during submission.
-- On success: Show success message or redirect, and optionally reset form.
-- On error: Display backend error messages (toast or form-level alert).
-
----
-
-## Decision Tree
-
-```
-Does the project use a validation library (Zod, Yup)?
-  ├── Yes → Use it to define schema and pass to form resolver
-  └── No  → Implement standard HTML5 validation or simple manual validation logic
-
-Is it a complex multi-step form (wizard)?
-  ├── Yes → Break into sub-components, use global or lifted state for form data
-  └── No  → Handle state locally within the single form component
-```
-
----
-
-## Output Format
-
-```
-📝 Form Built
-─────────────────────────────────────────────────
-Name:     [FormName]
-Schema:   [Zod / Yup / Manual]
-Library:  [React Hook Form / Formik / Native]
-
-Fields Implemented:
-  ✅ email (string, required, email)
-  ✅ password (string, required, min: 8)
-
-Integration:
-  - Validation: Client-side wired up
-  - Submission: Wired to `[submitFunction]`
-  - Loading UI: Handled on submit button
-
-🔗 Next Steps:
-  Make sure the API endpoint is ready to accept this payload.
-```
-
----
-
-## Validation Checklist
-
-- [ ] Form uses existing design system components (Inputs, Buttons)
-- [ ] Client-side validation is implemented
-- [ ] Error messages are displayed properly
-- [ ] Loading state disables the submit button
-- [ ] Accessibility: Inputs have associated labels and error ARIA attributes
-