Add wiki documentation sync and Copilot skills infrastructure (#823)

Author: haavamoa

.github/copilot-instructions.md

@@ -248,4 +248,12 @@ Format: `[Component/Feature] Description` (see existing entries for style)
 All code uses `DIPS.Mobile.UI.*` namespace. Platform folders (iOS/Android/dotnet) use same namespace as parent - no `.iOS` suffix.
 
 ## Wiki
-The codebase is documented in https://github.com/DIPSAS/DIPS.Mobile.UI/wiki
+The codebase is documented in https://github.com/DIPSAS/DIPS.Mobile.UI/wiki
+
+Documentation source lives in the `wiki/` folder in the main repository and is auto-synced to the GitHub wiki via a GitHub Action on pushes to `main`. The `_Sidebar.md` is auto-generated alphabetically from all wiki pages — no manual sidebar edits needed.
+
+**Documentation rules (enforced during PR creation and review):**
+1. **New features MUST have documentation** — add a `wiki/<FeatureName>.md` page in the PR
+2. **Changed behavior/API MUST update docs** — if code changes contradict existing wiki pages, update them
+3. **Breaking changes MUST update docs** — wiki must reflect the new API/behavior
+4. Always cross-reference changed code against existing `wiki/` pages to catch stale documentation

.github/skills/doc-write-component/SKILL.md

@@ -0,0 +1,113 @@
+---
+name: Write Component Documentation
+description: Generates wiki documentation for new DIPS.Mobile.UI components following established patterns and conventions.
+---
+
+# Write Component Documentation
+
+When asked to write documentation for a new component, generate a `wiki/<ComponentName>.md` page following the template and rules below.
+
+## Trigger Phrases
+
+- "Document this component"
+- "Write wiki page"
+- "Add documentation"
+- "Create wiki doc"
+
+## Before Writing
+
+1. **Read the component source code** — understand all public properties, bindable properties, events, commands, and options classes
+2. **Check for sub-components or variants** — e.g., `NavigationListItem` alongside `ListItem`, `FilledCheckBox` alongside `CheckBox`
+3. **Check for platform differences** — look at iOS/Android partial classes for behavioral differences
+4. **Check accessibility support** — does the component set semantic properties, use `TouchPlatformEffect`, or have accessibility-specific features?
+5. **Look at the sample app** — check `ComponentsSamples/` or `AccessibilitySamples/` for usage examples
+
+## Template
+
+Use the following structure. Sections marked **(if applicable)** should only be included when relevant.
+
+```markdown
+<Short description of what the component is — 1-2 sentences. Written before any heading. Explain the purpose and when to use it.>
+
+# Inspiration **(if applicable)**
+
+<Links to design guidelines that inspired the component, e.g., Material Design, Apple Human Interface Guidelines.>
+
+# Usage
+
+<XAML example showing the most common/basic usage of the component.>
+
+> <Any important notes about defaults, required properties, or common gotchas.>
+
+# Styles **(if applicable)**
+
+<List available styles/variants with a brief description of each.>
+
+# Tips and tricks **(if applicable)**
+
+<Practical guidance: recommended patterns, common combinations with other components, or things to watch out for.>
+
+# Accessibility **(if applicable)**
+
+<How the component behaves with VoiceOver/TalkBack. Any required semantic properties. Special accessibility features.>
+
+# Properties
+
+Inspect the [components properties class](<GitHub URL to .Properties.cs file>) to further customise and use it.
+```
+
+### Sub-Component Pattern
+
+When the component has variants or related sub-components, add them as `##` sections after the main component, each with their own `### Usage` and `### Properties`:
+
+```markdown
+## SubComponentName
+
+<Brief description of the sub-component.>
+
+### Usage
+
+<XAML example>
+
+### Properties
+
+Inspect the [components properties class](<GitHub URL>) to further customise and use it.
+```
+
+## Writing Rules
+
+### Intro
+- Start with a plain-text paragraph **before any heading** — describe what the component is and when people would use it
+- Keep it to 1-2 sentences
+
+### Usage Sections
+- Always include at least one XAML code block with `xml` as the language tag
+- Use the `dui:` XML namespace prefix — do not show `xmlns` declarations (readers already know this)
+- Show the simplest working example first, then more advanced configurations
+- If C# code-behind is needed (e.g., ViewModel bindings, event handlers), include it after the XAML block using `csharp` as the language tag
+
+### Properties
+- Always link to the `.Properties.cs` file on GitHub: `https://github.com/DIPSAS/DIPS.Mobile.UI/blob/main/src/library/DIPS.Mobile.UI/<path>/<Component>.Properties.cs`
+- Use the standard phrasing: *"Inspect the [components properties class](URL) to further customise and use it."*
+- This should be the **last section** (or last sub-section per component)
+
+### Callouts
+- Use blockquotes (`>`) for notes, warnings, and platform-specific differences
+- Bold the callout type: `> **NB!**`, `> **NOTE:**`, `> **Important:**`
+- Use callouts for: default values, platform differences (iOS vs Android), UX warnings, required configurations
+
+### Style
+- Use `#` (h1) for major sections
+- Use `##` (h2) for sub-components
+- Use `###` (h3) for sections within a sub-component
+- Be concise — developers scan documentation, not read it cover-to-cover
+- Write in present tense: *"The component displays..."* not *"The component will display..."*
+- Address the reader as *"you"*: *"Use this when you need..."*
+- Refer to end-users as *"people"*: *"People can tap to..."*
+
+### What NOT to Include
+- No namespace/xmlns declarations (unless the component requires a non-standard namespace)
+- No installation or NuGet instructions
+- No `_Sidebar.md` references — it is auto-generated
+- No Figma links (designers maintain those separately)
+- Do not document internal/private APIs — only public-facing properties and usage

…b/instructions/create_pr.instructions.md .github/skills/pr-create/SKILL.md.github/instructions/create_pr.instructions.md renamed to .github/skills/pr-create/SKILL.md .github/instructions/create_pr.instructions.md renamed to .github/skills/pr-create/SKILL.md

@@ -1,12 +1,14 @@
 ---
-applyTo: '**'
+name: Create PR
+description: Creates a pull request with proper title, description, changelog updates, and wiki documentation checks.
 ---
+
 # Pull Request Creation Instructions
 
 ## Trigger Phrases
 When I say **any** of these:
 - "Create PR"
-- "Make PR" 
+- "Make PR"
 - "PR"
 - "Create Pull Request"
 - "Make a PR"
@@ -15,12 +17,18 @@ When I say **any** of these:
 
 ## Action Steps
 1. **Check changes**: Get the diff between main branch and current branch
-2. **Update CHANGELOG.md**: Determine if Major/Minor/Patch bump is needed based on:
+2. **Update CHANGELOG.md** (only if `src/` has changes): Determine if Major/Minor/Patch bump is needed based on:
    - **Major**: Breaking changes (removed/changed public APIs)
    - **Minor**: New features (new components, properties, methods)
    - **Patch**: Bug fixes, internal improvements, accessibility fixes
    - Follow existing CHANGELOG.md format: `[Component/Feature] Description`
-3. **Generate PR**: Create pull request with title and body
+   - **Skip** if the PR has no changes under `src/` — documentation-only, build scripts, CI/CD, and config changes do not require a changelog entry
+3. **Wiki documentation**: Check if documentation in `wiki/` needs to be added or updated:
+   - **New feature?** → **MUST** add a new `wiki/<FeatureName>.md` page
+   - **Changed behavior/API?** → **MUST** update the relevant existing wiki page
+   - **Breaking change?** → **MUST** update wiki to reflect the new behavior
+   - The sidebar is auto-generated — just add the `.md` file to `wiki/`
+4. **Generate PR**: Create pull request with title and body
 
 ## PR Format Requirements
 
@@ -49,12 +57,16 @@ When I say **any** of these:
 
 ### Files Changed
 - Brief overview of major file changes
+```
 
 ## Additional Considerations
 
 ### Wiki Documentation
-If the change introduces new patterns or significant features, mention in the PR:
-> "This should be documented in the [wiki](https://github.com/DIPSAS/DIPS.Mobile.UI/wiki). Consider adding a page about [topic]."
+Documentation lives in the `wiki/` folder and is auto-synced to the GitHub wiki on merge to main.
+- **New features**: A wiki page in `wiki/` is **required** — not optional. Add it in the PR.
+- **Changed behavior**: Update the relevant `wiki/*.md` page in the same PR.
+- **Breaking changes**: Wiki must reflect the new API/behavior.
+- The `_Sidebar.md` is auto-generated from filenames — no manual sidebar edits needed.
 
 ### Tone and Style
 - **Clear**: Easy to understand what changed

…thub/instructions/review.instructions.md .github/skills/pr-review/SKILL.md.github/instructions/review.instructions.md renamed to .github/skills/pr-review/SKILL.md .github/instructions/review.instructions.md renamed to .github/skills/pr-review/SKILL.md

@@ -1,8 +1,23 @@
 ---
-applyTo: '**'
+name: Review PR
+description: Workflow and rules for AI-assisted pull request reviews.
 ---
+
 # Code Review Instructions
 
+## CRITICAL RULES
+
+### NEVER Approve or Request Changes
+
+**AI agents must NEVER use `--approve` or `--request-changes` flags.**
+
+| Action | Allowed? | Why |
+|--------|----------|-----|
+| `gh pr review --approve` | **NEVER** | Approval is a human decision |
+| `gh pr review --request-changes` | **NEVER** | Blocking PRs is a human decision |
+
+---
+
 ## When I say "Review" or "Review my changes"
 Perform a comprehensive code review of the current changes following these rules:
 
@@ -11,6 +26,34 @@ Perform a comprehensive code review of the current changes following these rules
 2. Analyze all modified files for adherence to project patterns
 3. Provide structured feedback with specific examples
 
+### Post PR Overview Comment
+
+When reviewing a PR, add a comment that gives the reviewer a clear understanding of the PR:
+
+1. **Pull request overview** — A short summary based on the title, description, and changed files. Explain *what* the PR does and *why*.
+
+2. **File summary** — A collapsible table listing each changed file with a brief description of the change. Use a `<details>` block so it can be minimized:
+
+   ```markdown
+   ### Pull request overview
+
+   <one or two paragraphs summarizing the purpose and approach of the PR>
+
+   ### Changes
+
+   - <bullet per logical change group>
+
+   <details>
+   <summary>📁 File summary (<N> files changed)</summary>
+
+   | File | Description |
+   |------|-------------|
+   | `path/to/file.cs` | Brief description of what changed |
+   | `path/to/other.cs` | Brief description of what changed |
+
+   </details>
+   ```
+
 ### Review Criteria
 
 #### 1. Platform-Specific Implementation
@@ -53,32 +96,14 @@ Perform a comprehensive code review of the current changes following these rules
 - ❌ **Flag**: iOS-only or Android-only implementation without documented reason
 - ✅ **Check**: Visual consistency with design system
 
-### Review Output Format
+#### 8. Wiki Documentation (wiki/)
+- ❌ **Flag**: New feature (component, effect, handler, service) without a corresponding wiki page in `wiki/`
+- ❌ **Flag**: Code changes that break or contradict existing wiki documentation (renamed APIs, changed behavior, removed features)
+- ✅ **Check**: If existing documented behavior changed, the relevant `wiki/*.md` page is updated in the same PR
+- ✅ **Check**: New wiki pages follow naming convention: `PascalCase.md` or `Hyphenated-Words.md`
+- ✅ **Check**: New wiki pages will appear in the auto-generated sidebar (no manual `_Sidebar.md` edits needed)
+- **Guidance**: Review all modified/added files and cross-reference with pages in `wiki/` to determine if documentation is affected
 
-Provide feedback in this structure:
-
-```markdown
-## Code Review Summary
-
-### ✅ Strengths
-- [List positive aspects]
-
-### ⚠️ Issues Found
-**Priority: High/Medium/Low**
-1. [Issue description]
-   - **File**: `path/to/file.cs`
-   - **Line**: XX
-   - **Problem**: [What's wrong]
-   - **Fix**: [Suggested solution with code example]
-
-### 🔍 Questions/Clarifications
-- [Any unclear design decisions that need explanation]
-
-### ✅ Approval Status
-- [ ] Ready to merge
-- [ ] Requires changes
-- [ ] Needs discussion
-```
 
 ### Common Review Patterns
 
@@ -102,12 +127,10 @@ Provide feedback in this structure:
 - Require migration guide in PR description
 - Document deprecated APIs
 
-### Things to Praise
-- Proper use of partial classes
-- Comprehensive accessibility support
-- Clear separation of concerns
-- Good test coverage in samples app
-- Well-documented platform differences
-
+**For Documentation (wiki/):**
+- Check if any changed code contradicts existing wiki pages
+- Verify new features have a corresponding `wiki/<FeatureName>.md` page
+- If behavior or API changed, verify the relevant wiki page is updated
+- Praise when documentation is proactively added or updated
 
-But use your judgment to adapt the review based on the specific changes made. You are encouraged to provide constructive feedback that helps maintain code quality and consistency across the project. Be a pro reviewer!
+But use your judgment to adapt the review based on the specific changes made. You are encouraged to provide constructive feedback that helps maintain code quality and consistency across the project. Be a pro reviewer!

.github/workflows/wiki-sync.yml

@@ -0,0 +1,65 @@
+name: Sync Wiki
+
+on:
+  push:
+    branches:
+      - main
+    paths:
+      - 'wiki/**'
+
+permissions:
+  contents: write
+
+jobs:
+  sync-wiki:
+    runs-on: ubuntu-latest
+    steps:
+      - name: Checkout repository
+        uses: actions/checkout@v4
+
+      - name: Generate Sidebar
+        run: |
+          cd wiki
+          echo "<!-- This file is auto-generated. Do not edit manually. -->" > _Sidebar.md
+          echo "" >> _Sidebar.md
+          echo "**[Home](Home)**" >> _Sidebar.md
+          echo "" >> _Sidebar.md
+
+          # Collect all .md files except Home.md, _Sidebar.md, and _Footer.md
+          # Sort them alphabetically and generate sidebar links
+          for file in $(ls *.md | grep -v -E '^(Home|_Sidebar|_Footer)\.md$' | sort -f); do
+            # Get the page name (filename without .md extension)
+            page_name="${file%.md}"
+            # Convert hyphens to spaces for display name
+            display_name=$(echo "$page_name" | sed 's/-/ /g')
+            echo "- [$display_name]($page_name)" >> _Sidebar.md
+          done
+
+      - name: Sync to Wiki
+        env:
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+        run: |
+          # Configure git
+          git config --global user.name "github-actions[bot]"
+          git config --global user.email "github-actions[bot]@users.noreply.github.com"
+
+          # Clone the wiki repository
+          wiki_url="https://x-access-token:${GITHUB_TOKEN}@github.com/${{ github.repository }}.wiki.git"
+          git clone "$wiki_url" /tmp/wiki-repo
+
+          # Remove all existing wiki content (except .git)
+          find /tmp/wiki-repo -maxdepth 1 -not -name '.git' -not -name '.' -delete 2>/dev/null || true
+
+          # Copy all wiki content from the repo
+          cp wiki/* /tmp/wiki-repo/
+
+          # Push changes if there are any
+          cd /tmp/wiki-repo
+          git add -A
+          if git diff --cached --quiet; then
+            echo "No changes to sync."
+          else
+            git commit -m "Sync wiki from main repository ($(date -u '+%Y-%m-%d %H:%M:%S UTC'))"
+            git push
+            echo "Wiki synced successfully."
+          fi