@dtt_siye/atool 1.1.0

package/skills/ui-ux-pro/SKILL.md

@@ -0,0 +1,140 @@
+---
+name: ui-ux-pro
+description: Expert UI/UX design skill for creating beautiful, user-friendly interfaces. Provides guidance on design principles, accessibility, component selection, color theory, typography, and responsive design best practices.
+version: 1.0.0
+---
+
+# UI/UX Pro
+
+This skill provides expert UI/UX design guidance for creating professional, user-friendly interfaces.
+
+## When to Use
+
+Use this skill when:
+- Designing or reviewing user interfaces
+- Making design system decisions
+- Choosing colors, typography, or layouts
+- Ensuring accessibility compliance
+- Creating responsive designs
+- Building component libraries
+
+## Core Principles
+
+### 1. User-First Design
+- Understand user needs before designing
+- Create clear user flows
+- Prioritize content hierarchy
+- Design for the target audience
+
+### 2. Visual Hierarchy
+- Use size, color, and spacing to guide attention
+- Establish clear focal points
+- Group related elements
+- Create breathing room with whitespace
+
+### 3. Consistency
+- Maintain design system coherence
+- Use consistent spacing scales
+- Keep typography predictable
+- Reuse component patterns
+
+### 4. Accessibility (A11y)
+- Ensure WCAG 2.1 AA compliance minimum
+- Color contrast ratio: 4.5:1 for text, 3:1 for UI components
+- Support keyboard navigation
+- Provide meaningful alt text
+- Test with screen readers
+
+## Design Guidelines
+
+### Color
+- **Primary**: Use for main actions and branding
+- **Secondary**: Use for supporting actions
+- **Neutral**: Use for text, backgrounds, borders
+- **Semantic**: Use for states (success, error, warning, info)
+- **Dark mode**: Always provide dark mode support
+
+### Typography
+- **Font size**: Minimum 16px for body text
+- **Line height**: 1.5 for body, 1.2 for headings
+- **Font weights**: Use 400-600 for most text
+- **Max width**: 60-75 characters per line for readability
+
+### Spacing
+- Use 8px base grid (8, 16, 24, 32, 48, 64)
+- Maintain consistent vertical rhythm
+- Provide adequate touch targets (44x44px minimum)
+- Group related elements with proximity
+
+### Layout
+- **Mobile-first**: Design for smallest screens first
+- **Breakpoints**: 640px, 768px, 1024px, 1280px, 1536px
+- **Containers**: Max-width 1280px-1536px for content
+- **Grid**: Use 12-column grid for complex layouts
+
+## Component Best Practices
+
+### Buttons
+- Clear, action-oriented labels
+- Primary/Secondary/Ghost variants
+- Loading and disabled states
+- Consistent sizing (sm, md, lg)
+
+### Forms
+- Label every input clearly
+- Show validation inline
+- Group related fields
+- Use appropriate input types
+
+### Navigation
+- Keep it simple and scannable
+- Highlight current location
+- Mobile: hamburger or bottom nav
+- Desktop: horizontal or sidebar
+
+### Cards
+- Clear content hierarchy
+- Consistent padding
+- Subtle shadows or borders
+- Hover/focus states
+
+## Responsive Design Checklist
+
+- [ ] Works on 320px width (small phones)
+- [ ] Touch targets are 44x44px minimum
+- [ ] Font sizes scale appropriately
+- [ ] Images are responsive
+- [ ] Navigation adapts to screen size
+- [ ] No horizontal scrolling
+- [ ] Content is readable without zoom
+
+## Tools & Resources
+
+- **Colors**: Adobe Color, Coolors, ColorHunt
+- **Typography**: Google Fonts, Font Pair
+- **Icons**: Lucide, Heroicons, Phosphor
+- **Inspiration**: Dribbble, Behance, Mobbin
+- **Testing**: Lighthouse, WAVE, axe DevTools
+
+## Design Review Questions
+
+1. Is the purpose of this screen immediately clear?
+2. Can users complete their primary task in 3 clicks or less?
+3. Is the visual hierarchy obvious?
+4. Would this work for users with color blindness?
+5. Does it work on a 320px wide screen?
+6. Are error messages helpful and actionable?
+7. Is the loading experience graceful?
+
+## Common Mistakes to Avoid
+
+- Using placeholder text (Lorem ipsum) in final designs
+- Inconsistent spacing
+- Poor color contrast
+- Too many font families
+- Ignoring empty states
+- Missing error handling UI
+- No loading states
+- Overusing animations
+- Cluttered interfaces
+- Hidden important actions

package/skills/verification-before-completion/SKILL.md

@@ -0,0 +1,119 @@
+---
+name: verification-before-completion
+description: Use when about to claim work is complete, fixed, or passing, before committing or creating PRs. Extends superpowers:verification-before-completion with documentation freshness verification.
+version: 0.1.0
+---
+
+# Verification Before Completion (aTool Enhanced)
+
+This skill extends `superpowers:verification-before-completion` with **documentation freshness checks**.
+
+**Use the superpowers:verification-before-completion skill as the base**, then apply these additions:
+
+## Enhancement: Documentation Freshness Gate
+
+**BEFORE claiming any task or feature is complete**, verify documentation is in sync with code changes.
+
+### The Documentation Gate Function
+
+```
+BEFORE claiming completion:
+
+1. LIST: What source files did you create or modify?
+2. CHECK: Which documentation files reference those source files?
+   - README.md (architecture, structure, tech stack)
+   - COMPONENT.md (component API, usage examples)
+   - UI_STYLE.md (UI patterns, design tokens)
+   - docs/ (module knowledge base)
+3. COMPARE: Is each doc file at least as recent as the source files it describes?
+   - If source file mtime > doc file mtime → documentation is STALE
+4. VERIFY: Have all stale docs been updated to reflect changes?
+   - If NO → Update docs first, THEN claim completion
+   - If YES → Claim completion WITH evidence
+```
+
+### Common Failures (Documentation)
+
+| Claim | Requires | Not Sufficient |
+|-------|----------|----------------|
+| "Docs updated" | Actually edited the doc files | "No doc changes needed" without checking |
+| "No doc impact" | Verified each doc file is unaffected | Assumed no impact without checking |
+| "README reflects changes" | README mtime >= source mtime | "README was already correct" |
+| "Feature complete" | Code + tests + docs all pass | Code + tests only |
+
+### Red Flags - STOP
+
+- Claiming "no documentation update needed" without listing affected docs
+- Skipping doc check because "changes are minor"
+- Moving to next task without verifying docs are fresh
+- Committing code without committing corresponding doc updates
+
+### How To Check Documentation Freshness
+
+**Method 1: Use the doc-sync-reminder hook**
+If the ATOOL-DOC-SYNC-REMINDER appears, documentation is stale. Update it before claiming completion.
+
+**Method 2: Manual check**
+```bash
+# Check if any source files are newer than README.md
+find src/ -newer README.md -type f | head -5
+
+# Check if any source files are newer than COMPONENT.md
+find src/ -newer COMPONENT.md -type f | head -5
+```
+
+**Method 3: For projects with aTool analysis**
+Check the ATOOL-PROJECT-CONTEXT in the session for "X source files modified after README.md" warnings.
+
+### Completion Claim Template
+
+When claiming completion, include documentation evidence:
+
+```
+✅ Tests: [command] → [output showing pass]
+✅ Build: [command] → [exit 0]
+✅ Docs: README.md §Architecture updated, COMPONENT.md §API updated, docs/ unchanged (verified)
+```
+
+Or if docs genuinely don't need updates:
+
+```
+✅ Tests: [command] → [output showing pass]
+✅ Build: [command] → [exit 0]
+✅ Docs: Checked README.md, COMPONENT.md, UI_STYLE.md — no sections reference changed files (verified)
+```
+
+## Enhancement: Code Quality Gate
+
+**BEFORE claiming completion, for files modified in this task:**
+
+### The Code Quality Gate Function
+
+```
+BEFORE claiming completion (after documentation check):
+
+1. CHECK: Run code-review lightweight analysis on changed files
+2. IDENTIFY: Any Critical-severity issues?
+   - Hardcoded secrets, SQL injection, empty catch blocks, unreachable code
+3. RESOLVE:
+   - Critical issues found → MUST fix before claiming completion
+   - Warning issues found → LIST in completion report, recommend fixing
+   - Info issues → Note for future improvement
+```
+
+### Code Quality Red Flags - STOP
+
+- Claiming "code looks fine" without checking against review rules
+- Ignoring hardcoded secrets or SQL injection patterns
+- Skipping quality check because "changes are minor"
+- Moving to next task with known Critical issues
+
+### Completion Claim Template (Updated)
+
+```
+✅ Tests: [command] → [output showing pass]
+✅ Build: [command] → [exit 0]
+✅ Docs: [documentation evidence]
+✅ Code Quality: No Critical issues in changed files (verified)
+   Warnings: [count] ([list briefly, or "none"])
+```

package/skills/web-conventions/SKILL.md

@@ -0,0 +1,259 @@
+---
+name: web-conventions
+description: Use when writing, reviewing, or refactoring frontend code — applies project structure, JavaScript style, JSDoc, React, Vue, Svelte, HTML, CSS/Less, and TypeScript conventions.
+version: 1.0.0
+category: conventions
+---
+
+# Web Development Conventions
+
+Use this skill when working on web applications (React, Next.js, Vue, Svelte) or plain JavaScript/HTML/CSS projects.
+
+## When to Use
+- Detected web project (package.json with react/next/vue/svelte)
+- Writing, reviewing, or refactoring frontend code
+- Asking about web framework best practices
+
+If the repository already has stricter local lint rules, follow the stricter rule.
+
+---
+
+## Core Behavior
+
+Before writing code:
+1. Infer whether the task is for a business project, shared package, React module, Vue page, or plain JS/HTML/CSS.
+2. Keep directory structure **business-oriented**, not resource-type-oriented.
+3. Match the existing framework and module style already used in the codebase.
+4. Prefer readable, maintainable code over framework tricks.
+
+After writing code, run a mental lint pass against the self-check checklist at the end of this skill.
+
+---
+
+## Project and Directory Structure
+
+- Directories must be organized by **function / business domain**, not by resource type at root.
+- Common root directories: `src`, `test`, `doc`, `dep`; optionally `tool`, `entry`.
+- **Do not** place resource-type directories (`js`, `css`, `img`) directly under project root.
+- In business projects, `src` contains business directories and `common` only.
+- `common` is reserved for shared business resources.
+- JS source files in `src` must be organized by business logic — not placed under a `src/js/` subdirectory.
+- Directory names: concise and singular (`src` not `source`, `img` not `images`, `css` not `styles`).
+- Shared images across pages: `src/common/img/`; page-specific or CSS-referenced images: local `./img/`.
+
+---
+
+## TypeScript
+
+- Use TypeScript for all new files.
+- Define interfaces/types for props, state, and API responses.
+- Avoid `any` — use `unknown` and type narrowing.
+- Prefer `interface` for object shapes, `type` for unions.
+
+---
+
+## JavaScript Formatting
+
+- Encoding: UTF-8 without BOM; trailing newline at end of file.
+- Indentation: **4 spaces** — never 2 spaces, never tabs.
+- `case` / `default` in `switch`: indented one level inside `switch`.
+- Binary operators: spaces on both sides.
+- Unary operators: no space between operator and operand.
+- Space required before `{` that starts a block.
+- Keywords (`if`, `else`, `for`, `while`, `function`, `switch`, `do`, `try`, `catch`, `finally`) followed by a space.
+- No space between function name and `(` in declaration, expression, or call.
+- Object literal `:` — no space before, one space after.
+- No spaces before `,` or `;`; one space after (when not at end of line).
+- No spaces just inside `()` or `[]`.
+- No trailing whitespace.
+- End every statement with `;`.
+- Keep line length within 120 characters; when breaking, put operator at the start of the new line.
+- Separate different logical blocks with blank lines.
+
+---
+
+## JavaScript Naming
+
+| Entity | Convention | Example |
+|--------|-----------|---------|
+| Variables | `camelCase` | `userData` |
+| Functions | `camelCase` (verb-object) | `fetchUserList` |
+| Classes | `PascalCase` | `UserService` |
+| Constants | `UPPER_SNAKE_CASE` | `MAX_RETRY_COUNT` |
+| Enums (object) | `PascalCase` | `UserStatus` |
+| Enum members | `UPPER_SNAKE_CASE` | `UserStatus.ACTIVE` |
+| Namespaces | `camelCase` | `userModule` |
+| Boolean vars | prefix `is` / `has` | `isLoading`, `hasError` |
+| Promise vars | progressive verb-object | `loadingData` |
+
+Acronyms respect surrounding style: `XMLParser`, `insertHTML`, `HTTPRequest`.
+
+---
+
+## JSDoc and Comments
+
+The following **must** use `/** ... */` doc comments:
+- File, namespace, class, function/method, class property, event, global variable, constant, AMD module.
+
+Rules:
+- Single-line comments on their own line, using `// `.
+- Avoid `/* ... */` block comments; prefer multiple `// ` lines.
+- Leave one blank line before a doc comment.
+- Document intent and guarantees, not implementation trivia.
+- `@param` and `@return` require type and description.
+- Use lowercase primitive type names: `{string}`, `{number}`, `{boolean}`.
+- For object parameters, document each field with a separate `@param`.
+
+---
+
+## Module and Loader Rules
+
+- AMD-style modules: `define(factory)` — do not specify explicit `moduleId` and `dependencies` unless the project already requires it.
+- Prefer returning the module object from `factory`.
+- In global runtime: async `require([...], callback)`.
+- Inside module definitions: use local `require`, not global `require`.
+- Reusable package internals must use relative module ids.
+- Static dependency plugins (css/tpl/js) should be required at the start of the factory.
+
+---
+
+## Components
+
+- Functional components only (no class components for new code).
+- Single responsibility — one component, one purpose.
+- Co-locate related files (component, styles, tests, types).
+- Use barrel exports (`index.ts`) for module public API.
+- Default export the main component; named exports for utilities.
+
+---
+
+## React / Next.js
+
+### Hooks
+- Custom hooks for reusable logic (`useAuth`, `useDebounce`).
+- `useCallback` for event handlers passed as props.
+- `useMemo` for expensive computations.
+- `useRef` for mutable values that don't trigger re-renders.
+
+### State Management
+- Local state first (`useState`, `useReducer`).
+- Lift state to the lowest common ancestor.
+- Context for widely shared state.
+- External libraries (Zustand, Redux Toolkit) for complex state.
+
+### Component Rules (React)
+- Component names: `PascalCase`; must match file name.
+- Higher-order components: `camelCase`, preferably `withXxx` or `xxxable` style.
+- Callback props: `onXxx` naming.
+- Event handler methods inside components: use business-meaningful names, not `onXxx`.
+
+### Next.js Specific
+- App Router (not Pages Router) for new projects.
+- Server Components by default; Client Components when needed.
+- Use `loading.tsx` for Suspense boundaries.
+- Route handlers (`route.ts`) for API endpoints.
+- Metadata API for SEO.
+
+---
+
+## Vue / Nuxt
+
+### Composition API
+- Use `<script setup>` syntax.
+- Composables (`use*` functions) for reusable logic.
+- `ref` and `reactive` for reactive state; `computed` for derived state.
+- `watch` / `watchEffect` for side effects.
+- Vue component naming, props, methods, and views must be consistent and semantic.
+- Keep Vue files organized: template, script, style in the project's preferred order.
+
+### Nuxt Specific
+- Use auto-imports (no need to import composables).
+- Server routes in `server/api/`.
+- Use `useFetch` and `useAsyncData` for data fetching.
+- Middleware in `middleware/`.
+
+---
+
+## Svelte / SvelteKit
+
+- Use `$:` reactive declarations.
+- Stores for shared state; actions for form handling.
+- SvelteKit: file-based routing in `src/routes/`; load functions for data fetching; form actions for POST/PUT/DELETE; layouts in `+layout.svelte`.
+
+---
+
+## HTML Rules
+
+- Valid DOCTYPE and UTF-8 encoding.
+- Consistent indentation and wrapping.
+- Semantic, readable tag and attribute naming.
+- Include standard metadata: title, favicon, viewport where relevant.
+- Form controls must have clear labels; buttons use appropriate element types.
+- Consider accessibility for forms and interactive content.
+
+---
+
+## CSS / Less Rules
+
+- 4-space indentation for standalone style files.
+- No unnecessary spaces or excessively long lines.
+- Keep selector and property ordering stable.
+- Prefer concise properties and reasonable shorthand.
+- **Avoid `!important`** unless there is clear justification.
+- Use controlled `z-index` values — no arbitrary stacking escalation.
+- Keep responsive and compatibility code explicit and minimal.
+- In Less: keep imports, variables, nesting, mixins, and namespaces tidy and readable.
+
+---
+
+## Styling
+- Use the project's established styling solution (Tailwind, CSS Modules, styled-components, etc.).
+- Don't mix styling approaches within a project.
+- Responsive design by default; follow a consistent spacing scale.
+
+---
+
+## Testing
+- Component tests: Testing Library (`@testing-library/react`, `@testing-library/vue`, etc.).
+- Unit tests: Vitest or Jest.
+- E2E tests: Playwright or Cypress.
+- Mock API calls in component tests; test user behavior, not implementation details.
+
+---
+
+## Performance
+- Code splitting and lazy loading.
+- Optimize images (next/image, vite-plugin-imagemin).
+- Virtualize long lists.
+- Debounce expensive operations.
+- Use Web Workers for heavy computation.
+
+---
+
+## Self-Check Before Finalizing
+
+1. Is the directory placement business-oriented and consistent?
+2. Did I avoid putting business JS under `src/js/`?
+3. Are naming styles correct for variables, classes, constants, components, and props?
+4. Is indentation 4 spaces with no tabs?
+5. Are semicolons present?
+6. Are spaces around operators and after keywords correct?
+7. Are any lines needlessly over 120 characters?
+8. Are doc comments (`/** */`) present where required?
+9. If using AMD, did I use `define(factory)` and local `require`?
+10. For React, do component names match file names and export style?
+11. For Vue, are props/methods/views named clearly and consistently?
+12. Did I avoid unnecessary `!important`, random `z-index`, or messy nesting?
+13. Are shared and page-local images placed in the right directories?
+
+---
+
+## Review Output Format
+
+When reviewing frontend code, group findings as:
+
+- **Blocking violations** — structure and naming issues that must be fixed
+- **Recommended improvements** — best practices not yet followed
+- **Optional cleanups** — style or readability improvements
+
+Always call out structure and naming issues before style nits.