diff options
| author | pablof7z <pfer@me.com> | 2025-06-06 19:19:26 +0100 |
|---|---|---|
| committer | pablof7z <pfer@me.com> | 2025-06-06 19:19:33 +0100 |
| commit | b8966eb10329a6b0e0ea0846fb4e803298696721 (patch) | |
| tree | 804129960a3539b8a4809d421ba731ff10da7765 | |
| parent | 3430b8bf3df77baacbaae2bdef381997f12884c9 (diff) | |
Add LLM stuff nip: Define prompt diffs for LLM modificationsllm-stuff
| -rw-r--r-- | xx.md | 72 |
1 files changed, 72 insertions, 0 deletions
| @@ -0,0 +1,72 @@ | |||
| 1 | NIP-XX | ||
| 2 | ====== | ||
| 3 | |||
| 4 | LLM Stuff | ||
| 5 | --------- | ||
| 6 | |||
| 7 | `draft` `optional` | ||
| 8 | |||
| 9 | This NIP defines kinds related to LLM stuff. | ||
| 10 | |||
| 11 | # Prompt diffs | ||
| 12 | a way to publish LLM prompts that describe modifications to software projects. Where code diffs usually expire in a couple of releases and require constant upkeep,tThese "prompt diffs" enable way longer-lasting, shareable software modifications. | ||
| 13 | |||
| 14 | ## Abstract | ||
| 15 | |||
| 16 | A prompt diff is a Nostr event that contains instructions for an LLM to modify a codebase. Prompt diffs describe the intent and let LLMs handle the implementation details. | ||
| 17 | |||
| 18 | ## Event Structure | ||
| 19 | |||
| 20 | ```json | ||
| 21 | { | ||
| 22 | "kind": 496, | ||
| 23 | "content": "<human-readable-description>", | ||
| 24 | "tags": [ | ||
| 25 | ["title", "<modification-title>"], | ||
| 26 | ["description", "<prompt>"], | ||
| 27 | ["r", "<git-repository-url>"], | ||
| 28 | ["t", "<tag>"], | ||
| 29 | ["model", "<suggested-llm-model>"], | ||
| 30 | ] | ||
| 31 | } | ||
| 32 | Required Tags | ||
| 33 | |||
| 34 | title - Short title describing the modification | ||
| 35 | r - Git repository URL this applies to | ||
| 36 | prompt - The actual prompt containing modification instructions | ||
| 37 | |||
| 38 | ## Optional Tags | ||
| 39 | |||
| 40 | t - Hashtags for categorization (#security, #performance, #feature-removal, etc.) | ||
| 41 | model - Suggested LLM model that successfully applies this modification | ||
| 42 | |||
| 43 | Example: Remove Edit Functionality from Amethyst | ||
| 44 | json{ | ||
| 45 | "kind": 496, | ||
| 46 | "pubkey": "...", | ||
| 47 | "created_at": 1234567890, | ||
| 48 | "content": "Removes the ability to edit kind:1 text notes in Amethyst", | ||
| 49 | "tags": [ | ||
| 50 | ["title", "Remove Kind:1 Edit Functionality"], | ||
| 51 | ["description", "Remove all edit functionality for kind:1 events from the Amethyst Android app. This includes:\n\n1. Find and remove the edit button/icon from the note options menu (three dots menu) for kind:1 events\n2. Remove any edit action handlers, click listeners, or menu item cases related to editing kind:1 notes\n3. Remove or disable any UI components like EditPostView or EditPostDialog that are used for editing existing posts\n4. Keep the edit functionality for other event kinds if they exist (like kind:30023 long-form content)\n5. Remove any edit-related permissions checks or business logic specific to kind:1 events\n6. Clean up any unused imports or resources that were only used for kind:1 editing\n7. Do not remove the ability to create new kind:1 posts, only the ability to edit existing ones\n8. Look for edit functionality in:\n - Note composition screens\n - Note option menus \n - ViewModels handling note actions\n - Any files with names containing 'Edit' and 'Note' or 'Post'\n\nMake sure the app still compiles and runs after these changes. The diff should be clean with no leftover dead code."], | ||
| 52 | ["r", "https://github.com/vitorpamplona/amethyst"], | ||
| 53 | ["t", "noedits"], | ||
| 54 | ["t", "amethyst"], | ||
| 55 | ["model", "claude-3.5-sonnet"], | ||
| 56 | ], | ||
| 57 | "sig": "..." | ||
| 58 | } | ||
| 59 | |||
| 60 | # Implementation Guidelines | ||
| 61 | ### For Prompt Authors | ||
| 62 | |||
| 63 | Write clear, specific prompts that describe intent rather than implementation | ||
| 64 | Include context about why changes should be made in certain locations | ||
| 65 | Specify what should NOT be changed to prevent over-modification | ||
| 66 | Add test commands to verify the modification works | ||
| 67 | Test prompts against the current main branch of the repository | ||
| 68 | |||
| 69 | # Security Considerations | ||
| 70 | |||
| 71 | * Always review LLM-generated changes before applying | ||
| 72 | * Prompt Injection Protection: Clients MUST sanitize repository file contents before passing to LLMs to prevent malicious code comments or documentation from hijacking the modification intent | ||