• src/blocks/additional-info/index.js (1)
• src/blocks/banking/index.js (1)
• src/blocks/climate/index.js (1)
• src/blocks/cuisine/index.js (1)
• src/blocks/dress/index.js (1)
• src/blocks/electricity/index.js (1)
• src/blocks/health/index.js (4)
• src/blocks/transport/index.js (5)
• src/js/conditional-block-registration.js (1)
• webpack.config.js (1)

• build/blocks/additional-info/block.json
• build/blocks/banking/block.json
• build/blocks/climate/block.json
• build/blocks/cuisine/block.json
• build/blocks/dress/block.json
• build/blocks/electricity/block.json
• build/blocks/health/block.json
• build/blocks/transport/block.json
• src/blocks/additional-info/block.json
• src/blocks/banking/block.json
• src/blocks/climate/block.json
• src/blocks/cuisine/block.json
• src/blocks/dress/block.json
• src/blocks/electricity/block.json
• src/blocks/health/block.json
• src/blocks/transport/block.json

• src/blocks/additional-info/index.js (diff tokens exceeds limit)
• src/blocks/banking/index.js (diff tokens exceeds limit)
• src/blocks/climate/index.js (diff tokens exceeds limit)
• src/blocks/cuisine/index.js (diff tokens exceeds limit)
• src/blocks/dress/index.js (diff tokens exceeds limit)
• src/blocks/electricity/index.js (diff tokens exceeds limit)
• src/js/conditional-block-registration.js (diff tokens exceeds limit)
• src/blocks/transport/index.js (nothing obtained from openai)
• webpack.config.js (nothing obtained from openai)
• src/blocks/health/index.js (nothing obtained from openai)

• src/blocks/electricity/index.js (no response)
• src/blocks/banking/index.js (no response)
• src/blocks/additional-info/index.js (no response)
• src/blocks/health/index.js (no response)
• src/blocks/dress/index.js (no response)
• src/blocks/cuisine/index.js (no response)
• src/js/conditional-block-registration.js (no response)
• webpack.config.js (no response)
• src/blocks/transport/index.js (no response)

• src/blocks/climate/index.js (diff too large)

• Review: 0
• LGTM: 0

Chat with CodeRabbit Bot (@coderabbitai)

• Reply on review comments left by this bot to ask follow-up questions. A review comment is a comment on a diff or a file.
• Invite the bot into a review comment chain by tagging @coderabbitai in a reply.

Code suggestions

• The bot may make code suggestions, but please review them carefully before committing since the line number ranges may be misaligned.
• You can edit the comment made by the bot and manually tweak the suggestion if it is slightly off.

Pausing incremental reviews

• Add @coderabbitai: ignore anywhere in the PR description to pause further reviews from the bot.

src/blocks/dress/block.json (1)

10-10: Consider a more intuitive icon for dress/clothing context.

The "admin-customizer" icon may not be immediately recognisable as dress-related. Consider alternatives such as "admin-appearance" or "admin-users" for better semantic alignment with clothing/attire.

src/blocks/electricity/block.json (1)

10-10: Consider a more semantic icon for electricity context.

The "admin-plugins" icon doesn't clearly relate to electricity or power. Consider more intuitive alternatives such as "lightbulb" or "admin-tools" for better semantic alignment.

src/blocks/additional-info/index.js (1)

53-53: Consider using template literals for HTML strings.

The string concatenation with + operator works but template literals provide better readability and are more idiomatic in modern JavaScript.

-content: '<strong>' + __('General', 'tour-operator') + '</strong>',
+content: `<strong>${__('General', 'tour-operator')}</strong>`,

Apply the same pattern on line 127.

Also applies to: 127-127

src/blocks/cuisine/index.js (1)

53-53: Consider using template literals for HTML strings.

Template literals provide better readability than string concatenation.

-content: '<strong>' + __('Cuisine', 'tour-operator') + '</strong>',
+content: `<strong>${__('Cuisine', 'tour-operator')}</strong>`,

Apply the same pattern on line 129.

Also applies to: 129-129

src/blocks/transport/index.js (1)

53-53: Consider using template literals for HTML strings.

Template literals are more readable than string concatenation.

-content: '<strong>' + __('Transport', 'tour-operator') + '</strong>',
+content: `<strong>${__('Transport', 'tour-operator')}</strong>`,

Apply the same pattern on line 128.

Also applies to: 128-128

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

• src/blocks/climate/index.js (1)
• src/blocks/cuisine/index.js (1)
• src/blocks/transport/index.js (4)

• src/blocks/climate/index.js (diff tokens exceeds limit)
• src/blocks/cuisine/index.js (diff tokens exceeds limit)
• src/blocks/transport/index.js (diff tokens exceeds limit)

• src/blocks/transport/index.js (no response)
• src/blocks/cuisine/index.js (no response)

• src/blocks/climate/index.js (diff too large)

• Review: 0
• LGTM: 0

Chat with CodeRabbit Bot (@coderabbitai)

• Reply on review comments left by this bot to ask follow-up questions. A review comment is a comment on a diff or a file.
• Invite the bot into a review comment chain by tagging @coderabbitai in a reply.

Code suggestions

• The bot may make code suggestions, but please review them carefully before committing since the line number ranges may be misaligned.
• You can edit the comment made by the bot and manually tweak the suggestion if it is slightly off.

Pausing incremental reviews

• Add @coderabbitai: ignore anywhere in the PR description to pause further reviews from the bot.

src/blocks/climate/index.js (2)

4-6: Add JSDoc comments for the registration function.

The coding guidelines require JSDoc comments with a @SInCE tag for all functions. This was previously flagged and remains unaddressed.

---

12-25: Replace inline SVG with centralized icon system or dashicon.

This inline SVG icon conflicts with the PR objectives which explicitly require using the centralized icons system. The past review comprehensively documented this issue, noting that block.json already defines "icon": "cloud". This remains unaddressed.

src/blocks/transport/index.js (1)

20-27: Fix isActive predicate logic mismatch.

The isActive function compares metadata.className (line 21), but the variation only defines metadata.name (line 25), not metadata.className. This will cause the isActive check to fail.

Apply this diff to fix the predicate:

 isActive: (blockAttributes, variationAttributes) => {
-    return blockAttributes.metadata?.className === variationAttributes.metadata?.className;
+    return blockAttributes.metadata?.name === variationAttributes.metadata?.name;
 },

src/blocks/cuisine/index.js (1)

67-80: Empty content attribute for metadata-bound paragraph.

The paragraph block with metadata bindings lacks a content attribute fallback. Whilst the binding to post meta key 'cuisine' will populate the content, consider adding a default/placeholder content value for clarity and to handle cases where the binding may not resolve.

src/blocks/climate/index.js (1)

66-66: Consider using template literals for string interpolation.

Whilst the string concatenation works correctly, the coding guidelines prefer template literals for cleaner code. Consider updating to:

-content: '<strong>' + __('Climate', 'tour-operator') + '</strong>',
+content: `<strong>${__('Climate', 'tour-operator')}</strong>`,

This also applies to line 141 in the example configuration.

src/blocks/transport/index.js (1)

4-177: Consider adding error handling for registration robustness.

The registration code lacks error handling. Wrapping the registration logic in a try-catch block would improve robustness and provide better debugging information if registration fails.

Consider this pattern:

 wp.domReady(() => {
+    try {
         // Register variation function
         const registerTransportVariation = () => {
             // ... existing code ...
         };
 
         // Initialize conditional registration
         const conditionalRegister = registerForPostTypesAndTemplates(
             ['destination'],
             ['destination'],
             registerTransportVariation
         );
 
         conditionalRegister();
+    } catch (error) {
+        // eslint-disable-next-line no-console
+        console.error('Failed to register Transport block variation:', error);
+    }
 });

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

• src/blocks/additional-info/index.js (1)
• src/blocks/banking/index.js (1)
• src/blocks/climate/index.js (1)
• src/blocks/cuisine/index.js (1)
• src/blocks/dress/index.js (1)
• src/blocks/electricity/index.js (1)
• src/blocks/health/index.js (1)
• src/blocks/transport/index.js (1)

• src/blocks/additional-info/index.js (diff tokens exceeds limit)
• src/blocks/banking/index.js (diff tokens exceeds limit)
• src/blocks/climate/index.js (diff tokens exceeds limit)
• src/blocks/cuisine/index.js (diff tokens exceeds limit)
• src/blocks/dress/index.js (diff tokens exceeds limit)
• src/blocks/electricity/index.js (diff tokens exceeds limit)
• src/blocks/health/index.js (diff tokens exceeds limit)
• src/blocks/transport/index.js (diff tokens exceeds limit)

• src/blocks/cuisine/index.js (no response)
• src/blocks/health/index.js (no response)
• src/blocks/electricity/index.js (no response)
• src/blocks/additional-info/index.js (no response)
• src/blocks/banking/index.js (no response)
• src/blocks/dress/index.js (no response)
• src/blocks/transport/index.js (no response)

• src/blocks/climate/index.js (diff too large)

• Review: 0
• LGTM: 0

Chat with CodeRabbit Bot (@coderabbitai)

• Reply on review comments left by this bot to ask follow-up questions. A review comment is a comment on a diff or a file.
• Invite the bot into a review comment chain by tagging @coderabbitai in a reply.

Code suggestions

• The bot may make code suggestions, but please review them carefully before committing since the line number ranges may be misaligned.
• You can edit the comment made by the bot and manually tweak the suggestion if it is slightly off.

Pausing incremental reviews

• Add @coderabbitai: ignore anywhere in the PR description to pause further reviews from the bot.

src/blocks/cuisine/index.js (2)

1-178: Add comprehensive JSDoc comments and @SInCE tags.

The file lacks JSDoc documentation required by the coding guidelines. All functions should have JSDoc comments including @SInCE tags indicating version 2.1.0.

---

53-53: String concatenation in translatable content can cause issues for translators.

The __() function should wrap the entire HTML string including the <strong> tags to provide proper context for translation.

Also applies to: 128-128

src/blocks/transport/index.js (4)

20-22: Consider using metadata.name for variation matching.

Whilst the current isActive predicate comparing className is functional (since className is defined on line 27), using metadata.name would be more semantically consistent with WordPress block variation patterns and align with the metadata-driven approach used throughout the variation definition.

Apply this diff to use metadata-based matching:

 isActive: (blockAttributes, variationAttributes) => {
-    return blockAttributes.className === variationAttributes.className;
+    return blockAttributes.metadata?.name === variationAttributes.metadata?.name;
 },

---

5-6: Add JSDoc documentation for the function.

The registerTransportVariation function lacks JSDoc documentation. According to coding guidelines, all functions must include proper JSDoc comments with a @since tag indicating the next version of the plugin (e.g., @since 2.1.0).

Apply this diff to add proper documentation:

+/**
+ * Registers the Transport block variation for destination post types.
+ *
+ * Creates a core/group variation with transport-specific attributes,
+ * innerBlocks structure, and metadata bindings for destination contexts.
+ *
+ * @since 2.1.0
+ */
 const registerTransportVariation = () => {

As per coding guidelines.

---

12-12: Replace hardcoded icon with custom SVG icon.

The transport block uses the hardcoded Dashicon string 'car', whilst other destination blocks (e.g., climate, ends-in) use custom SVG icons that align with the design system (20x20 viewBox, currentColor for fill/stroke). The PR objectives explicitly state to "integrate a centralized icon system" and "replace inline/hardcoded icons".

Replace the hardcoded string with a custom SVG icon following the pattern used by other blocks:

-icon: 'car',
+icon: (
+    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 20 20" width="20" height="20">
+        <path fill="currentColor" d="M15 8h-1V6c0-1.1-.9-2-2-2H8c-1.1 0-2 .9-2 2v2H5c-1.1 0-2 .9-2 2v5h2c0 1.1.9 2 2 2s2-.9 2-2h2c0 1.1.9 2 2 2s2-.9 2-2h2v-5c0-1.1-.9-2-2-2zM8 6h4v2H8V6zm-1 9c-.6 0-1-.4-1-1s.4-1 1-1 1 .4 1 1-.4 1-1 1zm6 0c-.6 0-1-.4-1-1s.4-1 1-1 1 .4 1 1-.4 1-1 1z"/>
+    </svg>
+),

---

53-53: Wrap entire HTML string in translation function.

Both lines 53 and 127 use string concatenation with __(), placing HTML tags outside the translation function. This prevents translators from seeing the full context and may cause translation issues. The entire HTML string, including tags, should be wrapped in __() to provide proper context for translators.

Apply these diffs to fix both occurrences:

Line 53:

-content: '<strong>' + __('Transport', 'tour-operator') + '</strong>',
+content: __('<strong>Transport</strong>', 'tour-operator'),

Line 127:

-content: '<strong>' + __('Transport', 'tour-operator') + '</strong>',
+content: __('<strong>Transport</strong>', 'tour-operator'),

Also applies to: 127-127

src/blocks/additional-info/index.js (3)

4-176: Add comprehensive JSDoc documentation.

The file lacks JSDoc comments required by the coding guidelines. Add a file-level JSDoc block describing the module and include @SInCE tags for all functions.

As per coding guidelines.

Apply this pattern:

+/**
+ * Additional Information block variation registration.
+ *
+ * Registers a conditional block variation for displaying additional destination information.
+ * Only available in destination post type and template contexts.
+ *
+ * @since 2.1.0
+ */
+
 import { __ } from '@wordpress/i18n';
 import { registerForPostTypesAndTemplates } from '@utils/conditional-block-registration.js';

 wp.domReady(() => {
+    /**
+     * Registers the Additional Information block variation.
+     *
+     * Creates a variation of core/group block with destination-specific metadata bindings.
+     *
+     * @since 2.1.0
+     */
     const registerAdditionalInfoVariation = () => {

---

53-53: Fix string concatenation in translatable content.

String concatenation with HTML tags breaks translator context. The __() function should wrap the entire string including HTML tags so translators see the complete context.

Apply this diff:

-                                        content: '<strong>' + __('General', 'tour-operator') + '</strong>',
+                                        content: __('<strong>General</strong>', 'tour-operator'),

---

127-127: Fix string concatenation in translatable content (duplicate).

Same issue as line 53: string concatenation breaks translator context.

Apply this diff:

-                                            content: '<strong>' + __('General', 'tour-operator') + '</strong>',
+                                            content: __('<strong>General</strong>', 'tour-operator'),

src/blocks/climate/index.js (3)

4-6: Add JSDoc comments for the registration function.

The coding guidelines require JSDoc comments for all functions, including an @SInCE tag indicating the next version. Add documentation for registerClimateVariation explaining its purpose, parameters (if any), and the version.

Apply this diff to add JSDoc comments:

 wp.domReady(() => {
-    // Register variation function
+    /**
+     * Registers the Climate block variation for destination post types.
+     *
+     * Creates a variation of core/group that displays climate and weather
+     * information with metadata bindings to the 'climate' post meta field.
+     *
+     * @since 2.1.0
+     */
     const registerClimateVariation = () => {

As per coding guidelines.

---

12-25: Replace inline SVG with icon from block.json.

The PR objectives (#691) require replacing inline icons with the centralized icon system. Your block.json already defines "icon": "cloud" (WordPress Dashicon), yet this code overrides it with an inline SVG. Remove the inline icon property from the variation registration to allow WordPress to use the icon defined in block.json.

Apply this diff to remove the inline icon:

         wp.blocks.registerBlockVariation('core/group', {
             name: 'lsx-tour-operator/climate',
             title: __('Climate', 'tour-operator'),
             description: __('Display climate and weather information for destinations.', 'tour-operator'),
-            icon: wp.element.createElement(
-                'svg',
-                {
-                    xmlns: 'http://www.w3.org/2000/svg',
-                    width: 20,
-                    height: 20,
-                    viewBox: '0 0 20 20',
-                    fill: 'none',
-                },
-                wp.element.createElement('path', {
-                    d: 'M15.175 1.5371C15.3281 1.5996 15.4406 1.7371 15.4719 1.8996L16 4.4996L18.6 5.0246C18.7625 5.05897 18.8969 5.16835 18.9625 5.32147C19.0281 5.4746 19.0094 5.6496 18.9188 5.7871L17.4531 7.99647L18.9188 10.2058C19.0094 10.3433 19.0281 10.5183 18.9625 10.6715C18.8969 10.8246 18.7625 10.9371 18.6 10.9683L16.6562 11.3652C16.2844 11.0933 15.8719 10.8777 15.425 10.7277C15.3469 10.3308 15.2125 9.95585 15.0281 9.6121C15.325 9.14647 15.5 8.59335 15.5 7.99647C15.5 6.34022 14.1562 4.99647 12.5 4.99647C11.0031 4.99647 9.7625 6.09335 9.5375 7.5246C8.70938 6.89022 7.67813 6.50897 6.55625 6.49647L6.08437 5.7871C5.99375 5.6496 5.975 5.4746 6.04063 5.32147C6.10625 5.16835 6.24062 5.05585 6.40312 5.0246L9 4.4996L9.525 1.8996C9.55937 1.7371 9.66875 1.60272 9.82187 1.5371C9.975 1.47147 10.15 1.49022 10.2875 1.58085L12.5 3.0496L14.7094 1.58397C14.8469 1.49335 15.0219 1.4746 15.175 1.54022V1.5371ZM14 7.9996C14 8.11835 13.9875 8.23397 13.9594 8.34647C13.2812 7.81522 12.4281 7.4996 11.5 7.4996C11.3562 7.4996 11.2156 7.50585 11.0781 7.52147C11.2781 6.92772 11.8406 6.4996 12.5 6.4996C13.3281 6.4996 14 7.17147 14 7.9996ZM4 17.9996C2.34375 17.9996 1 16.6558 1 14.9996C1 13.6715 1.8625 12.5433 3.05938 12.1496C3.01875 11.9402 3 11.7215 3 11.4996C3 9.56522 4.56562 7.9996 6.5 7.9996C7.84688 7.9996 9.01562 8.75897 9.6 9.8746C10.0594 9.34022 10.7406 8.9996 11.5 8.9996C12.8813 8.9996 14 10.1183 14 11.4996C14 11.6715 13.9812 11.8371 13.95 11.9996C13.9656 11.9996 13.9844 11.9996 14 11.9996C15.6562 11.9996 17 13.3433 17 14.9996C17 16.6558 15.6562 17.9996 14 17.9996H4Z',
-                    fill: '#currentColor',
-                })
-            ),
             category: 'lsx-tour-operator',

---

66-66: Wrap entire HTML string in translation function for proper translator context.

String concatenation in translatable content causes issues for translators. The __() function should wrap the entire HTML string including the <strong> tags to provide proper context for translation.

Apply this diff to lines 66 and 141:

-                                        content: '<strong>' + __('Climate', 'tour-operator') + '</strong>',
+                                        content: __('<strong>Climate</strong>', 'tour-operator'),

Also applies to: 141-141

src/blocks/health/index.js (2)

53-53: Wrap the entire HTML string in the translation function.

String concatenation in translatable content causes issues for translators. The __() function should wrap the entire HTML string including the <strong> tags to provide proper context for translation.

Apply this diff:

-                                        content: '<strong>' + __('Health', 'tour-operator') + '</strong>',
+                                        content: __('<strong>Health</strong>', 'tour-operator'),

---

128-128: Wrap the entire HTML string in the translation function.

Same issue as line 53: string concatenation in translatable content prevents translators from seeing the full context. The __() function should wrap the entire HTML string including the <strong> tags.

Apply this diff:

-                                            content: '<strong>' + __('Health', 'tour-operator') + '</strong>',
+                                            content: __('<strong>Health</strong>', 'tour-operator'),

src/blocks/electricity/index.js (2)

53-53: Fix translatable string to include HTML tags.

This issue was previously flagged but remains unresolved. The HTML <strong> tags should be inside the translatable string to provide proper context for translators. Concatenating HTML outside the translation function can cause localisation issues.

Apply this diff:

-                                        content: '<strong>' + __('Electricity', 'tour-operator') + '</strong>',
+                                        content: __('<strong>Electricity</strong>', 'tour-operator'),

---

128-128: Fix translatable string to include HTML tags.

Same issue as Line 53. The HTML <strong> tags should be inside the translatable string to provide proper context for translators.

Apply this diff:

-                                            content: '<strong>' + __('Electricity', 'tour-operator') + '</strong>',
+                                            content: __('<strong>Electricity</strong>', 'tour-operator'),

src/blocks/dress/index.js (3)

21-24: Use a valid colour keyword for the SVG fill.

'#currentColor' is not a valid CSS colour token, so the icon will not inherit the theme colour correctly. Switch to 'currentColor' (without the #) to let the icon follow editor styling.

-                    fill: '#currentColor',
+                    fill: 'currentColor',

---

66-66: Wrap the entire HTML string in the translation function.

String concatenation in translatable content can cause issues for translators. The __() function should wrap the entire HTML string including the <strong> tags to provide proper context for translation.

-                                        content: '<strong>' + __('Dress', 'tour-operator') + '</strong>',
+                                        content: __('<strong>Dress</strong>', 'tour-operator'),

---

33-35: Guard against undefined className values.

Whilst the predicate now correctly compares className directly (good fix from previous review), it will still match unrelated blocks when both className values are undefined. Add a guard to ensure only blocks with the intended className are matched.

-            isActive: (blockAttributes, variationAttributes) => {
-                return blockAttributes.className === variationAttributes.className;
-            },
+            isActive: (blockAttributes, variationAttributes) => {
+                return blockAttributes?.className === variationAttributes?.className && 
+                       blockAttributes?.className !== undefined;
+            },

src/blocks/cuisine/index.js (1)

20-27: Consider comparing metadata.name in isActive predicate for consistency.

While the current className comparison should work, WordPress best practice for block variations recommends comparing metadata.name instead. This approach is more reliable and aligns with the recommended pattern across the WordPress ecosystem.

Apply this diff:

 isActive: (blockAttributes, variationAttributes) => {
-    return blockAttributes.className === variationAttributes.className;
+    return blockAttributes.metadata?.name === variationAttributes.metadata?.name;
 },

src/blocks/health/index.js (1)

24-26: Consider internationalizing the metadata name.

The metadata.name is set to a static string 'Health'. Whilst this may be intentional for internal use, consider whether it should be internationalized for consistency with the rest of the variation metadata.

                 metadata: {
-                    name: 'Health',
+                    name: __('Health', 'tour-operator'),
                 },

src/blocks/electricity/index.js (2)

20-22: Add optional chaining to the isActive predicate for robustness.

Whilst the className comparison is now correct (addressing the previous review), adding optional chaining would make this more defensive against edge cases where className might be undefined.

Apply this diff:

             isActive: (blockAttributes, variationAttributes) => {
-                return blockAttributes.className === variationAttributes.className;
+                return blockAttributes?.className === variationAttributes?.className;
             },

---

170-178: Add error handling for registration failures.

The coding guidelines require proper error handling. If the conditional registration fails, there's no feedback or graceful degradation.

As per coding guidelines.

Apply this diff to add error handling:

     // Initialize conditional registration
     const conditionalRegister = registerForPostTypesAndTemplates(
         ['destination'], // Supported post types
         ['destination'], // Template slug patterns
         registerElectricityVariation
     );

-    conditionalRegister();
+    try {
+        conditionalRegister();
+    } catch (error) {
+        console.error('Failed to register Electricity block variation:', error);
+    }
 });

src/blocks/banking/index.js (3)

20-22: Consider adding optional chaining for defensive coding.

Whilst the main issue from the previous review has been addressed (comparing className instead of metadata?.className), adding optional chaining to blockAttributes would make the code more defensive against edge cases.

             isActive: (blockAttributes, variationAttributes) => {
-                return blockAttributes.className === variationAttributes.className;
+                return blockAttributes?.className === variationAttributes.className;
             },

---

4-6: Consider adding JSDoc documentation.

According to the coding guidelines, functions should be documented with JSDoc comments including a @since tag. Adding documentation would improve code maintainability.

 wp.domReady(() => {
-    // Register variation function
+    /**
+     * Registers the Banking block variation for destination contexts.
+     *
+     * Creates a group block variation with banking-specific metadata,
+     * nested blocks for title and description, and a "View More" button.
+     *
+     * @since 2.1.0
+     */
     const registerBankingVariation = () => {

---

6-194: Consider adding error handling for block registration.

Wrapping the block registration in a try-catch block would improve robustness and provide better debugging information if registration fails.

     const registerBankingVariation = () => {
-
+        try {
         wp.blocks.registerBlockVariation('core/group', {
             name: 'lsx-tour-operator/banking',
             // ... rest of configuration
         });
+        } catch (error) {
+            // eslint-disable-next-line no-console
+            console.error('Failed to register Banking block variation:', error);
+        }
     };

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro