{
  "platform": {
    "none": {
      "devopsSkills": "- Selected platform: `none` (from onboarding platform step).\n- Do NOT load `ob-userstory` or `ob-ops-ship`.\n- Work only from direct user instructions in the main conversation or from local OpenSpec artifacts.\n- Ignore GitHub/Azure DevOps URL inference unless the user explicitly reconfigures onboarding later.",
      "devopsMode": "This project does not use GitHub or Azure DevOps integration. Do not read work items, create PRs, or process PR feedback. Operate only from direct user instructions and local repository context.",
      "workflow": "When the user gives a task directly in the conversation, **I own the full lifecycle**. I work from the user request and local repository context. I may use OpenSpec when structured planning helps, but I do not depend on issue links or PR workflows.\n\nTrigger patterns, I recognize ALL of these, exact wording does not matter:\n- User describes a feature, bug, or refactor directly → clarify if needed → optionally load the `ob-plan-propose` skill → implement in the main session or `ob-plan-apply` as appropriate\n- `implement the plan` / `implement` / `start` / `go` → load the `ob-plan-apply` skill against the current OpenSpec change when one exists\n- `just do it` / `quick fix` / `raw conversation` → work directly in the main session without PR or work-item automation\n\n**GitHub Issue URLs, Azure DevOps work item URLs, and PR URLs are NOT automatic triggers in this mode.** Only use platform-specific flows if onboarding is later reconfigured for GitHub or Azure DevOps.",
      "pipeline": "```\nlead (main session)\n  → ob-plan-propose (propose + enrich tasks)\n        ↓\n  [confirm when scope needs it]\n        ↓\n*-engineer specialists (parallel via ob-plan-apply)\n  → implement assigned tasks (parallel waves)\n        ↓\nlead verifies and reports to user\n```\n\n### Phase 1, Clarify & Plan\n\n```\n1. Understand the task from the conversation and local repo context.\n2. If the work benefits from explicit specs/tasks, load the ob-plan-propose skill.\n   Enrich tasks.md: assign each task its best matching engineer (the engineer's tier sets the model) plus depends_on and touches.\n3. Show the plan or intended scope when non-trivial.\n4. If the request is small, implement directly in the main session.\n```\n\n### Phase 2, Implement\n\n```\n0. Run /quota before spawning, when available.\n1. If using OpenSpec tasks, load the ob-plan-apply skill.\n   - Classify cost tier, confirm if ≥4 tasks.\n   - Lead discovers engineers, builds dependency- and file-disjoint waves, and spawns each wave as parallel subagents.\n   - Each subagent implements its assigned tasks and returns; the lead commits each group and marks tasks done.\n2. If task is small, implement directly in the main session.\n3. Verify with tests/build/lint.\n```\n\nThere is no PR shipping phase in `none` mode. Report completion directly to the user.",
      "skillsGuide": "No platform skills installed (platform: none). Work from direct user instructions and local OpenSpec artifacts only."
    },
    "azure": {
      "devopsSkills": "- Selected platform: `azure` (from onboarding platform step).\n- Load Azure DevOps skills: `ob-userstory`, `ob-ops-ship`.\n- Use URL-based platform inference only if onboarding metadata is missing or ambiguous.",
      "devopsMode": "This project uses platform-integrated workflow modes described below.",
      "workflow": "When the user provides a work item URL or says \"implement the plan\" or \"I've added comments to the PR\", **I own the full lifecycle**. I load the appropriate userstory skill and coordinate implementation as native subagent waves via the `ob-plan-apply` skill.\n\nTrigger patterns, I recognize ALL of these, exact wording does not matter:\n- User pastes or mentions an Azure DevOps URL → load `ob-userstory` skill → parse work item → load the `ob-plan-propose` skill → confirm with user → load the `ob-plan-apply` skill → ship\n- `implement the plan` / `implement` / `start` / `go` → load the `ob-plan-apply` skill → ship\n- `I've added comments to the PR` → read PR comments → fix → update PR\n- Any Azure DevOps PR URL in a feedback/fix request (e.g. \"check comments\", \"fix PR feedback\") → run PR Feedback Loop\n\n**An Azure DevOps URL in the user's message is a strong trigger: follow the pipeline unless the user explicitly asks for analysis or context only.**",
      "pipeline": "```\nlead (main session)\n  → ob-plan-propose (parse work item + propose + enrich tasks)\n        ↓\n  [confirm with user]\n        ↓\n*-engineer specialists (parallel via ob-plan-apply)\n  → implement assigned tasks (parallel waves)\n        ↓\nlead loads the ob-ops-ship skill → commit + push + create PR\n```\n\n### Phase 1, Parse & Propose\n\n```\n1. If a work item URL is provided, load @ob-userstory skill.\n2. Load the ob-plan-propose skill → fetches work item, generates proposal.md, specs/, tasks.md, enriches tasks with agent + dependencies.\n3. Show the plan: change name, total tasks, task list with agent assignments.\n4. STOP. Ask user: \"Ready to implement? (yes/no)\", DO NOT proceed until confirmed.\n```\n\n### Phase 2, Implement\n\n```\n0. Run /quota to check remaining budget before spawning.\n1. Load the ob-plan-apply skill.\n   - Classify cost tier, announce scope, ask user to confirm if ≥4 tasks.\n   - Lead discovers available engineers from .opencode/agents/*.md, prefers matching custom engineers.\n   - Lead builds dependency- and file-disjoint waves, then spawns each wave as parallel subagents (by agent name; each engineer carries its own model).\n   - Each subagent implements its assigned tasks and returns; the lead commits each group and marks tasks done in tasks.md.\n2. Verify with tests/build/lint according to task scope.\n3. Run /quota after all waves complete.\n```\n\n### Phase 3, Ship\n\n```\n1. Load the ob-ops-ship skill to create the PR.\n2. Done: report PR URL to user.\n```\n\n### Handling PR Feedback\n\n```\nWhen user says \"I've added comments to the PR\" or shares a PR URL:\n1. Triage feedback: read and classify the PR comments via the repo platform CLI (the /ops-review flow).\n2. Fix items by loading the ob-plan-apply skill for the required tasks.\n3. Load the ob-ops-ship skill again to push updates and reply to PR threads.\n```",
      "skillsGuide": "Platform skills (Azure DevOps):\n- `@ob-userstory`: load when an Azure DevOps work item URL is detected. Fetches the work item via `az` CLI and creates an OpenSpec change. NEVER use browser tools for Azure DevOps operations.\n- `ob-ops-ship`: load in ship mode to create a PR and link the work item, or in feedback mode to read and classify PR review comments."
    },
    "github": {
      "devopsSkills": "- Selected platform: `github` (from onboarding platform step).\n- Load GitHub skills: `ob-userstory`, `ob-ops-ship`.\n- Use URL-based platform inference only if onboarding metadata is missing or ambiguous.",
      "devopsMode": "This project uses platform-integrated workflow modes described below.",
      "workflow": "When the user provides a work item URL or says \"implement the plan\" or \"I've added comments to the PR\", **I own the full lifecycle**. I load the appropriate userstory skill and coordinate implementation as native subagent waves via the `ob-plan-apply` skill.\n\nTrigger patterns, I recognize ALL of these, exact wording does not matter:\n- User pastes or mentions a GitHub Issue URL → load `ob-userstory` skill → parse issue → load the `ob-plan-propose` skill → confirm with user → load the `ob-plan-apply` skill → ship\n- `implement the plan` / `implement` / `start` / `go` → load the `ob-plan-apply` skill → ship\n- `I've added comments to the PR` → read PR comments → fix → update PR\n- Any GitHub PR URL in a feedback/fix request (e.g. \"check comments\", \"fix PR feedback\") → run PR Feedback Loop\n\n**A GitHub URL in the user's message is a strong trigger: follow the pipeline unless the user explicitly asks for analysis or context only.**",
      "pipeline": "```\nlead (main session)\n  → ob-plan-propose (parse work item + propose + enrich tasks)\n        ↓\n  [confirm with user]\n        ↓\n*-engineer specialists (parallel via ob-plan-apply)\n  → implement assigned tasks (parallel waves)\n        ↓\nlead loads the ob-ops-ship skill → commit + push + create PR\n```\n\n### Phase 1, Parse & Propose\n\n```\n1. If a work item URL is provided, load @ob-userstory skill.\n2. Load the ob-plan-propose skill → fetches work item, generates proposal.md, specs/, tasks.md, enriches tasks with agent + dependencies.\n3. Show the plan: change name, total tasks, task list with agent assignments.\n4. STOP. Ask user: \"Ready to implement? (yes/no)\", DO NOT proceed until confirmed.\n```\n\n### Phase 2, Implement\n\n```\n0. Run /quota to check remaining budget before spawning.\n1. Load the ob-plan-apply skill.\n   - Classify cost tier, announce scope, ask user to confirm if ≥4 tasks.\n   - Lead discovers available engineers from .opencode/agents/*.md, prefers matching custom engineers.\n   - Lead builds dependency- and file-disjoint waves, then spawns each wave as parallel subagents (by agent name; each engineer carries its own model).\n   - Each subagent implements its assigned tasks and returns; the lead commits each group and marks tasks done in tasks.md.\n2. Verify with tests/build/lint according to task scope.\n3. Run /quota after all waves complete.\n```\n\n### Phase 3, Ship\n\n```\n1. Load the ob-ops-ship skill to create the PR.\n2. Done: report PR URL to user.\n```\n\n### Handling PR Feedback\n\n```\nWhen user says \"I've added comments to the PR\" or shares a PR URL:\n1. Triage feedback: read and classify the PR comments via the repo platform CLI (the /ops-review flow).\n2. Fix items by loading the ob-plan-apply skill for the required tasks.\n3. Load the ob-ops-ship skill again to push updates and reply to PR threads.\n```",
      "skillsGuide": "Platform skills (GitHub):\n- `@ob-userstory`: load when a GitHub Issue URL is detected. Fetches the issue via `gh` CLI and creates an OpenSpec change. NEVER use webfetch to access GitHub URLs.\n- `ob-ops-ship`: load in ship mode to create a PR with screenshots, or in feedback mode to read and classify PR review comments."
    },
    "mixed": {
      "default": {
        "workflow": "This project uses a mixed-platform setup: the backlog (work items) and the repo (PRs) live on different platforms. Check `.opencode/opencode-onboard.json` → `platform.backlog` and `platform.repo`.\n\nWhen the user provides a work item URL or says \"implement the plan\" or \"I've added comments to the PR\", **I own the full lifecycle**: parse the work item with `@ob-userstory` (backlog platform CLI), plan via the `ob-plan-propose` skill, confirm with the user, implement via the `ob-plan-apply` skill, ship via the `ob-ops-ship` skill (repo platform CLI).\n\nTrigger patterns, I recognize ALL of these, exact wording does not matter:\n- A backlog work-item URL or issue key → load `ob-userstory` → parse → load the `ob-plan-propose` skill → confirm with user → load the `ob-plan-apply` skill → ship\n- `implement the plan` / `implement` / `start` / `go` → load the `ob-plan-apply` skill → ship\n- A PR/MR URL or \"I've added comments to the PR\" → read the PR comments via the repo platform CLI → run the PR Feedback Loop\n\nNever mix the CLIs: work items always go through the backlog platform CLI, PRs/MRs always through the repo platform CLI.",
        "pipeline": "{repo}",
        "skillsGuide": "Mixed platform setup: the two platform skills target different hosts:\n- `@ob-userstory` → fetches work items from the backlog platform. Load when a work-item URL or issue key is provided.\n- `ob-ops-ship` → creates PRs/MRs and triages review feedback on the repo platform. Load in ship mode or PR-feedback mode."
      }
    },
    "jira": {
      "devopsSkills": "- Selected backlog platform: `jira` (from onboarding platform step).\n- Jira is a BACKLOG-ONLY platform. Work items are fetched via `acli jira` CLI.\n- PRs and code review use the repo platform (GitHub or Azure DevOps) configured separately.\n- Load `ob-userstory` skill when a Jira URL is provided.\n- Load `ob-ops-ship` skill from the repo platform for PR operations.",
      "devopsMode": "This project uses Jira for backlog/work items and a separate repo platform (GitHub or Azure DevOps) for code. Fetch work items via `acli jira` CLI. Create PRs via the repo platform CLI. Do NOT use browser tools for Jira operations.",
      "workflow": "When the user provides a Jira URL or mentions a Jira issue key, **I own the full lifecycle**. I load `ob-userstory` skill to parse the Jira issue via `acli jira workitem view`, then load the `ob-plan-propose` skill to create the plan.\n\nTrigger patterns, I recognize ALL of these, exact wording does not matter:\n- User pastes or mentions a Jira URL (atlassian.net/browse/PROJ-123) -> load `ob-userstory` skill -> fetch via `acli jira` -> load the `ob-plan-propose` skill -> confirm -> load the `ob-plan-apply` skill -> ship\n- User mentions a Jira issue key (e.g. \"PROJ-123\") -> same flow\n- `implement the plan` / `implement` / `start` / `go` -> load the `ob-plan-apply` skill -> ship\n- PR feedback -> use the repo platform CLI (gh or az) for PR operations\n\n**A Jira URL or issue key in the user's message is a strong trigger: follow the pipeline unless the user explicitly asks for analysis or context only.**\n\nFor PR creation and code review, use the repo platform (configured as `platform.repo`). Jira has no PR capability.",
      "pipeline": "```\nlead (main session)\n  -> fetch Jira work item (acli jira workitem view)\n  -> ob-plan-propose (propose + enrich tasks)\n        |\n  [confirm when scope needs it]\n        |\n*-engineer specialists (parallel via ob-plan-apply)\n  -> implement assigned tasks (parallel waves)\n        |\nlead verifies, creates PR via repo platform (gh or az)\n  -> transition Jira work item to Done (acli jira workitem transition)\n```\n\n### Phase 1, Fetch & Plan\n\n```\n1. Fetch the Jira work item via acli jira workitem view --key KEY.\n2. Load the ob-plan-propose skill to create the OpenSpec change from the work item.\n3. Confirm with the user.\n```\n\n### Phase 2, Implement & Ship\n\n```\n1. Load the ob-plan-apply skill to implement via parallel subagent waves.\n2. Create PR via repo platform CLI (gh pr create or az repos pr create).\n3. Transition Jira work item: acli jira workitem transition --key KEY --status \"Done\"\n```",
      "skillsGuide": "### Backlog Platform: Jira\n- `ob-userstory` -> fetches Jira work items via `acli jira` CLI. Load when a Jira URL or issue key is provided.\n\n### Repo Platform\n- PR skills are loaded based on `platform.repo` (GitHub or Azure DevOps)."
    },
    "gitlab": {
      "devopsSkills": "- Selected repo platform: `gitlab` (from onboarding platform step).\n- GitLab is a REPO-ONLY platform. MRs and code review via `glab` CLI.\n- Backlog/work items use the backlog platform (GitHub / Azure / Jira) configured separately.\n- Load `ob-ops-ship` skill for GitLab MR operations.",
      "devopsMode": "This project uses GitLab for code repository and merge requests, with a separate backlog platform for work items. Create MRs via `glab mr create` CLI. Fetch work items via the backlog platform CLI. Do NOT use browser tools for GitLab operations.",
      "workflow": "When the user provides a GitLab MR URL or says \"implement the plan\", **I own the full lifecycle**. I load the appropriate userstory skill (from backlog platform) and `ob-ops-ship` skill (for GitLab MRs).\n\nTrigger patterns, I recognize ALL of these, exact wording does not matter:\n- User pastes or mentions a backlog work item URL -> load `ob-userstory` skill -> fetch via backlog CLI -> load the `ob-plan-propose` skill -> confirm -> load the `ob-plan-apply` skill -> ship\n- `implement the plan` / `implement` / `start` / `go` -> load the `ob-plan-apply` skill -> ship\n- User says \"I've added comments to the MR\" -> read MR comments via `glab mr note list` -> triage feedback\n- Any GitLab MR URL in a feedback/fix request -> run MR Feedback Loop via `glab` CLI\n\n**A GitLab MR URL in the user's message is a strong trigger: follow the pipeline unless the user explicitly asks for analysis or context only.**\n\nFor work item fetching, use the backlog platform (configured as `platform.backlog`). GitLab has no backlog integration.",
      "pipeline": "```\nlead (main session)\n  -> fetch work item (backlog platform CLI: gh / az / acli)\n  -> ob-plan-propose (propose + enrich tasks)\n        |\n  [confirm when scope needs it]\n        |\n*-engineer specialists (parallel via ob-plan-apply)\n  -> implement assigned tasks (parallel waves)\n        |\nlead verifies, creates MR via GitLab (glab mr create)\n```\n\n### Phase 1, Fetch & Plan\n\n```\n1. Fetch the work item via backlog platform CLI.\n2. Load the ob-plan-propose skill to create the OpenSpec change.\n3. Confirm with the user.\n```\n\n### Phase 2, Implement & Ship\n\n```\n1. Load the ob-plan-apply skill to implement via parallel subagent waves.\n2. Create MR via glab mr create.\n3. Archive change after MR is merged.\n```",
      "skillsGuide": "### Repo Platform: GitLab\n- `ob-ops-ship` -> creates GitLab merge requests via `glab` CLI. Load when shipping a branch or processing MR feedback.\n\n### Backlog Platform\n- Work item skills are loaded based on `platform.backlog` (GitHub / Azure / Jira)."
    },
    "browser": {
      "devopsSkills": "- Selected backlog platform: `browser` (from onboarding platform step).\n- No CLI integration for the backlog system. Work items are fetched via opencode-browser plugin.\n- The `ob-userstory` skill navigates to work item URLs the user provides and reads page content.\n- PRs and code review use the repo platform (GitHub / Azure DevOps / GitLab) configured separately.",
      "devopsMode": "This project uses browser automation for backlog/work items (no CLI) and a separate repo platform for code. Work items are read from web pages using the opencode-browser plugin. Create PRs via the repo platform CLI. The browser navigation exception ONLY applies to work item URLs the user explicitly provides.",
      "workflow": "When the user provides a work item URL from any backlog tool (Azure DevOps, Linear, Trello, etc.), **I own the full lifecycle**. I load `ob-userstory` skill to navigate to the URL via browser and read the page content.\n\nTrigger patterns, I recognize ALL of these, exact wording does not matter:\n- User pastes any URL to a work item/ticket/issue -> load `ob-userstory` skill -> navigate via browser -> read page text + snapshot -> parse work item -> load the `ob-plan-propose` skill -> confirm -> load the `ob-plan-apply` skill -> ship\n- `implement the plan` / `implement` / `start` / `go` -> load the `ob-plan-apply` skill -> ship\n- PR feedback -> use the repo platform CLI (gh, az, or glab) for PR operations\n\n**Any work item URL in the user's message is a trigger, regardless of the backlog tool it points to.**\n\nFor PR creation and code review, use the repo platform (configured as `platform.repo`). Browser is backlog-only: it has no PR capability.",
      "pipeline": "```\nlead (main session)\n  -> open work item URL in browser (browser_open_tab)\n  -> read page content (browser_query mode=page_text + browser_snapshot)\n  -> parse work item fields from page text\n  -> ob-plan-propose (propose + enrich tasks)\n        |\n  [confirm when scope needs it]\n        |\n*-engineer specialists (parallel via ob-plan-apply)\n  -> implement assigned tasks (parallel waves)\n        |\nlead verifies, creates PR via repo platform (gh / az / glab)\n```\n\n### Phase 1, Fetch & Plan\n\n```\n1. User provides a work item URL.\n2. Navigate to the URL via browser_open_tab.\n3. Read page text via browser_query mode=page_text.\n4. Take accessibility snapshot via browser_snapshot.\n5. Parse title, description, acceptance criteria from the page.\n6. Load the ob-plan-propose skill to create the OpenSpec change.\n7. Confirm with the user.\n```\n\n### Phase 2, Implement & Ship\n\n```\n1. Load the ob-plan-apply skill to implement via parallel subagent waves.\n2. Create PR via repo platform CLI (gh pr create, az repos pr create, or glab mr create).\n3. Archive change after PR is merged.\n```",
      "skillsGuide": "### Backlog Platform: Others (Browser)\n- `ob-userstory` -> navigates to work item URLs via browser plugin, reads page content, creates OpenSpec changes. Load when a URL the user provides does not match GitHub/Azure/Jira CLI platforms.\n\n### Repo Platform\n- PR skills are loaded based on `platform.repo` (GitHub / Azure DevOps / GitLab)."
    }
  }
}