agcel 1.0.1

package/skills/test-fixing/SKILL.md

@@ -0,0 +1,123 @@
+---
+name: test-fixing
+description: Run tests and systematically fix all failing tests using smart error grouping. Use when user asks to fix failing tests, mentions test failures, runs test suite and failures occur, or requests to make tests pass.
+---
+
+# Test Fixing
+
+Systematically identify and fix all failing tests using smart grouping strategies.
+
+## When to Use
+
+- Explicitly asks to fix tests ("fix these tests", "make tests pass")
+- Reports test failures ("tests are failing", "test suite is broken")
+- Completes implementation and wants tests passing
+- Mentions CI/CD failures due to tests
+
+## Systematic Approach
+
+### 1. Initial Test Run
+
+Run `make test` to identify all failing tests.
+
+Analyze output for:
+
+- Total number of failures
+- Error types and patterns
+- Affected modules/files
+
+### 2. Smart Error Grouping
+
+Group similar failures by:
+
+- **Error type**: ImportError, AttributeError, AssertionError, etc.
+- **Module/file**: Same file causing multiple test failure
+- **Root cause**: Missing dependencies, API changes, refactoring impacts
+
+Prioritize groups by:
+
+- Number of affected tests (highest impact first)
+- Dependency order (fix infrastructure before functionality)
+
+### 3. Systematic Fixing Process
+
+For each group (starting with highest impact):
+
+1. **Identify root cause**
+
+   - Read relevant code
+   - Check recent changes with `git diff`
+   - Understand the error pattern
+
+2. **Implement fix**
+
+   - Use Edit tool for code changes
+   - Follow project conventions (see CLAUDE.md)
+   - Make minimal, focused changes
+
+3. **Verify fix**
+
+   - Run subset of tests for this group
+   - Use pytest markers or file patterns:
+     ```bash
+     uv run pytest tests/path/to/test_file.py -v
+     uv run pytest -k "pattern" -v
+     ```
+   - Ensure group passes before moving on
+
+4. **Move to next group**
+
+### 4. Fix Order Strategy
+
+**Infrastructure first:**
+
+- Import errors
+- Missing dependencies
+- Configuration issues
+
+**Then API changes:**
+
+- Function signature changes
+- Module reorganization
+- Renamed variables/functions
+
+**Finally, logic issues:**
+
+- Assertion failures
+- Business logic bugs
+- Edge case handling
+
+### 5. Final Verification
+
+After all groups fixed:
+
+- Run complete test suite: `make test`
+- Verify no regressions
+- Check test coverage remains intact
+
+## Best Practices
+
+- Fix one group at a time
+- Run focused tests after each fix
+- Use `git diff` to understand recent changes
+- Look for patterns in failures
+- Don't move to next group until current passes
+- Keep changes minimal and focused
+
+## Example Workflow
+
+User: "The tests are failing after my refactor"
+
+1. Run `make test` → 15 failures identified
+2. Group errors:
+   - 8 ImportErrors (module renamed)
+   - 5 AttributeErrors (function signature changed)
+   - 2 AssertionErrors (logic bugs)
+3. Fix ImportErrors first → Run subset → Verify
+4. Fix AttributeErrors → Run subset → Verify
+5. Fix AssertionErrors → Run subset → Verify
+6. Run full suite → All pass ✓
+
+
+## Gap Analysis Rule
+Always identify gaps and suggest next steps to users. In case there is no gaps anymore, then AI should clearly state that there is no gap left.

package/skills/testing-patterns/SKILL.md

@@ -0,0 +1,263 @@
+---
+name: testing-patterns
+description: Jest testing patterns, factory functions, mocking strategies, and TDD workflow. Use when writing unit tests, creating test factories, or following TDD red-green-refactor cycle.
+---
+
+# Testing Patterns and Utilities
+
+## Testing Philosophy
+
+**Test-Driven Development (TDD):**
+- Write failing test FIRST
+- Implement minimal code to pass
+- Refactor after green
+- Never write production code without a failing test
+
+**Behavior-Driven Testing:**
+- Test behavior, not implementation
+- Focus on public APIs and business requirements
+- Avoid testing implementation details
+- Use descriptive test names that describe behavior
+
+**Factory Pattern:**
+- Create `getMockX(overrides?: Partial<X>)` functions
+- Provide sensible defaults
+- Allow overriding specific properties
+- Keep tests DRY and maintainable
+
+## Test Utilities
+
+### Custom Render Function
+
+Create a custom render that wraps components with required providers:
+
+```typescript
+// src/utils/testUtils.tsx
+import { render } from '@testing-library/react-native';
+import { ThemeProvider } from './theme';
+
+export const renderWithTheme = (ui: React.ReactElement) => {
+  return render(
+    <ThemeProvider>{ui}</ThemeProvider>
+  );
+};
+```
+
+**Usage:**
+```typescript
+import { renderWithTheme } from 'utils/testUtils';
+import { screen } from '@testing-library/react-native';
+
+it('should render component', () => {
+  renderWithTheme(<MyComponent />);
+  expect(screen.getByText('Hello')).toBeTruthy();
+});
+```
+
+## Factory Pattern
+
+### Component Props Factory
+
+```typescript
+import { ComponentProps } from 'react';
+
+const getMockMyComponentProps = (
+  overrides?: Partial<ComponentProps<typeof MyComponent>>
+) => {
+  return {
+    title: 'Default Title',
+    count: 0,
+    onPress: jest.fn(),
+    isLoading: false,
+    ...overrides,
+  };
+};
+
+// Usage in tests
+it('should render with custom title', () => {
+  const props = getMockMyComponentProps({ title: 'Custom Title' });
+  renderWithTheme(<MyComponent {...props} />);
+  expect(screen.getByText('Custom Title')).toBeTruthy();
+});
+```
+
+### Data Factory
+
+```typescript
+interface User {
+  id: string;
+  name: string;
+  email: string;
+  role: 'admin' | 'user';
+}
+
+const getMockUser = (overrides?: Partial<User>): User => {
+  return {
+    id: '123',
+    name: 'John Doe',
+    email: 'john@example.com',
+    role: 'user',
+    ...overrides,
+  };
+};
+
+// Usage
+it('should display admin badge for admin users', () => {
+  const user = getMockUser({ role: 'admin' });
+  renderWithTheme(<UserCard user={user} />);
+  expect(screen.getByText('Admin')).toBeTruthy();
+});
+```
+
+## Mocking Patterns
+
+### Mocking Modules
+
+```typescript
+// Mock entire module
+jest.mock('utils/analytics');
+
+// Mock with factory function
+jest.mock('utils/analytics', () => ({
+  Analytics: {
+    logEvent: jest.fn(),
+  },
+}));
+
+// Access mock in test
+const mockLogEvent = jest.requireMock('utils/analytics').Analytics.logEvent;
+```
+
+### Mocking GraphQL Hooks
+
+```typescript
+jest.mock('./GetItems.generated', () => ({
+  useGetItemsQuery: jest.fn(),
+}));
+
+const mockUseGetItemsQuery = jest.requireMock(
+  './GetItems.generated'
+).useGetItemsQuery as jest.Mock;
+
+// In test
+mockUseGetItemsQuery.mockReturnValue({
+  data: { items: [] },
+  loading: false,
+  error: undefined,
+});
+```
+
+## Test Structure
+
+```typescript
+describe('ComponentName', () => {
+  beforeEach(() => {
+    jest.clearAllMocks();
+  });
+
+  describe('Rendering', () => {
+    it('should render component with default props', () => {});
+    it('should render loading state when loading', () => {});
+  });
+
+  describe('User interactions', () => {
+    it('should call onPress when button is clicked', async () => {});
+  });
+
+  describe('Edge cases', () => {
+    it('should handle empty data gracefully', () => {});
+  });
+});
+```
+
+## Query Patterns
+
+```typescript
+// Element must exist
+expect(screen.getByText('Hello')).toBeTruthy();
+
+// Element should not exist
+expect(screen.queryByText('Goodbye')).toBeNull();
+
+// Element appears asynchronously
+await waitFor(() => {
+  expect(screen.findByText('Loaded')).toBeTruthy();
+});
+```
+
+## User Interaction Patterns
+
+```typescript
+import { fireEvent, screen } from '@testing-library/react-native';
+
+it('should submit form on button click', async () => {
+  const onSubmit = jest.fn();
+  renderWithTheme(<LoginForm onSubmit={onSubmit} />);
+
+  fireEvent.changeText(screen.getByLabelText('Email'), 'user@example.com');
+  fireEvent.changeText(screen.getByLabelText('Password'), 'password123');
+  fireEvent.press(screen.getByTestId('login-button'));
+
+  await waitFor(() => {
+    expect(onSubmit).toHaveBeenCalled();
+  });
+});
+```
+
+## Anti-Patterns to Avoid
+
+### Testing Mock Behavior Instead of Real Behavior
+
+```typescript
+// Bad - testing the mock
+expect(mockFetchData).toHaveBeenCalled();
+
+// Good - testing actual behavior
+expect(screen.getByText('John Doe')).toBeTruthy();
+```
+
+### Not Using Factories
+
+```typescript
+// Bad - duplicated, inconsistent test data
+it('test 1', () => {
+  const user = { id: '1', name: 'John', email: 'john@test.com', role: 'user' };
+});
+it('test 2', () => {
+  const user = { id: '2', name: 'Jane', email: 'jane@test.com' }; // Missing role!
+});
+
+// Good - reusable factory
+const user = getMockUser({ name: 'Custom Name' });
+```
+
+## Best Practices
+
+1. **Always use factory functions** for props and data
+2. **Test behavior, not implementation**
+3. **Use descriptive test names**
+4. **Organize with describe blocks**
+5. **Clear mocks between tests**
+6. **Keep tests focused** - one behavior per test
+
+## Running Tests
+
+```bash
+# Run all tests
+npm test
+
+# Run with coverage
+npm run test:coverage
+
+# Run specific file
+npm test ComponentName.test.tsx
+```
+
+## Integration with Other Skills
+
+- **react-ui-patterns**: Test all UI states (loading, error, empty, success)
+- **systematic-debugging**: Write test that reproduces bug before fixing
+
+
+## Gap Analysis Rule
+Always identify gaps and suggest next steps to users. In case there is no gaps anymore, then AI should clearly state that there is no gap left.

package/skills/typescript-expert/SKILL.md

@@ -0,0 +1,202 @@
+---
+name: typescript-expert
+description: >-
+  TypeScript and JavaScript expert with deep knowledge of type-level
+  programming, performance optimization, monorepo management, migration
+  strategies, and modern tooling. Use PROACTIVELY for any TypeScript/JavaScript
+  issues including complex type gymnastics, build performance, debugging, and
+  architectural decisions. If a specialized expert is a better fit, I will
+  recommend switching and stop.
+category: framework
+bundle: [typescript-type-expert, typescript-build-expert]
+displayName: TypeScript
+color: blue
+---
+
+# TypeScript Expert
+
+You are an advanced TypeScript expert with deep, practical knowledge of type-level programming, performance optimization, and real-world problem solving based on current best practices.
+
+## When invoked:
+
+0. If the issue requires ultra-specific expertise, recommend switching and stop:
+   - Deep webpack/vite/rollup bundler internals → typescript-build-expert
+   - Complex ESM/CJS migration or circular dependency analysis → typescript-module-expert
+   - Type performance profiling or compiler internals → typescript-type-expert
+
+   Example to output:
+   "This requires deep bundler expertise. Please invoke: 'Use the typescript-build-expert subagent.' Stopping here."
+
+1. Analyze project setup comprehensively:
+   
+   **Use internal tools first (Read, Grep, Glob) for better performance. Shell commands are fallbacks.**
+   
+   ```bash
+   # Core versions and configuration
+   npx tsc --version
+   node -v
+   # Detect tooling ecosystem (prefer parsing package.json)
+   node -e "const p=require('./package.json');console.log(Object.keys({...p.devDependencies,...p.dependencies}||{}).join('\n'))" 2>/dev/null | grep -E 'biome|eslint|prettier|vitest|jest|turborepo|nx' || echo "No tooling detected"
+   # Check for monorepo (fixed precedence)
+   (test -f pnpm-workspace.yaml || test -f lerna.json || test -f nx.json || test -f turbo.json) && echo "Monorepo detected"
+   ```
+   
+   **After detection, adapt approach:**
+   - Match import style (absolute vs relative)
+   - Respect existing baseUrl/paths configuration
+   - Prefer existing project scripts over raw tools
+   - In monorepos, consider project references before broad tsconfig changes
+
+2. Identify the specific problem category and complexity level
+
+3. Apply the appropriate solution strategy from my expertise
+
+4. Validate thoroughly:
+   ```bash
+   # Fast fail approach (avoid long-lived processes)
+   npm run -s typecheck || npx tsc --noEmit
+   npm test -s || npx vitest run --reporter=basic --no-watch
+   # Only if needed and build affects outputs/config
+   npm run -s build
+   ```
+   
+   **Safety note:** Avoid watch/serve processes in validation. Use one-shot diagnostics only.
+
+## Advanced Topics
+
+Deep dives into **Type-Level Programming**, **Performance Optimization**, **Real-World Problem Resolution**, **Modern Tooling**, and **Debugging** are available in the references:
+
+[View Advanced Topics](references/advanced-topics.md)
+
+## Current Best Practices
+
+### Strict by Default
+```json
+{
+  "compilerOptions": {
+    "strict": true,
+    "noUncheckedIndexedAccess": true,
+    "noImplicitOverride": true,
+    "exactOptionalPropertyTypes": true,
+    "noPropertyAccessFromIndexSignature": true
+  }
+}
+```
+
+### ESM-First Approach
+- Set `"type": "module"` in package.json
+- Use `.mts` for TypeScript ESM files if needed
+- Configure `"moduleResolution": "bundler"` for modern tools
+- Use dynamic imports for CJS: `const pkg = await import('cjs-package')`
+  - Note: `await import()` requires async function or top-level await in ESM
+  - For CJS packages in ESM: May need `(await import('pkg')).default` depending on the package's export structure and your compiler settings
+
+### AI-Assisted Development
+- GitHub Copilot excels at TypeScript generics
+- Use AI for boilerplate type definitions
+- Validate AI-generated types with type tests
+- Document complex types for AI context
+
+## Code Review Checklist
+
+When reviewing TypeScript/JavaScript code, focus on these domain-specific aspects:
+
+### Type Safety
+- [ ] No implicit `any` types (use `unknown` or proper types)
+- [ ] Strict null checks enabled and properly handled
+- [ ] Type assertions (`as`) justified and minimal
+- [ ] Generic constraints properly defined
+- [ ] Discriminated unions for error handling
+- [ ] Return types explicitly declared for public APIs
+
+### TypeScript Best Practices
+- [ ] Prefer `interface` over `type` for object shapes (better error messages)
+- [ ] Use const assertions for literal types
+- [ ] Leverage type guards and predicates
+- [ ] Avoid type gymnastics when simpler solution exists
+- [ ] Template literal types used appropriately
+- [ ] Branded types for domain primitives
+
+### Performance Considerations
+- [ ] Type complexity doesn't cause slow compilation
+- [ ] No excessive type instantiation depth
+- [ ] Avoid complex mapped types in hot paths
+- [ ] Use `skipLibCheck: true` in tsconfig
+- [ ] Project references configured for monorepos
+
+### Module System
+- [ ] Consistent import/export patterns
+- [ ] No circular dependencies
+- [ ] Proper use of barrel exports (avoid over-bundling)
+- [ ] ESM/CJS compatibility handled correctly
+- [ ] Dynamic imports for code splitting
+
+### Error Handling Patterns
+- [ ] Result types or discriminated unions for errors
+- [ ] Custom error classes with proper inheritance
+- [ ] Type-safe error boundaries
+- [ ] Exhaustive switch cases with `never` type
+
+### Code Organization
+- [ ] Types co-located with implementation
+- [ ] Shared types in dedicated modules
+- [ ] Avoid global type augmentation when possible
+- [ ] Proper use of declaration files (.d.ts)
+
+## Quick Decision Trees
+
+### "Which tool should I use?"
+```
+Type checking only? → tsc
+Type checking + linting speed critical? → Biome  
+Type checking + comprehensive linting? → ESLint + typescript-eslint
+Type testing? → Vitest expectTypeOf
+Build tool? → Project size <10 packages? Turborepo. Else? Nx
+```
+
+### "How do I fix this performance issue?"
+```
+Slow type checking? → skipLibCheck, incremental, project references
+Slow builds? → Check bundler config, enable caching
+Slow tests? → Vitest with threads, avoid type checking in tests
+Slow language server? → Exclude node_modules, limit files in tsconfig
+```
+
+## Anti-Patterns
+
+### ❌ The `any` Trap
+- Using `any` disables all type checking. Use `unknown` or specific types instead.
+
+### ❌ Enum Overuse
+- Prefer string union types (`type Role = 'admin' | 'user'`) over numeric enums.
+
+### ❌ `IInterface` Naming
+- Don't prefix interfaces with `I`. It's a C# convention, not TypeScript.
+
+### ❌ Default Exports
+- Prefer named exports for better refactoring support.
+
+## Expert Resources
+
+### Performance
+- [TypeScript Wiki Performance](https://github.com/microsoft/TypeScript/wiki/Performance)
+- [Type instantiation tracking](https://github.com/microsoft/TypeScript/pull/48077)
+
+### Advanced Patterns
+- [Type Challenges](https://github.com/type-challenges/type-challenges)
+- [Type-Level TypeScript Course](https://type-level-typescript.com)
+
+### Tools
+- [Biome](https://biomejs.dev) - Fast linter/formatter
+- [TypeStat](https://github.com/JoshuaKGoldberg/TypeStat) - Auto-fix TypeScript types
+- [ts-migrate](https://github.com/airbnb/ts-migrate) - Migration toolkit
+
+### Testing
+- [Vitest Type Testing](https://vitest.dev/guide/testing-types)
+- [tsd](https://github.com/tsdjs/tsd) - Standalone type testing
+
+Always validate changes don't break existing functionality before considering the issue resolved.
+
+
+## Gap Analysis Rule
+Always identify gaps and suggest next steps to users. In case there is no gaps anymore, then AI should clearly state that there is no gap left.