hatch3r 1.0.0 → 1.2.0

package/rules/hatch3r-tooling-hierarchy.md

@@ -3,29 +3,49 @@ id: hatch3r-tooling-hierarchy
 type: rule
 description: Priority order for tools and knowledge sources
 scope: always
+tags: [core]
 ---
 # Tooling Hierarchy
 
-## A. GitHub CLI-First
+## A. Platform MCP-First (when available)
 
-**Prefer `gh` CLI over GitHub MCP tools** for GitHub operations. CLI tools are optimized for agent use — lower token cost, faster execution, and deterministic output parsing.
+**Prefer platform MCP tools over the platform CLI** when the MCP server provides typed tools with structured input/output. Use them as the primary interface for issue tracker and repository operations.
 
-**Prerequisites:** `gh auth login` must be completed, or `GITHUB_TOKEN` environment variable set. For Projects v2: `gh auth refresh -s project`.
+Read `platform` from `.agents/hatch.json` to determine which platform tools to use.
 
-**Primary tool for:**
-- Issue CRUD: `gh issue create`, `gh issue edit`, `gh issue view`, `gh issue list`
-- PR CRUD: `gh pr create`, `gh pr view`, `gh pr list`, `gh pr merge`
-- Search: `gh search issues`, `gh search prs`, `gh search code`
-- Labels: `gh label create`, `gh label list`
-- Releases: `gh release create`
-- CI/Actions: `gh run list`, `gh run view`, `gh run watch`
-- Projects v2: `gh project item-add`, `gh project item-edit`, `gh project item-list`, `gh project field-list`, `gh project view`
+### Prerequisites
 
-**Fallback to GitHub MCP only when:**
-- The `gh` CLI lacks the specific capability (e.g., sub-issue management via `sub_issue_write`).
-- GraphQL queries are needed that `gh api graphql` cannot express concisely.
+| Platform | Auth Setup |
+|----------|-----------|
+| **GitHub** | `gh auth login` or `GITHUB_TOKEN` env var. For Projects v2: `gh auth refresh -s project` |
+| **Azure DevOps** | `az login` and `az devops configure --defaults organization=ORG project=PROJECT` |
+| **GitLab** | `glab auth login` or `GITLAB_TOKEN` env var |
 
-**Never** use GitHub MCP for operations that `gh` CLI handles well (issue CRUD, PR CRUD, search, labels, releases).
+### Platform CLI Fallback Reference
+
+**Fallback to the platform CLI only when:**
+- The MCP tool catalog lacks the specific capability.
+- An MCP call fails repeatedly and the CLI provides a viable alternative.
+
+**Never** use the platform CLI for operations that have a direct MCP equivalent (issue CRUD, PR/MR CRUD, search, labels).
+
+| Action | GitHub | Azure DevOps | GitLab |
+|--------|--------|--------------|--------|
+| Create issue | `gh issue create` | `az boards work-item create` | `glab issue create` |
+| Edit issue | `gh issue edit` | `az boards work-item update` | `glab issue update` |
+| View issue | `gh issue view` | `az boards work-item show --id N` | `glab issue view` |
+| List issues | `gh issue list` | `az boards work-item list` | `glab issue list` |
+| Create PR/MR | `gh pr create` | `az repos pr create` | `glab mr create` |
+| View PR/MR | `gh pr view` | `az repos pr show` | `glab mr view` |
+| List PRs/MRs | `gh pr list` | `az repos pr list` | `glab mr list` |
+| Merge PR/MR | `gh pr merge` | `az repos pr complete` | `glab mr merge` |
+| Search issues | `gh search issues` | `az boards query` | `glab issue list --search` |
+| Search PRs | `gh search prs` | `az repos pr list --status all` | `glab mr list --search` |
+| Search code | `gh search code` | `az repos show` | `glab search` |
+| Labels | `gh label create/list` | `az boards work-item update --fields` | `glab label create/list` |
+| Releases | `gh release create` | `az repos release` | `glab release create` |
+| CI runs | `gh run list/view/watch` | `az pipelines run list/show` | `glab ci list/view` |
+| Projects | `gh project item-add/edit/list` | `az boards iteration/area` | GitLab Boards API |
 
 ## B. Documentation MCP for Library Documentation
 
@@ -59,6 +79,13 @@ Use web search to retrieve current, real-world information not available in proj
 - Standard library API questions (use documentation MCP instead).
 - Internal project decisions (use project ADRs).
 
+**Fallback when web search is unavailable:**
+If no web search MCP server is configured (e.g., `brave-search` is not in `mcp.servers` in `.agents/hatch.json`), web research cannot be performed. In this case:
+- Note in your output when web research would have been valuable (e.g., "Web research recommended for CVE verification but not available").
+- Rely more heavily on Context7 documentation MCP and codebase exploration.
+- Flag security-sensitive decisions that would benefit from current advisory data.
+- Do NOT silently skip web research — surface the limitation so the user can decide whether to enable it.
+
 ## D. Browser Verification for UI Changes
 
 Use browser automation MCP tools to visually verify UI changes after automated tests pass.

package/rules/hatch3r-tooling-hierarchy.mdc

@@ -4,15 +4,31 @@ alwaysApply: true
 ---
 # Tooling Hierarchy
 
-## A. GitHub MCP-First (when available)
+## A. Platform MCP-First (when available)
 
-**Prefer GitHub MCP tools over `gh` CLI** when the MCP server provides typed tools with structured input/output. Use them as the primary interface for GitHub operations.
+**Prefer platform MCP tools over the platform CLI** when the MCP server provides typed tools with structured input/output. Use them as the primary interface for issue tracker and repository operations.
 
-**Fallback to `gh` CLI only when:**
+Read `platform` from `.agents/hatch.json` to determine which platform tools to use.
+
+**Fallback to the platform CLI only when:**
 - The MCP tool catalog lacks the specific capability.
 - An MCP call fails repeatedly and the CLI provides a viable alternative.
 
-**Never** use `gh` CLI for operations that have a direct MCP equivalent (issue CRUD, PR CRUD, search, labels).
+**Never** use the platform CLI for operations that have a direct MCP equivalent (issue CRUD, PR/MR CRUD, search, labels).
+
+### Platform CLI Fallback Reference
+
+| Action | GitHub | Azure DevOps | GitLab |
+|--------|--------|--------------|--------|
+| Create issue | `gh issue create` | `az boards work-item create` | `glab issue create` |
+| View issue | `gh issue view` | `az boards work-item show --id N` | `glab issue view` |
+| List issues | `gh issue list` | `az boards work-item list` | `glab issue list` |
+| Create PR/MR | `gh pr create` | `az repos pr create` | `glab mr create` |
+| View PR/MR | `gh pr view` | `az repos pr show` | `glab mr view` |
+| List PRs/MRs | `gh pr list` | `az repos pr list` | `glab mr list` |
+| Search code | `gh search code` | `az repos show` | `glab search` |
+| CI runs | `gh run list/view` | `az pipelines run list/show` | `glab ci list/view` |
+| Releases | `gh release create` | `az repos release` | `glab release create` |
 
 ## B. Documentation MCP for Library Documentation
 
@@ -46,6 +62,13 @@ Use web search to retrieve current, real-world information not available in proj
 - Standard library API questions (use documentation MCP instead).
 - Internal project decisions (use project ADRs).
 
+**Fallback when web search is unavailable:**
+If no web search MCP server is configured (e.g., `brave-search` is not in `mcp.servers` in `.agents/hatch.json`), web research cannot be performed. In this case:
+- Note in your output when web research would have been valuable (e.g., "Web research recommended for CVE verification but not available").
+- Rely more heavily on Context7 documentation MCP and codebase exploration.
+- Flag security-sensitive decisions that would benefit from current advisory data.
+- Do NOT silently skip web research — surface the limitation so the user can decide whether to enable it.
+
 ## D. Browser Verification for UI Changes
 
 Use browser automation MCP tools to visually verify UI changes after automated tests pass.

package/skills/hatch3r-a11y-audit/SKILL.md

@@ -1,6 +1,7 @@
 ---
 id: hatch3r-a11y-audit
 description: Comprehensive WCAG AA accessibility audit with findings and fixes. Use when auditing accessibility, verifying WCAG compliance, or improving a11y across the application.
+tags: [review, a11y]
 ---
 # Accessibility Audit Workflow
 

package/skills/hatch3r-agent-customize/SKILL.md

@@ -1,6 +1,7 @@
 ---
 id: hatch3r-agent-customize
 description: Create and manage per-agent customization files for model overrides, description changes, and project-specific markdown instructions. Use when tailoring agent behavior to project-specific needs.
+tags: [customize]
 ---
 # Agent Customization Management
 
@@ -31,6 +32,8 @@ Decide which customization approach to use:
 - **Description**: Change how the agent is described in adapter frontmatter
 - **Enabled**: Set to `false` to disable the agent entirely
 
+**Protected agents:** Some agents have `protected: true` in their canonical frontmatter. For these security-critical agents (e.g., reviewer, security-auditor, test-writer), customization cannot override `scope`, `description`, or `enabled` — only `model` and markdown instructions can be customized. See the `hatch3r-agent-customize` command for full details.
+
 **Markdown (`.customize.md`)** — for free-form instructions:
 - Domain-specific review checklists
 - Architecture context and constraints

package/skills/hatch3r-api-spec/SKILL.md

@@ -2,6 +2,7 @@
 id: hatch3r-api-spec
 type: skill
 description: Generate and validate OpenAPI specifications from codebase. Covers endpoint design, schema validation, and documentation generation.
+tags: [planning]
 ---
 
 # API Specification Workflow

package/skills/hatch3r-architecture-review/SKILL.md

@@ -1,6 +1,7 @@
 ---
 id: hatch3r-architecture-review
 description: Evaluate architectural decisions and produce ADRs following the project template. Use when making architectural decisions, evaluating trade-offs, or creating ADRs.
+tags: [review]
 ---
 # Architecture Review Workflow
 
@@ -54,7 +55,10 @@ Reference:
 ## Step 4: External Research
 
 - For external library docs and current best practices, follow the project's tooling hierarchy.
-- **GitHub MCP:** Search for related issues, prior discussions, or similar decisions in the repo.
+- **Issue/PR search** (check `platform` in `.agents/hatch.json`): Search for related issues, prior discussions, or similar decisions in the repo:
+  - **GitHub:** Use **GitHub MCP** or `gh issue list --search "..."` / `gh pr list --search "..."`
+  - **Azure DevOps:** `az boards query --wiql "SELECT [System.Id] FROM WorkItems WHERE [System.Title] CONTAINS '...'"` or `az repos pr list`
+  - **GitLab:** `glab issue list --search "..."` / `glab mr list --search "..."`
 - **Context7 MCP:** Look up current API patterns for relevant libraries.
 - **Web search:** For novel problems, security advisories, or best practices.
 
@@ -82,7 +86,7 @@ Save as `docs/adr/XXXX_short-title.md` (or project convention). Use next availab
 
 - Add references to the new ADR in relevant specs (e.g., data model, event model, quality engineering).
 - Update ADR index if the project maintains one.
-- Link from related GitHub issues or PRs.
+- Link from related issues/work items or PRs/MRs on the platform.
 - If superseding an ADR, update the old ADR's Status to `SUPERSEDED by ADR-XXXX`.
 
 ## Definition of Done

package/skills/hatch3r-bug-fix/SKILL.md

@@ -1,6 +1,7 @@
 ---
 id: hatch3r-bug-fix
 description: Step-by-step bug fix workflow. Diagnose root cause, implement minimal fix, write regression test. Use when fixing bugs, working on bug report issues, or when the user mentions a bug.
+tags: [core, implementation]
 ---
 > **Note:** Commands below use `npm` as an example. Substitute with your project's package manager (`yarn`, `pnpm`, `bun`) or build tool as appropriate.
 
@@ -106,9 +107,11 @@ Use the project's PR template. Include:
 
 ## Required Agent Delegation
 
+> **Note:** When this skill is invoked via the orchestration pipeline (board-pickup or workflow commands), skip this section — the orchestrator handles agent delegation in Phases 3 and 4.
+
 You MUST spawn these agents via the Task tool (`subagent_type: "generalPurpose"`) at the appropriate points:
 
-- **`hatch3r-researcher`** — MUST spawn before implementation with modes `symptom-trace`, `root-cause`, `codebase-impact`. Skip only for trivially simple bugs (`risk:low` AND `priority:p3`).
+- **`hatch3r-researcher`** — MUST spawn before implementation with modes `symptom-trace`, `root-cause`, `codebase-impact`. For Tier 2+ tasks (per `hatch3r-deep-context`), also include `requirements-elicitation` (bugs often have underspecified reproduction steps and ambiguous expected behavior). Skip only for trivially simple bugs (`risk:low` AND `priority:p3`).
 - **`hatch3r-test-writer`** — MUST spawn after fix implementation to write regression tests covering the fixed behavior and related edge cases.
 - **`hatch3r-reviewer`** — MUST spawn after implementation for code review before PR creation.
 

package/skills/hatch3r-ci-pipeline/SKILL.md

@@ -2,6 +2,7 @@
 id: hatch3r-ci-pipeline
 type: skill
 description: Design and optimize CI/CD pipelines. Covers stage design, test parallelization, artifact management, and pipeline performance.
+tags: [devops]
 ---
 
 # CI Pipeline Workflow

package/skills/hatch3r-command-customize/SKILL.md

@@ -1,6 +1,7 @@
 ---
 id: hatch3r-command-customize
 description: Create and manage per-command customization files for description overrides, enable/disable control, and project-specific markdown instructions. Use when tailoring command behavior to project-specific needs.
+tags: [customize]
 ---
 # Command Customization Management
 

package/skills/hatch3r-context-health/SKILL.md

@@ -1,6 +1,7 @@
 ---
 id: hatch3r-context-health
 description: Monitor and maintain conversation context health during long sessions. Use when context may be degrading, after many turns, or when experiencing repeated errors.
+tags: [maintenance]
 ---
 # Context Health Monitoring
 
@@ -53,7 +54,7 @@ Run through the self-assessment checklist:
 ### If 5 checks degraded (Red): Checkpoint and Stop
 1. Save all progress (files changed, tests written)
 2. Document remaining work and blockers
-3. Post progress on the GitHub issue
+3. Post progress on the issue/work item (GitHub Issue, ADO Work Item, or GitLab Issue — check `platform` in `.agents/hatch.json`)
 4. Recommend fresh conversation
 
 ## Step 4: Verify Improvement

package/skills/hatch3r-cost-tracking/SKILL.md

@@ -1,6 +1,7 @@
 ---
 id: hatch3r-cost-tracking
 description: Track token usage and estimate costs for agent sessions. Use when monitoring spend, approaching budget limits, or generating cost reports.
+tags: [maintenance]
 ---
 # Cost Tracking Workflow
 

package/skills/hatch3r-dep-audit/SKILL.md

@@ -1,6 +1,7 @@
 ---
 id: hatch3r-dep-audit
 description: Audit and update npm dependencies for security, freshness, and bundle impact. Use when auditing dependencies, responding to CVEs, or upgrading packages.
+tags: [maintenance, security]
 ---
 > **Note:** Commands below use `npm` as an example. Substitute with your project's package manager (`yarn`, `pnpm`, `bun`) or build tool as appropriate.
 
@@ -30,7 +31,10 @@ Task Progress:
 For critical and high vulnerabilities:
 
 - Use **web search** to look up each CVE: exploitability, affected versions, fix version, workarounds.
-- Check npm advisories and GitHub security advisories for official guidance.
+- Check npm advisories and platform-specific security tools for official guidance (check `platform` in `.agents/hatch.json`):
+  - **GitHub:** GitHub Security Advisories (`gh api /repos/{owner}/{repo}/security-advisories`)
+  - **Azure DevOps:** Azure Artifacts security scanning and Azure Boards advisory tracking
+  - **GitLab:** GitLab Dependency Scanning (Security & Compliance → Vulnerability Report)
 - Prioritize: critical first, then high. Moderate/low can be batched.
 - Note any packages with no fix available — document mitigation or deferral rationale.
 
@@ -38,7 +42,7 @@ For critical and high vulnerabilities:
 
 Before changing anything:
 
-- **Breaking vs non-breaking:** Check each package's changelog (npm, GitHub releases). For external library docs and current best practices, follow the project's tooling hierarchy.
+- **Breaking vs non-breaking:** Check each package's changelog (npm, release notes on the package's repository). For external library docs and current best practices, follow the project's tooling hierarchy.
 - **Bundle impact:** Check bundle size budget from project rules. Run `npm run build` and measure before/after for each upgrade.
 - **Upgrade order:** Security fixes first, then non-breaking minor/patch, then breaking changes (one at a time).
 - **Risks:** List packages that may require code changes (e.g., major version bumps).

package/skills/hatch3r-feature/SKILL.md

@@ -1,6 +1,7 @@
 ---
 id: hatch3r-feature
 description: End-to-end feature implementation workflow. Covers data model, domain logic, API, and UI as a vertical slice. Use when implementing new features or working on feature request issues.
+tags: [core, implementation]
 ---
 > **Note:** Commands below use `npm` as an example. Substitute with your project's package manager (`yarn`, `pnpm`, `bun`) or build tool as appropriate.
 
@@ -25,6 +26,8 @@ Task Progress:
 - Parse the issue body: problem/goal, proposed solution, acceptance criteria, scope (in/out), UX notes, edge cases, security considerations, rollout plan.
 - Read relevant project documentation (glossary, user flows, behavior, event model, data model, privacy, monetization, as applicable).
 - Review existing code patterns in the affected area.
+- **Review reference implementations**: If the orchestrator provided `similar-implementation` researcher output, read the reference implementations and their extracted conventions. These define the patterns this feature should follow (file structure, state management, error handling, data fetching, test structure, component composition).
+- **Review resolved requirements**: If the orchestrator provided `requirements-elicitation` answers, read them to understand explicit user decisions on ambiguities (data shape, error behavior, UI states, security model, etc.). Do not guess when explicit answers are available.
 - For external library docs and current best practices, follow the project's tooling hierarchy.
 
 ## Step 2: Implementation Plan
@@ -32,6 +35,7 @@ Task Progress:
 Before coding, output:
 
 - **Approach:** high-level strategy
+- **Convention alignment:** which reference implementation's patterns this follows (from `similar-implementation` output), with divergences noted and justified. If no reference was provided, note "no reference — using best judgment from codebase conventions."
 - **Files to create/modify:** list with what changes
 - **Data model changes:** new collections/fields, if any
 - **Event changes:** new event types, if any
@@ -62,6 +66,7 @@ Use standard flow (implement → test) when:
 ## Step 3: Implement
 
 - Deliver a complete vertical slice (data -> logic -> UI).
+- Follow the convention lock from Step 1 / the implementer's Step 1b — match the reference implementation's patterns for file structure, state management, error handling, data fetching, and testing. Do not invent new patterns when established ones exist in the codebase.
 - Use stable IDs from the project glossary.
 - If database/backend data is needed, include security rules updates.
 - If feature is gated, enforce entitlements client-side AND server-side.
@@ -105,10 +110,12 @@ Use the project's PR template. Include:
 
 ## Required Agent Delegation
 
+> **Note:** When this skill is invoked via the orchestration pipeline (board-pickup or workflow commands), skip this section — the orchestrator handles agent delegation in Phases 3 and 4.
+
 You MUST spawn these agents via the Task tool (`subagent_type: "generalPurpose"`) at the appropriate points:
 
-- **`hatch3r-researcher`** — MUST spawn before implementation with modes `codebase-impact`, `feature-design`, `architecture`. Skip only for trivially simple features (`risk:low` AND `priority:p3`).
-- **`hatch3r-implementer`** — MUST spawn one per sub-issue when the feature is decomposed into multiple tasks. Each implementer receives its own sub-issue context.
+- **`hatch3r-researcher`** — MUST spawn before implementation with modes `codebase-impact`, `feature-design`, `architecture`. For Tier 2+ tasks (per `hatch3r-deep-context`), also include `similar-implementation` and `requirements-elicitation`. Skip only for trivially simple features (`risk:low` AND `priority:p3`).
+- **`hatch3r-implementer`** — MUST spawn one per sub-issue when the feature is decomposed into multiple tasks. Each implementer receives its own sub-issue context, plus reference conventions and resolved requirements from the researcher output.
 - **`hatch3r-reviewer`** — MUST spawn after implementation for code review before PR creation.
 
 ## Related Skills

package/skills/hatch3r-gh-agentic-workflows/SKILL.md

@@ -1,21 +1,36 @@
 ---
 id: hatch3r-gh-agentic-workflows
-description: Set up GitHub Agentic Workflows for continuous AI-powered repository automation
+description: Set up CI/CD agentic workflows for continuous AI-powered repository automation (GitHub Actions, Azure Pipelines, GitLab CI)
+tags: [devops, team]
 ---
-# GitHub Agentic Workflows Integration
+# CI/CD Agentic Workflows Integration
 
-GitHub Agentic Workflows (technical preview, Feb 2026) bring AI agent orchestration into
-GitHub Actions. This skill guides setup for hatch3r-managed projects.
+> **Platform detection:** Check `platform` in `.agents/hatch.json` to determine which CI/CD system to use. Defaults to `"github"`.
+
+This skill guides setup for AI-powered CI/CD automation in hatch3r-managed projects across all supported platforms.
 
 ## Overview
 
-Agentic Workflows are markdown files in `.github/workflows/` with YAML frontmatter that
+### GitHub Actions (Agentic Workflows)
+
+GitHub Agentic Workflows (technical preview, Feb 2026) bring AI agent orchestration into
+GitHub Actions. Agentic Workflows are markdown files in `.github/workflows/` with YAML frontmatter that
 compile to GitHub Actions jobs. They support multiple AI engines (GitHub Copilot, Claude,
 OpenAI Codex) and use MCP for tool access.
 
+### Azure DevOps Pipelines
+
+Azure Pipelines use YAML files in the repo (typically `azure-pipelines.yml` or files under `.azuredevops/`) to define CI/CD jobs. Use the `az pipelines` CLI for management and monitoring.
+
+### GitLab CI/CD
+
+GitLab CI uses `.gitlab-ci.yml` at the repo root to define pipelines. Use the `glab ci` CLI for management and monitoring.
+
 ## Available Workflow Templates
 
-hatch3r recommends these agentic workflow patterns for projects:
+### Platform: GitHub Actions
+
+hatch3r recommends these agentic workflow patterns for GitHub-hosted projects:
 
 ### 1. Continuous Test Improvement
 
@@ -69,7 +84,7 @@ name: Continuous Documentation
 on:
   pull_request:
     types: [closed]
-    branches: [main]
+    branches: [{defaultBranch}]
 engine: copilot
 permissions:
   contents: write
@@ -77,8 +92,69 @@ permissions:
 ---
 ```
 
+Replace `{defaultBranch}` with `board.defaultBranch` from `.agents/hatch.json` (fallback: `"main"`).
+
 After a PR is merged, check if documentation needs updating and open a follow-up PR.
 
+### Platform: Azure DevOps Pipelines
+
+Equivalent pipeline patterns for Azure DevOps:
+
+#### 1. Continuous Test Improvement (ADO)
+
+```yaml
+# azure-pipelines/hatch3r-continuous-testing.yml
+trigger: none
+schedules:
+  - cron: '0 6 * * 1'
+    displayName: Weekly test improvement
+    branches:
+      include: [{defaultBranch}]
+    always: true
+
+pool:
+  vmImage: 'ubuntu-latest'
+
+steps:
+  - script: echo "Analyze test coverage gaps and create PRs with new tests"
+    displayName: 'AI-assisted test improvement'
+```
+
+Replace `{defaultBranch}` with `board.defaultBranch` from `.agents/hatch.json` (fallback: `"main"`).
+
+#### 2. Continuous Triage (ADO)
+
+Use Azure Boards service hooks to trigger a pipeline when a new work item is created. The pipeline applies labels and adds a triage comment.
+
+#### 3. Continuous Documentation (ADO)
+
+Trigger a pipeline on PR completion to the default branch. Check if documentation needs updating and open a follow-up PR via `az repos pr create`.
+
+### Platform: GitLab CI/CD
+
+Equivalent pipeline patterns for GitLab:
+
+#### 1. Continuous Test Improvement (GitLab)
+
+```yaml
+# .gitlab-ci.yml (or included file)
+continuous-test-improvement:
+  rules:
+    - if: $CI_PIPELINE_SOURCE == "schedule"
+  script:
+    - echo "Analyze test coverage gaps and create MRs with new tests"
+```
+
+Configure a pipeline schedule in GitLab (Settings → CI/CD → Schedules) for weekly runs.
+
+#### 2. Continuous Triage (GitLab)
+
+Use GitLab webhooks on issue creation to trigger a pipeline that applies labels from the hatch3r taxonomy and adds a triage comment via `glab issue update`.
+
+#### 3. Continuous Documentation (GitLab)
+
+Trigger on merge to the default branch. Check if documentation needs updating and open a follow-up MR via `glab mr create`.
+
 ## Security Considerations
 
 - Workflows run in sandboxed environments with minimal permissions
@@ -95,27 +171,54 @@ After a PR is merged, check if documentation needs updating and open a follow-up
 
 ## Setup
 
+### GitHub
 1. Enable GitHub Agentic Workflows in your repository settings
 2. Create workflow files in `.github/workflows/` using the templates above
 3. Configure the AI engine (copilot is default, claude and codex are alternatives)
 4. Set appropriate permissions for each workflow
 5. Monitor workflow runs in the Actions tab
 
+### Azure DevOps
+1. Create pipeline YAML files in the repo (e.g., `azure-pipelines/`)
+2. Register each pipeline in Azure DevOps (Pipelines → New Pipeline → Existing YAML)
+3. Configure service connections and variable groups for secrets
+4. Set appropriate pipeline permissions and approvals
+5. Monitor runs in Azure Pipelines
+
+### GitLab
+1. Define jobs in `.gitlab-ci.yml` (or use `include:` for modular files)
+2. Configure pipeline schedules for periodic jobs (Settings → CI/CD → Schedules)
+3. Set CI/CD variables for secrets (Settings → CI/CD → Variables)
+4. Configure protected branches and merge request approvals
+5. Monitor runs in CI/CD → Pipelines
+
 ## Verification Steps
 
-1. **Syntax check**: Validate the workflow file with `gh workflow view {name}` or the GitHub Actions web UI.
-2. **Dry run**: Trigger manually via `gh workflow run {name}` and monitor with `gh run watch`.
-3. **Output review**: Check the AI-generated output (PR, comment, label) for quality and correctness.
+1. **Syntax check**: Validate the workflow/pipeline definition:
+   - **GitHub:** `gh workflow view {name}` or the Actions web UI
+   - **Azure DevOps:** `az pipelines show --name {name}` or the Pipelines web UI
+   - **GitLab:** CI Lint (CI/CD → Editor → Validate) or `glab ci lint`
+2. **Dry run**: Trigger manually and monitor:
+   - **GitHub:** `gh workflow run {name}` → `gh run watch`
+   - **Azure DevOps:** `az pipelines run --name {name}` → `az pipelines runs show --id {id}`
+   - **GitLab:** `glab ci run` → `glab ci view`
+3. **Output review**: Check the AI-generated output (PR/MR, comment, label) for quality and correctness.
 4. **Permission audit**: Verify the workflow cannot access resources beyond its declared permissions.
 5. **Idempotency**: Run the workflow twice on the same input — it should not create duplicate artifacts.
 6. **Error handling**: Trigger with invalid/edge-case input — workflow should fail gracefully with clear error.
 
 ## Monitoring
 
-- **Execution tracking**: Use `gh run list --workflow={name}` to monitor recent runs.
-- **Failure alerts**: Configure GitHub Actions notifications (Settings → Notifications → Actions).
+- **Execution tracking**:
+  - **GitHub:** `gh run list --workflow={name}`
+  - **Azure DevOps:** `az pipelines runs list --pipeline-name {name}`
+  - **GitLab:** `glab ci list`
+- **Failure alerts**:
+  - **GitHub:** Settings → Notifications → Actions
+  - **Azure DevOps:** Pipeline notifications (Project Settings → Notifications)
+  - **GitLab:** Pipeline email notifications (Settings → Integrations)
 - **Cost awareness**: Monitor AI token usage per workflow run. Set spending limits in org settings.
-- **Quality metrics**: Track: success rate, output acceptance rate (merged PRs / total PRs), mean time per run.
+- **Quality metrics**: Track: success rate, output acceptance rate (merged PRs/MRs / total), mean time per run.
 
 ## Troubleshooting
 
@@ -132,19 +235,25 @@ After a PR is merged, check if documentation needs updating and open a follow-up
 
 If a workflow produces undesirable results:
 
-1. **Disable immediately**: `gh workflow disable {name}` or toggle in repo Settings → Actions.
-2. **Revert outputs**: Close AI-generated PRs, remove applied labels, revert merged changes if needed.
-3. **Diagnose**: Review recent run logs with `gh run view {run-id} --log`.
-4. **Fix and re-enable**: Update the workflow file, test via manual dispatch, then re-enable.
+1. **Disable immediately**:
+   - **GitHub:** `gh workflow disable {name}` or toggle in repo Settings → Actions
+   - **Azure DevOps:** `az pipelines update --name {name} --enabled false` or toggle in Pipelines UI
+   - **GitLab:** Pause pipeline schedules in Settings → CI/CD → Schedules, or use the GitLab API
+2. **Revert outputs**: Close AI-generated PRs/MRs, remove applied labels, revert merged changes if needed.
+3. **Diagnose**: Review recent run logs:
+   - **GitHub:** `gh run view {run-id} --log`
+   - **Azure DevOps:** `az pipelines runs show --id {run-id}` and download logs from the Pipelines UI
+   - **GitLab:** `glab ci view {pipeline-id}` or check CI/CD → Pipelines in the web UI
+4. **Fix and re-enable**: Update the workflow/pipeline file, test via manual dispatch, then re-enable.
 
 ## Definition of Done
 
-- [ ] Workflow file created in `.github/workflows/` with correct YAML frontmatter
-- [ ] Engine configured (copilot/claude/codex) with appropriate model selection
+- [ ] Workflow/pipeline file created in the platform-appropriate location (`.github/workflows/`, `azure-pipelines/`, `.gitlab-ci.yml`)
+- [ ] Engine/runner configured with appropriate model or agent selection
 - [ ] Permissions scoped to minimum required (read-only defaults, write only where needed)
 - [ ] MCP tool access configured if needed (with allowlisting)
 - [ ] Trigger events appropriate for the workflow's purpose
-- [ ] Manual `workflow_dispatch` trigger included for testing
+- [ ] Manual trigger included for testing (`workflow_dispatch` / manual pipeline run / manual pipeline trigger)
 - [ ] Workflow tested via manual dispatch with expected outcomes verified
-- [ ] Monitoring configured (GitHub Actions notifications or Slack integration)
+- [ ] Monitoring configured (platform notifications or Slack integration)
 - [ ] Documentation updated (README or CONTRIBUTING) to describe the new workflow

package/skills/hatch3r-incident-response/SKILL.md

@@ -1,6 +1,7 @@
 ---
 id: hatch3r-incident-response
 description: Handle production incidents with structured triage, mitigation, and post-mortem. Use when responding to production issues, outages, or security incidents.
+tags: [devops]
 ---
 # Incident Response Workflow
 
@@ -25,7 +26,10 @@ Task Progress:
 | P2       | Partial degradation, limited impact         | Single flow broken, slow performance       |
 | P3       | Minor issue, workaround available            | Cosmetic bug, edge case                     |
 
-- Use **GitHub MCP** (`issue_read`, `search_issues`) to check for related issues or prior incidents.
+- Check for related issues or prior incidents using the platform tools (check `platform` in `.agents/hatch.json`):
+  - **GitHub:** Use **GitHub MCP** (`issue_read`, `search_issues`) or `gh issue list --search "..."`
+  - **Azure DevOps:** `az boards query --wiql "SELECT [System.Id] FROM WorkItems WHERE [System.Title] CONTAINS '...'"` or `az boards work-item show --id N`
+  - **GitLab:** `glab issue list --search "..."` or `glab issue view N`
 - For external library docs and current best practices, follow the project's tooling hierarchy.
 
 ## Step 2: Triage
@@ -61,15 +65,17 @@ Write a structured post-mortem document:
 - **Action items:** Permanent fixes, preventive measures, process improvements.
 - **Lessons learned:** What we'll do differently.
 
-Store in project incident docs or as a GitHub issue/wiki page. Follow project conventions.
+Store in project incident docs or as an issue/wiki page on the platform. Follow project conventions.
 
 ## Step 6: Follow-Up Issues
 
-- Create GitHub issues for each action item from the post-mortem.
+- Create follow-up issues/work items for each action item from the post-mortem (check `platform` in `.agents/hatch.json`):
+  - **GitHub:** `gh issue create --title "..." --body "..." --label "incident-follow-up"` (or use **GitHub MCP** `issue_create`)
+  - **Azure DevOps:** `az boards work-item create --type "Bug" --title "..." --description "..." --fields "System.Tags=incident-follow-up"`
+  - **GitLab:** `glab issue create --title "..." --description "..." --label "incident-follow-up"`
 - Label appropriately (e.g., `incident-follow-up`, `P0`, `P1`).
-- Link issues to the post-mortem and to each other.
+- Link issues/work items to the post-mortem and to each other.
 - Assign owners and due dates for critical fixes.
-- Use **GitHub MCP** (`issue_create` or equivalent) to create issues.
 
 ## Definition of Done