ai-developer-skill-os 7.5.0 → 8.1.4

package/skills/_archive_old_skills/qk-table-crud-generator/SKILL.md

@@ -1,127 +0,0 @@
----
-name: qk-table-crud-generator
-description: >-
-  Tạo các bảng dữ liệu admin với đầy đủ tính năng phân trang, sắp xếp, lọc và thao tác thêm/sửa/xóa (CRUD).
-version: 1.0.0
-category: frontend
-tags: [table, data-grid, crud, admin, pagination, sorting]
-platforms: [antigravity, claude-code, kilo-code, cursor, windsurf]
----
-
-# Table & CRUD 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 an admin table", "build a user list", "add data grid"
-- User needs a view to manage a list of entities with CRUD capabilities
-- A feature requires complex data presentation (sorting, filtering, pagination)
-
----
-
-## Scope
-
-- ✅ Generate a data table using design system components or libraries (e.g., TanStack Table)
-- ✅ Implement client-side or server-side pagination, sorting, and filtering
-- ✅ Add UI actions for Create, Edit, and Delete (modals or routing)
-- ✅ Integrate with `api-integration` hooks for data fetching and mutations
-- ✅ Handle loading, error, and empty states gracefully
-
----
-
-## Non-goals
-
-- ❌ Do NOT build the backend API for the CRUD operations (assume they exist or delegate)
-- ❌ Do NOT use raw `<table>` tags if a powerful data-grid library is already installed
-
----
-
-## Workflow
-
-### Phase 1 — Data Model & Requirements
-
-1. Understand the entity (e.g., `User`, `Product`).
-2. Identify columns to display.
-3. Determine operations needed (e.g., just Read/Delete, or full CRUD).
-4. Decide on Pagination strategy: Server-side (URL params) or Client-side (in-memory).
-
----
-
-### Phase 2 — Table Component Setup
-
-1. Check for table libraries (e.g., `@tanstack/react-table`, MUI DataGrid, AntD Table).
-2. Define column definitions (headers, accessor keys, cell formatters).
-3. Set up the table UI wrapper.
-
----
-
-### Phase 3 — Data Integration
-
-Connect to the state/API layer (e.g., React Query).
-- `useQuery` for fetching the list. Pass pagination/sorting state.
-- Handle `isLoading` → show skeleton or spinner.
-- Handle empty data → show empty state component.
-
----
-
-### Phase 4 — CRUD Actions
-
-Implement actions (usually in an "Actions" column or toolbar):
-- **Create:** Button opening a Modal (delegate to `form-builder`) or routing to `/new`.
-- **Edit:** Button opening an Edit Modal or routing to `/edit/:id`.
-- **Delete:** Button opening a confirmation dialog, calling delete mutation on confirm.
-
----
-
-## Decision Tree
-
-```
-Is the dataset large (requires backend pagination)?
-  ├── Yes → Implement Server-side pagination (sync state with URL search params)
-  └── No  → Implement Client-side pagination (fetch all once, slice in UI)
-
-Does the project use TanStack Table (React Table)?
-  ├── Yes → Use `useReactTable` to manage table state and column definitions
-  └── No  → Use the project's specific UI library table component
-```
-
----
-
-## Output Format
-
-```
-📊 Table & CRUD Generated
-─────────────────────────────────────────────────
-Entity:     [Entity Name]
-Features:   [Pagination (Server), Sorting, CRUD actions]
-
-Components Created:
-  ✅ [Entity]Table.tsx
-  ✅ [Entity]Columns.tsx
-  ✅ DeleteConfirmModal.tsx
-
-Integration:
-  - Fetching: Linked to `use[Entity]List` hook
-  - Mutations: Linked to Create/Update/Delete hooks
-
-🔗 Next Steps:
-  If Create/Edit forms are needed, delegate to `form-builder`.
-```
-
----
-
-## Validation Checklist
-
-- [ ] Columns are defined correctly
-- [ ] Loading and empty states are handled
-- [ ] Pagination/sorting state is managed properly
-- [ ] CRUD actions trigger the correct mutations or navigations
-- [ ] Delete actions have a confirmation step
-

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

@@ -1,152 +0,0 @@
----
-name: qk-ui-builder
-description: >-
-  Xây dựng các màn hình và layout phức tạp từ yêu cầu, tái sử dụng component và đảm bảo responsive.
-version: 1.0.0
-category: frontend
-tags: [ui, layout, screens, pages, styling, responsive]
-platforms: [antigravity, claude-code, kilo-code, cursor, windsurf]
----
-
-# UI 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 wants to create a new page, screen, or view
-- User provides a mockup, wireframe, or visual description
-- User asks to "build a layout", "create a dashboard", "make the profile page"
-- Refactoring a large, messy view into a structured layout
-
----
-
-## Scope
-
-- ✅ Translate requirements into a component hierarchy
-- ✅ Build layouts using Grid, Flexbox, and project styling conventions
-- ✅ Ensure responsive design (mobile-first or desktop-first based on project)
-- ✅ Integrate existing shared components (Buttons, Cards, Inputs) via `design-system` rules
-- ✅ Define placeholders for data and logic (to be filled by `api-integration` or `state-management`)
-
----
-
-## Non-goals
-
-- ❌ Do NOT build backend APIs
-- ❌ Do NOT implement complex global state (delegate to `state-management`)
-- ❌ Do NOT invent new core UI components if they already exist in the design system
-- ❌ Do NOT write raw HTML (`<button>`) if a shared component (`<Button>`) exists
-
----
-
-## Workflow
-
-### Phase 1 — Requirement Analysis
-
-1. Understand the goal: What screen are we building?
-2. Identify major sections: Header, Sidebar, Main Content, Footer, Modals.
-3. Identify data requirements: What data will populate this view? (Use mock data initially).
-
----
-
-### Phase 2 — Component Hierarchy Planning
-
-Break the screen down into smaller components.
-**Rule of thumb:** If a section has complex logic or is reusable, it should be a separate component.
-
-*Example:*
-```text
-UserProfilePage
-  ├── ProfileHeader
-  │     ├── Avatar
-  │     └── UserStats
-  ├── UserSettingsForm (delegate to form-builder)
-  └── UserActivityList
-```
-
----
-
-### Phase 3 — Design System Integration
-
-*(Relies on output from `design-system` skill)*
-Identify which existing components will be used for each part of the hierarchy.
-
-- Buttons → `<Button>`
-- Layouts → `<Container>`, `<Grid>`
-- Typography → `<Typography variant="h2">` or Tailwind text classes
-
----
-
-### Phase 4 — Implementation
-
-Write the code.
-1. Build the layout skeleton first (Flexbox/Grid).
-2. Add static/mock data to visualize the structure.
-3. Apply styling for layout, spacing, and typography.
-4. Ensure responsive behavior (e.g., stack columns on mobile).
-
----
-
-### Phase 5 — Validation
-
-- [ ] Does it match the requirements?
-- [ ] Is it responsive?
-- [ ] Does it strictly use the design system?
-- [ ] Is the code clean and well-structured (not one giant file)?
-
----
-
-## Decision Tree
-
-```
-Is a section of the UI highly complex or forms a distinct logical unit?
-  ├── Yes → Extract it into its own component file (e.g., `ProfileHeader.tsx`)
-  └── No  → Keep it inline in the main layout file for now
-
-Does a required base component (e.g., DatePicker) exist in the project?
-  ├── Yes → Import and use it
-  └── No  → Use a standard HTML fallback or instruct `component-generator` to build it later
-
-Is the UI data-heavy (like a complex form or table)?
-  ├── Yes → Delegate specific sections to `form-builder` or `table-crud-generator`
-  └── No  → Build it fully within `ui-builder`
-```
-
----
-
-## Output Format
-
-```
-🎨 UI Builder Summary
-─────────────────────────────────────────────────
-Screen:     [Name of the screen/view built]
-
-Component Hierarchy:
-  [Tree showing parent and child components]
-
-📁 Files Created/Modified:
-  ✅ [path/to/Page.tsx]
-  ✅ [path/to/SubComponent.tsx]
-
-🛠️ Implementation Details:
-  - Responsive: [Yes - describe breakpoints used]
-  - Mock Data:  [Added placeholders for API integration]
-
-🔗 Next Steps:
-  → Need to wire up API? Route to `api-integration`.
-  → Need complex state? Route to `state-management`.
-```
-
----
-
-## Examples
-
-See `examples/` folder.
-

package/skills/_template/SKILL.md

@@ -1,238 +0,0 @@
----
-name: qk-[skill-name]
-category: [core|frontend|backend|fullstack|security|qa|maintenance|devops|utilities]
-version: 7.5.0
-description: "[One sentence — what it does]"
-platforms: [antigravity, claude-code, cursor, windsurf, kilo-code]
-execution_mode: deterministic
-
-# Orchestrator routing metadata
-cost: [low|medium|high]
-latency: [fast|medium|slow]
-risk: [low|medium|high]
-side_effects: [edit_files|run_commands|read_only|none]
-produces: [report|code|schema|plan|tokens]
-consumes: [context-graph|design-md|stack-trace|json-payload|none]
-
-token_budget:
-  max_files_read: 3
-  max_lines_per_read: 150
-  max_shell_commands: 2
-  stop_early: true
-
-exit_codes: [SUCCESS, BLOCKED, FAILED, PARTIAL]
----
-
-# qk-[skill-name]
-
-> **Language rule:** Code, identifiers, file names → English. Explanations, summaries → Vietnamese (match user language).
-
----
-
-## Preconditions
-Before executing, verify ALL exist. STOP with `BLOCKED` if any is missing.
-
-- [ ] [Precondition 1 — e.g., "Repository is accessible"]
-- [ ] [Precondition 2 — e.g., "DESIGN.md exists in project root"]
-
-```
-On missing precondition:
-  EXIT: BLOCKED
-  Message: "[Precondition X] not found. Please provide: [what]"
-```
-
----
-
-## Scope
-- ✅ [What this skill explicitly DOES]
-- ✅ [What this skill explicitly DOES]
-
-## Non-Goals
-- ❌ [Anti-pattern 1] — because [why]
-- ❌ [Anti-pattern 2]
-- ❌ Never create helper scripts (Node.js/Python/shell) to apply patches — edit files directly
-- ❌ Never read entire files > 150 lines — use targeted reads (StartLine:EndLine)
-
----
-
-## Priority Order
-When token budget is insufficient, execute checks in this order:
-
-| Priority | Check | Skip Threshold |
-|----------|-------|----------------|
-| P1 | [Most critical — never skip] | Never |
-| P2 | [High priority] | Budget < 30% |
-| P3 | [Medium priority] | Budget < 50% |
-| P4 | [Low priority — always optional] | Budget < 70% |
-
----
-
-## Workflow
-
-### Phase 1 — [Name: e.g., Triage]
-
-**Steps:**
-1. [Concrete step — specify tool: `grep_search` / `view_file[L1:L50]` / `run_command`]
-2. [Next step]
-
-**Exit When (stop this phase, move to next):**
-- [Condition A — e.g., "Root cause identified"]
-- [Condition B — e.g., "`max_files_read` reached"]
-
-**On Blocked:**
-```
-EXIT: BLOCKED
-Missing: [what specific info is needed]
-Questions:
-  1. [Specific question to user]
-```
-
----
-
-### Phase 2 — [Name: e.g., Analyze]
-
-**Steps:**
-1. [Step]
-
-**Decision:**
-```
-IF [condition met]
-  → proceed to Phase 3
-ELSE IF [edge case]
-  → EXIT: PARTIAL — note: [what was missed]
-ELSE
-  → ESCALATE
-```
-
----
-
-### Phase 3 — [Name: e.g., Execute]
-
-**Steps:**
-1. Apply fix using `replace_file_content` or `multi_replace_file_content` — NEVER via scripts
-2. [Verification step]
-
-**Exit When:**
-- Fix applied and verified → EXIT: SUCCESS
-- Fix applied but unverifiable → EXIT: PARTIAL
-
----
-
-## Confidence Model
-
-| Level | Condition | Action |
-|-------|-----------|--------|
-| HIGH | Direct evidence (file:line, stack trace, exact match) | Proceed |
-| MEDIUM | Inferred from patterns or similar code | Note assumption, proceed carefully |
-| LOW | Assumption without evidence | STOP — ask user before proceeding |
-
----
-
-## Severity
-
-| Level | Definition | Example |
-|-------|-----------|---------|
-| CRITICAL | Data loss / security breach / app down | Hardcoded secret, SQL injection |
-| HIGH | Core feature broken, blocking users | Null crash, broken API |
-| MEDIUM | Degraded UX, workaround exists | Cyclomatic > 10, missing loading state |
-| LOW | Style/cosmetic, non-blocking | Missing comment, minor inconsistency |
-
----
-
-## Evidence Format
-
-Every finding MUST use this format:
-```
-[SEVERITY] path/to/file.ts:LINE
-Reason:     [why this is a violation or finding]
-Confidence: [HIGH|MEDIUM|LOW]
-Fix:        [one-line suggestion]
-```
-
-**Example:**
-```
-[HIGH] src/auth.service.ts:132
-Reason:     Function length 64 lines exceeds threshold of 30
-Confidence: HIGH
-Fix:        Extract token validation to `validateToken()`
-```
-
----
-
-## Retry Policy
-
-```
-Action fails
-  └─ Attempt auto-fix (if fix is deterministic)
-       └─ Re-run verification
-            ├─ PASS → EXIT: SUCCESS
-            └─ FAIL (2nd time) → EXIT: PARTIAL + report
-                 └─ Do NOT retry more than 2 times
-                      └─ 3rd failure → ESCALATE to user
-```
-
----
-
-## Escalation Rules
-
-When blocked, **never just "STOP"** — return structured response:
-
-```
-BLOCKED: [Reason — specific, not vague]
-Missing:
-  - [Specific artifact or information needed]
-Questions:
-  1. [Specific question]
-  2. [Specific question]
-Recommended Assumptions (if you want me to proceed anyway):
-  - [Safe assumption 1]
-  - [Safe assumption 2]
-```
-
----
-
-## Handoff Contract
-
-### Consumes (Input from upstream)
-```json
-{
-  "from": "[skill-name or 'user']",
-  "required_fields": ["field1", "field2"],
-  "optional_fields": ["field3"]
-}
-```
-
-### Produces (Output for downstream)
-```json
-{
-  "to": "[skill-name or 'user']",
-  "output_fields": ["changed_files", "summary", "confidence", "exit_code"]
-}
-```
-
----
-
-## Output Format
-
-```
-[SKILL_NAME] Result
-─────────────────────────────────────────────────
-Status:      [SUCCESS | PARTIAL | BLOCKED | FAILED]
-Confidence:  [HIGH | MEDIUM | LOW]
-
-[Section specific to this skill]
-
-Exit Code:   [SUCCESS | PARTIAL | BLOCKED | FAILED]
-```
-
----
-
-## Exit Codes
-
-| Code | Meaning | Orchestrator Action |
-|------|---------|---------------------|
-| SUCCESS | All checks passed, task complete | Continue pipeline |
-| PARTIAL | Task done with degraded quality or skipped P3/P4 checks | Notify user, continue |
-| BLOCKED | Missing precondition or ambiguous requirement | STOP, ask user |
-| FAILED | Task failed after 2 retry attempts | STOP, report error |
-

package/skills/qk-access-policy/SKILL.md

@@ -1,179 +0,0 @@
----
-name: qk-access-policy
-category: security
-version: 7.5.0
-description: "Quản lý RBAC, ABAC — định nghĩa role matrix trước, implement middleware sau."
-platforms: [antigravity, claude-code, cursor, windsurf, kilo-code]
-execution_mode: deterministic
-cost: medium
-latency: medium
-risk: high
-side_effects: edit_files
-produces: [code, report]
-consumes: [user-description]
-token_budget:
-  max_files_read: 3
-  max_lines_per_read: 100
-  max_shell_commands: 0
-  stop_early: true
-exit_codes: [SUCCESS, BLOCKED, FAILED, PARTIAL]
-skill_version: 7.5.0
-runtime_version: 1
-schema_version: 2
----
-
-# qk-access-policy — Access Control Designer
-
-> **Language rule:** Code, identifiers, file names ? English. Explanations, summaries ? Vietnamese.
-
----
-
-## Preconditions
-- [ ] User roles and protected resources are defined
-- [ ] Auth system (JWT, session, OAuth) is identified
-
-```
-On missing precondition:
-  EXIT: BLOCKED
-  Message: "Cần định nghĩa: danh sách roles + resources cần bảo vệ."
-```
-
----
-
-## Scope
-- ✅ Define explicit Role-Permission Matrix before coding
-- ✅ Implement middleware/guards based strictly on the matrix
-- ✅ Separate auth (who are you?) from authz (what can you do?)
-
-## Non-Goals
-- ❌ Grant wildcard (*) permissions
-- ❌ Mix authentication logic with authorization logic
-- ❌ Hardcode role checks in business logic (use middleware/guards)
-
----
-
-## Priority Order
-| P | Task | Skip Threshold |
-|---|------|----------------|
-| P1 | Define Role-Permission Matrix | Never |
-| P2 | Implement deny-by-default middleware | Never |
-| P3 | Add role guards to routes/controllers | Budget < 30% |
-| P4 | Add audit logging for auth failures | Budget < 60% |
-
----
-
-## Role-Permission Matrix Format (Required)
-
-```
-Resource          | admin | manager | user | guest
-─────────────────────────────────────────────────
-GET /resource     |   ✅   |    ✅    |  ✅  |   ✅
-POST /resource    |   ✅   |    ✅    |  ❌  |   ❌
-DELETE /resource  |   ✅   |    ❌    |  ❌  |   ❌
-```
-
----
-
-## Workflow
-
-### Phase 1 — Matrix Definition
-1. List all roles and resources from requirements
-2. Create Role-Permission Matrix (table format above)
-3. Identify conflicts or contradictions
-
-**Decision:** `IF matrix has contradiction → EXIT: BLOCKED — resolve ambiguity`
-
-### Phase 2 — Implementation
-1. Create deny-by-default guard/middleware
-2. Apply guards to routes using matrix
-3. Add auth failure logging
-
-### Phase 3 — Verification
-1. Read matrix vs implementation — spot check 3 routes
-
----
-
-## Evidence Format
-```
-[SEVERITY] src/middleware/auth.ts:LINE
-Rule:       [WILDCARD | MISSING_GUARD | SOC_VIOLATION | HARDCODED_ROLE]
-Reason:     [specific issue]
-Confidence: HIGH
-Fix:        [specific change]
-```
-
----
-
-## Exit Codes
-| Code | Meaning | When |
-|------|---------|------|
-| SUCCESS | Matrix defined, middleware implemented, deny-by-default applied | Implementation complete |
-| PARTIAL | Implemented but missing audit logging or some routes unguarded | Post-verification minor gaps |
-| BLOCKED | Roles or resources undefined — cannot create matrix | Missing inputs |
-| FAILED | Contradiction in matrix or auth/authz mixed | Architectural violation |
-
----
-
-## Confidence Model
-| Level | Condition | Action |
-|-------|-----------|--------|
-| HIGH | Roles and resources explicitly defined | Build matrix and implement |
-| MEDIUM | Roles inferred from codebase | Build matrix, ask user to verify |
-| LOW | Authentication strategy unknown | EXIT: BLOCKED |
-
----
-
-## Severity
-| Level | Definition | Example |
-|-------|-----------|---------|
-| CRITICAL | Route unguarded due to missing middleware | Anyone can access DELETE /users |
-| HIGH | Hardcoded roles in business logic | `if (user.role === 'admin')` in service layer |
-| MEDIUM | Wildcard permissions granted | `user` can access `*` |
-| LOW | Audit log missing for auth failure | Unlogged 403 error |
-
----
-
-## Retry Policy
-```
-Route verification fails
-  └─ Route unguarded
-       ├─ Add missing guard to route
-       └─ Do NOT retry more than 1 time per route
-```
-
----
-
-## Escalation Rules
-```
-BLOCKED: Roles or resources undefined
-Missing:
-  - List of user roles
-  - List of protected resources
-Questions:
-  1. Hệ thống có những role nào? (ví dụ: admin, user, manager)
-  2. Những API/Route nào cần bảo vệ?
-Recommended Assumptions:
-  - Deny-by-default for all non-public routes
-```
-
----
-
-## Handoff Contract
-### Consumes
-```json
-{
-  "from": "user",
-  "required_fields": ["roles", "resources"],
-  "optional_fields": ["auth_strategy"]
-}
-```
-### Produces
-```json
-{
-  "to": "user",
-  "output_fields": ["role_matrix", "middleware_files", "guarded_routes", "exit_code"]
-}
-```
-
----
-