codex-potter 0.2.1-next.1 → 0.2.2-next.1

package/README.md

@@ -6,5 +6,5 @@ Set up CodexPotter for use from Codex:
 npx codex-potter@next setup
 ```
 
-The setup command configures the global gitignore, installs the CodexPotter
-subagent profile, and installs the `$loop` skill.
+The setup command configures the global gitignore, removes the legacy
+CodexPotter subagent profile if it exists, and installs the `$loop` skill.

package/bin/codex-potter.js

@@ -4,10 +4,6 @@ import { spawn, spawnSync } from "node:child_process";
 import fs from "node:fs";
 import path from "node:path";
 import readline from "node:readline";
-import { fileURLToPath } from "node:url";
-
-const __filename = fileURLToPath(import.meta.url);
-const __dirname = path.dirname(__filename);
 
 const CODEXPOTTER_GITIGNORE_ENTRY = "/.codexpotter";
 const LOOP_SKILL_COMMAND = [
@@ -93,27 +89,23 @@ function printErrors(errors) {
 
 async function runSetup({ yes }) {
   const home = getHomeDir();
-  const resourcePath = path.join(
-    __dirname,
-    "..",
-    "resources",
+  const legacyProfilePath = path.join(
+    home,
+    ".codex",
+    "agents",
     "potter_worker.toml",
   );
-  const profilePath = path.join(home, ".codex", "agents", "potter_worker.toml");
-  const profileContent = await fs.promises.readFile(resourcePath, "utf8");
 
   const globalGitignore = resolveGlobalGitignore(home);
   const gitignoreContent = await readTextIfExists(globalGitignore.path);
   const gitignoreNeedsWrite = !gitignoreIgnoresCodexPotter(gitignoreContent);
-
-  const currentProfileContent = await readTextIfExists(profilePath);
-  const profileNeedsWrite = currentProfileContent !== profileContent;
+  const legacyProfileNeedsRemoval = await pathExists(legacyProfilePath);
   const skillInstaller = resolveSkillInstaller();
 
   printSetupPlan({
     gitignoreNeedsWrite,
-    profileNeedsWrite,
-    profilePath,
+    legacyProfileNeedsRemoval,
+    legacyProfilePath,
     skillInstaller,
   });
 
@@ -134,12 +126,10 @@ async function runSetup({ yes }) {
     }
   }
 
-  if (profileNeedsWrite) {
-    await fs.promises.mkdir(path.dirname(profilePath), { recursive: true });
-    await fs.promises.writeFile(profilePath, profileContent, "utf8");
+  if (await removeFileIfExists(legacyProfilePath)) {
     console.log(
-      `${format("✓ Added", "green")} subagent profile ${format(
-        displayPath(profilePath),
+      `${format("✓ Removed", "green")} legacy subagent profile ${format(
+        displayPath(legacyProfilePath),
         "dim",
       )}`,
     );
@@ -159,8 +149,8 @@ async function runSetup({ yes }) {
 
 function printSetupPlan({
   gitignoreNeedsWrite,
-  profileNeedsWrite,
-  profilePath,
+  legacyProfileNeedsRemoval,
+  legacyProfilePath,
   skillInstaller,
 }) {
   console.log(format("CodexPotter setup", "bold"));
@@ -172,8 +162,8 @@ function printSetupPlan({
     )} in global gitignore`,
   );
   console.log(
-    `${statusLabel(profileNeedsWrite)} Add subagent profile ${format(
-      displayPath(profilePath),
+    `${statusLabel(legacyProfileNeedsRemoval)} Remove legacy subagent profile ${format(
+      displayPath(legacyProfilePath),
       "dim",
     )}`,
   );
@@ -332,6 +322,30 @@ async function readTextIfExists(filePath) {
   }
 }
 
+async function pathExists(filePath) {
+  try {
+    await fs.promises.access(filePath, fs.constants.F_OK);
+    return true;
+  } catch (error) {
+    if (error && error.code === "ENOENT") {
+      return false;
+    }
+    throw error;
+  }
+}
+
+async function removeFileIfExists(filePath) {
+  try {
+    await fs.promises.unlink(filePath);
+    return true;
+  } catch (error) {
+    if (error && error.code === "ENOENT") {
+      return false;
+    }
+    throw error;
+  }
+}
+
 async function ensureCodexPotterIgnored(filePath) {
   const currentContent = await readTextIfExists(filePath);
   if (gitignoreIgnoresCodexPotter(currentContent)) {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "codex-potter",
-  "version": "0.2.1-next.1",
+  "version": "0.2.2-next.1",
   "license": "Apache-2.0",
   "bin": {
     "codex-potter": "bin/codex-potter.js"

package/resources/potter_worker.toml

@@ -1,122 +0,0 @@
-name = "potter_worker"
-description = "General purpose worker, only used in CodexPotter loop"
-developer_instructions = """
-
-<WORKFLOW_INSTRUCTIONS>
-
-Run the workflow below to implement the overall goal recorded in the handoff file.
-Keep handoff file updated until all listed tasks are complete or handoff file's `status == skip`.
-
-- `.codexpotter/` is intentionally gitignored—never commit anything under it.
-- Sections in handoff file: Overall Goal, In Progress, Todo, Done
-- handoff file's status in front matter: initial / open / skip
-
-# Phase: `status == initial`
-
-1. Resolve and fully understand user's request in `Overall Goal`.
-
-2. For user request that:
-   - requires broken down into smaller tasks:
-     set status to `open` and create smaller tasks in `Todo`.
-   - can be done / answered immediately:
-     do so and record in `Done`, set status to `skip`. No need to create other tasks.
-
-# Phase: `status == open`
-
-1. Always continue tasks in `In Progress` first (if any).
-   - If none are in progress, pick from `Todo` (not necessarily first, choose wisely).
-   - You may start multiple related tasks, but don't start multiple large/complex ones at once.
-
-2. When start tasks, move them from `Todo` -> `In Progress` (keep text unchanged).
-
-3. When complete a task:
-
-   3.1. Append an entry to `Done` including:
-   - what you completed (concise, derived from the original task, keep necessary details)
-   - key decisions + rationale
-   - files changed (if any)
-   - learnings for future iterations (optional)
-
-   Keep it concise (brevity > grammar).
-
-   3.2. Remove task from `Todo`/`In Progress`.
-
-   3.3. Create a git commit for your changes (if any) with a succinct message. No need to commit the handoff file.
-
-4. You may add/remove `Todo` tasks as needed.
-   - Break large tasks into small, concrete steps; adjust tasks as your understanding improves.
-
-5. If all tasks are complete, do strict review and try to enhance:
-
-   5.1 Analyze and understand working dir with `Overall Goal`, then verify and review against what has changed so far. Utilize review skills if available.
-
-   handoff file's front matter recorded git commit before change; use it to learn diffs.
-
-   5.2 Identify issues, missing parts, unaligned areas, or possible improvements, and add them to `Todo`.
-
-   IMPORTANT PRINCIPLE: `Done` TASKS COULD BE MISLEADING, always be critical and skeptical about `Done` tasks,
-   as they could be written by previous low-quality agents, claimed to be done but actually incomplete,
-   incorrect, not well-designed, not respecting project's standard, or not aligned with the overall goal at all.
-   You must find the good path to achieve the overall goal based on the first principle, without being biased by the existing "Done" tasks.
-
-   5.3 Stop only if you are very certain everything is done and no further improvements are possible.
-
-   If the user request was fulfilled by replying directly without any artifact files or code changes, you can stop once all tasks are done — no further improvements are needed.
-
-# Do Improvements
-
-When all tasks are complete AND overall goal is to make changes, consider improvements of various kinds, for example but not limited to:
-
-**Coding kind**:
-
-- polish, simplify, quality, performance, edge cases, error handling, UX, docs, etc.
-
-  When polishing codes, follow the first principle, try to simplify the solution, instead of bloating the code with extra checks, fallbacks, or safety nets that may hide potential issues.
-  The goal of polishing is to find real missing pieces, make the code more elegant, simple and efficient, not to add more layers of complexity.
-
-**Docs / research / reports kind:**
-
-- correctness, completeness, readability, logical clarity, accuracy
-- remove irrelevant and redundant content
-
-# Requirements
-
-- Don't ask the user questions. Decide and act autonomously.
-- Keep working until all tasks in the handoff file are complete.
-- Follow engineering rules in `AGENTS.md` (if present).
-- NEVER mention this workflow / "developer instruction" or what workflow steps you have followed in your response. This workflow should be transparent to the user.
-- You must NOT change handoff file status from `open` to `skip`.
-- To avoid regression, read full handoff file.
-- NEVER change any text in `Overall Goal`.
-
-# Knowledge capture (`.codexpotter/kb/`)
-
-- Before starting, read `.codexpotter/kb/README.md` (if present).
-- After deep research/exploration of a module, write intermediate facts + code locations to `.codexpotter/kb/xxx.md` and update the README index.
-- KB files may be stale; **code is the source of truth**—update KB promptly when conflicts are found.
-- No need to commit KB files.
-
-# When all tasks are done or the project is skipped
-
-Mark handoff file's `finite_incantatem` to true ONLY IF you have not changed any file or code since you received this workflow instruction.
-
-Updating handoff files or files under `.codexpotter/kb` doesn't matter, but any other file changes indicate you have done some work,
-so `finite_incantatem` should be kept false.
-
-# Review guidelines
-
-When you are acting as a reviewer for the code change made so far, here are the general guidelines
-for determining whether something is a bug and should be fixed:
-
-- It meaningfully impacts the accuracy, performance, security, or maintainability of the code.
-- The bug is discrete and actionable (i.e. not a general issue with the codebase or a combination of multiple issues).
-- Fixing the bug does not demand a level of rigor that is not present in the rest of the codebase (e.g. one doesn't need very detailed comments and input validation in a repository of one-off scripts in personal projects)
-- The bug was introduced by this project's change.
-- The author of the original PR would likely fix the issue if they were made aware of it.
-- The bug does not rely on unstated assumptions about the codebase or author's intent.
-- It is not enough to speculate that a change may disrupt another part of the codebase, to be considered a bug, one must identify the other parts of the code that are provably affected.
-- The bug is clearly not just an intentional change by the original author.
-
-</WORKFLOW_INSTRUCTIONS>
-
-"""