ai-developer-skill-os 7.5.1 → 8.1.5

package/rename.js

@@ -1,64 +0,0 @@
-import fs from 'fs';
-import path from 'path';
-import { execSync } from 'child_process';
-
-const skillsDir = 'skills';
-const categories = fs.readdirSync(skillsDir).filter(f => fs.statSync(path.join(skillsDir, f)).isDirectory());
-
-categories.forEach(category => {
-  const catPath = path.join(skillsDir, category);
-  const skills = fs.readdirSync(catPath).filter(f => fs.statSync(path.join(catPath, f)).isDirectory());
-  skills.forEach(skill => {
-    if (!skill.startsWith('qk-')) {
-      const oldPath = path.join(catPath, skill).replace(/\\/g, '/');
-      const newPath = path.join(catPath, 'qk-' + skill).replace(/\\/g, '/');
-      try {
-        console.log(`Đang đổi tên: ${oldPath} -> ${newPath}`);
-        execSync(`git mv "${oldPath}" "${newPath}"`);
-      } catch(e) {
-        console.error('LỖI (Hãy chắc chắn bạn đã tắt hoàn toàn IDE/Cursor đang mở folder này):', e.message);
-      }
-    }
-  });
-});
-
-// Update skills.json
-const skillsJsonPath = 'skills.json';
-let skillsData = JSON.parse(fs.readFileSync(skillsJsonPath, 'utf8'));
-
-// Fix entries and modify their paths
-if(skillsData.skills) {
-    skillsData.skills = skillsData.skills.map(s => {
-        if(!s.name.startsWith('qk-')) {
-            s.name = 'qk-' + s.name;
-            const parts = s.path.split('/');
-            const skillFolder = parts[2];
-            if(!skillFolder.startsWith('qk-')) {
-                parts[2] = 'qk-' + skillFolder;
-            }
-            s.path = parts.join('/');
-        }
-        return s;
-    });
-}
-fs.writeFileSync(skillsJsonPath, JSON.stringify(skillsData, null, 2));
-
-// Update SKILL.md names
-categories.forEach(category => {
-  const catPath = path.join(skillsDir, category);
-  const skills = fs.readdirSync(catPath).filter(f => fs.statSync(path.join(catPath, f)).isDirectory());
-  skills.forEach(skill => {
-    if (skill.startsWith('qk-')) {
-      const skillMdPath = path.join(catPath, skill, 'SKILL.md');
-      if (fs.existsSync(skillMdPath)) {
-        let content = fs.readFileSync(skillMdPath, 'utf8');
-        content = content.replace(/^name:\s*([a-zA-Z0-9-]+)\s*$/m, (match, p1) => {
-          if (!p1.startsWith('qk-')) return 'name: qk-' + p1;
-          return match;
-        });
-        fs.writeFileSync(skillMdPath, content);
-      }
-    }
-  });
-});
-console.log('✅ Đã đổi tên thành công toàn bộ sang hệ qk-* !');

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.
-