Frontend Engineering — Vol. 6

Overview

9 prompts with one job: helping programming & dev move faster with AI. That's the Frontend Engineering — Vol. 6. Highlights include “Node.js Automation Script Developer”, “Base64 Promt” and “Prompt Writer for Specific Project”. They're meant to be a starting point you edit, not a finished answer, which is exactly why they work across so many situations. Copy, paste into ChatGPT, Claude and Gemini, and refine the output in a reply or two.

• 1.Develop a Notion Clone Application

  Copy

  Act as a Software Developer tasked with creating a Notion clone application. Your goal is to replicate the core features of Notion, enabling users to efficiently manage notes, tasks, and databases in a collaborative environment.\n\nYour task is to:\n- Design an intuitive user interface that mimics Notion's flexible layout.\n- Implement key functionalities such as databases, markdown support, and real-time collaboration.\n- Ensure a seamless experience across web and mobile platforms.\n- Incorporate integrations with other productivity tools.\n\nRules:\n- Use modern web technologies such as React or Vue.js for the frontend.\n- Implement a robust backend using Node.js or Django.\n- Prioritize user privacy and data security throughout the application.\n- Make the application scalable to handle a large number of users.\n\nVariables:\n- ${framework:React} - Preferred frontend framework\n- ${backend:Node.js} - Preferred backend technology

• 2.AST Code Analysis Superpower

  Copy

  ---
  name: ast-code-analysis-superpower
  description: AST-based code pattern analysis using ast-grep for security, performance, and structural issues. Use when (1) reviewing code for security vulnerabilities, (2) analyzing React hook dependencies or performance patterns, (3) detecting structural anti-patterns across large codebases, (4) needing systematic pattern matching beyond manual inspection.
  ---
  
  # AST-Grep Code Analysis
  
  AST pattern matching identifies code issues through structural recognition rather than line-by-line reading. Code structure reveals hidden relationships, vulnerabilities, and anti-patterns that surface inspection misses.
  
  ## Configuration
  
  - **Target Language**: ${language:javascript}
  - **Analysis Focus**: ${analysis_focus:security}
  - **Severity Level**: ${severity_level:ERROR}
  - **Framework**: ${framework:React}
  - **Max Nesting Depth**: ${max_nesting:3}
  
  ## Prerequisites
  
  ```bash
  # Install ast-grep (if not available)
  npm install -g @ast-grep/cli
  # Or: mise install -g ast-grep
  ```
  
  ## Decision Tree: When to Use AST Analysis
  
  ```
  Code review needed?
  |
  +-- Simple code (<${simple_code_lines:50} lines, obvious structure) --> Manual review
  |
  +-- Complex code (nested, multi-file, abstraction layers)
      |
      +-- Security review required? --> Use security patterns
      +-- Performance analysis? --> Use performance patterns
      +-- Structural quality? --> Use structure patterns
      +-- Cross-file patterns? --> Run with --include glob
  ```
  
  ## Pattern Categories
  
  | Category | Focus | Common Findings |
  |----------|-------|-----------------|
  | Security | Crypto functions, auth flows | Hardcoded secrets, weak tokens |
  | Performance | Hooks, loops, async | Infinite re-renders, memory leaks |
  | Structure | Nesting, complexity | Deep conditionals, maintainability |
  
  ## Essential Patterns
  
  ### Security: Hardcoded Secrets
  
  ```yaml
  # sg-rules/security/hardcoded-secrets.yml
  id: hardcoded-secrets
  language: ${language:javascript}
  rule:
    pattern: |
      const $VAR = '$LITERAL';
      $FUNC($VAR, ...)
    meta:
      severity: ${severity_level:ERROR}
      message: "Potential hardcoded secret detected"
  ```
  
  ### Security: Insecure Token Generation
  
  ```yaml
  # sg-rules/security/insecure-tokens.yml
  id: insecure-token-generation
  language: ${language:javascript}
  rule:
    pattern: |
      btoa(JSON.stringify($OBJ) + '.' + $SECRET)
    meta:
      severity: ${severity_level:ERROR}
      message: "Insecure token generation using base64"
  ```
  
  ### Performance: ${framework:React} Hook Dependencies
  
  ```yaml
  # sg-rules/performance/react-hook-deps.yml
  id: react-hook-dependency-array
  language: typescript
  rule:
    pattern: |
      useEffect(() => {
        $BODY
      }, [$FUNC])
    meta:
      severity: WARNING
      message: "Function dependency may cause infinite re-renders"
  ```
  
  ### Structure: Deep Nesting
  
  ```yaml
  # sg-rules/structure/deep-nesting.yml
  id: deep-nesting
  language: ${language:javascript}
  rule:
    any:
      - pattern: |
          if ($COND1) {
            if ($COND2) {
              if ($COND3) {
                $BODY
              }
            }
          }
      - pattern: |
          for ($INIT) {
            for ($INIT2) {
              for ($INIT3) {
                $BODY
              }
            }
          }
    meta:
      severity: WARNING
      message: "Deep nesting (>${max_nesting:3} levels) - consider refactoring"
  ```
  
  ## Running Analysis
  
  ```bash
  # Security scan
  ast-grep run -r sg-rules/security/
  
  # Performance scan on ${framework:React} files
  ast-grep run -r sg-rules/performance/ --include="*.tsx,*.jsx"
  
  # Full scan with JSON output
  ast-grep run -r sg-rules/ --format=json > analysis-report.json
  
  # Interactive mode for investigation
  ast-grep run -r sg-rules/ --interactive
  ```
  
  ## Pattern Writing Checklist
  
  - [ ] Pattern matches specific anti-pattern, not general code
  - [ ] Uses `inside` or `has` for context constraints
  - [ ] Includes `not` constraints to reduce false positives
  - [ ] Separate rules per language (JS vs TS)
  - [ ] Appropriate severity (${severity_level:ERROR}/WARNING/INFO)
  
  ## Common Mistakes
  
  | Mistake | Symptom | Fix |
  |---------|---------|-----|
  | Too generic patterns | Many false positives | Add context constraints |
  | Missing `inside` | Matches wrong locations | Scope with parent context |
  | No `not` clauses | Matches valid patterns | Exclude known-good cases |
  | JS patterns on TS | Type annotations break match | Create language-specific rules |
  
  ## Verification Steps
  
  1. **Test pattern accuracy**: Run on known-vulnerable code samples
  2. **Check false positive rate**: Review first ${sample_size:10} matches manually
  3. **Validate severity**: Confirm ${severity_level:ERROR}-level findings are actionable
  4. **Cross-file coverage**: Verify pattern runs across intended scope
  
  ## Example Output
  
  ```
  $ ast-grep run -r sg-rules/
  src/components/UserProfile.jsx:15: ${severity_level:ERROR} [insecure-tokens] Insecure token generation
  src/hooks/useAuth.js:8: ${severity_level:ERROR} [hardcoded-secrets] Potential hardcoded secret
  src/components/Dashboard.tsx:23: WARNING [react-hook-deps] Function dependency
  src/utils/processData.js:45: WARNING [deep-nesting] Deep nesting detected
  
  Found 4 issues (2 errors, 2 warnings)
  ```
  
  ## Project Setup
  
  ```bash
  # Initialize ast-grep in project
  ast-grep init
  
  # Create rule directories
  mkdir -p sg-rules/{security,performance,structure}
  
  # Add to CI pipeline
  # .github/workflows/lint.yml
  # - run: ast-grep run -r sg-rules/ --format=json
  ```
  
  ## Custom Pattern Templates
  
  ### ${framework:React} Specific Patterns
  
  ```yaml
  # Missing key in list rendering
  id: missing-list-key
  language: typescript
  rule:
    pattern: |
      $ARRAY.map(($ITEM) => <$COMPONENT $$$PROPS />)
    constraints:
      $PROPS:
        not:
          has:
            pattern: 'key={$_}'
    meta:
      severity: WARNING
      message: "Missing key prop in list rendering"
  ```
  
  ### Async/Await Patterns
  
  ```yaml
  # Missing error handling in async
  id: unhandled-async
  language: ${language:javascript}
  rule:
    pattern: |
      async function $NAME($$$) {
        $$$BODY
      }
    constraints:
      $BODY:
        not:
          has:
            pattern: 'try { $$$ } catch'
    meta:
      severity: WARNING
      message: "Async function without try-catch error handling"
  ```
  
  ## Integration with CI/CD
  
  ```yaml
  # GitHub Actions example
  name: AST Analysis
  on: [push, pull_request]
  jobs:
    analyze:
      runs-on: ubuntu-latest
      steps:
        - uses: actions/checkout@v4
        - name: Install ast-grep
          run: npm install -g @ast-grep/cli
        - name: Run analysis
          run: |
            ast-grep run -r sg-rules/ --format=json > report.json
            if grep -q '"severity": "${severity_level:ERROR}"' report.json; then
              echo "Critical issues found!"
              exit 1
            fi
  ```

• 3.Accessibility Expert

  Copy

  ---
  name: accessibility-expert
  description: Tests and remediates accessibility issues for WCAG compliance and assistive technology compatibility. Use when (1) auditing UI for accessibility violations, (2) implementing keyboard navigation or screen reader support, (3) fixing color contrast or focus indicator issues, (4) ensuring form accessibility and error handling, (5) creating ARIA implementations.
  ---
  
  # Accessibility Testing and Remediation
  
  ## Configuration
  
  - **WCAG Level**: ${wcag_level:AA}
  - **Target Component**: ${component_name:Application}
  - **Compliance Standard**: ${compliance_standard:WCAG 2.1}
  - **Testing Scope**: ${testing_scope:full-audit}
  - **Screen Reader**: ${screen_reader:NVDA}
  
  ## WCAG 2.1 Quick Reference
  
  ### Compliance Levels
  | Level | Requirement | Common Issues |
  |-------|-------------|---------------|
  | A | Minimum baseline | Missing alt text, no keyboard access, missing form labels |
  | ${wcag_level:AA} | Standard target | Contrast < 4.5:1, missing focus indicators, poor heading structure |
  | AAA | Enhanced | Contrast < 7:1, sign language, extended audio description |
  
  ### Four Principles (POUR)
  1. **Perceivable**: Content available to senses (alt text, captions, contrast)
  2. **Operable**: UI navigable by all input methods (keyboard, touch, voice)
  3. **Understandable**: Content and UI predictable and readable
  4. **Robust**: Works with current and future assistive technologies
  
  ## Violation Severity Matrix
  
  ```
  CRITICAL (fix immediately):
    - No keyboard access to interactive elements
    - Missing form labels
    - Images without alt text
    - Auto-playing audio without controls
    - Keyboard traps
  
  HIGH (fix before release):
    - Contrast ratio below ${min_contrast_ratio:4.5}:1 (text) or 3:1 (large text)
    - Missing skip links
    - Incorrect heading hierarchy
    - Focus not visible
    - Missing error identification
  
  MEDIUM (fix in next sprint):
    - Inconsistent navigation
    - Missing landmarks
    - Poor link text ("click here")
    - Missing language attribute
    - Complex tables without headers
  
  LOW (backlog):
    - Timing adjustments
    - Multiple ways to find content
    - Context-sensitive help
  ```
  
  ## Testing Decision Tree
  
  ```
  Start: What are you testing?
  |
  +-- New Component
  |   +-- Has interactive elements? --> Keyboard Navigation Checklist
  |   +-- Has text content? --> Check contrast + heading structure
  |   +-- Has images? --> Verify alt text appropriateness
  |   +-- Has forms? --> Form Accessibility Checklist
  |
  +-- Existing Page/Feature
  |   +-- Run automated scan first (axe-core, Lighthouse)
  |   +-- Manual keyboard walkthrough
  |   +-- Screen reader verification
  |   +-- Color contrast spot-check
  |
  +-- Third-party Widget
      +-- Check ARIA implementation
      +-- Verify keyboard support
      +-- Test with screen reader
      +-- Document limitations
  ```
  
  ## Keyboard Navigation Checklist
  
  ```markdown
  [ ] All interactive elements reachable via Tab
  [ ] Tab order follows visual/logical flow
  [ ] Focus indicator visible (${focus_indicator_width:2}px+ outline, 3:1 contrast)
  [ ] No keyboard traps (can Tab out of all elements)
  [ ] Skip link as first focusable element
  [ ] Enter activates buttons and links
  [ ] Space activates checkboxes and buttons
  [ ] Arrow keys navigate within components (tabs, menus, radio groups)
  [ ] Escape closes modals and dropdowns
  [ ] Modals trap focus until dismissed
  ```
  
  ## Screen Reader Testing Patterns
  
  ### Essential Announcements to Verify
  ```
  Interactive Elements:
    Button: "[label], button"
    Link: "[text], link"
    Checkbox: "[label], checkbox, [checked/unchecked]"
    Radio: "[label], radio button, [selected], [position] of [total]"
    Combobox: "[label], combobox, [collapsed/expanded]"
  
  Dynamic Content:
    Loading: Use aria-busy="true" on container
    Status: Use role="status" for non-critical updates
    Alert: Use role="alert" for critical messages
    Live regions: aria-live="${aria_live_politeness:polite}"
  
  Forms:
    Required: "required" announced with label
    Invalid: "invalid entry" with error message
    Instructions: Announced with label via aria-describedby
  ```
  
  ### Testing Sequence
  1. Navigate entire page with Tab key, listening to announcements
  2. Test headings navigation (H key in screen reader)
  3. Test landmark navigation (D key / rotor)
  4. Test tables (T key, arrow keys within table)
  5. Test forms (F key, complete form submission)
  6. Test dynamic content updates (verify live regions)
  
  ## Color Contrast Requirements
  
  | Text Type | Minimum Ratio | Enhanced (AAA) |
  |-----------|---------------|----------------|
  | Normal text (<${large_text_threshold:18}pt) | ${min_contrast_ratio:4.5}:1 | 7:1 |
  | Large text (>=${large_text_threshold:18}pt or 14pt bold) | 3:1 | 4.5:1 |
  | UI components & graphics | 3:1 | N/A |
  | Focus indicators | 3:1 | N/A |
  
  ### Contrast Check Process
  ```
  1. Identify all foreground/background color pairs
  2. Calculate contrast ratio: (L1 + 0.05) / (L2 + 0.05)
     where L1 = lighter luminance, L2 = darker luminance
  3. Common failures to check:
     - Placeholder text (often too light)
     - Disabled state (exempt but consider usability)
     - Links within text (must distinguish from text)
     - Error/success states on colored backgrounds
     - Text over images (use overlay or text shadow)
  ```
  
  ## ARIA Implementation Guide
  
  ### First Rule of ARIA
  Use native HTML elements when possible. ARIA is for custom widgets only.
  
  ```html
  <!-- WRONG: ARIA on native element -->
  <div role="button" tabindex="0">Submit</div>
  
  <!-- RIGHT: Native button -->
  <button type="submit">Submit</button>
  ```
  
  ### When ARIA is Needed
  ```html
  <!-- Custom tabs -->
  <div role="tablist">
    <button role="tab" aria-selected="true" aria-controls="panel1">Tab 1</button>
    <button role="tab" aria-selected="false" aria-controls="panel2">Tab 2</button>
  </div>
  <div role="tabpanel" id="panel1">Content 1</div>
  <div role="tabpanel" id="panel2" hidden>Content 2</div>
  
  <!-- Expandable section -->
  <button aria-expanded="false" aria-controls="content">Show details</button>
  <div id="content" hidden>Expandable content</div>
  
  <!-- Modal dialog -->
  <div role="dialog" aria-modal="true" aria-labelledby="title">
    <h2 id="title">Dialog Title</h2>
    <!-- content -->
  </div>
  
  <!-- Live region for dynamic updates -->
  <div aria-live="${aria_live_politeness:polite}" aria-atomic="true">
    <!-- Status messages injected here -->
  </div>
  ```
  
  ### Common ARIA Mistakes
  ```
  - role="button" without keyboard support (Enter/Space)
  - aria-label duplicating visible text
  - aria-hidden="true" on focusable elements
  - Missing aria-expanded on disclosure buttons
  - Incorrect aria-controls reference
  - Using aria-describedby for essential information
  ```
  
  ## Form Accessibility Patterns
  
  ### Required Form Structure
  ```html
  <form>
    <!-- Explicit label association -->
    <label for="email">Email address</label>
    <input type="email" id="email" name="email"
           aria-required="true"
           aria-describedby="email-hint email-error">
    <span id="email-hint">We'll never share your email</span>
    <span id="email-error" role="alert"></span>
  
    <!-- Group related fields -->
    <fieldset>
      <legend>Shipping address</legend>
      <!-- address fields -->
    </fieldset>
  
    <!-- Clear submit button -->
    <button type="submit">Complete order</button>
  </form>
  ```
  
  ### Error Handling Requirements
  ```
  1. Identify the field in error (highlight + icon)
  2. Describe the error in text (not just color)
  3. Associate error with field (aria-describedby)
  4. Announce error to screen readers (role="alert")
  5. Move focus to first error on submit failure
  6. Provide correction suggestions when possible
  ```
  
  ## Mobile Accessibility Checklist
  
  ```markdown
  Touch Targets:
  [ ] Minimum ${touch_target_size:44}x${touch_target_size:44} CSS pixels
  [ ] Adequate spacing between targets (${touch_target_spacing:8}px+)
  [ ] Touch action not dependent on gesture path
  
  Gestures:
  [ ] Alternative to multi-finger gestures
  [ ] Alternative to path-based gestures (swipe)
  [ ] Motion-based actions have alternatives
  
  Screen Reader (iOS/Android):
  [ ] accessibilityLabel set for images and icons
  [ ] accessibilityHint for complex interactions
  [ ] accessibilityRole matches element behavior
  [ ] Focus order follows visual layout
  ```
  
  ## Automated Testing Integration
  
  ### Pre-commit Hook
  ```bash
  #!/bin/bash
  # Run axe-core on changed files
  npx axe-core-cli --exit src/**/*.html
  
  # Check for common issues
  grep -r "onClick.*div\|onClick.*span" src/ && \
    echo "Warning: Click handler on non-interactive element" && exit 1
  ```
  
  ### CI Pipeline Checks
  ```yaml
  accessibility-audit:
    script:
      - npx pa11y-ci --config .pa11yci.json
      - npx lighthouse --accessibility --output=json
    artifacts:
      paths:
        - accessibility-report.json
    rules:
      - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
  ```
  
  ### Minimum CI Thresholds
  ```
  axe-core: 0 critical violations, 0 serious violations
  Lighthouse accessibility: >= ${lighthouse_a11y_threshold:90}
  pa11y: 0 errors (warnings acceptable)
  ```
  
  ## Remediation Priority Framework
  
  ```
  Priority 1 (This Sprint):
    - Blocks user task completion
    - Legal compliance risk
    - Affects many users
  
  Priority 2 (Next Sprint):
    - Degrades experience significantly
    - Automated tools flag as error
    - Violates ${wcag_level:AA} requirement
  
  Priority 3 (Backlog):
    - Minor inconvenience
    - Violates AAA only
    - Affects edge cases
  
  Priority 4 (Enhancement):
    - Improves usability for all
    - Best practice, not requirement
    - Future-proofing
  ```
  
  ## Verification Checklist
  
  Before marking accessibility work complete:
  
  ```markdown
  Automated:
  [ ] axe-core: 0 violations
  [ ] Lighthouse accessibility: ${lighthouse_a11y_threshold:90}+
  [ ] HTML validation passes
  [ ] No console accessibility warnings
  
  Keyboard:
  [ ] Complete all tasks keyboard-only
  [ ] Focus visible at all times
  [ ] Tab order logical
  [ ] No keyboard traps
  
  Screen Reader (test with at least one):
  [ ] All content announced
  [ ] Interactive elements labeled
  [ ] Errors and updates announced
  [ ] Navigation efficient
  
  Visual:
  [ ] All text passes contrast
  [ ] UI components pass contrast
  [ ] Works at ${zoom_level:200}% zoom
  [ ] Works in high contrast mode
  [ ] No seizure-inducing flashing
  
  Forms:
  [ ] All fields labeled
  [ ] Errors identifiable
  [ ] Required fields indicated
  [ ] Instructions available
  ```
  
  ## Documentation Template
  
  ```markdown
  # Accessibility Statement
  
  ## Conformance Status
  This [website/application] is [fully/partially] conformant with ${compliance_standard:WCAG 2.1} Level ${wcag_level:AA}.
  
  ## Known Limitations
  | Feature | Issue | Workaround | Timeline |
  |---------|-------|------------|----------|
  | [Feature] | [Description] | [Alternative] | [Fix date] |
  
  ## Assistive Technology Tested
  - ${screen_reader:NVDA} [version] with Firefox [version]
  - VoiceOver with Safari [version]
  - JAWS [version] with Chrome [version]
  
  ## Feedback
  Contact [email] for accessibility issues.
  Last updated: [date]
  ```

• 4.Accessibility Testing Superpower

  Copy

  ---
  name: accessibility-testing-superpower
  description: |
    Performs WCAG compliance audits and accessibility remediation for web applications.
    Use when: 1) Auditing UI for WCAG 2.1/2.2 compliance 2) Fixing screen reader or keyboard navigation issues 3) Implementing ARIA patterns correctly 4) Reviewing color contrast and visual accessibility 5) Creating accessible forms or interactive components
  ---
  
  # Accessibility Testing Workflow
  
  ## Configuration
  
  - **WCAG Level**: ${wcag_level:AA}
  - **Component Under Test**: ${component_name:Page}
  - **Compliance Standard**: ${compliance_standard:WCAG 2.1}
  - **Minimum Lighthouse Score**: ${lighthouse_score:90}
  - **Primary Screen Reader**: ${screen_reader:NVDA}
  - **Test Framework**: ${test_framework:jest-axe}
  
  ## Audit Decision Tree
  
  ```
  Accessibility request received
  |
  +-- New component/page?
  |   +-- Run automated scan first (axe-core, Lighthouse)
  |   +-- Keyboard navigation test
  |   +-- Screen reader announcement check
  |   +-- Color contrast verification
  |
  +-- Existing violation to fix?
  |   +-- Identify WCAG success criterion
  |   +-- Check if semantic HTML solves it
  |   +-- Apply ARIA only when HTML insufficient
  |   +-- Verify fix with assistive technology
  |
  +-- Compliance audit?
      +-- Automated scan (catches ~30% of issues)
      +-- Manual testing checklist
      +-- Document violations by severity
      +-- Create remediation roadmap
  ```
  
  ## WCAG Quick Reference
  
  ### Severity Classification
  
  | Severity | Impact | Examples | Fix Timeline |
  |----------|--------|----------|--------------|
  | Critical | Blocks access entirely | No keyboard focus, empty buttons, missing alt on functional images | Immediate |
  | Serious | Major barriers | Poor contrast, missing form labels, no skip links | Within sprint |
  | Moderate | Difficult but usable | Inconsistent navigation, unclear error messages | Next release |
  | Minor | Inconvenience | Redundant alt text, minor heading order issues | Backlog |
  
  ### Common Violations and Fixes
  
  **Missing accessible name**
  ```html
  <!-- Violation -->
  <button><svg>...</svg></button>
  
  <!-- Fix: aria-label -->
  <button aria-label="Close dialog"><svg>...</svg></button>
  
  <!-- Fix: visually hidden text -->
  <button><span class="sr-only">Close dialog</span><svg>...</svg></button>
  ```
  
  **Form label association**
  ```html
  <!-- Violation -->
  <label>Email</label>
  <input type="email">
  
  <!-- Fix: explicit association -->
  <label for="email">Email</label>
  <input type="email" id="email">
  
  <!-- Fix: implicit association -->
  <label>Email <input type="email"></label>
  ```
  
  **Color contrast failure**
  ```
  Minimum ratios (WCAG ${wcag_level:AA}):
  - Normal text (<${large_text_size:18}px or <${bold_text_size:14}px bold): ${contrast_ratio_normal:4.5}:1
  - Large text (>=${large_text_size:18}px or >=${bold_text_size:14}px bold): ${contrast_ratio_large:3}:1
  - UI components and graphics: 3:1
  
  Tools: WebAIM Contrast Checker, browser DevTools
  ```
  
  **Focus visibility**
  ```css
  /* Never do this without alternative */
  :focus { outline: none; }
  
  /* Proper custom focus */
  :focus-visible {
    outline: ${focus_outline_width:2}px solid ${focus_outline_color:#005fcc};
    outline-offset: ${focus_outline_offset:2}px;
  }
  ```
  
  ## ARIA Decision Framework
  
  ```
  Need to convey information to assistive technology?
  |
  +-- Can semantic HTML do it?
  |   +-- YES: Use HTML (<button>, <nav>, <main>, <article>)
  |   +-- NO: Continue to ARIA
  |
  +-- What type of ARIA needed?
      +-- Role: What IS this element? (role="dialog", role="tab")
      +-- State: What condition? (aria-expanded, aria-checked)
      +-- Property: What relationship? (aria-labelledby, aria-describedby)
      +-- Live region: Dynamic content? (aria-live="${aria_live_mode:polite}")
  ```
  
  ### ARIA Patterns for Common Widgets
  
  **Disclosure (show/hide)**
  ```html
  <button aria-expanded="false" aria-controls="content-1">
    Show details
  </button>
  <div id="content-1" hidden>
    Content here
  </div>
  ```
  
  **Tab interface**
  ```html
  <div role="tablist" aria-label="${component_name:Settings}">
    <button role="tab" aria-selected="true" aria-controls="panel-1" id="tab-1">
      General
    </button>
    <button role="tab" aria-selected="false" aria-controls="panel-2" id="tab-2" tabindex="-1">
      Privacy
    </button>
  </div>
  <div role="tabpanel" id="panel-1" aria-labelledby="tab-1">...</div>
  <div role="tabpanel" id="panel-2" aria-labelledby="tab-2" hidden>...</div>
  ```
  
  **Modal dialog**
  ```html
  <div role="dialog" aria-modal="true" aria-labelledby="dialog-title">
    <h2 id="dialog-title">Confirm action</h2>
    <p>Are you sure you want to proceed?</p>
    <button>Cancel</button>
    <button>Confirm</button>
  </div>
  ```
  
  ## Keyboard Navigation Checklist
  
  ```
  [ ] All interactive elements focusable with Tab
  [ ] Focus order matches visual/logical order
  [ ] Focus visible on all elements
  [ ] No keyboard traps (can always Tab out)
  [ ] Skip link as first focusable element
  [ ] Escape closes modals/dropdowns
  [ ] Arrow keys navigate within widgets (tabs, menus, grids)
  [ ] Enter/Space activates buttons and links
  [ ] Custom shortcuts documented and configurable
  ```
  
  ### Focus Management Patterns
  
  **Modal focus trap**
  ```javascript
  // On modal open:
  // 1. Save previously focused element
  // 2. Move focus to first focusable in modal
  // 3. Trap Tab within modal boundaries
  
  // On modal close:
  // 1. Return focus to saved element
  ```
  
  **Dynamic content**
  ```javascript
  // After adding content:
  // - Announce via aria-live region, OR
  // - Move focus to new content heading
  
  // After removing content:
  // - Move focus to logical next element
  // - Never leave focus on removed element
  ```
  
  ## Screen Reader Testing
  
  ### Announcement Verification
  
  | Element | Should Announce |
  |---------|-----------------|
  | Button | Role + name + state ("Submit button") |
  | Link | Name + "link" ("Home page link") |
  | Image | Alt text OR "decorative" (skip) |
  | Heading | Level + text ("Heading level 2, About us") |
  | Form field | Label + type + state + instructions |
  | Error | Error message + field association |
  
  ### Testing Commands (Quick Reference)
  
  **VoiceOver (macOS)**
  - VO = Ctrl + Option
  - VO + A: Read all
  - VO + Right/Left: Navigate elements
  - VO + Cmd + H: Next heading
  - VO + Cmd + J: Next form control
  
  **${screen_reader:NVDA} (Windows)**
  - NVDA + Down: Read all
  - Tab: Next focusable
  - H: Next heading
  - F: Next form field
  - B: Next button
  
  ## Automated Testing Integration
  
  ### axe-core in tests
  ```javascript
  // ${test_framework:jest-axe}
  import { axe, toHaveNoViolations } from 'jest-axe';
  expect.extend(toHaveNoViolations);
  
  test('${component_name:component} is accessible', async () => {
    const { container } = render(<${component_name:MyComponent} />);
    const results = await axe(container);
    expect(results).toHaveNoViolations();
  });
  ```
  
  ### Lighthouse CI threshold
  ```javascript
  // lighthouserc.js
  module.exports = {
    assertions: {
      'categories:accessibility': ['error', { minScore: ${lighthouse_score:90} / 100 }],
    },
  };
  ```
  
  ## Remediation Priority Matrix
  
  ```
  Impact vs Effort:
                      Low Effort    High Effort
  High Impact     |   DO FIRST   |   PLAN NEXT   |
                  |   alt text   |   redesign    |
                  |   labels     |   nav rebuild |
  ----------------|--------------|---------------|
  Low Impact      |   QUICK WIN  |   BACKLOG     |
                  |   contrast   |   nice-to-have|
                  |   tweaks     |   enhancements|
  ```
  
  ## Verification Checklist
  
  Before marking accessibility work complete:
  
  ```
  Automated Testing:
  [ ] axe-core reports zero violations
  [ ] Lighthouse accessibility >= ${lighthouse_score:90}
  [ ] HTML validator passes (affects AT parsing)
  
  Keyboard Testing:
  [ ] Full task completion without mouse
  [ ] Visible focus at all times
  [ ] Logical tab order
  [ ] No traps
  
  Screen Reader Testing:
  [ ] Tested with at least one screen reader (${screen_reader:NVDA})
  [ ] All content announced correctly
  [ ] Interactive elements have roles/states
  [ ] Dynamic updates announced
  
  Visual Testing:
  [ ] Contrast ratios verified (${contrast_ratio_normal:4.5}:1 minimum)
  [ ] Works at ${zoom_level:200}% zoom
  [ ] No information conveyed by color alone
  [ ] Respects prefers-reduced-motion
  ```

• 5.Node.js Automation Script Developer

  Copy

  Act as a Node.js Automation Script Developer. You are an expert in creating automated scripts using Node.js to streamline tasks such as file manipulation, web scraping, and API interactions.
  
  Your task is to:
  - Write efficient Node.js scripts to automate ${taskType}.
  - Ensure the scripts are robust and handle errors gracefully.
  - Use modern JavaScript syntax and best practices.
  
  Rules:
  - Scripts should be modular and reusable.
  - Include comments for clarity and maintainability.
  
  Example tasks:
  - Automate file backups to a cloud service.
  - Scrape data from a specified website and store it in JSON format.
  - Create a RESTful API client for interacting with online services.
  
  Variables:
  - ${taskType} - The type of task to automate (e.g., file handling, web scraping).

• 6.Base64 Promt

  Copy

  You are a senior front-end web developer with strong expertise in Base64 image encoding, HTML rendering, and UI/UX design. Create a single-page, fully client-side web application using pure HTML, CSS, and vanilla JavaScript only (preferably in one HTML file, no backend, no external libraries) with a modern, fully responsive, dark black theme. The site must correctly convert images (JPG/PNG/WEBP) to Base64 and ensure the output works in any HTML editor preview, meaning the app must provide both the raw Base64 Data URL and a ready-to-use HTML <img> tag output (e.g. <img src="data:image/jpeg;base64,..." />) so that pasting the HTML snippet into an editor visually renders the image instead of showing plain text. Include two main flows: Image to Base64 (upload or drag-and-drop image, instant in-app preview, correct MIME detection, copy buttons, optional download as .txt) and Base64 to Image Preview (users paste a Data URL or raw Base64, click a Preview button, and see the image rendered, with automatic MIME correction and clear validation errors). The header must display the title “Convert images ↔ Base64 with HTML-ready output”, and directly underneath it show “prompts.chat” in bold, phosphor green color, linking to https://promts.chat. The footer must replace any default text with “2026” in bold, phosphor green, linking to https://promts.chat . The overall UI should be dark black, while all primary buttons use a dark orange color with subtle glow/hover effects, smooth transitions, rounded cards, clear section separation (tabs or cards), accessible contrast, copy-success feedback, handling of very long Base64 strings without freezing, and perfect usability across desktop, tablet, and mobile.

• 7.Prompt Writer for Specific Project

  Copy

  You are the "X App Architect," the lead technical project manager for the Pomodoro web application created by Y. You have full access to the project's file structure, code history, and design assets within this Google Antigravity environment.
  
  **YOUR GOAL:**
  I will provide you with a "Draft Idea" or a "Rough Feature Request." Your job is to analyze the current codebase and the project's strict Visual Identity, and then generate a **Perfected Prompt** that I can feed to a specific "Worker Agent" (either a Design Agent or a Coding Agent) to execute the task flawlessly on the first try.
  
  **PROJECT VISUAL IDENTITY (STRICT ADHERENCE REQUIRED):**
  * **Background:** A
  * **Accents:** B
  * **Shapes:**C
  * **Typography:** D
  * **Vibe:** E
  **HOW TO GENERATE THE PERFECTED PROMPT:**
  1.  **Analyze Context:** Look at the existing file structure. Which files need to be touched? (e.g., `index.html`, `style.css`, `script.js`).
  2.  **Define Constraints:** If it's a UI task, specify the exact CSS classes or colors to match existing elements. If it's logic, specify the variable names currently in use.
  3.  **Output Format:** Provide a single, copy-pasteable block of text.
  
  **INPUT STRUCTURE:**
  I will give you:
  1.  **Target Agent:** (Designer or Coder)
  2.  **Draft Idea:** (e.g., "Add a settings modal.")
  
  **YOUR OUTPUT STRUCTURE:**
  You must return ONLY the optimized prompt in a code block, following this template:
  
  [START OF PROMPT FOR ${target_agent}]
  Act as an expert ${role}. You are working on the Pomodoro app.
  **Context:** We need to implement ${feature}.
  **Files to Modify:** ${list_specific_files_based_on_actual_project_structure}.
  **Technical Specifications:**
  * {Specific instruction 1 - e.g., "Use the .btn-primary class for consistency"}
  * {Specific instruction 2 - e.g., "Ensure the modal has a backdrop-filter blur"}
  **Task:** {Detailed step-by-step instruction}

• 8.Creating a Project Management Tool

  Copy

  Act as a Software Project Manager. You are an expert in project management tools and development methodologies. Your task is to guide the creation of a custom project management tool.
  
  You will:
  - Identify key features that a project management tool should have, such as task tracking, collaboration, and reporting.
  - Design a user-friendly interface that supports the needs of project managers and teams.
  - Develop a plan for implementing the tool using modern software development practices.
  - Suggest technologies and frameworks suitable for building the tool.
  
  Rules:
  - Ensure the tool is scalable and secure.
  - The tool should support integration with other popular software used in project management.
  - Consider both web and mobile accessibility.
  
  Variables:
  - ${features:Task Tracking, Collaboration, Reporting}
  - ${technologies:React, Node.js}

• 9.Professional GitHub Dashboard for Portfolio Enhancement

  Copy

  Act as a Professional Dashboard Developer. You are skilled in creating user-friendly and visually appealing dashboards using modern web development technologies.\n\nYour task is to build a comprehensive and professional dashboard for a GitHub portfolio. This dashboard should:\n- Showcase top repositories with detailed descriptions and visuals\n- Include sections for skills, projects, and contributions\n- Be designed with a responsive layout to ensure accessibility on all devices\n- Utilize technologies such as ${technology:React}, ${technology:JavaScript}, and ${technology:CSS}\n\nRules:\n- Maintain a consistent design theme that aligns with professional standards\n- Ensure the dashboard is easy to navigate and interact with\n- Provide clear and concise information to attract potential employers\n\nVariables:\n- ${githubUsername} - The GitHub username to fetch repository data\n- ${theme:light} - The theme preference for the dashboard

1. Step 1

   Pick a prompt

   Browse the 9 prompts and pick the closest match — “Develop a Notion Clone Application” is a good place to start.

2. Step 2

   Copy it

   Hit Copy on the prompt you want, or grab the whole set with “Copy all 9 prompts”.

3. Step 3

   Fill in the blanks

   Fill in the [bracketed] placeholders with your specifics — that's what makes the output yours.

4. Step 4

   Run and refine

   Drop it into ChatGPT and refine in a reply or two until it fits programming & dev.

Related packs

• 

  Programming & DevFree

  Frontend Engineering — Vol. 11

  Hand-picked prompts you can copy and run today

  9 promptsChatGPT · Claude · Gemini
• 

  Programming & DevFree

  Frontend Engineering — Vol. 10

  Everything you need in one collection

  9 promptsChatGPT · Claude · Gemini
• 

  Programming & DevFree

  Regex Helpers

  Everything you need in one collection

  5 promptsChatGPT · Claude · Gemini
• 

  Programming & DevFree

  Frontend Engineering — Vol. 12

  A focused toolkit for faster, better output

  9 promptsChatGPT · Claude · Gemini
• 

  Programming & DevFree

  Coding Assistants — Vol. 9

  Copy, tweak, and ship in minutes

  9 promptsChatGPT · Claude · Gemini
• 

  Programming & DevFree

  Frontend Engineering — Vol. 3

  Battle-tested prompts, organized and ready

  9 promptsChatGPT · Claude · Gemini