AGENTS.md: generalize tool names

AGENTS.md

@@ -114,9 +114,9 @@ This project comes with custom hooks for querying and publishing events on the N
 
 ### Nostr Implementation Guidelines
 
-- Always use the `nostr__read_nips_index` tool before implementing any Nostr features to see what kinds are currently in use across all NIPs.
+- Always check the full list of existing NIPs before implementing any Nostr features to see what kinds are currently in use across all NIPs.
-- If any existing kind or NIP might offer the required functionality, use the `nostr__read_nip` tool to investigate thoroughly. Several NIPs may need to be read before making a decision.
+- If any existing kind or NIP might offer the required functionality, read the relevant NIPs to investigate thoroughly. Several NIPs may need to be read before making a decision.
-- Only generate new kind numbers with the `nostr__generate_kind` tool if no existing suitable kinds are found after comprehensive research.
+- Only generate new kind numbers if no existing suitable kinds are found after comprehensive research.
 
 Knowing when to create a new kind versus reusing an existing kind requires careful judgement. Introducing new kinds means the project won't be interoperable with existing clients. But deviating too far from the schema of a particular kind can cause different interoperability issues.
 
@@ -124,7 +124,7 @@ Knowing when to create a new kind versus reusing an existing kind requires caref
 
 When implementing features that could use existing NIPs, follow this decision framework:
 
-1. **Thorough NIP Review**: Before considering a new kind, always perform a comprehensive review of existing NIPs and their associated kinds. Use the `nostr__read_nips_index` tool to get an overview, and then `nostr__read_nip` and `nostr__read_kind` to investigate any potentially relevant NIPs or kinds in detail. The goal is to find the closest existing solution.
+1. **Thorough NIP Review**: Before considering a new kind, always perform a comprehensive review of existing NIPs and their associated kinds. Get an overview of all NIPs, and then read specific NIPs and kind documentation to investigate any potentially relevant NIPs or kinds in detail. The goal is to find the closest existing solution.
 
 2. **Prioritize Existing NIPs**: Always prefer extending or using existing NIPs over creating custom kinds, even if they require minor compromises in functionality.
 
@@ -142,7 +142,7 @@ When implementing features that could use existing NIPs, follow this decision fr
    - The data structure is fundamentally different from existing patterns
    - The use case requires different storage characteristics (regular vs replaceable vs addressable)
 
-6. **Custom Kind Publishing**: When publishing events with custom kinds generated by `nostr__generate_kind`, always include a NIP-31 "alt" tag with a human-readable description of the event's purpose.
+6. **Custom Kind Publishing**: When publishing events with custom generated kinds, always include a NIP-31 "alt" tag with a human-readable description of the event's purpose.
 
 **Example Decision Process**:
 ```
@@ -938,14 +938,14 @@ import { Card, CardContent } from '@/components/ui/card';
 
 To add custom fonts, follow these steps:
 
-1. **Install a font package** using the `js-dev__npm_add_package` tool:
+1. **Install a font package** using npm:
 
    **Any Google Font can be installed** using the @fontsource packages. Examples:
-   - For Inter Variable: `js-dev__npm_add_package({ name: "@fontsource-variable/inter" })`
+   - For Inter Variable: `@fontsource-variable/inter`
-   - For Roboto: `js-dev__npm_add_package({ name: "@fontsource/roboto" })`
+   - For Roboto: `@fontsource/roboto`
-   - For Outfit Variable: `js-dev__npm_add_package({ name: "@fontsource-variable/outfit" })`
+   - For Outfit Variable: `@fontsource-variable/outfit`
-   - For Poppins: `js-dev__npm_add_package({ name: "@fontsource/poppins" })`
+   - For Poppins: `@fontsource/poppins`
-   - For Open Sans: `js-dev__npm_add_package({ name: "@fontsource/open-sans" })`
+   - For Open Sans: `@fontsource/open-sans`
 
    **Format**: `@fontsource/[font-name]` or `@fontsource-variable/[font-name]` (for variable fonts)
 
@@ -1018,7 +1018,7 @@ There is an important distinction between **writing new tests** and **running ex
 ### Running Tests (Executing the Test Suite)
 **ALWAYS run the test script** after making any code changes. This is mandatory regardless of whether you wrote new tests or not.
 
-- **You must run the test script** using `js-dev__run_script` tool with the "test" parameter
+- **You must run the test script** to validate your changes
 - **Your task is not complete** until the test script passes without errors
 - **This applies to all changes** - bug fixes, new features, refactoring, or any code modifications
 - **The test script includes** TypeScript compilation, ESLint checks, and existing test validation
@@ -1054,7 +1054,7 @@ describe('MyComponent', () => {
 
 ## Testing Your Changes
 
-**CRITICAL**: Whenever you are finished modifying code, you must run the **test** script using the **js-dev__run_script** tool.
+**CRITICAL**: Whenever you are finished modifying code, you must run the **test** script.
 
 **Your task is not considered finished until this test passes without errors.**