Add CODEOWNERS and update Copilot instructions

Add a new .github/CODEOWNERS file that assigns ownership for root files and maps individual plugin directories to their primary reviewers, with a plugins/* fallback owner. Update .github/copilot-instructions.md to reformat and clarify contributor guidelines: tighten wording and formatting, add/clarify metadata fields (name, schemaVersion, category, importNotSupported, author.name options), expand UI configuration guidance (required flags, displayName/name/help/placeholder conventions), add rules for dashboards and manifest inclusion, strengthen dataStreams and docs guidance, and include other minor wording and formatting fixes to improve reviewability.

Author: clarkd

.github/CODEOWNERS

@@ -0,0 +1,23 @@
+# Root files
+/*.md                @squaredup
+/LICENSE             @squaredup
+/.github/*           @squaredup
+
+# Request review from original author
+plugins/DigiCert/*  @shaswot77
+plugins/FantasyPremierLeague/*  @TimWheeler-SQUP
+plugins/GoogleSheets/*  @kieranlangton
+plugins/MetOffice/*  @blackgrouse
+plugins/Phare/*  @vinbab
+plugins/Postcoder/*  @richbenwell
+plugins/RDAP/*  @richbenwell
+plugins/RSS/*  @clarkd
+plugins/Rootly/*  @noorulkhan-n
+plugins/Spotify/*  @jame2O
+plugins/Steam/*  @kmichalski0
+plugins/SumoLogic/*  @richpeters
+plugins/TransportForLondon/*  @clarkd
+
+
+# Fallback – if a plugin has no specified author
+plugins/* @squaredup

.github/copilot-instructions.md

@@ -7,53 +7,72 @@ Any diff that touches files inside a plugin directory must include a correspondi
 - Check for hardcoded secrets, API keys, or credentials
 
 ## Code formatting
-* Follow existing formatting in the repo
-* Use consistent naming
-* Do not introduce formatting tools or config files unless explicitly requested.
+- Follow existing formatting in the repo
+- Use consistent naming
+- Do not introduce formatting tools or config files unless explicitly requested.
 
 ## Suggesting changes
 
 When suggesting changes:
 
-* Assume they will be reviewed by humans
-* Optimise for reviewability
-* Keep diffs focused and minimal
-* If a change is non-obvious, add a short comment explaining intent.
-* Comments should explain **why**, not restate **what** the code does
-* Use a neutral, professional tone
-* Avoid humour, sarcasm, or emojis in code comments
+- Assume they will be reviewed by humans
+- Optimise for reviewability
+- Keep diffs focused and minimal
+- If a change is non-obvious, add a short comment explaining intent.
+- Comments should explain **why**, not restate **what*- the code does
+- Use a neutral, professional tone
+- Avoid humour, sarcasm, or emojis in code comments
+- Include all review comments in the first review, do not add additional review comments to code that hasn't changed since the previous commit.
 
 ## File-specific guidelines
 
 ### icon.png/svg
-* SVG is preferred
-* Should be a square icon
-* Less than 100KB in size
+- SVG is preferred
+- Should be a square icon
+- Less than 100KB in size
 
 ### Metadata (metadata.json)
-* displayName - Use the correctly styled/cased official product name for display names, e.g. SharePoint NOT sharepoint
-* description - One short sentence describing what users can build or monitor. Avoid API or implementation language like Access HaloPSA APIs and query ticket data. Should always be appropriately punctuated, e.g. ending with a full stop.
-* version - The version number MUST be increased for any change to the plugin. It can never decrease. If a breaking change is made, the major version number of the plugin should be increased - for example, when deleting a data stream or significantly modifying the UI parameters.
-* author.type - Should always be set to `community`
-* author.name - Should typically be a GitHub username, prefixed with @. For example @username1
-* links - Should typically contain two links, one link with `category: source` linking to the GitHub repository, and another link with `category: documentation` linking to the markdown documentation in the repository. The links can be in any order, and there may be other links. 
+- name - Should generally be the lowercase kebab style version of the displayName, e.g. phare or google-sheets
+- displayName - Use the correctly styled/cased official product name for display names, e.g. SharePoint NOT sharepoint
+- description - One short sentence describing what users can build or monitor. Avoid API or implementation language like Access HaloPSA APIs and query ticket data. Should always be appropriately punctuated, e.g. ending with a full stop.
+- schemaVersion - Should be 2.0 or higher.
+- version - The version number MUST be increased for any change to the plugin. It can never decrease. If a breaking change is made, the major version number of the plugin should be increased - for example, when deleting a data stream or significantly modifying the UI parameters.
+- author.type - Should always be set to `community`
+- author.name - Should typically be a GitHub username, prefixed with @ OR an organisation name. For example `@username1` or `Contoso Inc.`
+- category - Mandatory. Reuse an existing category from other plugins where possible.
+- importNotSupported - Should be true unless a importDefinition/default.json is included.
+- links - Should typically contain two links, one link with `category: source` linking to the GitHub repository, and another link with `category: documentation` linking to the markdown documentation in the repository. The links can be in any order, and there may be other links. 
 
 ### UI Configuration (ui.json)
 - Generally prefer API tokens or OAuth where possible, flag usage of username/password unless the API offers no alternative.
-- Check that only stricly required fields are marked as `required`. Advanced options should never block first-time success.
-- Tooltips - Do not use tooltips unless they add specific value. Never state the obvious (e.g. “Enter the API key here”).
-- Placeholder text - Mandatory for text fields. Use example placeholders (especially for URLs) or “Enter the [data source] [info needed in lowercase]”. Use default values instead of hint text where a value is commonly the same across environments (e.g. default ports).
-- Do not use “you” “Your” in field names or labels. Keep text neutral, concise, and descriptive.
-* Should not specify the `title` attribute on any fields.
-
-### Out-of-the-box dashboards (*.dash.json)
-* Dashboard names - Use title case
-* Tile names - Use title case
-
-### Data streams - dataStreams/*.json
-* Display name - Use noun-based names describing the returned data, e.g. Tickets. Avoid verbs such as Get, Fetch, Run, Execute.
-* Description - Typically one sentence only. No full stop at the end. Add relevant clarifications in brackets. Never use two sentences.
-* Category - Mandatory. Reuse an existing category from other plugins where possible (e.g. Query).
-* ui
-  * Field names - First word uppercase, then lowercase (e.g. “Table name”). Single value: singular. Multiple values: “(s)” (e.g. Tables name(s)
-  * Tooltips - Use extremely sparingly. Never state the obvious. Only use when something important must be understood. Start with a verb where possible (e.g. “Supports the ServiceNow filtering definition format”).
+- Check that only strictly required fields are marked as `required: true`. Advanced options should never block first-time success.
+- For each field in the array:
+  - displayName - First word uppercase, then lowercase (e.g. “Table name", or "API key"). Single value: singular. Multiple values: “(s)" (e.g. Tables name(s))
+  - name - Should typically be the camel-cased version of the displayName.
+  - help - Do not use tooltips unless they add specific value. Never state the obvious (e.g. “Enter the API key here"). Start with a verb where possible (e.g. “Supports the ServiceNow filtering definition format"). Encourage include a reference link if relevant `Create an API key in the [Phare portal](https://docs.phare.io/api-reference/introduction)`
+  - placeholder - Mandatory for text fields. Use example placeholders (especially for URLs or values that follow a fixed pattern, e.g. rootly_xxxxxxxxx or https://organisation.atlassian.net) or “Enter the [data source] [info needed in lowercase]". Use default values instead of hint text where a value is commonly the same across environments (e.g. default ports).
+  - displayName - Do not use “you" “Your" in display names. Keep text neutral, concise, and descriptive.
+  - title - Should not specify the `title` attribute on any fields.
+
+### Out-of-the-box dashboards (defaultContent/**/*.dash.json)
+- Dashboard names - Use title case
+- Tile names - Use title case
+
+### Out-of-the-box dashboard manifest (defaultContent/**/manifest.json)
+- If out of the box dashboards are specified, ensure they are included in the manifest.json for the relevant folder.
+
+### Data streams - (dataStreams/*.json)
+- displayName - Use noun-based names describing the returned data, e.g. Tickets. Avoid verbs such as Get, Fetch, Run, Execute.
+- description - Typically one sentence only. No full stop at the end. Add relevant clarifications in brackets. Never use two sentences.
+- tags - Mandatory. Reuse an existing category from other plugins where possible.
+- ui
+  - displayName- First word uppercase, then lowercase (e.g. “Table name"). Single value: singular. Multiple values: “(s)" (e.g. Tables name(s). Do not use "you" "Your" in display names.
+  - help - Use extremely sparingly. Never state the obvious. Only use when something important must be understood. Start with a verb where possible (e.g. “Supports the ServiceNow filtering definition format").
+
+### Documentation - (docs/README.md)
+- Should typically start headings from level 1. When embedded in SquaredUp, the headings will be sized appropriately.
+- When the docs are embedded in SquaredUp, they are shown under a heading labelled "Need help?". As such, discourage documentation that starts with similar headings, or headings that don't make sense. Avoid headings that repeat the plugin name or use "Overview". A good heading might be something like `# Before you start` or `# Pre-requisites`.
+- Encourage the author to include documentation for all UI fields from metadata.json unless otherwise covered by a tooltip or help text.
+- Encourage the author to include links to the third-party tool or their documentation when appropriate, e.g. `Browse to [unifi.ui.com](https://unifi.ui.com) > Settings -> API Keys > Create New API Key`
+- The language should be neutral and clear, providing guidance on how to setup and use the plugin.  
+- Note that only the README.md is shown within SquaredUp, so do not apply these rules to other markdown files.