Decouples commands from Linear via PM skill

.opencode/command/commit.md

@@ -40,11 +40,13 @@ type: imperative title under 50 characters
 - Each bullet wrapped at 72 characters
 
 Delivers PAP-XXXX
+
+{commit trailer from PM skill}
 ```
 
 - **Title**: conventional prefix, imperative mood, capitalised, no trailing period, ≤50 characters
 - **Body**: 1-5 bullet points explaining why and what (omit body only for trivial changes)
-- **Trailer**: `Delivers {issue_id}` on the last line when an issue ID was found
+- **Trailer**: Use the commit trailer format defined in the PM skill on the last line when an issue ID was found
 - **Language**: English only
 
 ## Issue ID
@@ -53,8 +55,8 @@ Determine the associated issue ID in this order:
 
 1. **Session context** — If the session was invoked with an issue ID (e.g. /execute), use it
 2. **Branch name** — Run `git branch --show-current` and extract the `{PREFIX}-{NUMBER}` segment (e.g. `feature/pap-7024-desc` → `PAP-7024`). Normalise to uppercase.
-3. **Ask the user** — "Is there a Linear issue associated with these changes?"
-4. **Omit** — If no issue, proceed without the `Delivers` trailer
+3. **Ask the user** — "Is there an issue associated with these changes?"
+4. **Omit** — If no issue, proceed without a commit trailer
 
 ## Process:
 
@@ -68,7 +70,7 @@ Determine the associated issue ID in this order:
    - Identify which files belong together
    - **Auto-detect the commit type** from the diff using the types above
    - Draft messages following the Commit Message Format template
-   - Include the `Delivers` trailer on the first commit only if an issue ID was resolved
+   - Include the commit trailer on the first commit only if an issue ID was resolved
 
 3. **Present your plan to the user:**
    - List the files you plan to add for each commit
@@ -85,4 +87,4 @@ Determine the associated issue ID in this order:
 - Group related changes into atomic commits
 - Titles: imperative mood, capitalised, no trailing period, English only
 - Bodies: explain *why*, not just *what*
-- Include the `Delivers` trailer on the first commit when an issue ID was found
+- Include the commit trailer on the first commit when an issue ID was found

.opencode/command/execute.md

@@ -1,5 +1,5 @@
 ---
-description: Execute an implementation plan from a Linear issue. Provide a Linear issue ID as the argument. Best run in a new session.
+description: Execute an implementation plan from an issue. Provide an issue ID as the argument. Best run in a new session.
 ---
 
 # Implement Plan
@@ -71,15 +71,15 @@ Remember: You're implementing a solution, not just checking boxes. Keep the end
 
 ## Steps
 
-1. **Check status-ticket label and fetch all context from Linear:**
-   - Call `linear_get_issue` with the provided issue ID
-   - Inspect the `labels[]` array. If the `status-ticket` group value is NOT `planned`, surface this to the user:
-     > "The status-ticket label is currently `{value}`, not `planned`. Execution is intended to run after planning. Do you want to proceed anyway?"
-   - Wait for explicit confirmation before continuing if the label is not `planned`
+1. **Check status and fetch all context:**
+   - Retrieve the issue using the provided issue ID
+   - If the status is not 'planned', surface this to the user:
+     > "The issue status is currently '{status}', not 'planned'. Execution is intended to run after planning. Do you want to proceed anyway?"
+   - Wait for explicit confirmation before continuing if the status is not 'planned'
    - Read the issue `description` field — this is the ticket content
-   - Fetch all documents linked to the issue:
-      - Call `linear_list_documents` with the issue ID to list documents associated with it
-      - For each document, call `linear_get_document` with the document `id` to retrieve its content
+   - Fetch all documents linked to the issue following the PM skill's document retrieval pattern:
+      - List all documents for the issue
+      - Retrieve each document's full content
    - **Identify the plan document** by finding the document whose `title` starts with `"Plan:"`.
       - If NO such document exists, **stop immediately** and inform the user:
         > "No plan document was found on issue {issue_id}. Cannot proceed with execution. Please run /plan first."
@@ -111,20 +111,14 @@ Remember: You're implementing a solution, not just checking boxes. Keep the end
    - Discoveries made during implementation
    - Decisions taken that differ from the plan
 
-   At the end of execution, create a Linear document for the execution notes:
-   - Call `linear_create_document` with:
-      - `issue`: the Linear issue ID
-      - `title`: `"Execution Notes: {issue_id}"`
-      - `content`: the full markdown content of the execution notes file
+   At the end of execution, create a document for the issue following the PM skill's document creation pattern:
+   - Title: `"Execution Notes: {issue_id}"`
+   - Content: the full markdown content of the execution notes file
 
 7. **Handle any mismatches or issues** by presenting them clearly and asking for guidance if needed.
 
-8. **Set status-ticket label to 'implemented':**
-   Using the label preservation protocol:
-   1. Call `linear_get_issue` to get the current `labels[]` array
-   2. Remove any existing `status-ticket` group value
-   3. Append `"implemented"` to the array
-   4. Call `linear_save_issue` with the full updated labels array
+8. **Set status to 'implemented':**
+   Update the status to 'implemented' following the status update protocol in the PM skill.
 
 Use the todowrite tool to create a structured task list for the 8 steps above, marking each as pending initially. Note that Step 3 may expand into multiple implementation subtasks derived from the plan.
 

.opencode/command/plan.md

@@ -1,5 +1,5 @@
 ---
-description: Create an implementation plan from a Linear issue. Provide a Linear issue ID as the argument. Best run in a new session.
+description: Create an implementation plan from an issue. Provide an issue ID as the argument. Best run in a new session.
 ---
 
 # Implementation Plan
@@ -10,17 +10,17 @@ You are tasked with creating detailed implementation plans through an interactiv
 
 ### Step 1: Context Gathering & Initial Analysis
 
-1. **Check status-ticket label and fetch all context from Linear:**
-   - Call `linear_get_issue` with the provided issue ID
-   - Inspect the `labels[]` array. If the `status-ticket` group value is NOT `researched`, surface this to the user:
-     > "The status-ticket label is currently `{value}`, not `researched`. Planning is intended to run after research. Do you want to proceed anyway?"
-   - Wait for explicit confirmation before continuing if the label is not `researched`
+1. **Check status and fetch all context:**
+   - Retrieve the issue using the provided issue ID
+   - If the status is not 'researched', surface this to the user:
+     > "The issue status is currently '{status}', not 'researched'. Planning is intended to run after research. Do you want to proceed anyway?"
+   - Wait for explicit confirmation before continuing if the status is not 'researched'
    - Read the issue `description` field — this is the ticket content
-   - Fetch all documents linked to the issue:
-      - Call `linear_list_documents` with the issue ID to list documents associated with it
-      - For each document, call `linear_get_document` with the document `id` to retrieve its content
+   - Fetch all documents linked to the issue following the PM skill's document retrieval pattern:
+      - List all documents for the issue
+      - Retrieve each document's full content
       - Treat all documents as context (research documents, prior artefacts)
-    - **IMPORTANT**: Do not read any local `thoughts/` files as inputs. Linear is the sole source of truth.
+    - **IMPORTANT**: Do not read any local `thoughts/` files as inputs. The project management tool is the sole source of truth.
     - **Detect pathway context:**
       - Load the workbench-context skill: `skill({ name: 'workbench-context' })`
       - Check if `.workbench/config.yaml` exists in the repository root
@@ -154,11 +154,9 @@ After structure approval:
 1. **Write the plan** to `thoughts/plans/{issue_id}_{descriptive_name}.md`
    (e.g. `thoughts/plans/PAP-7003_amend_agentic_commands.md`)
 
-   After writing the local file, **create a Linear document for the issue**:
-   - Call `linear_create_document` with:
-      - `issue`: the Linear issue ID
-      - `title`: `"Plan: {issue_id} - {descriptive_name}"`
-      - `content`: the full markdown content of the plan
+   After writing the local file, **create a document for the issue** following the PM skill's document creation pattern:
+   - Title: `"Plan: {issue_id} - {descriptive_name}"`
+   - Content: the full markdown content of the plan
 
    This file is a convenience copy only — downstream commands must not read it as input.
 
@@ -252,7 +250,7 @@ After structure approval:
 
 ## References
 
-- Linear issue: `{issue_id}` — https://linear.app/.../{issue_id}
+- Issue: `{issue_id}` — see the PM skill for issue URL format
 - Research document: see issue documents titled `"Research: {issue_id} - ..."`
 ```
 
@@ -278,13 +276,9 @@ After structure approval:
 
 4. **Continue refining** until the user is satisfied
 
-### Step 6: Set status-ticket label to 'planned'
+### Step 6: Set status to 'planned'
 
-Using the label preservation protocol:
-1. Call `linear_get_issue` to get the current `labels[]` array
-2. Remove any existing `status-ticket` group value
-3. Append `"planned"` to the array
-4. Call `linear_save_issue` with the full updated labels array
+Update the status to 'planned' following the status update protocol in the PM skill.
 
 Use the todowrite tool to create a structured task list for the 6 steps above, marking each as pending initially.
 

.opencode/command/research.md

@@ -1,22 +1,22 @@
 ---
-description: Research a Linear issue. Provide a Linear issue ID as the argument. Best run in a new session.
+description: Research an issue. Provide an issue ID as the argument. Best run in a new session.
 ---
 
 # Research Codebase
 
 You are tasked with conducting comprehensive research across the codebase to answer user questions by spawning tasks and synthesizing their findings.
 
-The user will provide a Linear issue ID. You will fetch the ticket from Linear and research the codebase accordingly.
+The user will provide an issue ID. You will fetch the ticket and research the codebase accordingly.
 
 ## Steps to follow after receiving the research query:
 
-1. **Check status-ticket label and fetch the ticket:**
-   - Call `linear_get_issue` with the provided issue ID
-   - Inspect the `labels[]` array. If the `status-ticket` group value is NOT `open`, surface this to the user:
-     > "The status-ticket label is currently `{value}`, not `open`. Research is intended to run after the ticket phase. Do you want to proceed anyway?"
-   - Wait for explicit confirmation before continuing if the label is not `open`
+1. **Check status and fetch the ticket:**
+   - Retrieve the issue using the provided issue ID
+   - If the status is not 'open', surface this to the user:
+     > "The issue status is currently '{status}', not 'open'. Research is intended to run after the ticket phase. Do you want to proceed anyway?"
+   - Wait for explicit confirmation before continuing if the status is not 'open'
    - Read the issue `description` field — this is the ticket content
-    - **IMPORTANT**: Do not read the ticket from any local file. The Linear issue description is the sole source of truth.
+    - **IMPORTANT**: Do not read the ticket from any local file. The issue description in the project management tool is the sole source of truth.
     - **Detect pathway context:**
       - Load the workbench-context skill: `skill({ name: 'workbench-context' })`
       - Check if `.workbench/config.yaml` exists in the repository root
@@ -90,7 +90,7 @@ Use the following metadata for the research document body:
 
 6. **Generate research document:**
    - Filename: `thoughts/research/{issue_id}_{topic}.md`
-     (e.g. `thoughts/research/PAP-7003_linear_integration.md`)
+     (e.g. `thoughts/research/PAP-7003_pm_integration.md`)
    - Write the local file using the Write tool
    - Structure WITHOUT YAML frontmatter — use a Metadata section in the body:
 
@@ -127,11 +127,9 @@ Use the following metadata for the research document body:
      [Areas needing further investigation]
      ```
 
-   - After writing the local file, **create a Linear document for the issue**:
-      - Call `linear_create_document` with:
-         - `issue`: the Linear issue ID
-         - `title`: `"Research: {issue_id} - {topic}"`
-         - `content`: the full markdown content of the research document
+   - After writing the local file, **create a document for the issue** following the PM skill's document creation pattern:
+      - Title: `"Research: {issue_id} - {topic}"`
+      - Content: the full markdown content of the research document
 
 7. **Present findings:**
    - Present a concise summary of findings to the user
@@ -142,16 +140,13 @@ Use the following metadata for the research document body:
    - If the user has follow-up questions, conduct additional research and produce a new document
    - Use a sequenced filename: `{issue_id}_{topic}_part2.md`, `_part3.md`, etc.
    - Write the new local file to `thoughts/research/`
-   - Create a new Linear document for the issue (never update existing documents):
-      - Call `linear_create_document` with `issue`, `title`: `"Research: {issue_id} - {topic} (part N)"`, and `content`
-   - Do NOT use any prior local research file as input — always fetch context from the Linear issue and its documents
-
-9. **Set status-ticket label to 'researched':**
-   Using the label preservation protocol:
-   1. Call `linear_get_issue` to get the current `labels[]` array
-   2. Remove any existing `status-ticket` group value
-   3. Append `"researched"` to the array
-   4. Call `linear_save_issue` with the full updated labels array
+   - Create a new document for the issue (never update existing documents) following the PM skill's document creation pattern:
+      - Title: `"Research: {issue_id} - {topic} (part N)"`
+      - Content: the new research content
+   - Do NOT use any prior local research file as input — always fetch context from the issue and its documents
+
+9. **Set status to 'researched':**
+   Update the status to 'researched' following the status update protocol in the PM skill.
 
 Use the todowrite tool to create a structured task list for the 9 steps above, marking each as pending initially.
 

.opencode/command/review.md

@@ -1,26 +1,26 @@
 ---
-description: Review the execution of a Linear issue's plan. Provide a Linear issue ID as the argument. Best run after execution is complete.
+description: Review the execution of an issue's plan. Provide an issue ID as the argument. Best run after execution is complete.
 ---
 
 # Review Plan
 
 You are tasked with validating that an implementation plan was correctly executed, verifying all success criteria and identifying any deviations or issues.
 
-You will be given a Linear issue ID. You will fetch the ticket, plan, and execution notes from Linear and validate that the implementation matches the plan.
+You will be given an issue ID. You will fetch the ticket, plan, and execution notes and validate that the implementation matches the plan.
 
 ## Validation Process
 
 ### Step 1: Context Discovery
 
-1. **Check status-ticket label and fetch all context from Linear:**
-   - Call `linear_get_issue` with the provided issue ID
-   - Inspect the `labels[]` array. If the `status-ticket` group value is NOT `implemented`, surface this to the user:
-     > "The status-ticket label is currently `{value}`, not `implemented`. Review is intended to run after execution. Do you want to proceed anyway?"
-   - Wait for explicit confirmation before continuing if the label is not `implemented`
+1. **Check status and fetch all context:**
+   - Retrieve the issue using the provided issue ID
+   - If the status is not 'implemented', surface this to the user:
+     > "The issue status is currently '{status}', not 'implemented'. Review is intended to run after execution. Do you want to proceed anyway?"
+   - Wait for explicit confirmation before continuing if the status is not 'implemented'
    - Read the issue `description` field — this is the ticket content
-   - Fetch all documents linked to the issue:
-      - Call `linear_list_documents` with the issue ID to list documents associated with it
-      - For each document, call `linear_get_document` with the document `id` to retrieve its content
+   - Fetch all documents linked to the issue following the PM skill's document retrieval pattern:
+      - List all documents for the issue
+      - Retrieve each document's full content
    - Identify key documents by their `title` prefix:
      - Plan: `title` starts with `"Plan:"`
      - Execution Notes: `title` starts with `"Execution Notes:"`
@@ -79,11 +79,9 @@ Create comprehensive validation summary and:
    (e.g. `thoughts/reviews/PAP-7003_amend_agentic_commands_review.md`)
    This is a convenience copy only — it must not be used as input by any command.
 
-   2. **Create a Linear document for the issue**:
-      - Call `linear_create_document` with:
-         - `issue`: the Linear issue ID
-         - `title`: `"Review: {issue_id} - {plan_name}"`
-         - `content`: the full markdown content of the review
+   2. **Create a document for the issue** following the PM skill's document creation pattern:
+      - Title: `"Review: {issue_id} - {plan_name}"`
+      - Content: the full markdown content of the review
 
 Use this report structure:
 
@@ -136,13 +134,9 @@ Use this report structure:
 - Document new API endpoints
 ```
 
-### Step 4: Set status-ticket label to 'reviewed'
+### Step 4: Set status to 'reviewed'
 
-Using the label preservation protocol:
-1. Call `linear_get_issue` to get the current `labels[]` array
-2. Remove any existing `status-ticket` group value
-3. Append `"reviewed"` to the array
-4. Call `linear_save_issue` with the full updated labels array
+Update the status to 'reviewed' following the status update protocol in the PM skill.
 
 Use the todowrite tool to create a structured task list for the 4 steps above, marking each as pending initially.