Add agent skill instructions and repository guidance

.agents/skills/caveman/SKILL.md

@@ -0,0 +1,49 @@
+---
+name: caveman
+description: >
+  Ultra-compressed communication mode. Cuts token usage ~75% by dropping
+  filler, articles, and pleasantries while keeping full technical accuracy.
+  Use when user says "caveman mode", "talk like caveman", "use caveman",
+  "less tokens", "be brief", or invokes /caveman.
+---
+
+Respond terse like smart caveman. All technical substance stay. Only fluff die.
+
+## Persistence
+
+ACTIVE EVERY RESPONSE once triggered. No revert after many turns. No filler drift. Still active if unsure. Off only when user says "stop caveman" or "normal mode".
+
+## Rules
+
+Drop: articles (a/an/the), filler (just/really/basically/actually/simply), pleasantries (sure/certainly/of course/happy to), hedging. Fragments OK. Short synonyms (big not extensive, fix not "implement a solution for"). Abbreviate common terms (DB/auth/config/req/res/fn/impl). Strip conjunctions. Use arrows for causality (X -> Y). One word when one word enough.
+
+Technical terms stay exact. Code blocks unchanged. Errors quoted exact.
+
+Pattern: `[thing] [action] [reason]. [next step].`
+
+Not: "Sure! I'd be happy to help you with that. The issue you're experiencing is likely caused by..."
+Yes: "Bug in auth middleware. Token expiry check use `<` not `<=`. Fix:"
+
+### Examples
+
+**"Why React component re-render?"**
+
+> Inline obj prop -> new ref -> re-render. `useMemo`.
+
+**"Explain database connection pooling."**
+
+> Pool = reuse DB conn. Skip handshake -> fast under load.
+
+## Auto-Clarity Exception
+
+Drop caveman temporarily for: security warnings, irreversible action confirmations, multi-step sequences where fragment order risks misread, user asks to clarify or repeats question. Resume caveman after clear part done.
+
+Example -- destructive op:
+
+> **Warning:** This will permanently delete all rows in the `users` table and cannot be undone.
+>
+> ```sql
+> DROP TABLE users;
+> ```
+>
+> Caveman resume. Verify backup exist first.

.agents/skills/code-review/SKILL.md

@@ -0,0 +1,129 @@
+---
+name: code-review
+description: Conducts professional and thorough code reviews for local changes or remote PRs. Checks correctness, project-specific conventions (repository/caching pattern, service contracts, MassTransit messaging, WPF patterns, NUnit tests), security, tests, and code quality. Use when asked to review code, review a PR, or check implementation against project standards.
+argument-hint: [pr-number or URL]
+allowed-tools: Read, Grep, Glob, Bash(git *), Bash(gh *), Bash(msbuild *), Bash(nuget *), Bash(vstest.console*)
+---
+
+# Code Review
+
+This skill guides a professional and thorough code review for both local development and remote Pull Requests.
+
+## Workflow
+
+### 1. Determine Review Target
+
+- **Remote PR**: User provides a PR number or URL (e.g., "Review PR #123") → target that remote PR.
+- **Local changes**: No PR specified, or user says "review my changes" → target current local file system state (staged and unstaged).
+
+### 2. Preparation
+
+**For Remote PRs:**
+1. Checkout the PR: `gh pr checkout <PR_NUMBER>`
+2. Read the PR description and existing comments to understand goal and history: `gh pr view <PR_NUMBER>`
+3. Preflight — run the standard verification suite to catch automated failures early:
+   ```bash
+   nuget restore JJRichards.Commercial.sln
+   msbuild JJRichards.Commercial.sln /t:Rebuild /p:Configuration=Release /p:vsVersion=17.0
+   vstest.console.exe "**\bin\Release\*.Tests.dll"
+   ```
+
+**For Local Changes:**
+1. Check status: `git status`
+2. Read diffs: `git diff` (working tree) and/or `git diff --staged` (staged)
+3. Preflight (optional): If changes are substantial, ask the user whether to run the build and tests before reviewing.
+
+### 3. In-Depth Analysis
+
+Analyze the code changes across two categories: **universal pillars** and **project-specific rules**.
+
+#### Universal Pillars
+
+- **Correctness** — Does the code achieve its stated purpose without bugs or logical errors?
+- **Maintainability** — Is the code clean, well-structured, and easy to modify? Does it follow established design patterns?
+- **Readability** — Is formatting consistent? Are comments present only where logic isn't self-evident?
+- **Efficiency** — Are there obvious performance bottlenecks or resource inefficiencies?
+- **Security** — Any potential vulnerabilities? (injection, XSS, insecure deserialization, exposed secrets, OWASP Top 10)
+- **Edge Cases & Error Handling** — Does the code handle edge cases and errors appropriately?
+- **Testability** — Is new/modified code adequately covered by tests?
+
+#### Project-Specific Rules
+
+**Architecture & Patterns**
+- Solution has 62 projects across Backend, UI, Tests, Devices, and Deployment — changes should respect the existing project boundaries
+- Repository pattern with caching: `IRepository` / `CachingRepository` implementations for data access
+- Service layer: `IService` / `Service` implementations for business logic
+- Service contracts in `JJRichards.ServiceContracts` — shared interface definitions between components
+- No business logic in UI code-behind; no data-access logic in services
+- DI through constructor injection — services and repositories not instantiated directly
+
+**WPF / UI Conventions**
+- MVVM pattern: views in XAML, logic in code-behind or view models
+- Shared UI controls live in `JJRichards.JTrack.UI.Shared`
+- Custom controls and UserControls follow existing naming and structure
+- XAML resources and styles should be consistent with existing themes
+
+**Service Bus & Messaging (MassTransit / RabbitMQ)**
+- Message contracts defined in `JJRichards.ServiceBus.MessageContracts`
+- Service contracts in `JJRichards.ServiceContracts` and `JJRichards.ServiceContracts.Common`
+- Consumer-based endpoints follow MassTransit patterns
+- New consumers/messages must be registered in DI/bus configuration
+
+**Device Integration**
+- Device drivers live under `Devices/` with a common framework in `JTrack.Devices`
+- Each device type has its own project (CR203X, RUTX, RuggON, BlackMoth, Comet, etc.)
+- RFID integration in `JJRichards.JTrack.InTruck.RFID`
+
+**DateTime — Always UTC**
+- `DateTime.UtcNow` only — never `DateTime.Now`
+- `new DateTime(...)` must pass `DateTimeKind.Utc`
+
+**Code Conventions (.editorconfig)**
+- Braces always required (`csharp_prefer_braces = true:error`)
+- `var` preferred for all variable declarations
+- Interfaces prefixed with `I`
+- Private fields: `_camelCase`
+- Public members & constants: PascalCase
+- Line endings: CRLF, UTF-8
+- Max line length: 200 characters
+- Indentation: 4 spaces
+
+**Compiler Hygiene**
+- Zero warnings — flag any new warnings introduced
+- No unused variables, unreachable code, or suppressed analyzer warnings without justification
+
+**Tests**
+- NUnit 3.x test framework
+- Test projects: `*.Tests` naming convention (8 test projects in solution)
+- New logic should have corresponding unit tests
+- Tests run via: `vstest.console.exe "**\bin\Release\*.Tests.dll"`
+- Suggest specific additional test cases that would improve coverage or robustness
+
+**Configuration & Feature Flags**
+- Feature flags in `JJRichards.Shared/FeatureFlags/`
+- App.config for application configuration
+- Connection strings reference SQL Server environments (dev, test, prod)
+- Never hardcode connection strings or secrets
+
+### 4. Provide Feedback
+
+**Structure:**
+
+- **Summary** — High-level overview of the changes and overall impression
+- **Findings** (grouped by severity):
+  - **Critical** — Bugs, security issues, breaking changes, or violations of project-critical rules (UTC datetimes, repository pattern, service bus contracts)
+  - **Improvements** — Better code quality, missing patterns, performance, or test coverage
+  - **Nitpicks** — Formatting, minor naming inconsistencies, optional style issues
+- **Conclusion** — Clear recommendation: **Approved** or **Request Changes**
+
+**Tone:**
+- Constructive, professional, and specific
+- Always explain *why* a change is requested, not just *what* to change
+- For approvals, acknowledge the specific value of the contribution
+
+### 5. Cleanup (Remote PRs Only)
+
+After completing the review, ask the user if they want to switch back to the main branch:
+```bash
+git checkout master
+```

.agents/skills/commit-changes/SKILL.md

@@ -0,0 +1,210 @@
+---
+name: commit-changes
+description: Composes a well-structured commit message following the project's hybrid Conventional Commits format ([Scope] type: description). Inspects staged changes, infers the appropriate scope and type, and presents a draft for review. Use when asked to write a commit message, stage a commit, or check if a commit message follows project conventions.
+argument-hint: [optional context or description of the change]
+allowed-tools: Bash(git status), Bash(git diff*), Bash(git log*)
+---
+
+# Commit Message
+
+This skill composes commit messages that follow the project's hybrid **Conventional Commits** format.
+
+## Format
+
+```
+[Scope] type: short imperative description
+
+Optional body — explain *why*, not *what*. Wrap at 72 characters.
+Use multiple paragraphs if needed.
+
+#12345
+BREAKING CHANGE: description of what broke and how to migrate
+```
+
+### Rules
+
+- **Subject line** (first line): `[Scope] type: description`
+  - Max 72 characters total
+  - Imperative mood — "add", "fix", "remove", not "added", "fixes"
+  - No period at the end
+  - Lowercase type and description; capitalised `[Scope]`
+- **Blank line** between subject and body (if body is present)
+- **Body**: explain the *why* behind the change, not what the diff already shows
+- **`#<id>` footer is required** — links the commit to the Azure DevOps work item. Extract the number from the branch name (see Workflow step 1). If no number is found, ask the user before proceeding.
+- **Footers**: each on its own line after a blank line; use `BREAKING CHANGE:` for breaking changes
+
+---
+
+## Scopes
+
+Use the component(s) directly affected. If a commit touches multiple components, list the primary one or use `Multi`.
+
+| Scope | When to use |
+|---|---|
+| `[InTruck]` | JJRichards.JTrack.InTruck.Commercial — WPF driver application |
+| `[Console]` | JJRichards.JTrack.Console.Commercial — WPF operations console |
+| `[ServiceBus]` | JJRichards.ServiceBus — MassTransit/RabbitMQ service bus |
+| `[Contracts]` | JJRichards.ServiceContracts — service contract interfaces and message types |
+| `[Shared]` | JJRichards.Shared — common utilities, configuration, feature flags |
+| `[Devices]` | Device framework and drivers (CR203X, RUTX, RuggON, BlackMoth, Comet) |
+| `[RFID]` | JJRichards.JTrack.InTruck.RFID — RFID reader integration |
+| `[Camera]` | Camera/video system (CameraDaemon, CameraProvider, VideoRecorder) |
+| `[UI.Shared]` | JJRichards.JTrack.UI.Shared — shared WPF controls and resources |
+| `[Integration]` | JJRichards.JTrack.GCCCIntegrationService |
+| `[PhoneIn]` | JJRichards.PhoneIn.Service |
+| `[Upload]` | JJRichards.JTrack.UploadFiles.Commercial |
+| `[Map]` | JJRichards.JTrack.MapControl, JTrackMapZipper |
+| `[Tests]` | Test projects |
+| `[CI]` | CI/CD pipelines, azure-pipelines-ci.yml |
+| `[Docs]` | Documentation, AGENTS.md, README, Docs/ |
+| `[Multi]` | Commit spans more than two unrelated scopes |
+
+---
+
+## Types
+
+| Type | Maps to | When to use |
+|---|---|---|
+| `feat` | MINOR | New feature or capability visible to users |
+| `fix` | PATCH | Bug fix |
+| `refactor` | — | Code restructure with no behaviour change |
+| `perf` | PATCH | Performance improvement |
+| `test` | — | Adding or updating tests only |
+| `docs` | — | Documentation only |
+| `chore` | — | Tooling, config, dependencies, migrations with no logic change |
+| `style` | — | Formatting, whitespace — no logic change |
+| `ci` | — | CI/CD pipeline changes |
+| `build` | — | Build system or NuGet/package changes |
+
+**Breaking changes** — append `!` to the type and add a `BREAKING CHANGE:` footer:
+```
+[Contracts] feat!: rename TruckEvents to VehicleEvents
+
+BREAKING CHANGE: TruckEvents contract removed. Use VehicleEvents.
+Existing consumers must update their subscriptions.
+```
+
+---
+
+## Workflow
+
+### 1. Inspect staged changes and extract work item number
+
+```bash
+git branch --show-current
+git status
+git diff --staged
+```
+
+**Extract the work item number** from the branch name by finding the first run of digits (4+ digits). Common branch patterns:
+
+| Branch | Work item |
+|---|---|
+| `feature/12345-add-foo` | `12345` |
+| `feedback/58340/from-luke` | `58340` |
+| `JTC-56566-missing-screen` | `56566` |
+| `docs/59478` | `59478` |
+| `bugfix/99-fix-bar` | `99` |
+
+If no number is found in the branch name, ask the user to provide the Azure DevOps work item ID before continuing — it is required.
+
+If nothing is staged, check unstaged changes with `git diff` and ask the user whether they want to stage everything or specific files before continuing.
+
+### 2. Infer scope and type
+
+- Match changed file paths to the scope table above
+- Determine the type from the nature of the changes (new screen = `feat`, bug correction = `fix`, config change = `chore`, etc.)
+- If the change is breaking (renamed/removed contract, service endpoint changed), note `!` and prepare a `BREAKING CHANGE:` footer
+
+### 3. Draft the message
+
+Produce a candidate commit message in the correct format. Then:
+
+- Check the subject line is ≤ 72 characters
+- Check imperative mood
+- Add a body if the *why* is non-obvious from the diff
+- **Always include `#<id>` as the first footer line** — use the number extracted in step 1
+- Add `BREAKING CHANGE:` footer if applicable
+
+### 4. Present for review
+
+Show the proposed message clearly (in a code block) and briefly explain the scope/type choice. Ask the user to confirm or request changes before committing.
+
+### 5. Commit (only on confirmation)
+
+Once confirmed:
+```bash
+git commit -m "$(cat <<'EOF'
+[Scope] type: short description
+
+Optional body here.
+
+Optional footers.
+EOF
+)"
+```
+
+Never commit without explicit user approval.
+
+---
+
+## Examples
+
+```
+[Console] feat: add trailer management screen
+
+Implements basic trailer entry and listing for ops console
+with run selection integration.
+
+#55448
+```
+
+```
+[InTruck] fix: correct event handler detachment in else block
+
+OnAccessCompleted was using += instead of -= in the else
+branch, causing duplicate event handling and memory leaks.
+
+#57122
+```
+
+```
+[ServiceBus] feat: send GPS updates to RabbitMQ
+
+#56257
+```
+
+```
+[RFID] feat: implement TID-based tag identification
+
+Adds TID reading support with feature flag for gradual rollout.
+Only reads TID identifier, ignoring other tag memory banks.
+
+#56257
+```
+
+```
+[Shared] fix: UTC-normalize all datetime conversions
+
+DateTime.Now calls replaced with DateTime.UtcNow across
+shared utility methods to prevent timezone-related bugs.
+
+#12345
+```
+
+```
+[Contracts] feat!: rename TruckEvents to VehicleEvents
+
+TruckEvents contract and all related types renamed to
+VehicleEvents to align with updated domain terminology.
+
+#9900
+BREAKING CHANGE: TruckEvents removed. Use VehicleEvents.
+All consumers must update their subscriptions.
+```
+
+```
+[Multi] chore: update NuGet packages to latest patch versions
+
+#12345
+```