Sync agents and skills from help-content-tools

.github/agents/Assess-doc-impact.agent.md

@@ -30,6 +30,8 @@ Invoke the **jira-context** skill to fetch the Jira ticket. Extract the followin
 | Description | `fields.description` |
 | Issue type | `fields.issuetype.name` |
 | Status | `fields.status.name` |
+| Reporter display name | `fields.reporter.displayName` |
+| Reporter account ID | `fields.reporter.accountId` |
 | Assignee display name | `fields.assignee.displayName` |
 | Assignee account ID | `fields.assignee.accountId` |
 | Labels already applied | `fields.labels` |
@@ -147,7 +149,7 @@ Only run this step if either help.qlik.com or Qlik.dev impact = `yes`.
 
 Build a single structured comment from all gathered findings and post it to the Jira ticket using **ADF (Atlassian Document Format)**. Then apply labels.
 
-**Assignee notification:** If either impact is `yes` and the ticket has an assignee (`fields.assignee.accountId` is present), include a mention node inline with the call-to-action text.
+**Notification:** If input quality is `incomplete` and the ticket has a reporter (`fields.reporter.accountId` is present), include a mention node for the reporter inline with the call-to-action text. Otherwise, if either impact is `yes` and the ticket has an assignee (`fields.assignee.accountId` is present), include a mention node for the assignee inline with the call-to-action text.
 
 #### ADF comment structure
 
@@ -160,9 +162,34 @@ The comment should contain paragraphs for:
 4. Qlik.dev impact
 5. Complexity
 6. Additional considerations (only if availability assumptions, AI/GenAI features, or migration impact detected)
-7. Call to action (with inline assignee mention if applicable)
+7. Call to action (with inline reporter mention if input quality is incomplete; otherwise, with inline assignee mention if applicable)
 
-**Call-to-action paragraph with assignee mention (when assignee exists and either impact is yes):**
+**Call-to-action paragraph with reporter mention (when input quality is incomplete):**
+```json
+{
+  "type": "paragraph",
+  "content": [
+    {
+      "type": "text",
+      "text": "Call to action: ",
+      "marks": [{"type": "strong"}]
+    },
+    {
+      "type": "mention",
+      "attrs": {
+        "id": "<fields.reporter.accountId>",
+        "text": "@<fields.reporter.displayName>"
+      }
+    },
+    {
+      "type": "text",
+      "text": " [call-to-action text based on outcome]"
+    }
+  ]
+}
+```
+
+**Call-to-action paragraph with assignee mention (when input quality is good, assignee exists, and either impact is yes):**
 ```json
 {
   "type": "paragraph",
@@ -187,7 +214,7 @@ The comment should contain paragraphs for:
 }
 ```
 
-**Call-to-action paragraph without assignee mention:**
+**Call-to-action paragraph without a mention (when the applicable reporter or assignee is not available):**
 ```json
 {
   "type": "paragraph",
@@ -227,7 +254,7 @@ The assessment report should contain:
 - **AI/GenAI feature:** [If detected: "This feature uses AI/ML capabilities and requires GenAI disclaimers and responsible AI documentation"]
 - **Migration impact:** [If detected: briefly describe the impact on existing users, migration requirements, or breaking changes]
 
-**Call to action:** [@assignee if applicable] [see call-to-action rules below]
+**Call to action:** [@reporter if input quality is incomplete; otherwise @assignee if applicable] [see call-to-action rules below]
 
 #### Call-to-action rules
 

.github/skills/markdown-markup-validation/SKILL.md

@@ -0,0 +1,40 @@
+---
+name: markdown-markup-validation
+description: "Use when: validating Markdown output for Qlik Help content, including standard Markdown, Markdig styling, images, links, and embedded HTML."
+---
+
+# Markdown Markup Validation Skill
+
+Use this skill to validate Markdown source for Qlik Help content. The build uses Markdig with repository-specific styling extensions. Apply `qlik-writing-guidelines` separately for writing, accessibility, localization, and naming.
+
+## YAML Front Matter
+
+- Start each topic with a YAML front-matter block delimited by `---` on its own first and closing lines.
+- Preserve the fields and values of an existing topic unless the change requires an update.
+- For a new topic, copy the front matter from a nearby topic in the same guide. Most guides use `title`, `description`, `categories`, `hidden`, `isApi`, `qlik-products`, `persona`, and `topics`; legacy data-integration topics use only the applicable taxonomy lists.
+- Use YAML lists for multiple `qlik-products`, `persona`, or `topics` values. Keep Boolean values as `True` or `False`.
+- Quote a scalar value when it contains YAML-significant characters, such as `:`, `#`, `{`, or `}`.
+
+## Validate
+
+- Use a single level-one heading for the topic title. Do not skip heading levels.
+- Escape Markdown punctuation with `\` when it must be literal. Use a blank line for a new paragraph and `<br/>` only for a forced line break.
+- Use `**bold**`, `_italic_`, and backticks for inline code. Use matching fenced code blocks for multi-line code.
+- Use consistent list markers and indent nested list items. Ordered lists can use `1.` for every item; Markdig numbers them automatically.
+- Use Markdown tables with a header row and alignment delimiter row. Keep the number of cells consistent across rows.
+- Use forward slashes in local paths. Internal published-topic links use paths such as `/Content/cloud-platform/topic.htm`; external links use full `https://` URLs and `{target=_blank class=see-also-link-external}`.
+- Give images meaningful alternative text. Use `alt=""` only for decorative images.
+
+## Markdig Styling
+
+- Add an inline style with `::text::{class=style-name}`.
+- Add a block style with a matching `:::{class=style-name}` opening delimiter and `:::` closing delimiter on their own lines. Use this for note, tip, and warning blocks.
+- Add a block attribute directly after the paragraph it styles, for example `Introduction text.{class=introduction}`.
+- Use a matching `^^^Caption` opening delimiter and `^^^` closing delimiter for a figure containing a Markdown image.
+- Keep attributes in balanced braces and place them directly after the element they modify.
+- Do not create, add, or edit `data-mc-conditions` or `mc-data-conditions` feature-condition markup. Flag any existing feature-condition markup for the content owner to resolve.
+
+## Embedded HTML
+
+- Use embedded HTML only when Markdown or a Markdig extension cannot produce the required output.
+- Ensure HTML tags and comments are balanced, correctly nested, and use quoted attribute values.