You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
You are tasked with analyzing Svelte 5 and SvelteKit documentation pages to identify when they would be useful.
48
-
49
-
Your task:
50
-
1. Read the documentation page content provided
51
-
2. Identify the main use cases, scenarios, or queries where this documentation would be relevant
52
-
3. Create a VERY SHORT, comma-separated list of use cases (maximum 200 characters total)
53
-
4. Think about what a developer might be trying to build or accomplish when they need this documentation
54
-
55
-
Guidelines:
56
-
- Focus on WHEN this documentation would be needed, not WHAT it contains
57
-
- Consider specific project types (e.g., "e-commerce site", "blog", "dashboard", "social media app")
58
-
- Consider specific features (e.g., "authentication", "forms", "data fetching", "animations")
59
-
- Consider specific components (e.g., "slider", "modal", "dropdown", "card")
60
-
- Consider development stages (e.g., "project setup", "deployment", "testing", "migration")
61
-
- Use "always" for fundamental concepts that apply to virtually all Svelte projects
62
-
- Be concise but specific
63
-
- Use lowercase
64
-
- Separate multiple use cases with commas
65
-
66
-
Examples of good use_cases:
67
-
- "always, any svelte project, core reactivity"
68
-
- "authentication, login systems, user management"
69
-
- "e-commerce, product listings, shopping carts"
70
-
- "forms, user input, data submission"
71
-
- "deployment, production builds, hosting setup"
72
-
- "animation, transitions, interactive ui"
73
-
- "routing, navigation, multi-page apps"
74
-
- "blog, content sites, markdown rendering"
75
-
76
-
Requirements:
77
-
- Maximum 200 characters (including spaces and commas)
78
-
- Lowercase only
79
-
- Comma-separated list of use cases
80
-
- Focus on WHEN/WHY someone would need this, not what it is
81
-
- Be specific about project types, features, or components when applicable
82
-
- Use "always" sparingly, only for truly universal concepts
83
-
- Do not include quotes or special formatting in your response
84
-
- Respond with ONLY the use cases text, no additional text
85
-
86
-
Here is the documentation page content to analyze:
87
-
88
-
`;
89
-
90
-
constDISTILLED_PROMPT=`You are an expert in web development, specifically Svelte 5 and SvelteKit. Your task is to condense and distill the Svelte documentation into a concise format while preserving the most important information.
91
-
Shorten the text information AS MUCH AS POSSIBLE while covering key concepts.
92
-
93
-
Focus on:
94
-
1. Code examples with short explanations of how they work
95
-
2. Key concepts and APIs with their usage patterns
96
-
3. Important gotchas and best practices
97
-
4. Patterns that developers commonly use
98
-
99
-
Remove:
100
-
1. Redundant explanations
101
-
2. Verbose content that can be simplified
102
-
3. Marketing language
103
-
4. Legacy or deprecated content
104
-
5. Anything else that is not strictly necessary
105
-
106
-
Keep your output in markdown format. Preserve code blocks with their language annotations.
107
-
Maintain headings but feel free to combine or restructure sections to improve clarity.
108
-
109
-
Make sure all code examples use Svelte 5 runes syntax ($state, $derived, $effect, etc.)
110
-
111
-
Keep the following Svelte 5 syntax rules in mind:
112
-
* There is no colon (:) in event modifiers. You MUST use "onclick" instead of "on:click".
113
-
* Runes do not need to be imported, they are globals.
114
-
* $state() runes are always declared using let, never with const.
115
-
* When passing a function to $derived, you must always use $derived.by(() => ...).
116
-
* Error boundaries can only catch errors during component rendering and at the top level of an $effect inside the error boundary.
117
-
* Error boundaries do not catch errors in onclick or other event handlers.
118
-
119
-
IMPORTANT: All code examples MUST come from the documentation verbatim, do NOT create new code examples. Do NOT modify existing code examples.
120
-
IMPORTANT: Because of changes in Svelte 5 syntax, do not include content from your existing knowledge, you may only use knowledge from the documentation to condense.
"Carefully analyze the use_cases field for each section to identify which documentation is relevant for the user's specific query. The use_cases contain keywords for project types, features, components, and development stages. After identifying relevant sections, use the get-documentation tool with ALL relevant section titles or paths at once (can pass multiple sections as an array).";
6
+
7
+
exportconstUSE_CASES_PROMPT=`You are tasked with analyzing Svelte 5 and SvelteKit documentation pages to identify when they would be useful.
8
+
9
+
Your task:
10
+
1. Read the documentation page content provided
11
+
2. Identify the main use cases, scenarios, or queries where this documentation would be relevant
12
+
3. Create a VERY SHORT, comma-separated list of use cases (maximum 200 characters total)
13
+
4. Think about what a developer might be trying to build or accomplish when they need this documentation
14
+
15
+
Guidelines:
16
+
- Focus on WHEN this documentation would be needed, not WHAT it contains
17
+
- Consider specific project types (e.g., "e-commerce site", "blog", "dashboard", "social media app")
18
+
- Consider specific features (e.g., "authentication", "forms", "data fetching", "animations")
19
+
- Consider specific components (e.g., "slider", "modal", "dropdown", "card")
20
+
- Consider development stages (e.g., "project setup", "deployment", "testing", "migration")
21
+
- Use "always" for fundamental concepts that apply to virtually all Svelte projects
22
+
- Be concise but specific
23
+
- Use lowercase
24
+
- Separate multiple use cases with commas
25
+
26
+
Examples of good use_cases:
27
+
- "always, any svelte project, core reactivity"
28
+
- "authentication, login systems, user management"
29
+
- "e-commerce, product listings, shopping carts"
30
+
- "forms, user input, data submission"
31
+
- "deployment, production builds, hosting setup"
32
+
- "animation, transitions, interactive ui"
33
+
- "routing, navigation, multi-page apps"
34
+
- "blog, content sites, markdown rendering"
35
+
36
+
Requirements:
37
+
- Maximum 200 characters (including spaces and commas)
38
+
- Lowercase only
39
+
- Comma-separated list of use cases
40
+
- Focus on WHEN/WHY someone would need this, not what it is
41
+
- Be specific about project types, features, or components when applicable
42
+
- Use "always" sparingly, only for truly universal concepts
43
+
- Do not include quotes or special formatting in your response
44
+
- Respond with ONLY the use cases text, no additional text
45
+
46
+
Here is the documentation page content to analyze:
47
+
`;
48
+
49
+
exportconstDISTILLED_PROMPT=`You are an expert in web development, specifically Svelte 5 and SvelteKit. Your task is to condense and distill the Svelte documentation into a concise format while preserving the most important information.
50
+
Shorten the text information AS MUCH AS POSSIBLE while covering key concepts.
51
+
52
+
Focus on:
53
+
1. Code examples with short explanations of how they work
54
+
2. Key concepts and APIs with their usage patterns
55
+
3. Important gotchas and best practices
56
+
4. Patterns that developers commonly use
57
+
58
+
Remove:
59
+
1. Redundant explanations
60
+
2. Verbose content that can be simplified
61
+
3. Marketing language
62
+
4. Legacy or deprecated content
63
+
5. Anything else that is not strictly necessary
64
+
65
+
Keep your output in markdown format. Preserve code blocks with their language annotations.
66
+
Maintain headings but feel free to combine or restructure sections to improve clarity.
67
+
68
+
Make sure all code examples use Svelte 5 runes syntax ($state, $derived, $effect, etc.)
69
+
70
+
Keep the following Svelte 5 syntax rules in mind:
71
+
* There is no colon (:) in event modifiers. You MUST use "onclick" instead of "on:click".
72
+
* Runes do not need to be imported, they are globals.
73
+
* $state() runes are always declared using let, never with const.
74
+
* When passing a function to $derived, you must always use $derived.by(() => ...).
75
+
* Error boundaries can only catch errors during component rendering and at the top level of an $effect inside the error boundary.
76
+
* Error boundaries do not catch errors in onclick or other event handlers.
77
+
78
+
IMPORTANT: All code examples MUST come from the documentation verbatim, do NOT create new code examples. Do NOT modify existing code examples.
79
+
IMPORTANT: Because of changes in Svelte 5 syntax, do not include content from your existing knowledge, you may only use knowledge from the documentation to condense.
0 commit comments