@preapexis/pi-kit 1.0.0 → 1.0.7

package/skills/component-implementation/SKILL.md

@@ -1,80 +1,80 @@
----
-name: component-implementation
-description: Builds or modifies frontend components using the project's existing component patterns, styling system, accessibility rules, and test conventions.
----
-
----
-
-# Component Implementation
-
-Use this skill when creating or modifying frontend UI components.
-
-Do not use this skill for backend-only changes, database work, deployment work, or general refactors unless they directly affect frontend components.
-
-## Before Editing
-
-Inspect existing nearby components to understand:
-
-- naming conventions
-- file layout
-- props style
-- styling approach
-- accessibility patterns
-- test style
-- story/demo pattern, if any
-
-If the component requirements are unclear, ask questions before editing.
-
-## Component Rules
-
-- Prefer small, focused components.
-- Keep props clear and typed.
-- Avoid unnecessary state.
-- Prefer controlled inputs when the project already uses them.
-- Reuse existing design-system components.
-- Reuse existing icons, spacing, colors, and typography tokens.
-- Do not add a new UI package unless explicitly asked.
-- Avoid large rewrites of existing components.
-- Match the project's existing component style.
-
-## Accessibility Rules
-
-Check:
-
-- semantic HTML
-- keyboard navigation
-- visible focus states
-- labels for inputs
-- button vs link usage
-- alt text for meaningful images
-- ARIA only when necessary
-- color contrast risks
-
-## State Rules
-
-- Keep local UI state local.
-- Do not introduce global state unless needed.
-- Avoid duplicating server state in local state.
-- Preserve existing loading, error, and empty states.
-
-## After Editing
-
-Run the narrowest relevant command if available:
-
-- component test
-- unit test
-- typecheck
-- lint
-- storybook check
-
-If checks are not available or cannot run, explain why.
-
-## Output
-
-Explain:
-
-1. What component changed
-2. Why the approach matches existing patterns
-3. Accessibility considerations
-4. Tests or checks run
-5. Any remaining risks
+---
+name: component-implementation
+description: Builds or modifies frontend components using the project's existing component patterns, styling system, accessibility rules, and test conventions.
+---
+
+---
+
+# Component Implementation
+
+Use this skill when creating or modifying frontend UI components.
+
+Do not use this skill for backend-only changes, database work, deployment work, or general refactors unless they directly affect frontend components.
+
+## Before Editing
+
+Inspect existing nearby components to understand:
+
+- naming conventions
+- file layout
+- props style
+- styling approach
+- accessibility patterns
+- test style
+- story/demo pattern, if any
+
+If the component requirements are unclear, ask questions before editing.
+
+## Component Rules
+
+- Prefer small, focused components.
+- Keep props clear and typed.
+- Avoid unnecessary state.
+- Prefer controlled inputs when the project already uses them.
+- Reuse existing design-system components.
+- Reuse existing icons, spacing, colors, and typography tokens.
+- Do not add a new UI package unless explicitly asked.
+- Avoid large rewrites of existing components.
+- Match the project's existing component style.
+
+## Accessibility Rules
+
+Check:
+
+- semantic HTML
+- keyboard navigation
+- visible focus states
+- labels for inputs
+- button vs link usage
+- alt text for meaningful images
+- ARIA only when necessary
+- color contrast risks
+
+## State Rules
+
+- Keep local UI state local.
+- Do not introduce global state unless needed.
+- Avoid duplicating server state in local state.
+- Preserve existing loading, error, and empty states.
+
+## After Editing
+
+Run the narrowest relevant command if available:
+
+- component test
+- unit test
+- typecheck
+- lint
+- storybook check
+
+If checks are not available or cannot run, explain why.
+
+## Output
+
+Explain:
+
+1. What component changed
+2. Why the approach matches existing patterns
+3. Accessibility considerations
+4. Tests or checks run
+5. Any remaining risks

package/skills/frontend-onboarding/SKILL.md

@@ -1,76 +1,76 @@
----
-name: frontend-onboarding
-description: Understands the frontend app structure, framework, routing, build tools, styling system, and test setup. Use when starting work in an unfamiliar frontend repo or feature area.
----
-
----
-
-# Frontend Onboarding
-
-Use this skill before making frontend changes in an unfamiliar codebase.
-
-This skill is read-only. Do not edit files during onboarding unless explicitly asked.
-
-## Inspect First
-
-Read the most relevant files:
-
-- README.md
-- AGENTS.md
-- package.json
-- vite.config._ / next.config._ / webpack.config._ / astro.config._ / svelte.config.\*
-- tsconfig.json
-- eslint.config._ / .eslintrc._
-- prettier config
-- tailwind.config.\* / theme files / design-system files
-- src/ or app/
-- routes/pages directory
-- components directory
-- tests directory
-- storybook config, if present
-
-## Identify
-
-Find and summarize:
-
-1. Frontend framework
-2. Routing approach
-3. State management approach
-4. Styling approach
-5. Component organization
-6. API/data fetching pattern
-7. Form handling pattern
-8. Test setup
-9. Build/lint/typecheck commands
-10. Important files that should be edited carefully
-
-## Safety Rules
-
-- Do not change global styles.
-- Do not introduce new UI libraries.
-- Do not change routing, auth, or data-fetching behavior casually.
-- Do not edit generated files or build output.
-- Prefer existing patterns over new abstractions.
-- If the frontend structure is unclear, ask questions before suggesting changes.
-
-## Output
-
-Return:
-
-# Frontend Summary
-
-# App Structure
-
-# Styling System
-
-# State and Data Flow
-
-# Forms and Validation
-
-# Test Commands
-
-# Risks and Careful Areas
-
-# Suggested Frontend Agent Rules
-
-# Open Questions
+---
+name: frontend-onboarding
+description: Understands the frontend app structure, framework, routing, build tools, styling system, and test setup. Use when starting work in an unfamiliar frontend repo or feature area.
+---
+
+---
+
+# Frontend Onboarding
+
+Use this skill before making frontend changes in an unfamiliar codebase.
+
+This skill is read-only. Do not edit files during onboarding unless explicitly asked.
+
+## Inspect First
+
+Read the most relevant files:
+
+- README.md
+- AGENTS.md
+- package.json
+- vite.config._ / next.config._ / webpack.config._ / astro.config._ / svelte.config.\*
+- tsconfig.json
+- eslint.config._ / .eslintrc._
+- prettier config
+- tailwind.config.\* / theme files / design-system files
+- src/ or app/
+- routes/pages directory
+- components directory
+- tests directory
+- storybook config, if present
+
+## Identify
+
+Find and summarize:
+
+1. Frontend framework
+2. Routing approach
+3. State management approach
+4. Styling approach
+5. Component organization
+6. API/data fetching pattern
+7. Form handling pattern
+8. Test setup
+9. Build/lint/typecheck commands
+10. Important files that should be edited carefully
+
+## Safety Rules
+
+- Do not change global styles.
+- Do not introduce new UI libraries.
+- Do not change routing, auth, or data-fetching behavior casually.
+- Do not edit generated files or build output.
+- Prefer existing patterns over new abstractions.
+- If the frontend structure is unclear, ask questions before suggesting changes.
+
+## Output
+
+Return:
+
+# Frontend Summary
+
+# App Structure
+
+# Styling System
+
+# State and Data Flow
+
+# Forms and Validation
+
+# Test Commands
+
+# Risks and Careful Areas
+
+# Suggested Frontend Agent Rules
+
+# Open Questions

package/skills/frontend-quality/SKILL.md

@@ -1,85 +1,85 @@
----
-name: frontend-quality
-description: Reviews frontend code for accessibility, responsiveness, performance, UX states, browser behavior, and maintainability.
----
-
----
-
-# Frontend Quality Review
-
-Use this skill when reviewing or improving frontend quality.
-
-Do not edit files unless explicitly asked.
-
-## Review Areas
-
-Check for:
-
-- broken UI states
-- missing loading states
-- missing error states
-- missing empty states
-- poor responsive behavior
-- keyboard accessibility issues
-- focus management issues
-- incorrect semantic HTML
-- unnecessary re-renders
-- expensive rendering logic
-- unstable keys in lists
-- hydration issues
-- client/server boundary mistakes
-- inconsistent styling
-- duplicated UI logic
-- missing tests
-
-## Accessibility Checklist
-
-Verify:
-
-- interactive elements are keyboard reachable
-- form fields have labels
-- modals/dialogs manage focus correctly
-- buttons are buttons and links are links
-- images have appropriate alt text
-- errors are announced or clearly visible
-- focus states are not removed
-- ARIA is not used incorrectly
-
-## Performance Checklist
-
-Look for:
-
-- large unnecessary client bundles
-- avoidable client components
-- repeated expensive computations
-- unnecessary effects
-- unnecessary global state
-- unoptimized images
-- layout shift risks
-- over-fetching data
-
-## Rules
-
-- Prefer specific findings with file paths.
-- Do not report generic advice as a finding.
-- If unsure, mark it as a question.
-- Prioritize user-visible issues first.
-- Suggest safe, small follow-up fixes.
-
-## Output
-
-Return:
-
-# Critical Issues
-
-# Recommended Fixes
-
-# Accessibility Notes
-
-# Performance Notes
-
-# Tests to Add
-
-# Safe Follow-Up Changes
-
-# Open Questions
+---
+name: frontend-quality
+description: Reviews frontend code for accessibility, responsiveness, performance, UX states, browser behavior, and maintainability.
+---
+
+---
+
+# Frontend Quality Review
+
+Use this skill when reviewing or improving frontend quality.
+
+Do not edit files unless explicitly asked.
+
+## Review Areas
+
+Check for:
+
+- broken UI states
+- missing loading states
+- missing error states
+- missing empty states
+- poor responsive behavior
+- keyboard accessibility issues
+- focus management issues
+- incorrect semantic HTML
+- unnecessary re-renders
+- expensive rendering logic
+- unstable keys in lists
+- hydration issues
+- client/server boundary mistakes
+- inconsistent styling
+- duplicated UI logic
+- missing tests
+
+## Accessibility Checklist
+
+Verify:
+
+- interactive elements are keyboard reachable
+- form fields have labels
+- modals/dialogs manage focus correctly
+- buttons are buttons and links are links
+- images have appropriate alt text
+- errors are announced or clearly visible
+- focus states are not removed
+- ARIA is not used incorrectly
+
+## Performance Checklist
+
+Look for:
+
+- large unnecessary client bundles
+- avoidable client components
+- repeated expensive computations
+- unnecessary effects
+- unnecessary global state
+- unoptimized images
+- layout shift risks
+- over-fetching data
+
+## Rules
+
+- Prefer specific findings with file paths.
+- Do not report generic advice as a finding.
+- If unsure, mark it as a question.
+- Prioritize user-visible issues first.
+- Suggest safe, small follow-up fixes.
+
+## Output
+
+Return:
+
+# Critical Issues
+
+# Recommended Fixes
+
+# Accessibility Notes
+
+# Performance Notes
+
+# Tests to Add
+
+# Safe Follow-Up Changes
+
+# Open Questions

package/skills/safe-coding/SKILL.md

@@ -1,48 +1,48 @@
----
-name: safe-coding
-description: Applies safe, reviewable coding practices when modifying any file. Enforces small diffs, pre-read, no secrets, no lockfiles, and post-edit verification.
----
-
----
-
-# Safe Coding
-
-Use this skill when modifying code.
-
-## Before Editing
-
-- Read the file or files you plan to change before making edits.
-- Understand the existing patterns, naming conventions, and structure.
-- Identify related files that may be affected by the change.
-- If the task is unclear, ask questions before editing.
-
-## Rules
-
-- Make small, focused, reviewable changes.
-- Preserve existing behavior unless explicitly asked to change it.
-- Do not edit secrets, env files, lockfiles, build output, coverage reports, or `.git` internals.
-- Prefer targeted edits over full rewrites.
-- Do not install packages, delete files, or rewrite history without clear user approval.
-- Prefer additive changes; avoid destructive updates.
-- Explain risky or irreversible operations before executing them.
-- Match the project’s existing style and conventions.
-
-## After Editing
-
-Run the narrowest relevant verification command if available:
-
-- unit or component test
-- typecheck
-- lint
-- integration test, if applicable
-
-If verification cannot be run, explain why.
-
-## Output
-
-Explain:
-
-1. What changed and why
-2. How existing behavior is preserved
-3. Any risks or follow-up actions needed
-4. Verification command run and its result
+---
+name: safe-coding
+description: Applies safe, reviewable coding practices when modifying any file. Enforces small diffs, pre-read, no secrets, no lockfiles, and post-edit verification.
+---
+
+---
+
+# Safe Coding
+
+Use this skill when modifying code.
+
+## Before Editing
+
+- Read the file or files you plan to change before making edits.
+- Understand the existing patterns, naming conventions, and structure.
+- Identify related files that may be affected by the change.
+- If the task is unclear, ask questions before editing.
+
+## Rules
+
+- Make small, focused, reviewable changes.
+- Preserve existing behavior unless explicitly asked to change it.
+- Do not edit secrets, env files, lockfiles, build output, coverage reports, or `.git` internals.
+- Prefer targeted edits over full rewrites.
+- Do not install packages, delete files, or rewrite history without clear user approval.
+- Prefer additive changes; avoid destructive updates.
+- Explain risky or irreversible operations before executing them.
+- Match the project’s existing style and conventions.
+
+## After Editing
+
+Run the narrowest relevant verification command if available:
+
+- unit or component test
+- typecheck
+- lint
+- integration test, if applicable
+
+If verification cannot be run, explain why.
+
+## Output
+
+Explain:
+
+1. What changed and why
+2. How existing behavior is preserved
+3. Any risks or follow-up actions needed
+4. Verification command run and its result