diff --git a/.opencode/command/commit.md b/.opencode/command/commit.md index 2509b1b..93466f8 100644 --- a/.opencode/command/commit.md +++ b/.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 diff --git a/.opencode/command/execute.md b/.opencode/command/execute.md index 5542d95..9075794 100644 --- a/.opencode/command/execute.md +++ b/.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. diff --git a/.opencode/command/plan.md b/.opencode/command/plan.md index fa18962..7ecd807 100644 --- a/.opencode/command/plan.md +++ b/.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. diff --git a/.opencode/command/research.md b/.opencode/command/research.md index 06feb81..b4044cf 100644 --- a/.opencode/command/research.md +++ b/.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. diff --git a/.opencode/command/review.md b/.opencode/command/review.md index 87aa706..adefffe 100644 --- a/.opencode/command/review.md +++ b/.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. diff --git a/.opencode/command/ticket.md b/.opencode/command/ticket.md index b0e7e7b..4ff6d3f 100644 --- a/.opencode/command/ticket.md +++ b/.opencode/command/ticket.md @@ -1,5 +1,5 @@ --- -description: Creates a structured ticket for a Linear issue. Provide a Linear issue ID as the argument. +description: Creates a structured ticket for an issue. Provide an issue ID as the argument. --- # Create Ticket @@ -11,10 +11,10 @@ You create well-structured tickets that provide maximum context for downstream r ## Process Overview -### Step 1: Read the Linear Issue +### Step 1: Read the Issue -1. Call `linear_get_issue` with the provided issue ID to fetch the issue title, description, and current labels. -2. If the issue has a parent, call `linear_get_issue` on the parent ID to read the parent description for broader context. Do not duplicate parent-level content in the ticket — use it only to understand the wider scope. +1. Retrieve the issue using the provided issue ID to fetch the issue title, description, and current labels. +2. If the issue has a parent, retrieve the parent issue to read the parent description for broader context. Do not duplicate parent-level content in the ticket — use it only to understand the wider scope. 3. Use the fetched content as the starting context for the Q&A. The existing issue description (if any) is the raw input from the user; treat it as prior context, not the final ticket. 4. **Detect pathway context:** - Load the workbench-context skill: `skill({ name: 'workbench-context' })` @@ -164,8 +164,7 @@ Once the Q&A and scope exploration are complete: - [ ] [Manual test step] ``` -2. **Overwrite the Linear issue description** with the full ticket content: - - Call `linear_save_issue` with `id: {issue_id}` and `description: {full ticket content}` +2. **Overwrite the issue description** with the full ticket content following the PM skill's tool mapping. 3. **Save a local convenience copy** to `thoughts/tickets/{issue_id}_{subject}.md` using the Write tool. This file must never be used as an input by any downstream command. @@ -177,13 +176,9 @@ Before finalizing: 3. **Confirm research hooks**: Verify keywords and patterns will be useful for research 4. **Check scope**: Ensure the ticket is atomic and well-scoped -### Step 7: Set status-ticket label to 'open' +### Step 7: Set status to 'open' -Using the label preservation protocol: -1. Call `linear_get_issue` to get the current `labels[]` array -2. Remove any existing `status-ticket` group value (open/researched/planned/implemented/reviewed) -3. Append `"open"` to the array -4. Call `linear_save_issue` with `labels: [, "open"]` +Update the status to 'open' following the status update protocol in the PM skill. Use the todowrite tool to create a structured task list for the 7 steps above, marking each as pending initially. diff --git a/.opencode/skill/linear/SKILL.md b/.opencode/skill/linear/SKILL.md new file mode 100644 index 0000000..0489fb3 --- /dev/null +++ b/.opencode/skill/linear/SKILL.md @@ -0,0 +1,113 @@ +--- +name: linear +description: Linear project management integration. Provides tool mappings, status protocols, document operations, and workflow patterns for Linear. Load this skill when the configured project management tool is 'linear'. +--- + +# Linear Project Management Skill + +All project management operations use Linear MCP tools. This skill maps generic operations to Linear-specific tool calls and defines protocol patterns for common workflows. + +## Critical Rules + +1. **The issue description on Linear is the sole source of truth.** Do not read local `thoughts/` files as inputs — they are convenience copies only. +2. **Never update existing documents.** Always create new ones for follow-ups. +3. **Preserve non-status labels** when updating issue status. Never remove labels that are not part of the status-ticket group. +4. **Content is literal Markdown.** When creating documents or updating descriptions, use literal newlines and special characters — do not escape them. + +## Tool Mapping + +| Generic Operation | Linear Tool Call | +|---|---| +| Retrieve an issue | `linear_get_issue({ id: "{issue_id}" })` | +| Retrieve an issue with relations | `linear_get_issue({ id: "{issue_id}", includeRelations: true })` | +| Update an issue | `linear_save_issue({ id: "{issue_id}", ...fields })` | +| Overwrite issue description | `linear_save_issue({ id: "{issue_id}", description: "{content}" })` | +| Update issue labels | `linear_save_issue({ id: "{issue_id}", labels: ["{label1}", "{label2}"] })` | +| List documents for an issue | Retrieve the issue — the response includes an associated `documents` array with `id` and `title` for each | +| Retrieve a document | `linear_get_document({ id: "{document_id}" })` | +| Create a document | `linear_create_document({ issue: "{issue_id}", title: "{title}", content: "{content}" })` | + +## Status Management + +### Status Values + +The status lifecycle follows this order: + +`open → researched → planned → implemented → reviewed` + +These values correspond to the `status-ticket` label group in Linear. + +### Status Guard + +Before performing a workflow operation, verify the issue has the expected status: + +1. Retrieve the issue using the issue ID +2. Inspect the `labels[]` array for the `status-ticket` group value +3. If the status does not match the expected value, surface a warning: + > "The issue status is currently `{status}`, not `{expected}`. {Operation} is intended to run after {previous step}. Do you want to proceed anyway?" +4. Wait for explicit confirmation before continuing if the status is not as expected + +### Label Preservation Protocol + +When updating the issue status: + +1. Retrieve the issue to get the current `labels[]` array +2. Remove any existing `status-ticket` group value (`open`, `researched`, `planned`, `implemented`, `reviewed`) +3. Append the new status value to the labels array +4. Update the issue: `linear_save_issue({ id: "{issue_id}", labels: ["{preserved_label_1}", "{preserved_label_2}", "{new_status}"] })` + +**Example**: Issue has labels `["researched", "Improvement"]`. Setting status to `"planned"`: +- Remove `"researched"` (current status) +- Keep `"Improvement"` (non-status label) +- Append `"planned"` +- Result: `linear_save_issue({ id: "PAP-7018", labels: ["Improvement", "planned"] })` + +## Document Operations + +### Creating Documents + +Use `linear_create_document` with: +- `issue`: the issue ID (e.g., `"PAP-7018"`) +- `title`: the document title (e.g., `"Research: PAP-7018 - Topic Name"`) +- `content`: the full Markdown content — use literal newlines and special characters, not escape sequences + +Rules: +- Never update existing documents — always create new ones +- Follow-up documents use titles like `"Research: {issue_id} - {topic} (part N)"` + +### Fetching Documents + +1. Retrieve the issue to get the list of associated documents (the response includes a `documents` array with `id` and `title` for each) +2. For each document, call `linear_get_document` with the document `id` to retrieve full content + +Document identification by title prefix: +- `"Research:"` — research documents +- `"Plan:"` — implementation plans +- `"Execution Notes:"` — execution notes +- `"Review:"` — review documents + +## Issue References + +### Issue URL + +Format: `https://linear.app/plan-and-publish/issue/{issue_id}/{slug}` + +Use this format when referencing issues in documents or plans. + +### Commit Trailer + +Format: `Delivers {issue_id}` + +Example: +``` + +Delivers PAP-7018 + +``` + +This creates bidirectional links in the Linear UI between the commit and the issue. Include this trailer on the first commit only when an issue ID is associated with the changes. + +### Issue ID in Branch Names + +Extract the issue ID from the branch name by matching the `{PREFIX}-{NUMBER}` segment. +Example: `feature/pap-7024-desc` → `PAP-7024` (normalised to uppercase). diff --git a/.opencode/skill/workbench-context/SKILL.md b/.opencode/skill/workbench-context/SKILL.md index e52ca15..febef30 100644 --- a/.opencode/skill/workbench-context/SKILL.md +++ b/.opencode/skill/workbench-context/SKILL.md @@ -26,6 +26,19 @@ This is a presence-only check. Do not parse or read `config.yaml`. 2. If found, run `ck --status` to verify index readiness 3. On any failure: warn the user and continue with grep/glob only (graceful degradation — never block execution) +## Project Management Configuration + +When the command involves project management operations (retrieving issues, updating statuses, creating documents, commit trailers), configure the PM tool: + +1. Read `.workbench/settings.yml` to determine the configured project management tool +2. If the file is missing or the `project_management` field is absent, stop with error: + > "No project management tool configured. Add `project_management: ` to `.workbench/settings.yml`" +3. The field value is the name of the PM skill to load +4. Load the corresponding PM skill: `skill({ name: '' })` +5. The PM skill provides tool mappings, protocols, and workflow patterns for all PM operations + +If the command does not involve project management operations, skip this step. + ## Context Passing Format After detecting pathway and checking ck availability, include the appropriate context block in every spawned agent's prompt. diff --git a/.workbench/schemas/settings.json b/.workbench/schemas/settings.json new file mode 100644 index 0000000..de0410a --- /dev/null +++ b/.workbench/schemas/settings.json @@ -0,0 +1,15 @@ +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "title": "Workbench Settings", + "description": "Configuration for workbench project management and tooling", + "type": "object", + "properties": { + "project_management": { + "description": "The project management tool to use for issue tracking and workflow management", + "type": "string", + "enum": ["linear"] + } + }, + "required": ["project_management"], + "additionalProperties": false +} diff --git a/.workbench/settings.yml b/.workbench/settings.yml new file mode 100644 index 0000000..358446f --- /dev/null +++ b/.workbench/settings.yml @@ -0,0 +1,2 @@ +# yaml-language-server: $schema=./schemas/settings.json +project_management: linear diff --git a/packages/workbench-cli/src/index.ts b/packages/workbench-cli/src/index.ts index 97f786a..7662b36 100644 --- a/packages/workbench-cli/src/index.ts +++ b/packages/workbench-cli/src/index.ts @@ -118,7 +118,7 @@ async function runNonInteractiveInit(args: CliArgs): Promise { process.exit(1) } - if (existsSync(".workbench")) { + if (existsSync(".workbench/config.yaml")) { console.error(".workbench/ already exists") process.exit(1) } @@ -211,7 +211,7 @@ async function runNonInteractiveInitCmd(args: CliArgs): Promise { process.exit(0) } - if (existsSync(".workbench")) { + if (existsSync(".workbench/config.yaml")) { console.error(".workbench/ already exists") process.exit(1) }