conductor-4-all 0.0.17 → 0.0.19

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (4) hide show
  1. package/dist/templates/commands/implement.toml +0 -3
  2. package/dist/templates/commands/newTrack.toml +0 -2
  3. package/dist/templates/commands/setup.toml +59 -59
  4. package/package.json +4 -1
package/dist/templates/commands/implement.toml CHANGED
@@ -117,7 +117,6 @@ CRITICAL: You must validate the success of every tool call. If any tool call fai
117
117
  b. **Update Product Definition:**
118
118
  i. **Condition for Update:** Based on your analysis, you MUST determine if the completed feature or bug fix significantly impacts the description of the product itself.
119
119
  ii. **Propose and Confirm Changes:** If an update is needed:
120
- - **Announce:** Briefly state that updates are proposed. Do NOT repeat the request to review in the chat.
121
120
  - **Ask for Approval:** Use the `ask_user` tool to request confirmation. You MUST embed the proposed updates (in a diff format) directly into the `question` field so the user can review them in context.
122
121
  - **questions:**
123
122
  - **header:** "Product"
@@ -132,7 +131,6 @@ CRITICAL: You must validate the success of every tool call. If any tool call fai
132
131
  c. **Update Tech Stack:**
133
132
  i. **Condition for Update:** Similarly, you MUST determine if significant changes in the technology stack are detected as a result of the completed track.
134
133
  ii. **Propose and Confirm Changes:** If an update is needed:
135
- - **Announce:** Briefly state that updates are proposed. Do NOT repeat the request to review in the chat.
136
134
  - **Ask for Approval:** Use the `ask_user` tool to request confirmation. You MUST embed the proposed updates (in a diff format) directly into the `question` field so the user can review them in context.
137
135
  - **questions:**
138
136
  - **header:** "Tech Stack"
@@ -148,7 +146,6 @@ CRITICAL: You must validate the success of every tool call. If any tool call fai
148
146
  i. **CRITICAL WARNING:** This file defines the core identity and communication style of the product. It should be modified with extreme caution and ONLY in cases of significant strategic shifts, such as a product rebrand or a fundamental change in user engagement philosophy. Routine feature updates or bug fixes should NOT trigger changes to this file.
149
147
  ii. **Condition for Update:** You may ONLY propose an update to this file if the track's **Specification** explicitly describes a change that directly impacts branding, voice, tone, or other core product guidelines.
150
148
  iii. **Propose and Confirm Changes:** If the conditions are met:
151
- - **Announce:** Briefly state that updates are proposed. Do NOT repeat the request to review in the chat.
152
149
  - **Ask for Approval:** Use the `ask_user` tool to request confirmation. You MUST embed the proposed changes (in a diff format) directly into the `question` field, including a clear warning.
153
150
  - **questions:**
154
151
  - **header:** "Product"
package/dist/templates/commands/newTrack.toml CHANGED
@@ -80,7 +80,6 @@ CRITICAL: You must validate the success of every tool call. If any tool call fai
80
80
  3. **Draft `spec.md`:** Once sufficient information is gathered, draft the content for the track's `spec.md` file, including sections like Overview, Functional Requirements, Non-Functional Requirements (if any), Acceptance Criteria, and Out of Scope.
81
81
 
82
82
  4. **User Confirmation:**
83
- - **Announce:** Briefly state that the draft is ready (e.g., "Draft generated."). Do NOT repeat the request to "review" or "approve" in the chat.
84
83
  - **Ask for Approval:** Use the `ask_user` tool to request confirmation. You MUST embed the drafted content directly into the `question` field so the user can review it in context.
85
84
  - **questions:**
86
85
  - **header:** "Confirm Spec"
@@ -113,7 +112,6 @@ CRITICAL: You must validate the success of every tool call. If any tool call fai
113
112
  * **CRITICAL: Inject Phase Completion Tasks.** Determine if a "Phase Completion Verification and Checkpointing Protocol" is defined in the **Workflow**. If this protocol exists, then for each **Phase** that you generate in `plan.md`, you MUST append a final meta-task to that phase. The format for this meta-task is: `- [ ] Task: Conductor - User Manual Verification '<Phase Name>' (Protocol in workflow.md)`.
114
113
 
115
114
  3. **User Confirmation:**
116
- - **Announce:** Briefly state that the draft is ready (e.g., "Draft generated."). Do NOT repeat the request to "review" or "approve" in the chat.
117
115
  - **Ask for Approval:** Use the `ask_user` tool to request confirmation. You MUST embed the drafted content directly into the `question` field so the user can review it in context.
118
116
  - **questions:**
119
117
  - **header:** "Confirm Plan"
package/dist/templates/commands/setup.toml CHANGED
@@ -5,8 +5,6 @@ You are an AI agent. Your primary function is to set up and manage a software pr
5
5
 
6
6
  CRITICAL: You must validate the success of every tool call. If any tool call fails, you MUST halt the current operation immediately, announce the failure to the user, and await further instructions.
7
7
 
8
- CRITICAL: When determining model complexity, ALWAYS select the "flash" model, regardless of the task's perceived difficulty.
9
-
10
8
  ---
11
9
 
12
10
  ## 1.1 PRE-INITIALIZATION OVERVIEW
@@ -22,30 +20,38 @@ CRITICAL: When determining model complexity, ALWAYS select the "flash" model, re
22
20
 
23
21
  ---
24
22
 
25
- ## 1.2 BEGIN `RESUME` CHECK
26
- **PROTOCOL: Before starting the setup, determine the project's state using the state file.**
23
+ ## 1.2 PROJECT AUDIT
24
+ **PROTOCOL: Before starting the setup, determine the project's state by auditing existing artifacts.**
25
+
26
+ 1. **Announce Audit:** Inform the user that you are auditing the project for any existing Conductor configuration.
27
27
 
28
- 1. **Read State File:** Check for the existence of `conductor/setup_state.json`.
29
- - If it does not exist, this is a new project setup. Proceed directly to Step 1.2.
30
- - If it exists, read its content.
28
+ 2. **Audit Artifacts:** Check the file system for the existence of the following files/directories in the `conductor/` directory:
29
+ - `product.md`
30
+ - `product-guidelines.md`
31
+ - `tech-stack.md`
32
+ - `code_styleguides/`
33
+ - `workflow.md`
34
+ - `index.md`
35
+ - `tracks/*/` (specifically `plan.md` and `index.md`)
31
36
 
32
- 2. **Resume Based on State:**
33
- - Let the value of `last_successful_step` in the JSON file be `STEP`.
34
- - Based on the value of `STEP`, jump to the **next logical section**:
37
+ 3. **Determine Target Section:** Map the project's state to a target section using the priority table below (highest match wins). **DO NOT JUMP YET.** Keep this target in mind.
35
38
 
36
- - If `STEP` is "2.1_product_guide", announce "Resuming setup: The Product Guide (`product.md`) is already complete. Next, we will create the Product Guidelines." and proceed to **Section 2.2**.
37
- - If `STEP` is "2.2_product_guidelines", announce "Resuming setup: The Product Guide and Product Guidelines are complete. Next, we will define the Technology Stack." and proceed to **Section 2.3**.
38
- - If `STEP` is "2.3_tech_stack", announce "Resuming setup: The Product Guide, Guidelines, and Tech Stack are defined. Next, we will select Code Styleguides." and proceed to **Section 2.4**.
39
- - If `STEP` is "2.4_code_styleguides", announce "Resuming setup: All guides and the tech stack are configured. Next, we will define the project workflow." and proceed to **Section 2.5**.
40
- - If `STEP` is "2.5_workflow", announce "Resuming setup: The initial project scaffolding is complete. Next, we will generate the first track." and proceed to **Phase 2 (3.0)**.
41
- - If `STEP` is "3.3_initial_track_generated":
42
- - Announce: "The project has already been initialized. You can create a new track with `/conductor:newTrack` or start implementing existing tracks with `/conductor:implement`."
43
- - Halt the `setup` process.
44
- - If `STEP` is unrecognized, announce an error and halt.
39
+ | Artifact Exists | Target Section | Announcement |
40
+ | :--- | :--- | :--- |
41
+ | All files in `tracks/<track_id>/` (`spec`, `plan`, `metadata`, `index`) | **HALT** | "The project is already initialized. Use `/conductor:newTrack` or `/conductor:implement`." |
42
+ | `index.md` (top-level) | **Section 3.0** | "Resuming setup: Scaffolding is complete. Next: generate the first track. (Note: If an incomplete track folder was detected, we will restart this step to ensure a clean, consistent state)." |
43
+ | `workflow.md` | **Section 2.6** | "Resuming setup: Workflow is defined. Next: generate project index." |
44
+ | `code_styleguides/` | **Section 2.5** | "Resuming setup: Guides/Tech Stack configured. Next: define project workflow." |
45
+ | `tech-stack.md` | **Section 2.4** | "Resuming setup: Tech Stack defined. Next: select Code Styleguides." |
46
+ | `product-guidelines.md` | **Section 2.3** | "Resuming setup: Guidelines are complete. Next: define the Technology Stack." |
47
+ | `product.md` | **Section 2.2** | "Resuming setup: Product Guide is complete. Next: create Product Guidelines." |
48
+ | (None) | **Section 2.0** | (None) |
49
+
50
+ 4. **Proceed to Section 2.0:** You MUST proceed to Section 2.0 to establish the Greenfield/Brownfield context before jumping to your target.
45
51
 
46
52
  ---
47
53
 
48
- ## 2.0 PHASE 1: STREAMLINED PROJECT SETUP
54
+ ## 2.0 STREAMLINED PROJECT SETUP
49
55
  **PROTOCOL: Follow this sequence to perform a guided, interactive setup with the user.**
50
56
 
51
57
 
@@ -53,17 +59,25 @@ CRITICAL: When determining model complexity, ALWAYS select the "flash" model, re
53
59
  1. **Detect Project Maturity:**
54
60
  - **Classify Project:** Determine if the project is "Brownfield" (Existing) or "Greenfield" (New) based on the following indicators:
55
61
  - **Brownfield Indicators:**
56
- - Check for existence of version control directories: `.git`, `.svn`, or `.hg`.
57
- - If a `.git` directory exists, execute `git status --porcelain`. If the output is not empty, classify as "Brownfield" (dirty repository).
58
- - Check for dependency manifests: `package.json`, `pom.xml`, `requirements.txt`, `go.mod`.
59
- - Check for source code directories: `src/`, `app/`, `lib/` containing code files.
60
- - If ANY of the above conditions are met (version control directory, dirty git repo, dependency manifest, or source code directories), classify as **Brownfield**.
62
+ - Check for dependency manifests: `package.json`, `pom.xml`, `requirements.txt`, `go.mod`, `Cargo.toml`.
63
+ - Check for source code directories: `src/`, `app/`, `lib/`, `bin/` containing code files.
64
+ - If a `.git` directory exists, execute `git status --porcelain`. Ignore changes within the `conductor/` directory. If there are *other* uncommitted changes, it may be Brownfield.
65
+ - If ANY of the primary indicators (manifests or source code directories) are found, classify as **Brownfield**.
61
66
  - **Greenfield Condition:**
62
- - Classify as **Greenfield** ONLY if NONE of the "Brownfield Indicators" are found AND the current directory is empty or contains only generic documentation (e.g., a single `README.md` file) without functional code or dependencies.
67
+ - Classify as **Greenfield** ONLY if:
68
+ 1. NONE of the "Brownfield Indicators" are found.
69
+ 2. The directory contains no application source code or dependency manifests (ignoring the `conductor/` directory, a clean or newly initialized `.git` folder, and a `README.md`).
70
+
63
71
 
64
- 2. **Execute Workflow based on Maturity:**
72
+ 2. **Resume Fast-Forward Check:**
73
+ - If the **Target Section** (from 1.2) is anything other than "Section 2.0":
74
+ - Announce the project maturity (Greenfield/Brownfield) and **briefly state the reason** (e.g., "A Greenfield project was detected because no application code exists"). Then announce the target section.
75
+ - **IMMEDIATELY JUMP** to the Target Section. Do not execute the rest of Section 2.0.
76
+ - If the Target Section is "Section 2.0", proceed to step 3.
77
+
78
+ 3. **Execute Workflow based on Maturity:**
65
79
  - **If Brownfield:**
66
- - Announce that an existing project has been detected.
80
+ - Announce that an existing project has been detected, and **briefly state the specific indicator you found** (e.g., "because I found a `package.json` file"). Be concise.
67
81
  - If the `git status --porcelain` command (executed as part of Brownfield Indicators) indicated uncommitted changes, inform the user: "WARNING: You have uncommitted changes in your Git repository. Please commit or stash your changes before proceeding, as Conductor will be making modifications."
68
82
  - **Begin Brownfield Project Initialization Protocol:**
69
83
  - **1.0 Pre-analysis Confirmation:**
@@ -97,13 +111,13 @@ CRITICAL: When determining model complexity, ALWAYS select the "flash" model, re
97
111
  4. **Infer Project Goal:** Summarize the project's goal in one sentence based strictly on the provided `README.md` header or `package.json` description.
98
112
  - **Upon completing the brownfield initialization protocol, proceed to the Generate Product Guide section in 2.1.**
99
113
  - **If Greenfield:**
100
- - Announce that a new project will be initialized.
114
+ - Announce that new project will be initialized, briefly noting that no existing application code or dependencies were found.
101
115
  - Proceed to the next step in this file.
102
116
 
103
- 3. **Initialize Git Repository (for Greenfield):**
117
+ 4. **Initialize Git Repository (for Greenfield):**
104
118
  - If a `.git` directory does not exist, execute `git init` and report to the user that a new Git repository has been initialized.
105
119
 
106
- 4. **Inquire about Project Goal (for Greenfield):**
120
+ 5. **Inquire about Project Goal (for Greenfield):**
107
121
  - **Ask the user the following question using the `ask_user` tool and wait for their response before proceeding to the next step:**
108
122
  - **header:** "Project Goal"
109
123
  - **type:** "text"
@@ -112,11 +126,9 @@ CRITICAL: When determining model complexity, ALWAYS select the "flash" model, re
112
126
  - **CRITICAL: You MUST NOT execute any tool calls until the user has provided a response.**
113
127
  - **Upon receiving the user's response:**
114
128
  - Execute `mkdir -p conductor`.
115
- - **Initialize State File:** Immediately after creating the `conductor` directory, you MUST create `conductor/setup_state.json` with the exact content:
116
- `{"last_successful_step": ""}`
117
129
  - Write the user's response into `conductor/product.md` under a header named `# Initial Concept`.
118
130
 
119
- 5. **Continue:** Immediately proceed to the next section.
131
+ 6. **Continue:** Immediately proceed to the next section.
120
132
 
121
133
  ### 2.1 Generate Product Guide (Interactive)
122
134
  1. **Introduce the Section:** Announce that you will now help the user create the `product.md`.
@@ -148,10 +160,9 @@ CRITICAL: When determining model complexity, ALWAYS select the "flash" model, re
148
160
  - **If user chose "Autogenerate":** Use your best judgment to expand on the initial project goal and infer any missing details to create a comprehensive document.
149
161
  - **If user chose "Interactive":** Use the specific answers provided. The source of truth is **only the user's selected answer(s)**. You are encouraged to expand on these choices to create a polished output.
150
162
  5. **User Confirmation Loop:**
151
- - **Announce:** Briefly state that the draft is ready (e.g., "Draft generated."). Do NOT repeat the request to "review" or "approve" in the chat.
152
163
  - **Ask for Approval:** Use the `ask_user` tool to request confirmation. You MUST embed the drafted content directly into the `question` field so the user can review it in context.
153
164
  - **questions:**
154
- - **header:** "Review"
165
+ - **header:** "Review Draft"
155
166
  - **question:**
156
167
  Please review the drafted Product Guide below. What would you like to do next?
157
168
 
@@ -164,9 +175,7 @@ CRITICAL: When determining model complexity, ALWAYS select the "flash" model, re
164
175
  - Label: "Approve", Description: "The guide looks good, proceed to the next step."
165
176
  - Label: "Suggest changes", Description: "I want to modify the drafted content."
166
177
  6. **Write File:** Once approved, append the generated content to the existing `conductor/product.md` file, preserving the `# Initial Concept` section.
167
- 7. **Commit State:** Upon successful creation of the file, you MUST immediately write to `conductor/setup_state.json` with the exact content:
168
- `{"last_successful_step": "2.1_product_guide"}`
169
- 8. **Continue:** After writing the state file, immediately proceed to the next section.
178
+ 7. **Continue:** Immediately proceed to the next section.
170
179
 
171
180
  ### 2.2 Generate Product Guidelines (Interactive)
172
181
  1. **Introduce the Section:** Announce that you will now help the user create the `product-guidelines.md`.
@@ -198,10 +207,9 @@ CRITICAL: When determining model complexity, ALWAYS select the "flash" model, re
198
207
  - **If user chose "Autogenerate":** Use your best judgment to infer standard, high-quality guidelines suitable for the project type.
199
208
  - **If user chose "Interactive":** Use the specific answers provided. The source of truth is **only the user's selected answer(s)**. You are encouraged to expand on these choices to create a polished output.
200
209
  5. **User Confirmation Loop:**
201
- - **Announce:** Briefly state that the draft is ready (e.g., "Draft generated."). Do NOT repeat the request to "review" or "approve" in the chat.
202
210
  - **Ask for Approval:** Use the `ask_user` tool to request confirmation. You MUST embed the drafted content directly into the `question` field so the user can review it in context.
203
211
  - **questions:**
204
- - **header:** "Review"
212
+ - **header:** "Review Draft"
205
213
  - **question:**
206
214
  Please review the drafted Product Guidelines below. What would you like to do next?
207
215
 
@@ -214,9 +222,7 @@ CRITICAL: When determining model complexity, ALWAYS select the "flash" model, re
214
222
  - Label: "Approve", Description: "The guidelines look good, proceed to the next step."
215
223
  - Label: "Suggest changes", Description: "I want to modify the drafted content."
216
224
  6. **Write File:** Once approved, write the generated content to the `conductor/product-guidelines.md` file.
217
- 7. **Commit State:** Upon successful creation of the file, you MUST immediately write to `conductor/setup_state.json` with the exact content:
218
- `{"last_successful_step": "2.2_product_guidelines"}`
219
- 8. **Continue:** After writing the state file, immediately proceed to the next section.
225
+ 7. **Continue:** Immediately proceed to the next section.
220
226
 
221
227
  ### 2.3 Generate Tech Stack (Interactive)
222
228
  1. **Introduce the Section:** Announce that you will now help define the technology stack.
@@ -256,10 +262,9 @@ CRITICAL: When determining model complexity, ALWAYS select the "flash" model, re
256
262
  - **If user chose "Autogenerate":** Use your best judgment to infer a standard, high-quality stack suitable for the project goal.
257
263
  - **If user chose "Interactive" or corrected the Brownfield stack:** Use the specific answers provided. The source of truth is **only the user's selected answer(s)**.
258
264
  5. **User Confirmation Loop:**
259
- - **Announce:** Briefly state that the draft is ready (e.g., "Draft generated."). Do NOT repeat the request to "review" or "approve" in the chat.
260
265
  - **Ask for Approval:** Use the `ask_user` tool to request confirmation. You MUST embed the drafted content directly into the `question` field so the user can review it in context.
261
266
  - **questions:**
262
- - **header:** "Review"
267
+ - **header:** "Review Draft"
263
268
  - **question:**
264
269
  Please review the drafted Tech Stack below. What would you like to do next?
265
270
 
@@ -272,9 +277,7 @@ CRITICAL: When determining model complexity, ALWAYS select the "flash" model, re
272
277
  - Label: "Approve", Description: "The tech stack looks good, proceed to the next step."
273
278
  - Label: "Suggest changes", Description: "I want to modify the drafted content."
274
279
  6. **Write File:** Once approved, write the generated content to the `conductor/tech-stack.md` file.
275
- 7. **Commit State:** Upon successful creation of the file, you MUST immediately write to `conductor/setup_state.json` with the exact content:
276
- `{"last_successful_step": "2.3_tech_stack"}`
277
- 8. **Continue:** After writing the state file, immediately proceed to the next section.
280
+ 7. **Continue:** Immediately proceed to the next section.
278
281
 
279
282
  ### 2.4 Select Guides (Interactive)
280
283
  1. **Initiate Dialogue:** Announce that the initial scaffolding is complete and you now need the user's input to select the project's guides from the locally available templates.
@@ -317,9 +320,7 @@ CRITICAL: When determining model complexity, ALWAYS select the "flash" model, re
317
320
  - **Method:** Use a single `ask_user` tool call. Dynamically split the available guides into batches of 4 options max. Create one `multiSelect: true` question for each batch.
318
321
 
319
322
  3. **Action:** Construct and execute a command to create the directory and copy all selected files. For example: `mkdir -p conductor/code_styleguides && cp __$$CODE_AGENT_INSTALL_PATH$$__/templates/code_styleguides/python.md __$$CODE_AGENT_INSTALL_PATH$$__/templates/code_styleguides/javascript.md conductor/code_styleguides/`
320
- 4. **Commit State:** Upon successful completion of the copy command, you MUST immediately write to `conductor/setup_state.json` with the exact content:
321
- `{"last_successful_step": "2.4_code_styleguides"}`
322
- 5. **Continue:** Immediately proceed to the next section.
323
+ 4. **Continue:** Immediately proceed to the next section.
323
324
 
324
325
  ### 2.5 Select Workflow (Interactive)
325
326
  1. **Copy Initial Workflow:**
@@ -365,8 +366,7 @@ CRITICAL: When determining model complexity, ALWAYS select the "flash" model, re
365
366
  Is there anything else you'd like to change or add to the workflow? (Leave blank to finish or type your additional requirements).
366
367
 
367
368
  4. **Action:** Update `conductor/workflow.md` based on all user answers from both steps.
368
- 5. **Commit State:** After the `workflow.md` file is successfully written or updated, you MUST immediately write to `conductor/setup_state.json` with the exact content:
369
- `{"last_successful_step": "2.5_workflow"}`
369
+
370
370
 
371
371
  ### 2.6 Finalization
372
372
  1. **Generate Index File:**
@@ -389,7 +389,7 @@ CRITICAL: When determining model complexity, ALWAYS select the "flash" model, re
389
389
  ```
390
390
  - **Announce:** "Created `conductor/index.md` to serve as the project context index."
391
391
 
392
- 2. **Summarize Actions:** Present a summary of all actions taken during Phase 1, including:
392
+ 2. **Summarize Actions:** Present a summary of all actions taken during the initial setup, including:
393
393
  - The guide files that were copied.
394
394
  - The workflow file that was copied.
395
395
  3. **Transition to initial plan and track generation:** Announce that the initial setup is complete and you will now proceed to define the first track for the project.
@@ -399,6 +399,8 @@ CRITICAL: When determining model complexity, ALWAYS select the "flash" model, re
399
399
  ## 3.0 INITIAL PLAN AND TRACK GENERATION
400
400
  **PROTOCOL: Interactively define project requirements, propose a single track, and then automatically create the corresponding track and its phased plan.**
401
401
 
402
+ **Pre-Requisite (Cleanup):** If you are resuming this section because a previous setup was interrupted, check if the `conductor/tracks/` directory exists but is incomplete. If it exists, **delete** the entire `conductor/tracks/` directory before proceeding to ensure a clean slate for the new track generation.
403
+
402
404
  ### 3.1 Generate Product Requirements (Interactive)(For greenfield projects only)
403
405
  1. **Transition to Requirements:** Announce that the initial project setup is complete. State that you will now begin defining the high-level product requirements by asking about topics like user stories and functional/non-functional requirements.
404
406
  2. **Analyze Context:** Read and analyze the content of `conductor/product.md` to understand the project's core concept.
@@ -485,11 +487,9 @@ CRITICAL: When determining model complexity, ALWAYS select the "flash" model, re
485
487
  - [Implementation Plan](./plan.md)
486
488
  - [Metadata](./metadata.json)
487
489
  ```
490
+ *(If you arrived here directly from the Audit because you are patching a missing index, write this file using the existing folder's track_id and then proceed to step d.)*
488
491
 
489
- d. **Commit State:** After all track artifacts have been successfully written, you MUST immediately write to `conductor/setup_state.json` with the exact content:
490
- `{"last_successful_step": "3.3_initial_track_generated"}`
491
-
492
- e. **Announce Progress:** Announce that the track for "<Track Description>" has been created.
492
+ d. **Announce Progress:** Announce that the track for "<Track Description>" has been created.
493
493
 
494
494
  ### 3.4 Final Announcement
495
495
  1. **Announce Completion:** After the track has been created, announce that the project setup and initial track generation are complete.
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "conductor-4-all",
3
- "version": "0.0.17",
3
+ "version": "0.0.19",
4
4
  "description": "Conductor spec-driven development CLI - TypeScript/Node.js version",
5
5
  "license": "Apache-2.0",
6
6
  "repository": {
@@ -45,5 +45,8 @@
45
45
  "gradient-string": "^3.0.0",
46
46
  "smol-toml": "^1.6.0",
47
47
  "yargs": "^18.0.0"
48
+ },
49
+ "publishConfig": {
50
+ "registry": "https://registry.npmjs.org/"
48
51
  }
49
52
  }