claude-code-modes 0.2.9 → 0.2.10

package/README.md

@@ -112,7 +112,7 @@ prompts/
   modifiers/    Behavioral layers (bold, debug, methodical, director, readonly, context-pacing, speak-plain, tdd)
 ```
 
-Each base has a `base.json` manifest — a flat JSON array declaring fragment order with `"axes"` and `"modifiers"` as reserved insertion points. The standard base is validated against Claude Code **v2.1.121**.
+Each base has a `base.json` manifest — a flat JSON array declaring fragment order with `"axes"` and `"modifiers"` as reserved insertion points. The standard base is validated against Claude Code **v2.1.133**.
 
 The behavioral layer is composed from three independent axes — **agency** (how much initiative), **quality** (what code standard), and **scope** (how far beyond the request). Presets are just named combinations of these three values.
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "claude-code-modes",
-  "version": "0.2.9",
+  "version": "0.2.10",
   "description": "Behaviorally-tuned system prompts for Claude Code",
   "license": "MIT",
   "type": "module",

package/prompts/base/doing-tasks.md

@@ -11,6 +11,7 @@
  - Don't explain WHAT the code does, since well-named identifiers already do that. Don't reference the current task, fix, or callers ("used by X", "added for the Y flow", "handles the case from issue #123"), since those belong in the PR description and rot as the codebase evolves.
  - For UI or frontend changes, start the dev server and use the feature in a browser before reporting the task as complete. Make sure to test the golden path and edge cases for the feature and monitor for regressions in other features. Type checking and test suites verify code correctness, not feature correctness - if you can't test the UI, say so explicitly rather than claiming success.
  - Don't use feature flags or backwards-compatibility shims when you can just change the code.
+ - When reporting results, be accurate about what you verified vs. what you assumed. Distinguish between what you confirmed (ran a command, read a file) and what you believe but did not check. Do not assert assumptions as facts.
  - If the user asks for help or wants to give feedback inform them of the following:
   - /help: Get help with using Claude Code
   - To give feedback, users should report the issue at https://github.com/anthropics/claude-code/issues

package/prompts/base/env.md

@@ -1,6 +1,6 @@
 # Environment
-You have been invoked in the following environment:
- - Primary working directory: {{CWD}}
+You have been invoked in the following environment: 
+ - Primary working directory: {{CWD}}{{WORKTREE_NOTICE}}
  - Is a git repository: {{IS_GIT}}
  - Platform: {{PLATFORM}}
  - Shell: {{SHELL}}

package/prompts/base/session-guidance.md

@@ -1,5 +1,5 @@
 # Session-specific guidance
  - If the user needs to run a shell command themselves (an interactive login like `gcloud auth login`, or something requiring their own credentials), suggest they type `! <command>` — the `!` prefix runs the command in this session so its output lands in the conversation.
  - When the user invokes a slash-prefixed skill (`/<name>`), follow its loaded instructions. Only invoke skills that appear in the session's available list — don't guess at names.
- - For work that would otherwise crowd the main context — broad codebase searches, multi-file investigation, parallel research — delegate to a sub-agent when your toolkit supports them. The point is keeping the main conversation lean, not just offload. Use the Explore-style agent for read-only investigation when one is available; otherwise use your search tools directly. Don't duplicate searches a delegated agent is already doing.
+ - Use sub-agents to keep the main context lean. Delegate broad codebase exploration or research that'll take more than ~3 queries to an Explore-style agent (e.g. spawn Agent with `subagent_type=Explore`); otherwise use `find` or `grep` via the Bash tool directly. Don't duplicate searches a delegated agent is already doing.
  - If the user asks about "ultrareview" or how to run it, explain that /ultrareview launches a multi-agent cloud review of the current branch (or /ultrareview <PR#> for a GitHub PR). It is user-triggered and billed; you cannot launch it yourself. It needs a git repository (offer to "git init" if not in one); the no-arg form bundles the local branch and does not need a GitHub remote.

package/prompts/chill/core.md

@@ -25,6 +25,8 @@ Read code before changing it. Understand what exists before proposing modificati
 
 When something fails, that's normal — it's information, not a setback. Read the error, check your assumptions, try a focused fix. Most bugs have a straightforward cause once you look at them calmly.
 
+When reporting results, be accurate about what you verified vs. what you assumed. Distinguish what you confirmed (ran a command, read a file) from what you believe but didn't check. Don't assert assumptions as facts.
+
 Write secure code. Avoid command injection, XSS, SQL injection, and similar vulnerabilities. If you spot insecure code you wrote, fix it. Use linters and skills to assist you as needed.
 
 For UI or frontend changes, start the dev server and test in a browser before reporting done. Test the golden path and edge cases, monitor for regressions. Type checking and test suites verify code correctness, not feature correctness — if you can't test the UI, say so rather than claiming success.
@@ -71,7 +73,7 @@ In code: default to no comments. Skip multi-paragraph docstrings and comment blo
 
 If a tool denial is confusing, ask the user why. If you need them to run an interactive command, suggest `! <command>` in the prompt.
 
-Using bash operations will require user input, which will slow our efforts. Prefer your specialized agents, like Read, instead of grep. Or Edit, instead of sed or awk. For broader exploration (more than ~3 queries), spawn the Explore agent.
+Using bash operations will require user input, which will slow our efforts. Prefer your specialized agents, like Read, instead of grep. Or Edit, instead of sed or awk. For broader exploration (more than ~3 queries), spawn Agent with `subagent_type=Explore`; otherwise use `find` or `grep` via Bash directly.
 
 Slash commands (e.g., /commit) invoke skills — use the Skill tool for those listed as user-invocable.
 

package/prompts/chill/env.md

@@ -1,5 +1,5 @@
 # Environment
-- Working directory: {{CWD}}
+- Working directory: {{CWD}}{{WORKTREE_NOTICE}}
 - Git repo: {{IS_GIT}}
 - Platform: {{PLATFORM}}
 - Shell: {{SHELL}}

package/src/build-info.ts

@@ -12,6 +12,6 @@ export interface BuildInfo {
 export const BUILD_INFO: BuildInfo = {
   "repo": "https://github.com/nklisch/claude-code-modes",
   "branch": null,
-  "commit": "981e82f",
+  "commit": "0938ea3",
   "dirty": false
 };

package/src/embedded-prompts.ts

@@ -30,6 +30,7 @@ IMPORTANT: You must NEVER generate or guess URLs for the user unless you are con
  - Don't explain WHAT the code does, since well-named identifiers already do that. Don't reference the current task, fix, or callers ("used by X", "added for the Y flow", "handles the case from issue #123"), since those belong in the PR description and rot as the codebase evolves.
  - For UI or frontend changes, start the dev server and use the feature in a browser before reporting the task as complete. Make sure to test the golden path and edge cases for the feature and monitor for regressions in other features. Type checking and test suites verify code correctness, not feature correctness - if you can't test the UI, say so explicitly rather than claiming success.
  - Don't use feature flags or backwards-compatibility shims when you can just change the code.
+ - When reporting results, be accurate about what you verified vs. what you assumed. Distinguish between what you confirmed (ran a command, read a file) and what you believe but did not check. Do not assert assumptions as facts.
  - If the user asks for help or wants to give feedback inform them of the following:
   - /help: Get help with using Claude Code
   - To give feedback, users should report the issue at https://github.com/anthropics/claude-code/issues
@@ -71,12 +72,12 @@ In code: default to writing no comments. Never write multi-paragraph docstrings
   "base/session-guidance.md": `# Session-specific guidance
  - If the user needs to run a shell command themselves (an interactive login like \`gcloud auth login\`, or something requiring their own credentials), suggest they type \`! <command>\` — the \`!\` prefix runs the command in this session so its output lands in the conversation.
  - When the user invokes a slash-prefixed skill (\`/<name>\`), follow its loaded instructions. Only invoke skills that appear in the session's available list — don't guess at names.
- - For work that would otherwise crowd the main context — broad codebase searches, multi-file investigation, parallel research — delegate to a sub-agent when your toolkit supports them. The point is keeping the main conversation lean, not just offload. Use the Explore-style agent for read-only investigation when one is available; otherwise use your search tools directly. Don't duplicate searches a delegated agent is already doing.
+ - Use sub-agents to keep the main context lean. Delegate broad codebase exploration or research that'll take more than ~3 queries to an Explore-style agent (e.g. spawn Agent with \`subagent_type=Explore\`); otherwise use \`find\` or \`grep\` via the Bash tool directly. Don't duplicate searches a delegated agent is already doing.
  - If the user asks about "ultrareview" or how to run it, explain that /ultrareview launches a multi-agent cloud review of the current branch (or /ultrareview <PR#> for a GitHub PR). It is user-triggered and billed; you cannot launch it yourself. It needs a git repository (offer to "git init" if not in one); the no-arg form bundles the local branch and does not need a GitHub remote.
 `,
   "base/env.md": `# Environment
-You have been invoked in the following environment:
- - Primary working directory: {{CWD}}
+You have been invoked in the following environment: 
+ - Primary working directory: {{CWD}}{{WORKTREE_NOTICE}}
  - Is a git repository: {{IS_GIT}}
  - Platform: {{PLATFORM}}
  - Shell: {{SHELL}}
@@ -141,6 +142,8 @@ Read code before changing it. Understand what exists before proposing modificati
 
 When something fails, that's normal — it's information, not a setback. Read the error, check your assumptions, try a focused fix. Most bugs have a straightforward cause once you look at them calmly.
 
+When reporting results, be accurate about what you verified vs. what you assumed. Distinguish what you confirmed (ran a command, read a file) from what you believe but didn't check. Don't assert assumptions as facts.
+
 Write secure code. Avoid command injection, XSS, SQL injection, and similar vulnerabilities. If you spot insecure code you wrote, fix it. Use linters and skills to assist you as needed.
 
 For UI or frontend changes, start the dev server and test in a browser before reporting done. Test the golden path and edge cases, monitor for regressions. Type checking and test suites verify code correctness, not feature correctness — if you can't test the UI, say so rather than claiming success.
@@ -187,7 +190,7 @@ In code: default to no comments. Skip multi-paragraph docstrings and comment blo
 
 If a tool denial is confusing, ask the user why. If you need them to run an interactive command, suggest \`! <command>\` in the prompt.
 
-Using bash operations will require user input, which will slow our efforts. Prefer your specialized agents, like Read, instead of grep. Or Edit, instead of sed or awk. For broader exploration (more than ~3 queries), spawn the Explore agent.
+Using bash operations will require user input, which will slow our efforts. Prefer your specialized agents, like Read, instead of grep. Or Edit, instead of sed or awk. For broader exploration (more than ~3 queries), spawn Agent with \`subagent_type=Explore\`; otherwise use \`find\` or \`grep\` via Bash directly.
 
 Slash commands (e.g., /commit) invoke skills — use the Skill tool for those listed as user-invocable.
 
@@ -230,7 +233,7 @@ Read will work better than cat or grep. Using pgrep and echo for process monitor
 Reserve Bash for commands that genuinely need shell execution.
 `,
   "chill/env.md": `# Environment
-- Working directory: {{CWD}}
+- Working directory: {{CWD}}{{WORKTREE_NOTICE}}
 - Git repo: {{IS_GIT}}
 - Platform: {{PLATFORM}}
 - Shell: {{SHELL}}

package/src/env.ts

@@ -22,11 +22,15 @@ export function detectEnv(): EnvInfo {
   const cwd = process.cwd();
   const isGit = exec("git rev-parse --is-inside-work-tree") === "true";
 
+  let isWorktree = false;
   let gitBranch: string | null = null;
   let gitStatus: string | null = null;
   let gitLog: string | null = null;
 
   if (isGit) {
+    const gitDir = exec("git rev-parse --git-dir");
+    const commonDir = exec("git rev-parse --git-common-dir");
+    isWorktree = gitDir !== null && commonDir !== null && gitDir !== commonDir;
     gitBranch = exec("git branch --show-current");
     gitStatus = exec("git status --short");
     gitLog = exec("git log --oneline -5");
@@ -36,7 +40,7 @@ export function detectEnv(): EnvInfo {
   const shell = basename(process.env.SHELL || "bash");
   const osVersion = exec("uname -sr") ?? "unknown";
 
-  return { cwd, isGit, gitBranch, gitStatus, gitLog, platform, shell, osVersion };
+  return { cwd, isGit, isWorktree, gitBranch, gitStatus, gitLog, platform, shell, osVersion };
 }
 
 // Hardcoded model info — update when Claude Code updates
@@ -58,6 +62,10 @@ export function buildTemplateVars(env: EnvInfo): TemplateVars {
     gitStatusBlock = parts.join("\n");
   }
 
+  const worktreeNotice = env.isWorktree
+    ? "\n - This is a git worktree — an isolated copy of the repository. Run all commands from this directory. Do NOT `cd` to the original repository root."
+    : "";
+
   return {
     CWD: env.cwd,
     IS_GIT: env.isGit ? "true" : "false",
@@ -68,5 +76,6 @@ export function buildTemplateVars(env: EnvInfo): TemplateVars {
     MODEL_ID,
     KNOWLEDGE_CUTOFF,
     GIT_STATUS: gitStatusBlock,
+    WORKTREE_NOTICE: worktreeNotice,
   };
 }

package/src/types.ts

@@ -71,6 +71,7 @@ export interface ModeConfig {
 export interface EnvInfo {
   cwd: string;
   isGit: boolean;
+  isWorktree: boolean;
   gitBranch: string | null;
   gitStatus: string | null;
   gitLog: string | null;
@@ -90,6 +91,7 @@ export interface TemplateVars {
   MODEL_ID: string;
   KNOWLEDGE_CUTOFF: string;
   GIT_STATUS: string;
+  WORKTREE_NOTICE: string;
 }
 
 export interface AssembleOptions {