Skip to content

Commit 1edad8c

Browse files
committed
Adjust file create + refine prompt
1 parent c97b8c0 commit 1edad8c

File tree

2 files changed

+62
-61
lines changed

2 files changed

+62
-61
lines changed

packages/vscode-extension/src/node/shopify-magic-prompts/base.ts

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -26,6 +26,7 @@ export function basePrompt(textEditor: TextEditor): string {
2626
</focus_areas>
2727
<ensurance>
2828
<point>The new code you propose contain full lines of valid code and keep the correct indentation, scope, and style format as the original code</point>
29+
<point>The new code you propose is different and better than the original code</point>
2930
<point>Scopes are defined by the opened by "{%", "{{" with the matching closing element "%}" or "}}"</point>
3031
<point>The range must include the closing element ("%}","}}") for every opening element ("{%","{{")</point>
3132
<point>Code suggestions cannot overlap in line numbers. If you have multiple suggestions for the same code chunk, merge them into a single suggestion</point>
Lines changed: 61 additions & 61 deletions
Original file line numberDiff line numberDiff line change
@@ -1,86 +1,86 @@
11
export function uxPrinciplesRules() {
22
return `
3-
<ux_principles>
4-
<settings>
5-
<general_guidance>
6-
Keep it simple, clear, and non-repetitive.
3+
<ux_principles>
4+
<settings>
5+
<general_guidance>
6+
Keep it simple, clear, and non-repetitive.
77
8-
- The setting type can provide context that the setting label doesn't need to provide. Example: "Number of columns" can simply be "Columns" if the input indicates that it's a number value.
9-
- Assume all settings to be device-agnostic, with graceful scaling between breakpoints. Only mention mobile or desktop if there is a unique setting required.
10-
- Use common shorthand where it makes sense. Example: Max/Min to mean Maximum and Minimum. Caveat: ensure these values are translated/localized correctly
11-
- Help text: Minimize use as much as possible. If really required, make it short and remove punctuation unless it's more than 1 sentence (but it shouldn't be!)
12-
</general_guidance>
8+
- The setting type can provide context that the setting label doesn't need to provide. Example: "Number of columns" can simply be "Columns" if the input indicates that it's a number value.
9+
- Assume all settings to be device-agnostic, with graceful scaling between breakpoints. Only mention mobile or desktop if there is a unique setting required.
10+
- Use common shorthand where it makes sense. Example: Max/Min to mean Maximum and Minimum. Caveat: ensure these values are translated/localized correctly
11+
- Help text: Minimize use as much as possible. If really required, make it short and remove punctuation unless it's more than 1 sentence (but it shouldn't be!)
12+
</general_guidance>
1313
14-
<information_architecture>
15-
<ordering>
16-
The order of theme settings greatly impacts the merchant's ability to understand and configure the section/block.
14+
<information_architecture>
15+
<ordering>
16+
The order of theme settings greatly impacts the merchant's ability to understand and configure the section/block.
1717
18-
- List settings to reflect the order of elements they control in the preview. Top to bottom, left to right, background to foreground.
19-
- List resource pickers first, if they're needed, followed by customization settings. Focus on what the merchant needs to take action on in order for the section/block to function. Example: a featured collection block needs the merchant to choose a collection before deciding the number of products per row.
20-
- List settings in order of visual impact, example: Number of products per row should come before the product card settings.
21-
</ordering>
18+
- List settings to reflect the order of elements they control in the preview. Top to bottom, left to right, background to foreground.
19+
- List resource pickers first, if they're needed, followed by customization settings. Focus on what the merchant needs to take action on in order for the section/block to function. Example: a featured collection block needs the merchant to choose a collection before deciding the number of products per row.
20+
- List settings in order of visual impact, example: Number of products per row should come before the product card settings.
21+
</ordering>
2222
23-
<groupings>
24-
Consider grouping settings under a heading if there are more than 1 related setting. List ungrouped settings at the top of the section/block.
23+
<groupings>
24+
Consider grouping settings under a heading if there are more than 1 related setting. List ungrouped settings at the top of the section/block.
2525
26-
Common groupings:
26+
Common groupings:
2727
28-
- Layout
29-
- Typography
30-
- Colors
31-
- Padding
32-
</groupings>
28+
- Layout
29+
- Typography
30+
- Colors
31+
- Padding
32+
</groupings>
3333
34-
<naming>
35-
Remove word duplication in the heading and nested labels. When a word appears in a heading (e.g. "Color"), it should not be repeated in nested setting labels or help text. The hierarchy of information provides sufficient context.
36-
</naming>
34+
<naming>
35+
Remove word duplication in the heading and nested labels. When a word appears in a heading (e.g. "Color"), it should not be repeated in nested setting labels or help text. The hierarchy of information provides sufficient context.
36+
</naming>
3737
38-
<conditional>
39-
Use conditional settings when it:
38+
<conditional>
39+
Use conditional settings when it:
4040
41-
- simplifies decision-making for merchants via progressive disclosure
42-
- avoids duplication of settings
43-
- avoids visual clutter and reduces cognitive load
41+
- simplifies decision-making for merchants via progressive disclosure
42+
- avoids duplication of settings
43+
- avoids visual clutter and reduces cognitive load
4444
45-
Conditional settings should appear in the information architecture wherever they're most relevant. That might be directly below the trigger setting, or it could be a whole separate group of settings that are surfaced elsewhere where it makes sense for the merchant.
45+
Conditional settings should appear in the information architecture wherever they're most relevant. That might be directly below the trigger setting, or it could be a whole separate group of settings that are surfaced elsewhere where it makes sense for the merchant.
4646
47-
Tradeoffs and considerations of conditional settings:
47+
Tradeoffs and considerations of conditional settings:
4848
49-
- They hide functionality/options that help merchants decide how style their website, so be judicious in what concepts you tie together. For example, don't make a Product card's "Swatch display" setting conditional on a "Quick buy" setting. They are both related to variant selection, but they serve different purposes.
50-
- Limit conditions to 2 levels deep to avoid complex logic (up for discussion!)
51-
- Even when not shown, a conditional setting's value is evaluated in the Liquid code. Code defensively, never assume a theme setting's value is nil.
52-
</conditional>
49+
- They hide functionality/options that help merchants decide how style their website, so be judicious in what concepts you tie together. For example, don't make a Product card's "Swatch display" setting conditional on a "Quick buy" setting. They are both related to variant selection, but they serve different purposes.
50+
- Limit conditions to 2 levels deep to avoid complex logic (up for discussion!)
51+
- Even when not shown, a conditional setting's value is evaluated in the Liquid code. Code defensively, never assume a theme setting's value is nil.
52+
</conditional>
5353
54-
<input_type>
55-
**Checkbox**: Treat checkbox as an on/off switch. Avoid using verb-based labels, example: use "Language selector" and not "Enable language selector". The presence of the verb may inadvertently suggest the direction to toggle to enable or disable it.
54+
<input_type>
55+
**Checkbox**: Treat checkbox as an on/off switch. Avoid using verb-based labels, example: use "Language selector" and not "Enable language selector". The presence of the verb may inadvertently suggest the direction to toggle to enable or disable it.
5656
57-
**Select**: Keep select option labels as short as possible so they can be dynamically displayed as segmented controls
58-
</input_type>
59-
</information_architecture>
60-
</settings>
57+
**Select**: Keep select option labels as short as possible so they can be dynamically displayed as segmented controls
58+
</input_type>
59+
</information_architecture>
60+
</settings>
6161
62-
<server_side_rendering>
63-
Storefronts are to be rendered server-side with Liquid as a first principle. As opposed to client-side JavaScript.
62+
<server_side_rendering>
63+
Storefronts are to be rendered server-side with Liquid as a first principle. As opposed to client-side JavaScript.
6464
65-
When using JavaScript to render part of the page, fetch the new HTML from the server wherever possible.
66-
<optimistic_ui>
67-
This is the exception to the rule of server-side rendering
65+
When using JavaScript to render part of the page, fetch the new HTML from the server wherever possible.
66+
<optimistic_ui>
67+
This is the exception to the rule of server-side rendering
6868
69-
"Optimistic UI" is the idea that we can update part of the UI before the server response is received in the name of **perceived performance**.
69+
"Optimistic UI" is the idea that we can update part of the UI before the server response is received in the name of **perceived performance**.
7070
71-
<criteria>
72-
Key factors to consider when deciding whether to use optimistic UI:
71+
<criteria>
72+
Key factors to consider when deciding whether to use optimistic UI:
7373
74-
1. You are updating a **small** portion of the UI on the client (with JavaScript) before the server response is received.
75-
2. The API request has a high degree of certainty of being successful.
74+
1. You are updating a **small** portion of the UI on the client (with JavaScript) before the server response is received.
75+
2. The API request has a high degree of certainty of being successful.
7676
77-
Examples of appropriate use cases:
77+
Examples of appropriate use cases:
7878
79-
When filtering a collection page, we can update the a list of applied filters client-side as a Buyer chooses them, i.e. "Color: Red" or "Size: Medium". However, we do not know how many products will be returned that match the filters, so we can't update the product grid or a count of products.
79+
When filtering a collection page, we can update the a list of applied filters client-side as a Buyer chooses them, i.e. "Color: Red" or "Size: Medium". However, we do not know how many products will be returned that match the filters, so we can't update the product grid or a count of products.
8080
81-
When a Buyer attempts to add an item to their cart, we can update the cart item count client-side. Assuming our product form's "add to cart" button is already checking the item's availability, we can have a reasonably high degree of certainty that the item will be added to the cart (API request is successful). However, we do not know what the new cart total will be, nor do we know what the line items will look like, so we can't update those in a cart drawer without waiting for the server response.
82-
</criteria>
83-
</optimistic_ui>
84-
</server_side_rendering>
85-
</ux_principles>`;
81+
When a Buyer attempts to add an item to their cart, we can update the cart item count client-side. Assuming our product form's "add to cart" button is already checking the item's availability, we can have a reasonably high degree of certainty that the item will be added to the cart (API request is successful). However, we do not know what the new cart total will be, nor do we know what the line items will look like, so we can't update those in a cart drawer without waiting for the server response.
82+
</criteria>
83+
</optimistic_ui>
84+
</server_side_rendering>
85+
</ux_principles>`;
8686
}

0 commit comments

Comments
 (0)