ac-framework 2.3.0 → 2.4.0

package/framework/make_your_own/.clinerules/skills/find-skills/SKILL.md

@@ -0,0 +1,130 @@
+---
+name: find-skills
+description: Build and maintain a custom project skill repertoire. Always use at new project bootstrap and when users ask for new domain capabilities. Detect active assistant folders first, recommend at least 5 skills per search batch, confirm installs, normalize install paths, and regenerate workflow files.
+---
+
+# Find Skills
+
+Use this skill to discover, install, and operationalize reusable skills for the current project.
+
+## Mandatory triggers
+
+Run this skill automatically when:
+1. A project is starting from zero and needs its initial skill repertoire.
+2. The user explicitly asks to find/add/install skills.
+3. The user says they are entering a new work area (for example: security, testing, deployment, data, mobile).
+
+## Step 0: Detect active assistant targets first (required)
+
+Before searching skills, list workspace root folders and detect which assistant folders exist.
+
+```bash
+ls -la
+```
+
+Look for folders such as:
+- `.claude`
+- `.opencode`
+- `.cursor`
+- `.windsurf`
+- `.roo`
+- `.github`
+- `.gemini`
+- `.continue`
+- `.agents`
+
+If multiple assistants exist, ask which target(s) should receive installed skills.
+
+## Step 1: Scope the batch
+
+Define one search batch per domain/request (for example: "testing", "api", "devops").
+For each batch, recommend at least 5 candidate skills.
+
+Minimum output per batch:
+- 5 or more skills
+- short reason per skill
+- install source/package
+- estimated trust signal (publisher quality, adoption)
+
+## Step 2: Search from multiple sources (no API key required)
+
+Primary source:
+
+```bash
+npx skills find <query>
+```
+
+Additional source (keyword API, anonymous mode):
+
+```bash
+curl -sS "https://skillsmp.com/api/v1/skills/search?q=<query>&page=1&limit=20&sortBy=recent"
+```
+
+Important:
+- Do not require API keys.
+- Do not block on authenticated endpoints.
+- AI semantic search endpoint is optional only when user explicitly provides a key and asks for it.
+
+## Step 3: Present and confirm selections
+
+For each batch, present at least 5 options and then confirm exactly which skill(s) to install.
+
+Required confirmation format:
+1. Selected skill names
+2. Target assistant folder(s)
+3. Install order
+
+## Step 4: Install selected skills
+
+Use the standard install command pattern. Example:
+
+```bash
+npx skills add https://github.com/vercel-labs/skills --skill find-skills
+```
+
+If installer shows an interactive agent selector, choose the confirmed target assistant(s).
+
+## Step 5: Normalize install location (required)
+
+If installation creates a new folder (for example `.agentss`) instead of the intended target:
+1. Detect where the skill was created.
+2. Copy/move the skill into the original target assistant folder (for example `.claude/skills/`).
+3. Remove temporary/unwanted folder after migration.
+
+Example normalization flow:
+
+```bash
+mkdir -p .claude/skills
+cp -R .agentss/skills/<skill-name> .claude/skills/
+rm -rf .agentss
+```
+
+Repeat for each selected assistant target when needed.
+
+## Step 6: Regenerate workflow files after installation
+
+After final skill selection and installation, regenerate project workflow docs in this order:
+1. `ac.md` (required)
+2. `ac-lite.md` (if present)
+3. `AGENTS.md` / `CLAUDE.md` / `GEMINI.md` / `copilot-instructions.md` (if present)
+
+Use the custom workflow template and include only the selected skills plus the general baseline.
+
+## Required output contract
+
+When this skill runs, return:
+1. Detected assistant folders
+2. Search batches executed
+3. At least 5 recommendations per batch
+4. User-confirmed install list
+5. Final installed skills by assistant target
+6. Normalization actions performed (if any)
+7. Confirmation that `ac.md` and companion instruction files were regenerated
+
+## Quality rules
+
+- Never install without explicit confirmation of skill names.
+- Never leave skills stranded in unintended folders (for example `.agentss`).
+- Always keep workflow docs synchronized with the installed skill repertoire.
+- Keep suggestions relevant; avoid filler suggestions just to reach 5.
+

package/framework/make_your_own/.clinerules/skills/performance-optimizer/SKILL.md

@@ -0,0 +1,43 @@
+---
+name: performance-optimizer
+description: Transform the agent into a performance engineer. Apply methodologies for measuring, profiling, and optimizing code (caching, algorithm complexity, resource usage).
+---
+
+# Performance Optimization
+
+## Overview
+
+Use this skill to analyze and improve the performance of the codebase. Focus on measurable improvements, not premature optimization.
+
+## Workflow
+
+1.  **Measure First**:
+    *   Never optimize without a baseline.
+    *   Use profiling tools or simple timing logs to identify bottlenecks.
+    *   "What gets measured, gets managed."
+
+2.  **Analyze and Hypothesize**:
+    *   Identify the root cause: CPU, Memory, I/O, or Network?
+    *   Look for common culprits: N+1 queries, unoptimized loops, large payload sizes, unnecessary re-renders (frontend).
+
+3.  **Optimize**:
+    *   **Algorithmic**: Improve Big-O complexity (e.g., O(n^2) -> O(n)).
+    *   **Caching**: Implement caching strategies (in-memory, Redis, HTTP caching).
+    *   **Database**: Add indexes, optimize queries, use batching.
+    *   **Frontend**: Lazy loading, memoization, code splitting, asset optimization.
+
+4.  **Verify**:
+    *   Run the measurements again.
+    *   Confirm the improvement.
+    *   Ensure no regression in functionality.
+
+## Techniques & Patterns
+
+*   **Database**: Explain Analyze, Indexing, Connection Pooling.
+*   **Backend**: Async processing, Caching layers, Load balancing.
+*   **Frontend**: Virtualization for long lists, Debouncing/Throttling events.
+
+## Output
+
+*   Create a brief report of findings and improvements.
+*   Update code with optimized solution.

package/framework/make_your_own/.clinerules/skills/requirement-checklist/SKILL.md

@@ -0,0 +1,90 @@
+---
+name: requirement-checklist
+description: Generate comprehensive checklists to validate requirements quality (Unit Tests for Specs). Critically examine the spec for clarity, completeness, and consistency before implementation starts.
+---
+
+# Requirement Checklist Generation
+
+## Overview
+
+Checklists are **UNIT TESTS FOR REQUIREMENTS WRITING** - they validate the quality, clarity, and completeness of requirements in a given domain.
+
+**NOT for verification/testing implementation**:
+*   ❌ NOT "Verify the button clicks correctly"
+*   ❌ NOT "Test error handling works"
+*   ❌ NOT "Confirm the API returns 200"
+*   ❌ NOT checking if code/implementation matches the spec
+
+**FOR requirements quality validation**:
+*   ✅ "Are visual hierarchy requirements defined for all card types?" (completeness)
+*   ✅ "Is 'prominent display' quantified with specific sizing/positioning?" (clarity)
+*   ✅ "Are hover state requirements consistent across all interactive elements?" (consistency)
+*   ✅ "Are accessibility requirements defined for keyboard navigation?" (coverage)
+*   ✅ "Does the spec define what happens when logo image fails to load?" (edge cases)
+
+## Execution Steps
+
+1.  **Setup**:
+    *   Parse feature directory and available docs list.
+    *   Identify the target feature spec (`spec.md`, `plan.md`, `tasks.md`).
+
+2.  **Clarify intent (dynamic)**:
+    *   Derive up to THREE initial contextual clarifying questions (no pre-baked catalog). They MUST:
+        *   Be generated from the user's phrasing + extracted signals from spec/plan/tasks
+        *   Only ask about information that materially changes checklist content
+    *   Generation algorithm:
+        1.  Extract signals: feature domain keywords (e.g., auth, latency, UX, API), risk indicators ("critical", "must", "compliance"), stakeholder hints ("QA", "review", "security team"), and explicit deliverables ("a11y", "rollback", "contracts").
+        2.  Cluster signals into candidate focus areas (max 4) ranked by relevance.
+        3.  Identify probable audience & timing (author, reviewer, QA, release) if not explicit.
+        4.  Detect missing dimensions: scope breadth, depth/rigor, risk emphasis, exclusion boundaries, measurable acceptance criteria.
+
+3.  **Generate checklist - Create "Unit Tests for Requirements"**:
+    *   Create a checklist file in the feature directory (e.g., `checklists/[domain].md`).
+    *   Format: `[domain].md` (e.g., `ux.md`, `api.md`, `security.md`).
+    *   Number items sequentially starting from CHK001.
+    *   Each run creates a NEW file (never overwrites existing checklists unless explicitly told).
+
+    **CORE PRINCIPLE - Test the Requirements, Not the Implementation**:
+    Every checklist item MUST evaluate the REQUIREMENTS THEMSELVES for:
+    *   **Completeness**: Are all necessary requirements present?
+    *   **Clarity**: Are requirements unambiguous and specific?
+    *   **Consistency**: Do requirements align with each other?
+    *   **Measurability**: Can requirements be objectively verified?
+    *   **Coverage**: Are all scenarios/edge cases addressed?
+
+    **Category Structure**:
+    *   Requirement Completeness
+    *   Requirement Clarity
+    *   Requirement Consistency
+    *   Acceptance Criteria Quality
+    *   Scenario Coverage
+    *   Edge Case Coverage
+    *   Non-Functional Requirements
+    *   Dependencies & Assumptions
+    *   Ambiguities & Conflicts
+
+4.  **Structure Reference**:
+    *   Generate the checklist following a markdown template: Title, Purpose, Category Headings, `##` sections, `- [ ] CHK### <requirement item>` lines.
+
+5.  **Report**:
+    *   Output full path to created checklist, item count, and remind user that each run creates a new file.
+    *   Summarize focus areas selected, depth level, and valid user must-haves.
+
+## Checklist Item Guidelines
+
+**Example Checklist Items**:
+
+*   **UX**: "Are visual hierarchy requirements defined with measurable criteria? [Clarity, Spec §FR-1]"
+*   **API**: "Are error response formats specified for all failure scenarios? [Completeness]"
+*   **Performance**: "Are performance requirements quantified with specific metrics? [Clarity]"
+*   **Security**: "Are authentication requirements specified for all protected resources? [Coverage]"
+
+**Avoid Implementation Tests**:
+*   ❌ "Verify landing page displays 3 episode cards"
+*   ❌ "Test hover states work correctly on desktop"
+*   ❌ "Confirm logo click navigates to home page"
+
+**Use Quality Checks**:
+*   ✅ "Are the exact number and layout of featured episodes specified?" [Completeness]
+*   ✅ "Is 'prominent display' quantified with specific sizing/positioning?" [Clarity]
+*   ✅ "Are hover state requirements consistent across all interactive elements?" [Consistency]