aramidefemi
16 verified skills16 total stars
skills/truncation-stress-checklist
# name Truncation Stress Checklist ## description Evaluates overflow and truncation resilience for long localized strings. ## when to use - Before localization release. - After locale files are updated. ## inputs - Translated strings - UI breakpoints - Component width constraints ## strict output template ```md ## Truncation Stress Checklist - [ ] Primary CTAs render fully - severity if failed: `Blocker` - [ ] Form labels do not clip - severity if failed: `Major` - [ ] Navigation items do no
tools1
skills/frontend-string-extractor
# name Frontend String Extractor ## description Extracts frontend-facing English strings into a canonical key candidate list. ## when to use - Before translation work starts. - When hardcoded UI copy is suspected. ## inputs - Frontend source files - Existing locale key patterns ## strict output template ```md ## Frontend String Extraction ### New String Candidates - text: `<english text>` - suggested_key: `<key.path>` - severity: `<Blocker|Major|Minor>` ### Existing Key Matches - text: `<en
development1
skills/system-defender-existing-impl-scan
# name System Defender Existing Implementation Scan ## description Finds reusable implementation paths and avoids duplicate logic. ## when to use - During early feature scoping. - When similar behavior may already exist. ## inputs - Feature intent - Candidate files/modules ## strict output template ```md ## Existing Implementation Scan ### Reuse Candidates - `<module/path>` - relevance: `<high|medium|low>` - severity if ignored: `<Major|Minor>` ### Extension Path - Primary extension target:
tools1
skills/shopify-section-naming-conventions
# name Shopify Section Naming Conventions ## description Normalizes section, class, and setting names for consistency and reuse. ## when to use - Before implementing Shopify sections. - During review for naming drift. ## inputs - Existing theme naming patterns - Proposed section/component names ## strict output template ```md ## Naming Convention Report ### Approved Names - `<name>` - reason: `<short>` ### Rejected Names - `<name>` - severity: `<Major|Minor>` - reason: `<short>` ### Final
business1
skills/rtl-risk-checklist
# name RTL Risk Checklist ## description Identifies directional and layout risks when enabling RTL locales. ## when to use - During locale rollout planning. - Before QA sign-off for RTL support. ## inputs - UI flow list - Components with directional behavior - Locale set including RTL languages ## strict output template ```md ## RTL Risk Checklist - [ ] Direction-sensitive layout validated - severity if failed: `Blocker` - [ ] Text alignment rules mapped - severity if failed: `Major` - [ ] I
testing1
skills/backend-pr-checklist
# name Backend PR Checklist ## description Validates backend changes for safety, tests, and regression coverage. ## when to use - Before opening or approving backend PRs. ## inputs - Changed backend files - Test results - Risk reports ## strict output template ```md ## Backend PR Checklist - [ ] No unresolved `Blocker` - [ ] `Major` issues addressed or documented - [ ] Tests added/updated for changed behavior - [ ] Shared dependency impact reviewed - [ ] Rollback/risk note included ``` ## r
development1
skills/frontend-pr-checklist
# name Frontend PR Checklist ## description Checks frontend changes for readability, UX, state handling, and tests. ## when to use - Before opening or approving frontend PRs. ## inputs - Changed frontend files - Visual/UX notes - Test status ## strict output template ```md ## Frontend PR Checklist - [ ] No unresolved `Blocker` - [ ] `Major` issues resolved or accepted - [ ] Error/loading/empty/success states covered - [ ] Naming and duplication checks passed - [ ] Tests updated for changed f
development1
skills/locale-file-fill-plan
# name Locale File Fill Plan ## description Creates an ordered, minimal plan to fill missing locale keys safely. ## when to use - After coverage and risk reports are complete. - Before `locale-implementer` runs. ## inputs - Locale gap matrix - Approved key conventions - Glossary and translation source ## strict output template ```md ## Locale File Fill Plan ### Preconditions - unresolved_blockers: `<yes|no>` - open_questions: `<yes|no>` ### Ordered Fill Steps 1. `<locale file>` - keys: `<co
data-ai1
skills/locale-gap-matrix
# name Locale Gap Matrix ## description Builds a per-locale coverage matrix for all required translation keys. ## when to use - Before filling locale files. - During translation QA and release checks. ## inputs - Canonical key set - Supported locale list - Current locale files ## strict output template ```md ## Locale Gap Matrix | Key | Locale | Status (Present/Missing/Stale) | Severity | |---|---|---|---| | `<key.path>` | `<locale>` | `<status>` | `<Blocker|Major|Minor>` | ## Coverage Summ
development1
skills/locale-key-normalizer
# name Locale Key Normalizer ## description Applies consistent naming and grouping standards to locale keys. ## when to use - After string extraction. - Before locale file updates. ## inputs - Candidate key list - Existing locale naming conventions ## strict output template ```md ## Locale Key Normalization ### Accepted Keys - `<key.path>` - reason: `<short>` ### Renamed Keys - from: `<old>` -> to: `<new>` - severity: `<Major|Minor>` ### Rejected Keys - `<key.path>` - reason: `<short>` - s
tools1
skills/screenshot-to-elements-format
# name Screenshot To Elements Format ## description Standardizes screenshot decomposition into a complete element inventory format. ## when to use - When receiving UI screenshots for implementation. - Before DOM planning. ## inputs - Screenshot(s) - Context notes (viewport, locale, state) ## strict output template ```md ## Element Inventory | # | Element Type | Visible Text/Label | Position Hint | Severity | |---|---|---|---|---| | 1 | `<type>` | `<text>` | `<hint>` | `<Blocker|Major|Minor>`
development1
skills/shopify-section-schema-writer
# name Shopify Section Schema Writer ## description Produces section schema plans aligned to approved UI structure and naming. ## when to use - Before creating a new Shopify section. - When validating schema/settings completeness. ## inputs - Verified element inventory - DOM map and style constraints - Merchant config requirements ## strict output template ```md ## Shopify Section Schema Plan ### Section Identity - name: `<section name>` - handle: `<section handle>` ### Settings Model - `<s
documentation1
skills/system-defender-feature-checklist
# name System Defender Feature Checklist ## description Creates a reuse-first readiness checklist for a requested feature. ## when to use - Before any implementation planning. - When validating if existing modules can be extended. ## inputs - Feature request - Acceptance criteria - Known touched modules ## strict output template ```md ## Feature Checklist - [ ] Existing module candidate identified (`Blocker` if none) - [ ] Extension path defined - [ ] New abstraction necessity justified - [
tools1
skills/system-defender-minimal-change-path
# name System Defender Minimal Change Path ## description Converts analysis into a minimal approved execution path. ## when to use - After reuse and regression scans. - Before calling implementers. ## inputs - Reuse report - Regression report - Test/gap report ## strict output template ```md ## Minimal Change Path ### Approved Reuse Path - `<path/module>` ### Ordered Steps 1. `<step>` 2. `<step>` ### Risk Notes - `<risk>` - severity: `<Blocker|Major|Minor>` ### Minor Items To Skip - `<ite
testing1
skills/system-defender-regression-scan
# name System Defender Regression Scan ## description Assesses regression risk from dependencies, shared modules, and side effects. ## when to use - After a draft minimal plan exists. - Before any implementer agent runs. ## inputs - Proposed change path - Shared module map - Critical flows ## strict output template ```md ## Regression Scan ### Shared Modules At Risk - `<module>` - severity: `<Blocker|Major|Minor>` - reason: `<short>` ### Side Effects - `<effect>` - severity: `<Blocker|Major
testing1
skills/visual-diff-report-format
# name Visual Diff Report Format ## description Enforces a consistent severity-based visual diff reporting structure. ## when to use - Any screenshot vs implementation comparison. - QA gate before sign-off. ## inputs - Baseline screenshot - Current screenshot - Optional approved specs ## strict output template ```md ## Diff Report ### Severity Summary - Blocker: `<count>` - Major: `<count>` - Minor: `<count>` ### Findings - `<location>` - `<difference>` - severity: `<Blocker|Major|Minor>`
development1