agentleFS
JohannesKlaussJohannesKlauss/react-hotkeys-hook/AGENTS.md

react-hotkeys-hook

AGENTS.md3.5k starsChanged 19 months agoMITView on GitHub

This file provides guidelines for agentic coding agents working in this repository. This repo is hosted on Github. Use the gh CLI to fetch issues, create PRs, etc.

Trending

Less talk lately.about the whole repository

Dec 2025: 2 mentionsJan 2026: 1 mentionFeb 2026: 2 mentionsMar 2026: 2 mentionsApr 2026: 1 mentionMay 2026: 6 mentionsJun 2026: 2 mentionsJul 2026: 9 mentionsAug 2026: 5 mentionsSep 2026: 0 mentionsOct 2026: 4 mentionsNov 2026: 1 mention
Dec 2025Jun 2026Nov 2026
Mentions a month of the JohannesKlauss/react-hotkeys-hook repository that our weekly crawl found. There is no adoption data for this file yet.

Who's talking about JohannesKlauss/react-hotkeys-hook

The biggest 5 of 52 mentions linking to the repository that our crawl found. Each line is their own headline.

See all 52

Talked about on GitHub, Bluesky and Stack Overflow (52 times).

On GitHub · 50

45 more on GitHub

On Bluesky · 1

  • Where files are headingNew AGENTS.md files have more rules about keeping secrets out of the code, and fewer about code style.

    Of the AGENTS.md files we read, the 31,439 first seen in the last six months, against the older ones: the kind of rule that gained most share, and the kind that lost most. About files like this in general, not this one, and an estimate, since a kind is a pattern in the words.

The file

Show its rules and text

We split this AGENTS.md into the rules it gives an agent

41 rules. About 0 are common, 13 are distinctive, and 28 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈13

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 28

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Use packages/lab to reproduce bugs

    line 11
  2. Distinctive:

    Verify behavior with the playwright mcp

    line 12
  3. Very specific:

    Use import type for type-only imports: import type { Hotkey } from './types'

    line 46
  4. Distinctive:

    Keep imports at top of file, grouped by purpose

    line 48
  5. Distinctive:

    Use explicit type annotations for function parameters and returns

    line 51
  6. Very specific:

    Prefer readonly for arrays that shouldn't be modified: readonly FormTags[]

    line 52
  7. Very specific:

    Use type over interface for object types (this codebase uses type)

    line 53
  8. Very specific:

    Use generic type parameters with constraints: function foo<T extends HTMLElement>()

    line 54
  9. Very specific:

    Use as const for literal types where appropriate

    line 55
  10. Very specific:

    Use @ts-expect-error for intentional type errors with explanation

    line 56
  11. Distinctive:

    Use functional components with hooks

    line 66
  12. Very specific:

    Use useCallback for event handlers and functions passed to children

    line 67
  13. Very specific:

    Use useRef for mutable refs and DOM elements

    line 68
  14. Very specific:

    Use useState for component state

    line 69
  15. Very specific:

    Use useEffect or useLayoutEffect for side effects

    line 70
  16. Very specific:

    Prefer useLayoutEffect over useEffect for DOM mutations

    line 71
  17. Very specific:

    Use TypeScript generics for refs: useRef<T>(null)

    line 72
  18. Distinctive:

    Use conditional checks instead of try-catch where possible

    line 76
  19. Very specific:

    Use type guards: isReadonlyArray(enabledOnTags)

    line 78
  20. Distinctive:

    Check for undefined/null before accessing properties

    line 79
  21. Very specific:

    Use optional chaining: e.target?.isContentEditable

    line 80
  22. Very specific:

    Use TODO comments for future improvements: // TODO: Make modifiers work with sequences

    line 83
  23. Very specific:

    Use biome-ignore comments for intentional lint violations: // biome-ignore lint/correctness/useExhaustiveDependencies

    line 84
  24. Distinctive:

    Avoid inline comments for obvious code

    line 85
  25. Distinctive:

    Add comments for complex logic or non-obvious behavior

    line 86
  26. Distinctive:

    Use console.warn for developer-facing warnings in production code

    line 87
  27. Very specific:

    Test files use .test.tsx extension in src/test/ directory

    line 90
  28. Very specific:

    Use test() from vitest (not it())

    line 91
  29. Very specific:

    Use expect() for assertions

    line 92
  30. Very specific:

    Use vi.useFakeTimers() for timer-related tests

    line 94
  31. Very specific:

    Use userEvent.setup() for user interactions

    line 95
  32. Very specific:

    Test files in src/test/, source in src/lib/

    line 96
  33. Very specific:

    Use renderHook() for testing hooks

    line 97
  34. Very specific:

    Use render() for testing components

    line 98
  35. Very specific:

    Use beforeEach() for setup

    line 99
  36. Very specific:

    Use .only() sparingly for debugging only (remove before commit)

    line 100
  37. Very specific:

    Use type imports for type-only imports to reduce bundle size

    line 111
  38. Distinctive:

    Avoid parameter reassignment (Biome rule)

    line 112
  39. Distinctive:

    Use single variable declarators (Biome rule)

    line 113
  40. Distinctive:

    Avoid unnecessary else statements (Biome rule)

    line 114
  41. Distinctive:

    Use as const assertions for literal types (Biome rule)

    line 116

≈ “Common” is an estimate: at least 1 in 5 of the 40,246 AGENTS.md files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
AGENTS.md

AGENTS.md

This file provides guidelines for agentic coding agents working in this repository.

Github

This repo is hosted on Github. Use the gh CLI to fetch issues, create PRs, etc.

Development Workflow

  • Use packages/lab to reproduce bugs
  • Verify behavior with the playwright mcp

Development Commands

Build and Development

  • npm run build - Build the main library package (runs in packages/react-hotkeys-hook)
  • npm run build:documentation - Build documentation site
  • npm run -w packages/react-hotkeys-hook dev - Start development server for library
  • npm run -w packages/react-hotkeys-hook build - Build library only (TypeScript + Vite)

Linting and Formatting

  • npm run lint - Run Biome linter with auto-fix (applies to all packages)
  • npm run format - Run Biome formatter (applies to all packages)
  • npx @biomejs/biome lint --write packages - Lint with write directly
  • npx @biomejs/biome format --write packages - Format with write directly

Testing

  • npm run test - Run all tests (Vitest in packages/react-hotkeys-hook)
  • npm run -w packages/react-hotkeys-hook test - Run tests in library package
  • npm run -w packages/react-hotkeys-hook vitest run - Run tests once (no watch mode)
  • npx vitest run --testNamePattern "test name" - Run single test matching pattern
  • npx vitest run src/test/useHotkeys.test.tsx - Run specific test file
  • npx vitest run -t "should listen to key presses" - Run tests matching name

Code Style Guidelines

Formatting (Biome)

  • Line width: 120 characters
  • Indentation: Spaces (2 spaces)
  • Quotes: Single quotes
  • Semicolons: As needed (optional)
  • Biome auto-organizes imports on save

Imports

  • Use import type for type-only imports: import type { Hotkey } from './types'
  • Group imports: external React hooks first, then local modules
  • Keep imports at top of file, grouped by purpose

TypeScript

  • Use explicit type annotations for function parameters and returns
  • Prefer readonly for arrays that shouldn't be modified: readonly FormTags[]
  • Use type over interface for object types (this codebase uses type)
  • Use generic type parameters with constraints: function foo<T extends HTMLElement>()
  • Use as const for literal types where appropriate
  • Use @ts-expect-error for intentional type errors with explanation

Naming Conventions

  • Variables and functions: camelCase (isHotkeyEnabled, recordedKeys)
  • Components: PascalCase (HotkeysProvider, BoundHotkeysProxyProvider)
  • Types: PascalCase (HotkeyCallback, Options, HotkeysContextType)
  • Constants: UPPER_SNAKE_CASE (FORM_TAGS_AND_ROLES)
  • Private/internal variables: Prefix with underscore (_options, _deps)

React Patterns

  • Use functional components with hooks
  • Use useCallback for event handlers and functions passed to children
  • Use useRef for mutable refs and DOM elements
  • Use useState for component state
  • Use useEffect or useLayoutEffect for side effects
  • Prefer useLayoutEffect over useEffect for DOM mutations
  • Use TypeScript generics for refs: useRef<T>(null)
  • Export default hooks for main API: export default function useHotkeys()

Error Handling

  • Use conditional checks instead of try-catch where possible
  • Return early from functions on error conditions
  • Use type guards: isReadonlyArray(enabledOnTags)
  • Check for undefined/null before accessing properties
  • Use optional chaining: e.target?.isContentEditable

Comments

  • Use TODO comments for future improvements: // TODO: Make modifiers work with sequences
  • Use biome-ignore comments for intentional lint violations: // biome-ignore lint/correctness/useExhaustiveDependencies
  • Avoid inline comments for obvious code
  • Add comments for complex logic or non-obvious behavior
  • Use console.warn for developer-facing warnings in production code

Testing Patterns (Vitest + Testing Library)

  • Test files use .test.tsx extension in src/test/ directory
  • Use test() from vitest (not it())
  • Use expect() for assertions
  • Mock functions with vi.fn()
  • Use vi.useFakeTimers() for timer-related tests
  • Use userEvent.setup() for user interactions
  • Test files in src/test/, source in src/lib/
  • Use renderHook() for testing hooks
  • Use render() for testing components
  • Use beforeEach() for setup
  • Use .only() sparingly for debugging only (remove before commit)

File Structure

  • Main source: packages/react-hotkeys-hook/src/lib/
  • Tests: packages/react-hotkeys-hook/src/test/
  • Types: Defined in src/lib/types.ts
  • Entry point: src/lib/index.ts
  • Monorepo: Multiple packages in packages/ directory

Additional Notes

  • This is an ES modules project (type: "module" in package.json)
  • Use type imports for type-only imports to reduce bundle size
  • Avoid parameter reassignment (Biome rule)
  • Use single variable declarators (Biome rule)
  • Avoid unnecessary else statements (Biome rule)
  • Self-closing JSX elements (Biome rule)
  • Use as const assertions for literal types (Biome rule)
  • This project uses Vitest, not Jest
  • Build system: Vite + TypeScript
  • Testing environment: jsdom

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.