Add a no-worktree workspace mode

README.md

@@ -31,7 +31,9 @@ Once installed, you can use Trycycle from any Claude Code or Codex CLI session.
 Use trycycle to add a dark mode toggle to the settings page.
 ```
 
-Trycycle will ask you any questions it needs answered before starting, then handle the rest. It creates a git worktree, writes a plan, strengthens that plan until a fresh editor approves it unchanged, builds a test plan, builds the code, and reviews the code -- all without further input from you unless something comes up that needs your judgment.
+Trycycle will ask you any questions it needs answered before starting, then handle the rest. By default it creates a git worktree, writes a plan, strengthens that plan until a fresh editor approves it unchanged, builds a test plan, builds the code, and reviews the code -- all without further input from you unless something comes up that needs your judgment.
+
+If you want Trycycle to reuse the current checkout instead, include the literal flag `--no-worktree` in your request. This is useful in tools like Conductor that already create an isolated workspace and branch for you.
 
 You can use Trycycle for anything from small features to large refactors. It works best when you have a clear goal in mind and a codebase that Trycycle can read and test.
 

SKILL.md

@@ -28,6 +28,14 @@ When a step below tells you to render a prompt template:
 
 The prompt builder supports conditional blocks inside templates. A block guarded by `{{#if NAME}} ... {{/if}}` is included only when `NAME` is bound to a non-empty value.
 
+## Workspace path convention
+
+Throughout this skill, `{WORKTREE_PATH}` means the directory where implementation happens:
+- In the default mode, it is the path to the dedicated git worktree created in Step 4.
+- If the user's request includes the literal flag `--no-worktree`, it is the path to the current checkout/workspace instead.
+
+In `--no-worktree` mode, do not create a nested git worktree. Reuse the current checkout as the implementation workspace. This is intended for tools such as Conductor that already provide an isolated workspace and branch.
+
 ## Transcript placeholder helper
 
 When a step below references `{USER_REQUEST_TRANSCRIPT}`, `{INITIAL_REQUEST_AND_SUBSEQUENT_CONVERSATION}`, or `{FULL_CONVERSATION_VERBATIM}`:
@@ -97,17 +105,25 @@ When the subagent returns a proposed strategy, present it to the user verbatim a
 
 The agreed testing strategy is used in step 7.
 
-## 4) Create worktree
+## 4) Prepare implementation workspace
+
+Default behavior: read and follow `<skill-directory>/subskills/trycycle-worktrees/SKILL.md` to create an isolated worktree for the implementation with an appropriately named branch, for example `add-connection-status-icon`.
 
-Read and follow `<skill-directory>/subskills/trycycle-worktrees/SKILL.md` to create an isolated worktree for the implementation with an appropriately named branch, for example `add-connection-status-icon`.
+If the user's request includes the literal flag `--no-worktree`, skip the worktree-creation subskill and prepare the current checkout as the implementation workspace instead:
+- Set `{WORKTREE_PATH}` to the current repository root.
+- Run `git -C {WORKTREE_PATH} status --short` and stop unless it is clean.
+- Detect the default branch. Prefer `CONDUCTOR_DEFAULT_BRANCH` when it is set and non-empty. Otherwise use the repo's configured remote default branch if available; if not, fall back to `main`, then `master`.
+- If `CONDUCTOR_WORKSPACE_PATH` is set and resolves to the current workspace, treat that as confirmation that the existing checkout is already an isolated workspace and do not create any nested worktree.
+- If `git -C {WORKTREE_PATH} branch --show-current` already shows a non-default branch, reuse it.
+- Otherwise create and switch to a new appropriately named branch in place.
 
-Immediately after creating the worktree, run:
+Immediately after preparing the implementation workspace, run:
 - `git -C {WORKTREE_PATH} branch --show-current`
 - `git -C {WORKTREE_PATH} status --short`
 
 Do not continue until the branch is correct and the status is clean.
 
-## 5) Worktree hygiene gate (mandatory)
+## 5) Workspace hygiene gate (mandatory)
 
 Before and after each major phase (`plan-editing`, `execution`, `post-implementation review`), run:
 - `git -C {WORKTREE_PATH} branch --show-current`
@@ -137,7 +153,7 @@ Wait for the planning subagent to return either:
 
 If the planning subagent returns `USER DECISION REQUIRED:`, present that question to the user, send the user's answer back to that active planning subagent, and wait again for either a planning report or another `USER DECISION REQUIRED:` report.
 
-If a planning report was returned, update `{IMPLEMENTATION_PLAN_PATH}` from `## Plan path`, then run the Worktree hygiene gate checks, verify the latest commit hash plus changed-file list match the planning subagent's report, and confirm the plan file exists at `{IMPLEMENTATION_PLAN_PATH}`.
+If a planning report was returned, update `{IMPLEMENTATION_PLAN_PATH}` from `## Plan path`, then run the workspace hygiene gate checks, verify the latest commit hash plus changed-file list match the planning subagent's report, and confirm the plan file exists at `{IMPLEMENTATION_PLAN_PATH}`.
 
 ## 7) Plan-editor loop (up to 5 rounds)
 
@@ -151,7 +167,7 @@ After each edit round:
 1. Wait for the planning subagent to return either an updated planning report containing `## Plan verdict`, `## Plan path`, `## Commit`, and `## Changed files`, or a report beginning with `USER DECISION REQUIRED:`.
 2. If the planning subagent returns `USER DECISION REQUIRED:`, present that question to the user, send the user's answer back to that active planning subagent, and wait again for either an updated planning report or another `USER DECISION REQUIRED:` report.
 3. Update `{IMPLEMENTATION_PLAN_PATH}` from `## Plan path` in the latest planning report.
-4. Run the Worktree hygiene gate checks and verify the latest commit hash plus changed-file list match the planning subagent's report.
+4. Run the workspace hygiene gate checks and verify the latest commit hash plus changed-file list match the planning subagent's report.
 5. If `## Plan verdict` is `ALREADY-EXCELLENT`, continue to step 8 with the current `{IMPLEMENTATION_PLAN_PATH}`.
 6. If `## Plan verdict` is `MADE-EXCELLENT`, repeat with a fresh planning subagent.
 7. Repeat up to 5 rounds.
@@ -173,7 +189,7 @@ When the subagent returns:
 2. If the test-plan report includes `## Strategy changes requiring user approval`, present that section to the user verbatim.
 3. If the user requests changes or redirects the approach, rebuild `{FULL_CONVERSATION_VERBATIM}` immediately before the next render, save it to a temp file again, re-render `<skill-directory>/subagents/prompt-test-plan.md` with `--set IMPLEMENTATION_PLAN_PATH={IMPLEMENTATION_PLAN_PATH}`, `--set WORKTREE_PATH={WORKTREE_PATH}`, `--set-file FULL_CONVERSATION_VERBATIM=<temp-file>`, and `--require-nonempty-tag conversation`, save the rendered prompt to a temp file, re-dispatch the test-plan subagent with the exact rendered prompt file contents verbatim, update `{TEST_PLAN_PATH}` from the latest test-plan report, and repeat until the user explicitly approves or the report no longer includes that section.
 4. Do not proceed until the current test-plan report either has no `## Strategy changes requiring user approval` section or the user has explicitly approved it.
-5. Run the Worktree hygiene gate checks, verify the latest commit hash plus changed-file list match the test-plan subagent's report, and verify the test plan file exists at `{TEST_PLAN_PATH}`.
+5. Run the workspace hygiene gate checks, verify the latest commit hash plus changed-file list match the test-plan subagent's report, and verify the test plan file exists at `{TEST_PLAN_PATH}`.
 
 ## 9) Execute with trycycle-executing (subagent-owned)
 
@@ -185,7 +201,7 @@ Render `<skill-directory>/subagents/prompt-executing.md` with the prompt builder
 
 Do not proceed to post-implementation review until the implementation subagent has returned an implementation report.
 
-After implementation completes, run the Worktree hygiene gate checks and verify the latest commit hash plus changed-file list match the implementation subagent's report before launching post-implementation review.
+After implementation completes, run the workspace hygiene gate checks and verify the latest commit hash plus changed-file list match the implementation subagent's report before launching post-implementation review.
 
 ## 10) Post-implementation review loop (up to 8 rounds)
 
@@ -199,7 +215,7 @@ Use the review subagent's output as the fix-loop input. When another fix round i
 3. Render `<skill-directory>/subagents/prompt-executing.md` with the prompt builder using `--set IMPLEMENTATION_PLAN_PATH={IMPLEMENTATION_PLAN_PATH}`, `--set TEST_PLAN_PATH={TEST_PLAN_PATH}`, `--set WORKTREE_PATH={WORKTREE_PATH}`, and `--set-file POST_IMPLEMENTATION_REVIEW_FINDINGS_VERBATIM=<review-findings-temp-file>`, then save the rendered prompt to a temp file.
 4. Resume the same implementation subagent and send the exact rendered prompt file contents verbatim.
 
-After each implementation-subagent fix round, run the Worktree hygiene gate checks and verify the latest commit hash plus changed-file list match the implementation subagent's report before starting the next fresh review round.
+After each implementation-subagent fix round, run the workspace hygiene gate checks and verify the latest commit hash plus changed-file list match the implementation subagent's report before starting the next fresh review round.
 
 Stop when either condition is met:
 1. No **critical** or **major** issues remain.
@@ -221,4 +237,4 @@ Clean up temporary artifacts created during the loop (for example plan scratch f
 
 Report the process to the user using concrete facts and returned artifacts: how many plan-editor rounds, how many code-review rounds, the current `HEAD`, the changed-file list, the implementation subagent's latest summary and verification results, and any reviewer-reported residual issues.
 
-Then read and follow `<skill-directory>/subskills/trycycle-finishing/SKILL.md` to present the user with options for integrating the worktree (merge, PR, etc.).
+Then read and follow `<skill-directory>/subskills/trycycle-finishing/SKILL.md` to present the user with options for integrating the implementation workspace (merge, PR, etc.).

maintenance/import-skills.sh

@@ -18,13 +18,20 @@ cleanup() {
 }
 trap cleanup EXIT
 
-# Map trycycle skill names to superpowers source skill directory names
-declare -A SKILL_MAP=(
-  [trycycle-worktrees]="using-git-worktrees"
-  [trycycle-planning]="writing-plans"
-  [trycycle-executing]="executing-plans"
-  [trycycle-finishing]="finishing-a-development-branch"
-)
+# Map trycycle skill names to superpowers source skill directory names.
+# Use a case statement so the script still works on macOS's default Bash 3.2.
+source_skill_name_for() {
+  case "$1" in
+    trycycle-worktrees) echo "using-git-worktrees" ;;
+    trycycle-planning) echo "writing-plans" ;;
+    trycycle-executing) echo "executing-plans" ;;
+    trycycle-finishing) echo "finishing-a-development-branch" ;;
+    *)
+      echo "ERROR: unknown trycycle skill name: $1" >&2
+      return 1
+      ;;
+  esac
+}
 
 # Extract base-commit from an existing adapted skill's header.
 # Returns empty string if no header found (first import).
@@ -303,7 +310,8 @@ main() {
   local any_aborted=false
 
   for trycycle_name in trycycle-worktrees trycycle-planning trycycle-executing trycycle-finishing; do
-    local source_name="${SKILL_MAP[$trycycle_name]}"
+    local source_name
+    source_name="$(source_skill_name_for "$trycycle_name")"
     echo ""
     echo "--- Importing $source_name -> $trycycle_name ---"
 

maintenance/skill-instructions/trycycle-finishing.txt

@@ -3,7 +3,7 @@ This skill is invoked in trycycle Step 11 ("Finish"). After the post-implementat
 **What the orchestrator already handles:**
 - The orchestrator has already verified correctness through up to 8 rounds of code review (Step 10).
 - The orchestrator runs its own cleanup of temporary artifacts before invoking this skill.
-- The orchestrator runs final worktree hygiene checks (status, HEAD, changed files) before this step.
+- The orchestrator runs final workspace hygiene checks (status, HEAD, changed files) before this step.
 
 **What to strip:**
 
@@ -14,11 +14,13 @@ This skill is invoked in trycycle Step 11 ("Finish"). After the post-implementat
    - Step 2 (Determine Base Branch) — keep.
    - Step 3 (Present Options) — keep the 4 options and their mechanics, but replace any placeholder summary-writing or verification-writing with reuse of artifacts already produced earlier in trycycle. For the PR option, replace `<paste the implementation subagent's implementation summary here>` with `<paste the latest \`## Implementation summary\` returned by the implementation subagent here>`, replace `<paste the implementation subagent's verification results here>` with `<paste the latest \`## Verification results\` returned by the implementation subagent here>`, and carry through any reviewer-reported residual issues if present.
    - Step 4 (Execute Choice) — keep all 4 option implementations, and keep using those same latest implementation-summary / verification-result / residual-issue artifacts whenever an option needs PR text or user-facing reporting.
-   - Step 5 (Cleanup Worktree) — keep.
+   - Step 5 (Cleanup Worktree) — keep, but make it mode-aware. In default mode, clean up the dedicated worktree as before. In `--no-worktree` mode, do not attempt to remove a worktree; instead preserve the current checkout and only perform the branch actions relevant to the chosen option.
    - Quick Reference table — keep.
    - Common Mistakes — keep the ones about skipping test verification, no confirmation for discard. Remove ones about integration with skills we don't ship.
    - Red Flags — keep.
 
-3. **This is the lightest adaptation** of the four skills. The finishing workflow is self-contained and the orchestrator doesn't override any of its behavior — it just invokes it.
+3. **Adjust language to "workspace" where it helps.** The skill still manages branches, but it should not imply that every run has a removable git worktree. It must work for either a dedicated worktree or an existing isolated workspace such as a Conductor workspace.
+
+4. **This is the lightest adaptation** of the four skills. The finishing workflow is self-contained and the orchestrator doesn't override any of its behavior — it just invokes it.
 
 **Resulting structure should be roughly the same as the original, minus stale cross-references.**

maintenance/skill-instructions/trycycle-planning.txt

@@ -8,15 +8,15 @@ This skill is invoked in trycycle Step 6 ("Plan with trycycle-planning"). A dedi
 
 **What to strip:**
 
-1. **Remove brainstorming preconditions.** The line "This should be run in a dedicated worktree (created by brainstorming skill)" should change to something like "This should be run in a dedicated worktree" (drop the brainstorming reference). The orchestrator creates the worktree in Step 4.
+1. **Remove brainstorming preconditions.** The line "This should be run in a dedicated worktree (created by brainstorming skill)" should change to something like "This should be run in an isolated implementation workspace" (drop the brainstorming reference). The orchestrator prepares that workspace in Step 4, either as a dedicated worktree or as an existing isolated checkout when `--no-worktree` is used.
 
 2. **Remove the plan header line about executing-plans.** The template header says `> **For Claude:** REQUIRED SUB-SKILL: Use superpowers:executing-plans to implement this plan task-by-task.` — change this to reference `trycycle-executing`.
 
 3. **Keep everything else.** The bite-sized task granularity, the plan document header format, the task structure template, the "Remember" list — these are all core operational content the planning subagent needs. The TDD emphasis, exact file paths, complete code in plan — all essential. Keep them intact.
 
 **Resulting structure should be roughly:**
 - Overview (plan writing guidance)
-- Context note (run in dedicated worktree)
+- Context note (run in isolated implementation workspace)
 - Save plans to `docs/plans/YYYY-MM-DD-<feature-name>.md`
 - Bite-sized task granularity rules
 - Plan document header template

maintenance/skill-instructions/trycycle-worktrees.txt

@@ -1,4 +1,4 @@
-This skill is invoked in trycycle Step 2 ("Create worktree"). The orchestrator calls it to set up an isolated worktree before any planning or implementation begins.
+This skill is invoked only in the default trycycle Step 4 flow ("Prepare implementation workspace"). The orchestrator calls it to set up an isolated worktree before any planning or implementation begins. If the user request includes `--no-worktree`, the orchestrator skips this skill and reuses the current checkout instead.
 
 **What the orchestrator already handles:**
 - Immediately after worktree creation, the orchestrator runs `git branch --show-current` and `git status --short` to verify. So the skill's own verification is redundant but harmless — keep it light.
@@ -21,4 +21,4 @@ This skill is invoked in trycycle Step 2 ("Create worktree"). The orchestrator c
 - Create worktree in `.worktrees/<branch-name>`
 - Verify `.worktrees` is gitignored (fix if not)
 - Auto-detect and run project setup
-- Report worktree path
+- Report worktree path

subagents/prompt-executing.md

@@ -14,7 +14,7 @@ All other trycycle-executing behaviors remain in effect (run verifications, foll
 
 The test plan is at `{TEST_PLAN_PATH}`.
 
-Work in the worktree at `{WORKTREE_PATH}`.
+Work in the implementation workspace at `{WORKTREE_PATH}`.
 
 {{#if POST_IMPLEMENTATION_REVIEW_FINDINGS_VERBATIM}}
 <post_implementation_review_findings_verbatim>

subagents/prompt-planning-edit.md

@@ -26,8 +26,8 @@ Task:
 - Declare the plan already excellent unchanged only if it is aligned to the user's request, architecturally sound, consistent with `trycycle-planning`, idiomatic to the technologies and the general approach of the repo if any, and ready for direct execution.
 - Ensure your decisions are thoughtful and justified, and that the justification for decisions is included in the plan.
 - If a user decision is genuinely required because there is no safe path forward without it, return a detailed report beginning with `USER DECISION REQUIRED:` that names the decision, explains why it is required, justifies it carefully, and gives your recommended choice.
-- Work in the worktree at `{WORKTREE_PATH}`.
-- If you revise the plan, commit the revised plan to the worktree. If you declare it already excellent unchanged, do not modify files.
+- Work in the implementation workspace at `{WORKTREE_PATH}`.
+- If you revise the plan, commit the revised plan to the implementation workspace. If you declare it already excellent unchanged, do not modify files.
 - Return a markdown report with these sections in this order:
   - `## Plan verdict` — `MADE-EXCELLENT` if you changed the plan, or `ALREADY-EXCELLENT` if you left it unchanged
   - `## Plan path` — the absolute path to the current plan file

subagents/prompt-planning-initial.md

@@ -19,8 +19,8 @@ Task:
 - Be bold. Consider what is idiomatic for any existing technologies or code, and what is architecturally clean and robust over what is expedient.
 - Ensure your decisions are thoughtful and justified, and that the justification for decisions is included in the plan.
 - The plan will be executed all at once with a single cutover; do not plan interim steps unless it is necessary and the user has approved.
-- Work in the worktree at `{WORKTREE_PATH}`.
-- Commit the current plan to the worktree.
+- Work in the implementation workspace at `{WORKTREE_PATH}`.
+- Commit the current plan to the implementation workspace.
 - Otherwise, return a markdown report with these sections in this order:
   - `## Plan verdict` — `CREATED`
   - `## Plan path` — the absolute path to the current plan file