ai-developer-skill-os 7.5.0 → 8.1.4

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

@@ -1,121 +0,0 @@
----
-name: qk-accessibility-audit
-description: >-
-  Kiểm tra và sửa lỗi khả năng tiếp cận (a11y/WCAG). Đảm bảo hỗ trợ phím, screen reader và semantic HTML.
-version: 1.0.0
-category: frontend
-tags: [accessibility, a11y, aria, wcag, screen-reader, keyboard]
-platforms: [antigravity, claude-code, kilo-code, cursor, windsurf]
----
-
-# Accessibility (A11y) 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.
-
----
-
-## Trigger
-
-Activate this skill when:
-- User asks to "make this accessible", "fix a11y", or "audit accessibility"
-- Building complex interactive components (modals, dropdowns, tabs, sliders)
-- Preparing an app for production or public release
-- Project audit flags missing semantic HTML or ARIA issues
-
----
-
-## Scope
-
-- ✅ **Keyboard Navigation:** Ensure all interactive elements are reachable via `Tab`, and operable via `Enter`/`Space`/Arrows. Focus management (trapping focus in modals).
-- ✅ **Screen Reader Support:** Add proper `aria-` attributes, `alt` text, and visually hidden text (`sr-only`).
-- ✅ **Semantic HTML:** Replace `div` soups with `<nav>`, `<main>`, `<article>`, `<button>`, etc.
-- ✅ **Color Contrast:** Verify text vs. background contrast meets WCAG AA (4.5:1 for normal text).
-- ✅ **Form Labels:** Ensure all inputs have associated `<label>`s or `aria-label`s.
-
----
-
-## Non-goals
-
-- ❌ Do NOT completely redesign the UI visually (unless fixing a severe contrast issue, and even then, ask first).
-- ❌ Do NOT overuse ARIA. The first rule of ARIA is: "No ARIA is better than bad ARIA." Use semantic HTML first.
-
----
-
-## Workflow
-
-### Phase 1 — Semantic HTML Check
-
-Scan the component for basic HTML semantics:
-- Are buttons actually `<button>` elements (not `<div onClick>`)?
-- Are links actually `<a>` elements with `href`s?
-- Do images have meaningful `alt` text (or `alt=""` if decorative)?
-- Are headings (`h1`-`h6`) in a logical, unbroken hierarchy?
-
-### Phase 2 — Keyboard & Focus Management
-
-- Can the user tab through the component logically?
-- Does every interactive element have a visible focus state (`:focus-visible`)?
-- For Modals/Dialogs: Is focus trapped inside when open? Is focus restored when closed?
-- For custom widgets (Tabs/Dropdowns): Implement correct arrow key navigation per WAI-ARIA authoring practices.
-
-### Phase 3 — Screen Reader (ARIA) Check
-
-- Do custom interactive elements have correct `role`s (e.g., `role="tablist"`)?
-- Is dynamic state communicated? (`aria-expanded`, `aria-selected`, `aria-invalid`, `aria-busy`).
-- Are icon-only buttons properly labeled? (`aria-label` or `<span className="sr-only">Label</span>`).
-- Are dynamic live regions used for important announcements (`aria-live="polite"` or `assertive`)?
-
-### Phase 4 — Contrast & Visuals
-
-- Check text colors against backgrounds.
-- Ensure form fields have visible borders or indicators.
-- Ensure information is not conveyed *only* by color (e.g., a red border for an error must also have error text).
-
----
-
-## Decision Tree
-
-```
-Is the component a native HTML element (e.g., standard `<button>`)?
-  ├── Yes → Ensure it has accessible text/labels. No ARIA roles needed.
-  └── No  → (e.g., a custom `div` acting as a checkbox)
-              ├── Can it be refactored to use native HTML?
-              │     ├── Yes → Refactor to native HTML `<input type="checkbox">`
-              │     └── No  → Apply `role="checkbox"`, `tabIndex={0}`, `aria-checked`, and keyboard event handlers.
-```
-
----
-
-## Output Format
-
-```
-♿ Accessibility Audit Report
-─────────────────────────────────────────────────
-Component:  [ComponentName]
-
-Issues Found & Fixed:
-  ✅ Semantic HTML: Replaced `<div onClick>` with `<button>`
-  ✅ Screen Readers: Added `aria-label` to icon-only close button
-  ✅ Keyboard: Added focus trap inside the Modal
-  ✅ Forms: Associated `<label htmlFor="email">` with Input
-
-⚠️ Remaining Warnings (Manual Check Required):
-  - Please verify color contrast of primary button in light mode (needs 4.5:1 ratio).
-
-🔗 Next Steps:
-  Code updated. Recommend testing with a screen reader (VoiceOver/NVDA).
-```
-
----
-
-## Validation Checklist
-
-- [ ] Semantic HTML preferred over ARIA
-- [ ] Keyboard navigation (Tab + Enter/Space) works correctly
-- [ ] Focus is visible on all interactive elements
-- [ ] Forms have proper labels
-- [ ] Icon-only buttons have accessible names
-

package/skills/_archive_old_skills/qk-agent-orchestrator/SKILL.md

@@ -1,179 +0,0 @@
----
-name: qk-agent-orchestrator
-description: >-
-  Phân tích yêu cầu, lên kế hoạch thực thi chi tiết và điều phối các tác vụ cho đúng skill. Không tự viết code.
-version: 1.0.0
-category: engineering
-tags: [orchestration, planning, workflow, task-decomposition]
-platforms: [antigravity, claude-code, kilo-code, cursor, windsurf]
----
-
-# Agent Orchestrator
-
-> **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 CONSTRAINT: This skill MUST NOT write any code.**
-> Its only job is to analyze, plan, and delegate.
-> If the orchestrator starts writing implementation code — it is violating its role.
-> Immediately stop and delegate to the appropriate skill instead.
-
----
-
-## Trigger
-
-Activate this skill when:
-- User describes a task without knowing where to start
-- User request spans multiple concerns (UI + API + state + tests)
-- Request is ambiguous and needs decomposition before action
-- User says: "help me plan", "what should I do first", "how do I approach this"
-
----
-
-## Scope
-
-- ✅ Analyze the user's request
-- ✅ Identify which skills are needed
-- ✅ Define the correct execution order
-- ✅ Create a step-by-step plan
-- ✅ Delegate each step to the correct skill
-- ✅ Track overall progress
-
----
-
-## Non-goals
-
-- ❌ Do NOT write implementation code
-- ❌ Do NOT modify files
-- ❌ Do NOT fix bugs directly (delegate to `bug-fix`)
-- ❌ Do NOT build UI directly (delegate to `ui-builder`)
-- ❌ Do NOT make architectural decisions unilaterally (delegate to `frontend-architecture`)
-
----
-
-## Workflow
-
-### Phase 1 — Request Analysis
-
-Parse the user's request:
-
-1. **What** is being asked? (feature, fix, refactor, review, deploy?)
-2. **Where** does it belong? (frontend, backend, shared, infrastructure?)
-3. **What is the scope?** (single component, full feature, entire codebase?)
-4. **What is unknown?** List any ambiguities that need clarification.
-
-If critical information is missing → ask before planning.
-
----
-
-### Phase 2 — Skill Selection
-
-Map the request to skills from the registry:
-
-| Request type | Recommended skill(s) |
-|---|---|
-| "I don't know what's wrong" | `project-audit` → `bug-fix` |
-| "Build a new page" | `frontend-architecture` → `design-system` → `ui-builder` |
-| "Add API call" | `context-manager` → `api-integration` |
-| "App is slow" | `project-audit` → `frontend-performance` |
-| "Upgrade dependencies" | `migration` |
-| "Write tests" | `frontend-testing` |
-
-Always check dependencies from `skills.json` — load dependent skills first.
-
----
-
-### Phase 3 — Execution Plan
-
-Produce a numbered, ordered plan. Each step maps to one skill.
-
-Format:
-```
-Step 1: [skill-name] — [what it will do]
-Step 2: [skill-name] — [what it will do]
-Step 3: [skill-name] — [what it will do]
-```
-
-Mark dependencies explicitly:
-```
-Step 2 requires Step 1 to complete first.
-```
-
----
-
-### Phase 4 — Delegation
-
-For each step in the plan:
-1. Announce which skill is being activated
-2. Pass relevant context to that skill
-3. Wait for skill output
-4. Confirm completion before moving to next step
-
----
-
-### Phase 5 — Progress Tracking
-
-After each skill completes:
-- Mark step as ✅ done
-- Note any output or blockers
-- Adjust remaining plan if needed
-- Report overall progress to user
-
----
-
-## Decision Tree
-
-```
-Is the request clear enough to plan?
-  ├── No  → Ask 1-3 clarifying questions, then plan
-  └── Yes → Does it span multiple concerns?
-              ├── Yes → Create multi-step plan with skill sequence
-              └── No  → Route directly to single skill
-```
-
-```
-Does a skill dependency exist?
-  ├── Yes → Run dependency skill first
-  └── No  → Run skill directly
-```
-
----
-
-## Output Format
-
-```
-📋 Plan: [Brief description of what we're doing]
-
-Step 1: `[skill-name]` — [Purpose]
-Step 2: `[skill-name]` — [Purpose]  ← requires Step 1
-Step 3: `[skill-name]` — [Purpose]
-
-⏳ Starting with Step 1...
-```
-
-After each step:
-```
-✅ Step 1 complete: [Brief outcome]
-▶️  Moving to Step 2: `[skill-name]`
-```
-
----
-
-## Validation Checklist
-
-Before finishing orchestration:
-
-- [ ] All planned steps completed
-- [ ] Each step was handled by the correct skill
-- [ ] No code was written by the orchestrator itself
-- [ ] User has been informed of final outcome
-- [ ] Next recommended actions provided if relevant
-
----
-
-## Examples
-
-See `examples/` folder.
-

package/skills/_archive_old_skills/qk-api-integration/SKILL.md

@@ -1,389 +0,0 @@
----
-name: qk-api-integration
-description: >-
-  Chuyển đổi tài liệu API (curl, swagger...) thành code tích hợp frontend chuẩn xác, có type an toàn và xử lý lỗi.
-version: 2.0.0
-category: engineering
-tags: [api, integration, rest, graphql, axios, fetch, react-query, typescript]
-platforms: [antigravity, claude-code, kilo-code, cursor, windsurf]
----
-
-# API Integration 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 the user provides any of:
-- `curl` command
-- Swagger 2.0 / OpenAPI 3.0 (YAML or JSON)
-- Postman collection or HAR file
-- API documentation (endpoint, method, request/response)
-- Code snippet to reverse-engineer (fetch/axios/custom client)
-- Backend controller or route handler to mirror on the frontend
-
----
-
-## Scope
-
-- ✅ Parse and understand any API input format
-- ✅ Extract the full API contract (request + response + errors)
-- ✅ Detect existing project patterns (HTTP client, state layer, conventions)
-- ✅ Generate typed service/client, hooks/queries, and TypeScript types
-- ✅ Follow and extend existing architecture — never duplicate it
-- ✅ Handle special cases: file upload, file download, pagination, auth, WebSocket
-
----
-
-## Non-goals
-
-- ❌ Do NOT create a new HTTP client if one already exists
-- ❌ Do NOT introduce a new state system if one is already in use
-- ❌ Do NOT hardcode URLs, tokens, or secrets
-- ❌ Do NOT use `any` when types can be inferred
-- ❌ Do NOT overwrite existing files without explicit user approval
-
----
-
-## Severity Levels
-
-| Level | Meaning |
-|-------|---------|
-| P0 | Conflict with existing endpoint or type — must resolve before generating |
-| P1 | Missing critical info (auth, response schema) — ask before proceeding |
-| P2 | Naming or structure inconsistency — warn and apply best guess |
-| P3 | Missing optional fields — document assumption and proceed |
-
----
-
-## Workflow
-
-### Phase 1 — Input Validation
-
-Before parsing, verify:
-- URL is valid and method is correct (GET/POST/PUT/PATCH/DELETE)
-- Auth format is identifiable (Bearer, API Key, OAuth2, Basic, Cookie)
-- Request info is present (path params, query params, body)
-- Response structure is clear (JSON, binary, stream, paginated)
-- Error cases are documented
-
-If critical info is missing → **stop and ask**. Do not guess.
-
-```json
-{
-  "validation": {
-    "status": "VALID | INVALID | INCOMPLETE",
-    "confidence": 0.95,
-    "errors": [],
-    "warnings": [],
-    "input_type": "curl | openapi | postman | docs | code"
-  }
-}
-```
-
----
-
-### Phase 2 — API Contract Extraction
-
-Extract the full contract:
-
-```
-metadata:
-  name, domain, endpoint, method, version, description
-
-request:
-  pathParams:    { name, type, required }
-  queryParams:   { name, type, required, default }
-  headers:       { name, value, required }
-  body:          { contentType, schema { field, type, required, nullable } }
-  auth:          { type, location, name }
-
-response:
-  success:       { statusCode, contentType, schema, pagination? }
-  errors:        [ { statusCode, message, businessCode? } ]
-
-special:
-  rateLimit, timeout, retryable, streaming
-```
-
-Map each field: `type`, `required`, `nullable`, `enum`, `example`.
-
----
-
-### Phase 3 — Project Profile Detection
-
-1. Check for `.api-config.json` at project root → use if present
-2. Otherwise infer from:
-   - Framework: `package.json`, config files, imports
-   - HTTP client: existing axios instance, fetch wrapper, custom client
-   - State management: React Query, Redux, Zustand, Pinia, Apollo, Vuex
-   - Type system: `tsconfig.json`, JSDoc, plain JS
-   - Folder conventions: `services/`, `hooks/`, `api/`, `types/`, `adapters/`
-   - Naming: camelCase, PascalCase, snake_case, file patterns
-3. Read 1-2 existing API files to capture exact patterns for imports, typing, error handling, naming
-
-If project context is ambiguous → use conservative defaults and document all assumptions.
-
----
-
-### Phase 4 — Conflict Detection
-
-Before generating code, check for:
-
-| Conflict | Action |
-|----------|--------|
-| `ENDPOINT_DUPLICATE` — endpoint already exists | Reuse if same, warn if different |
-| `FUNCTION_DUPLICATE` — function name conflicts | Warn, propose new name |
-| `TYPE_DUPLICATE` — type already defined | Extend or reuse existing |
-| `LOGIC_OVERLAP` — logic exists in another service | Consolidate, don't duplicate |
-| `IMPORT_CONFLICT` — import path conflicts | Resolve before generating |
-
-**P0 conflict → stop, report, wait for user decision before proceeding.**
-
----
-
-### Phase 5 — Code Generation
-
-Generate the minimum necessary set for the task:
-
-#### TypeScript Types
-```typescript
-// Request types
-export interface CreateUserRequest {
-  name: string;
-  email: string;
-  role?: UserRole;
-}
-
-// Response types
-export interface CreateUserResponse {
-  id: string;
-  name: string;
-  email: string;
-  createdAt: string;
-}
-
-// Error types
-export interface ApiError {
-  code: string;
-  message: string;
-  details?: Record<string, unknown>;
-}
-```
-
-#### Service / API Layer
-```typescript
-// Thin layer: HTTP + mapping only. No UI, no business logic.
-export const createUser = async (
-  data: CreateUserRequest
-): Promise<CreateUserResponse> => {
-  const response = await apiClient.post<CreateUserResponse>('/users', data);
-  return response.data;
-};
-```
-
-#### Hook / Query (if project uses React Query)
-```typescript
-export const useCreateUser = () => {
-  return useMutation<CreateUserResponse, ApiError, CreateUserRequest>({
-    mutationFn: createUser,
-    onSuccess: () => {
-      queryClient.invalidateQueries({ queryKey: ['users'] });
-    },
-  });
-};
-```
-
-**If project uses Redux** → follow existing slice/thunk pattern.
-**If project uses Zustand** → follow existing store pattern.
-**If project uses Pinia/Vuex** → follow existing composable/action pattern.
-
-Do NOT mix patterns.
-
----
-
-### Phase 6 — Special Case Handling
-
-#### File Upload (`multipart/form-data`)
-```typescript
-// Always use FormData — never send File object in JSON
-const formData = new FormData();
-formData.append('file', file);
-formData.append('name', name);
-await apiClient.post('/upload', formData, {
-  headers: { 'Content-Type': 'multipart/form-data' },
-});
-```
-
-#### File Download (binary response)
-```typescript
-const response = await apiClient.get('/export', { responseType: 'blob' });
-const url = URL.createObjectURL(response.data);
-const a = document.createElement('a');
-a.href = url;
-a.download = filename;
-a.click();
-URL.revokeObjectURL(url);
-```
-
-#### Pagination
-```typescript
-interface PaginatedResponse<T> {
-  items: T[];
-  total: number;
-  page: number;
-  limit: number;
-}
-// Implement consistently with existing project pagination pattern
-```
-
-#### Authentication
-- Follow existing auth mechanism (interceptor, header injection, cookie)
-- Never hardcode tokens or credentials
-- Refresh token logic belongs in the existing interceptor
-
----
-
-### Phase 7 — Quality Validation
-
-Before marking as ready:
-
-- [ ] TypeScript strict — compiles clean, no `any` without justification
-- [ ] All functions/params have explicit types and return types
-- [ ] No unused imports, no debug code
-- [ ] Error handling complete (try/catch, `.catch`, fallback)
-- [ ] No hardcoded URLs, tokens, or secrets — use env vars
-- [ ] Naming matches project conventions
-- [ ] Reuses existing HTTP client, interceptors, and query client
-- [ ] JSDoc added for public API if project convention requires it
-- [ ] React: dependency arrays correct, cleanup present, no race conditions
-
----
-
-### Phase 8 — End-to-End UI Integration (Optional / On-Demand)
-
-If the user explicitly requests to integrate the API directly into the UI (End-to-End):
-1. **Find Target Component:** Identify the UI component where the API should be called.
-2. **Wire State:** Inject the generated Hook/Query/Service into the component.
-3. **Handle States:** Implement Loading (spinners, skeletons), Error (toast, alert), and Success (redirect, form reset, table refetch) states in the UI.
-4. **Data Binding:** Bind the API response data to the UI elements (Table rows, Dropdowns, etc.) and bind UI inputs to the API request payload.
-
----
-
-## Decision Tree
-
-```
-Is required info complete?
-  ├── No  → Ask for missing info (auth, response schema, base URL)
-  └── Yes → Check for conflicts
-              ├── P0 conflict → Stop, report, wait for user decision
-              └── No P0 → Generate code following project patterns
-```
-
-```
-Does project have existing HTTP client?
-  ├── Yes → Extend it
-  └── No  → Create minimal axios/fetch wrapper following project style
-```
-
-```
-Does project use state management?
-  ├── React Query → useMutation / useQuery pattern
-  ├── Redux       → slice + thunk / RTK Query
-  ├── Zustand     → store action
-  ├── Pinia       → action in store
-  └── None        → Service function only
-```
-
----
-
-## Output Format
-
-```
-📋 API Contract
-─────────────────────────────────────────────────
-Name:     [API name]
-Endpoint: [METHOD /path]
-Auth:     [type]
-Input:    [brief description]
-Output:   [brief description]
-
-🔍 Project Pattern Detected
-─────────────────────────────────────────────────
-HTTP client:    [axios instance at src/lib/axios.ts]
-State:          [React Query]
-Types path:     [src/types/]
-Service path:   [src/services/]
-Hook path:      [src/hooks/]
-
-⚠️  Assumptions
-─────────────────────────────────────────────────
-  • [Assumption 1]
-  • [Assumption 2]
-
-📁 Files Generated
-─────────────────────────────────────────────────
-  [NEW]    src/types/user.types.ts
-  [NEW]    src/services/user.service.ts
-  [NEW]    src/hooks/useCreateUser.ts
-  [EXTEND] src/services/index.ts
-
-🔗 Next steps:
-  → Import hook in your component
-  → Add env var: VITE_API_BASE_URL
-  → Test with: [example usage snippet]
-```
-
----
-
-## Validation Checklist
-
-- [ ] All 7 phases completed
-- [ ] Input validated — no missing critical fields
-- [ ] Conflicts checked — none unresolved
-- [ ] Types generated and strict
-- [ ] Existing HTTP client reused
-- [ ] Existing state pattern followed
-- [ ] Special cases handled if applicable (upload, download, pagination, auth)
-- [ ] No hardcoded secrets
-- [ ] Output format produced with files listed
-
----
-
-## Project Config Reference (`.api-config.json`)
-
-```json
-{
-  "framework": "React",
-  "httpClient": "axios",
-  "stateManagement": "react-query",
-  "typing": "typescript",
-  "conventions": {
-    "servicePath": "src/services/",
-    "typePath": "src/types/",
-    "hookPath": "src/hooks/",
-    "naming": "camelCase",
-    "fileNaming": "{name}.service.ts",
-    "typeFileNaming": "{Name}.types.ts",
-    "hookFileNaming": "use{Name}.ts"
-  },
-  "httpConfig": {
-    "baseURL": "process.env.VITE_API_URL",
-    "interceptor": "src/lib/axios.ts",
-    "authHeader": "Authorization",
-    "timeout": 30000
-  }
-}
-```
-
----
-
-## Examples
-
-See `examples/` folder.
-