style rules for marketplace

.github/workflows/stylecheck.yml

@@ -33,7 +33,7 @@ jobs:
         id: stylecheck
         env:
           GITHUB_TOKEN: ${{ secrets.STYLECHECK }}
-          LLM_JWT: ${{ secrets.LLM_JWT }} 
+          LLM_TOKEN: ${{ secrets.LLM_TOKEN }} 
           REPO_OWNER: ${{ github.repository_owner }}
           REPO_NAME: ${{ github.event.repository.name }}
           PR_NUMBER: ${{ github.event.pull_request.number }}

llm_client.py

@@ -21,40 +21,34 @@ def get_response(prompt):
             r = requests.post('https://openwebui.dev.devrev-eng.ai/api/chat/completions', json=payload,
                             headers=headers)
             r.raise_for_status()
-            print(r)
 
             if not r.text:
                 raise ValueError("Empty response received from API")
-            else:
-                response = r.json()
-
-            if not response.get('choices'):
+            json_response = r.json()
+            if not json_response.get('choices'):
                 raise ValueError("No 'choices' field in response")
-            if not response['choices'][0].get('message'):
+            if not json_response['choices'][0].get('message'):
                 raise ValueError("No 'message' field in response")
-            if not response['choices'][0]['message'].get('content'):
+            if not json_response['choices'][0]['message'].get('content'):
                 raise ValueError("No 'content' field in response")
-            else:
-                response = response['choices'][0]['message']['content']
 
+            response = json_response['choices'][0]['message']['content']
+
+            # Check if final response is empty
             if not response:
-                raise ValueError("Empty content received from LLM.")
-            else:
-                print("Response received from LLM.")
-                return response
+                raise ValueError("Empty content received from API")
+
+            return response
 
         except requests.RequestException as e:
-            msg = f"HTTP request failed. Error: {type(e)} {e}"
-            print(msg)
-            return msg
+            print(f"HTTP request failed. Error: {type(e)} {e}")
+            return None
         except ValueError as e:
-            msg = f"Invalid response received. Error: {e}"
-            print(msg)
-            return msg
+            print(f"Invalid response received. Error: {e}")
+            return None
         except Exception as e:
-            msg = f"Failed to generate response. Error: {type(e)} {e}"
-            print(msg)
-            return msg
+            print(f"Failed to generate response. Error: {type(e)} {e}")
+            return None
 
 def get_lines_between_tags(text, tag):
   pattern = r'<' + tag + r'>(.*?)<\/' + tag + r'>'

style/prompt.md

@@ -1,3 +1,3 @@
-You are an expert technical documentation editor. Analyze the included document and revise it so that it adheres to the following style rules. While you can make suggestions for being more concise, be very careful not to remove any facts from the document. Also do not change the document structure, including removing the title or headings, unless the original structure violates any of the guidelines. Also check the terminology given in CSV format inside the `<terminology>` element.
+You are an expert technical documentation editor. Analyze the included document and revise it so that it adheres to the following style rules. While you can make suggestions for being more concise, be very careful not to remove any facts from the document. In general, make the minimum number of changes necessary to ensure that the document adheres to the guidelines. Avoid changing the document structure, including removing the title or headings, unless the original structure violates any of the guidelines. Also check the terminology given in CSV format inside the `<terminology>` element.
 
-In your response, summarize the violations that you fixed. Return the revised markdown inside a separate element `<document>` element, just like in this request, that contains only the document and no other commentary. I’m going to read your suggestions through an API and need to be able to get just the document for the next stage.
+In your response, summarize the fixes you made. Return the revised markdown inside a separate `<document>` element, just like in this request, that contains only the document and no other commentary. I’m going to read your suggestions through an API and need to be able to get just the document for the next stage.

style/sample-marketplace.md

@@ -0,0 +1,33 @@
+# Auto Parts to Conversation
+
+<img src="https://devrev.ai/marketplace/api/item-artifact/don%3Acore%3Advrv-us-1%3Adevo%2F0%3Aartifact%2F7398" align="center"/> 
+
+## Overview
+
+The Auto Part to Conversation snap-in is a powerful tool that utilizes advanced natural language processing (NLP) capabilities to analyze customer conversations. It aims to automatically identify the specific parts discussed in a conversation, providing valuable insights for enhanced customer service.
+
+## How it Works
+
+Once you install the snap-in, it does the following:
+
+1. Resolution assignment: When the conversation is resolved, the snap-in will automatically analyze customer conversations and identify the relevant parts being discussed. It will assign the appropriate part to the conversation based on its analysis.
+
+2. No part assignment when uncertain: In cases where the snap-in is unable to confidently identify a part, it will refrain from assigning any part to the conversation, ensuring accuracy.
+
+## Features
+
+**Automatic part assignment**
+
+The Auto Part to Conversation snap-in eliminates the need for manual intervention by automatically assigning the relevant part to a conversation.
+
+**Channel compatibility**
+
+It seamlessly works across various communication channels, including email, PLuG, and Slack, providing consistent functionality and efficiency.
+
+**High accuracy**
+
+The snap-in ensures high accuracy by assigning a part only when it has a high level of confidence, minimizing the possibility of errors.
+
+## Installation
+
+To enable the auto part to conversation snap-in, click the Install button and follow the installation steps.

style/style-common.md

@@ -7,21 +7,33 @@ For the writing style, apply the following descriptive keywords to revising the
 - Vocabulary choice: consistent, technical
 - Grammar and syntax: structured, flawless, articulate
 - Descriptive language: clear, concise, informative
-- Language variant: standard technical/professional US American English; not British, Indian, or other variants.
+- Language variant: standard technical/professional US American English; not British, Indian, or other variants
+- Prohibited: profanity, hate speech, non-inclusive words, or any other unprofessional expressions
 
 There are also some very specific style rules that need to be followed:
 
+- Avoid future tense when describing the behavior of the product. Use simple present instead.
+- Do not make any reference to how things used to be ("currently", "new") or to future plans.
+
+### Titles
+
+- Do not use w-words (what, why, how) in headings or titles. 
+- Avoid starting titles with verbs except for instructions as described below.
+- Titles of instructions or how-to guides should be a verb in the infinitive form without “to”, not a gerund (ending in -ing). Titles of any other type of section should be noun phrases.
 - Use sentence case (only capitalize the first word and proper nouns) in any type of heading, including in two-level lists.
+
+### Instructions or how-to guides
+
+- They may use two levels; both should be ordered (numbered) lists, not unordered (bulleted) lists.
+- Instructions should be in imperative mood.
+- If there is a location or condition in a step, it should be at the front of the main clause, which must still be in imperative mood.
+- Steps should be more than a single "click"; combine steps if needed to make them more meaningful. If there is an outcome of the step stated, it should be part of the same step, not a new step.
+
+### Lists
+
 - Ensure that any list is in parallel structure (use the same syntax for every entry).
-- Instructions or how-to guides:
-    - They may use two levels; both should be ordered (numbered) lists, not unordered (bulleted) lists.
-    - Instructions should be in imperative mood.
-    - If there is a location or condition in a step, it should be at the front of the main clause, which must still be in imperative mood.
-    - Steps should be more than a single "click"; combine steps if needed to make them more meaningful. If there is an outcome of the step stated, it should be part of the same step, not a new step.
 - End each list item with a period or other appropriate sentence-ending punctuation, except in the following cases:
     - If the item consists of a single word, don't add end punctuation.
     - If the item doesn't include a verb, don't add end punctuation.
     - If the item is entirely in code font, don't add end punctuation.
     - If the item is entirely link text or a document title, don't add end punctuation.
-- Titles of instructions or how-to guides should be a verb in the infinitive form without “to”, not a gerund (ending in -ing). Titles of any other type of section should be noun phrases.
-- Avoid future tense when describing the behavior of the product. Use simple present instead.

style/style-marketplace.md

@@ -0,0 +1,9 @@
+## Marketplace-specific style
+
+### Document structure
+
+- Start with a paragraph, not a title or heading.
+- The first section should be an H2 titled "Features" containing a bulleted list of the snap-in features.
+- The second section should be an H2 titled "Installation" containing a numbered list of the installation instructions.
+- The third section should be an H2 titled "Configuration" containing a numbered list of the configuration instructions.
+- No other sections are allowed.

style/term-common.csv

@@ -1,6 +1,7 @@
 Deprecated;Approved
 foo;example
 Devrev;DevRev
+navigate to;go to
 RevOrg;workspace
 RevUser;customer
 snapin;snap-in