prompt-language-shell 0.7.4 → 0.7.6

package/README.md

@@ -28,7 +28,7 @@ $ pls list skills
 Here's what I can help with:
 
   - Introspect - list available capabilities and skills
-  - Config - manage and configure system settings
+  - Configure - manage and configure system settings
   - Answer - respond to questions and provide information
   - Execute - run shell commands and process operations
   ```
@@ -74,10 +74,10 @@ Run `pls` without arguments to see the welcome screen.
 ## How It Works
 
 When you make a request, `pls` interprets your intent and creates a structured
-plan breaking down the work into individual tasks. You'll see this plan
+plan breaking down the work into individual tasks. You'll see this schedule
 displayed in your terminal before anything executes.
 
-After reviewing the plan, you can confirm to proceed or cancel if something
+After reviewing the schedule, you can confirm to proceed or cancel if something
 doesn't look right. Once confirmed, `pls` executes each task sequentially and
 shows real-time progress and results.
 

package/dist/services/anthropic.js

@@ -74,8 +74,8 @@ export class AnthropicService {
                 const skillsSection = formatSkillsForPrompt(skills);
                 systemPrompt += skillsSection;
             }
-            // Add config structure for config tool only
-            if (toolName === 'config') {
+            // Add config structure for configure tool only
+            if (toolName === 'configure') {
                 const configStructure = getAvailableConfigStructure();
                 const configuredKeys = getConfiguredKeys();
                 const configSection = '\n## Available Configuration\n\n' +

package/dist/services/router.js

@@ -97,99 +97,121 @@ function executeTasksAfterConfirm(tasks, service, userRequest, handlers) {
         handlers.onError(error instanceof Error ? error.message : String(error));
         return;
     }
-    // Flatten Group tasks to get actual executable subtasks
-    const flattenedTasks = [];
     const scheduledTasks = tasks;
+    // Process tasks in order, preserving Group boundaries
+    // Track consecutive standalone tasks to group them by type
+    let consecutiveStandaloneTasks = [];
+    const processStandaloneTasks = () => {
+        if (consecutiveStandaloneTasks.length === 0)
+            return;
+        // Group consecutive standalone tasks by type
+        const tasksByType = {};
+        for (const type of Object.values(TaskType)) {
+            tasksByType[type] = [];
+        }
+        for (const task of consecutiveStandaloneTasks) {
+            tasksByType[task.type].push(task);
+        }
+        // Route each type group
+        for (const [type, typeTasks] of Object.entries(tasksByType)) {
+            const taskType = type;
+            if (typeTasks.length === 0)
+                continue;
+            routeTasksByType(taskType, typeTasks, service, userRequest, handlers);
+        }
+        consecutiveStandaloneTasks = [];
+    };
+    // Process tasks in original order
     for (const task of scheduledTasks) {
         if (task.type === TaskType.Group && task.subtasks) {
-            // Add all subtasks from the group
-            flattenedTasks.push(...task.subtasks);
+            // Process any accumulated standalone tasks first
+            processStandaloneTasks();
+            // Process Group as separate component
+            if (task.subtasks.length > 0) {
+                const subtasks = task.subtasks;
+                const taskType = subtasks[0].type;
+                routeTasksByType(taskType, subtasks, service, userRequest, handlers);
+            }
         }
         else {
-            // Add non-group tasks as-is
-            flattenedTasks.push(task);
+            // Accumulate standalone task
+            consecutiveStandaloneTasks.push(task);
         }
     }
-    // Group flattened tasks by type - initialize all TaskType keys with empty arrays
-    const tasksByType = {};
-    for (const type of Object.values(TaskType)) {
-        tasksByType[type] = [];
+    // Process any remaining standalone tasks
+    processStandaloneTasks();
+}
+/**
+ * Route tasks by type to appropriate components
+ * Extracted to allow reuse for both Groups and standalone tasks
+ */
+function routeTasksByType(taskType, typeTasks, service, userRequest, handlers) {
+    if (taskType === TaskType.Answer) {
+        // Create separate Answer component for each question
+        for (const task of typeTasks) {
+            handlers.addToQueue(createAnswerDefinition(task.action, service));
+        }
     }
-    for (const task of flattenedTasks) {
-        tasksByType[task.type].push(task);
+    else if (taskType === TaskType.Introspect) {
+        handlers.addToQueue(createIntrospectDefinition(typeTasks, service));
     }
-    // Route each type group appropriately
-    for (const [type, typeTasks] of Object.entries(tasksByType)) {
-        const taskType = type;
-        // Skip empty task groups (pre-initialized but unused)
-        if (typeTasks.length === 0) {
-            continue;
-        }
-        if (taskType === TaskType.Answer) {
-            const question = typeTasks[0].action;
-            handlers.addToQueue(createAnswerDefinition(question, service));
-        }
-        else if (taskType === TaskType.Introspect) {
-            handlers.addToQueue(createIntrospectDefinition(typeTasks, service));
-        }
-        else if (taskType === TaskType.Config) {
-            // Route to Config flow - extract keys from task params
-            const configKeys = typeTasks
-                .map((task) => task.params?.key)
-                .filter((key) => key !== undefined);
-            handlers.addToQueue(createConfigDefinitionWithKeys(configKeys, (config) => {
-                // Save config - Config component will handle completion and feedback
-                try {
-                    // Convert flat dotted keys to nested structure grouped by section
-                    const configBySection = unflattenConfig(config);
-                    // Save each section
-                    for (const [section, sectionConfig] of Object.entries(configBySection)) {
-                        saveConfig(section, sectionConfig);
-                    }
-                }
-                catch (error) {
-                    const errorMessage = error instanceof Error
-                        ? error.message
-                        : 'Failed to save configuration';
-                    throw new Error(errorMessage);
-                }
-            }, (operation) => {
-                handlers.onAborted(operation);
-            }));
-        }
-        else if (taskType === TaskType.Execute) {
-            // Execute tasks with validation
+    else if (taskType === TaskType.Config) {
+        // Route to Config flow - extract keys from task params
+        const configKeys = typeTasks
+            .map((task) => task.params?.key)
+            .filter((key) => key !== undefined);
+        handlers.addToQueue(createConfigDefinitionWithKeys(configKeys, (config) => {
+            // Save config - Config component will handle completion and feedback
             try {
-                const validation = validateExecuteTasks(typeTasks);
-                if (validation.validationErrors.length > 0) {
-                    // Show error feedback for invalid skills
-                    const errorMessages = validation.validationErrors.map((error) => {
-                        const issuesList = error.issues
-                            .map((issue) => `  - ${issue}`)
-                            .join('\n');
-                        return `Invalid skill definition "${error.skill}":\n\n${issuesList}`;
-                    });
-                    handlers.addToQueue(createFeedback(FeedbackType.Failed, errorMessages.join('\n\n')));
-                }
-                else if (validation.missingConfig.length > 0) {
-                    handlers.addToQueue(createValidateDefinition(validation.missingConfig, userRequest, service, (error) => {
-                        handlers.onError(error);
-                    }, () => {
-                        handlers.addToQueue(createExecuteDefinition(typeTasks, service));
-                    }, (operation) => {
-                        handlers.onAborted(operation);
-                    }));
-                }
-                else {
-                    handlers.addToQueue(createExecuteDefinition(typeTasks, service));
+                // Convert flat dotted keys to nested structure grouped by section
+                const configBySection = unflattenConfig(config);
+                // Save each section
+                for (const [section, sectionConfig] of Object.entries(configBySection)) {
+                    saveConfig(section, sectionConfig);
                 }
             }
             catch (error) {
-                // Handle skill reference errors (e.g., unknown skills)
-                const errorMessage = error instanceof Error ? error.message : String(error);
-                const message = createMessage(errorMessage);
-                handlers.addToQueue(message);
+                const errorMessage = error instanceof Error
+                    ? error.message
+                    : 'Failed to save configuration';
+                throw new Error(errorMessage);
             }
+        }, (operation) => {
+            handlers.onAborted(operation);
+        }));
+    }
+    else if (taskType === TaskType.Execute) {
+        // Execute tasks with validation
+        try {
+            const validation = validateExecuteTasks(typeTasks);
+            if (validation.validationErrors.length > 0) {
+                // Show error feedback for invalid skills
+                const errorMessages = validation.validationErrors.map((error) => {
+                    const issuesList = error.issues
+                        .map((issue) => `  - ${issue}`)
+                        .join('\n');
+                    return `Invalid skill definition "${error.skill}":\n\n${issuesList}`;
+                });
+                handlers.addToQueue(createFeedback(FeedbackType.Failed, errorMessages.join('\n\n')));
+            }
+            else if (validation.missingConfig.length > 0) {
+                handlers.addToQueue(createValidateDefinition(validation.missingConfig, userRequest, service, (error) => {
+                    handlers.onError(error);
+                }, () => {
+                    handlers.addToQueue(createExecuteDefinition(typeTasks, service));
+                }, (operation) => {
+                    handlers.onAborted(operation);
+                }));
+            }
+            else {
+                handlers.addToQueue(createExecuteDefinition(typeTasks, service));
+            }
+        }
+        catch (error) {
+            // Handle skill reference errors (e.g., unknown skills)
+            const errorMessage = error instanceof Error ? error.message : String(error);
+            const message = createMessage(errorMessage);
+            handlers.addToQueue(message);
         }
     }
 }

package/dist/services/skills.js

@@ -7,10 +7,10 @@ import { parseSkillMarkdown, displayNameToKey } from './parser.js';
  * Built-in skill names that user skills cannot override
  */
 const BUILT_IN_SKILLS = new Set([
-    'plan',
+    'schedule',
     'execute',
     'answer',
-    'config',
+    'configure',
     'validate',
     'introspect',
 ]);

package/dist/skills/answer.md

@@ -13,8 +13,8 @@ training data.
 ## Execution Flow
 
 This tool is invoked AFTER:
-1. PLAN detected an information request and created a task with type "answer"
-2. User reviewed and confirmed the plan
+1. SCHEDULE detected an information request and created a task with type "answer"
+2. User reviewed and confirmed the schedule
 3. The answer task is now being executed
 
 Your task is to provide a clear, concise answer to the user's question.

package/dist/skills/execute.md

@@ -7,11 +7,11 @@ operations when tasks with type "execute" have been planned and confirmed.
 ## Execution Flow
 
 This tool is invoked AFTER:
-1. PLAN created tasks with type "execute" describing operations to perform
-2. User reviewed and confirmed the plan
+1. SCHEDULE created tasks with type "execute" describing operations to perform
+2. User reviewed and confirmed the schedule
 3. The execute tasks are now being executed
 
-Your task is to translate the planned actions into specific shell commands
+Your task is to translate the scheduled actions into specific shell commands
 that can be run in the terminal.
 
 ## Input

package/dist/skills/introspect.md

@@ -82,7 +82,7 @@ NON-NEGOTIABLE and applies to EVERY response.
 These MUST appear FIRST, in this EXACT sequence:
 
 1. **Introspect** ← ALWAYS FIRST
-2. **Config** ← ALWAYS SECOND
+2. **Configure** ← ALWAYS SECOND
 3. **Answer** ← ALWAYS THIRD
 4. **Execute** ← ALWAYS FOURTH
 
@@ -149,7 +149,7 @@ Examples:
 
 When user asks "list your skills", create an introductory message like
 "here are my capabilities:" followed by tasks for built-in capabilities
-(Introspect, Config, Answer, Execute), then indirect workflow capabilities
+(Introspect, Configure, Answer, Execute), then indirect workflow capabilities
 (Schedule, Validate, Report).
 
 Each task uses type "introspect" with an action describing the
@@ -167,7 +167,7 @@ deploy app skill with its description.
 When user asks "what can you do" and user-defined skills like "process
 data" and "backup files" exist, create an introductory message like "i can
 help with these operations:" followed by all built-in capabilities
-(Introspect, Config, Answer, Execute, Validate, Schedule, Report) plus the
+(Introspect, Configure, Answer, Execute, Validate, Schedule, Report) plus the
 user-defined skills. Each capability and skill becomes a task with type
 "introspect".
 

package/dist/skills/schedule.md

@@ -56,6 +56,14 @@ Every task MUST have a type field. Use the appropriate type:
 a matching skill in the "Available Skills" section. DO NOT create
 `execute` tasks without a corresponding skill.
 
+**Define task params**: When creating a `define` type task, include:
+- `skill`: the skill name that needs variant selection (REQUIRED)
+- `options`: array of option strings describing each variant (REQUIRED)
+
+Example: User "build" without variant → Task with type "define",
+params { skill: "Build Project", options: ["Build project Alpha, the
+main variant", "Build project Beta, the experimental variant"] }
+
 ## Configuration Requests
 
 When user wants to configure or change settings (e.g., "config",
@@ -130,12 +138,15 @@ components (e.g., {project.VARIANT.path}, {env.TYPE.config},
 
 5. **Extract config expressions**: All leaf tasks must include a
    `config` array listing resolved configuration paths:
-   - After resolving variant placeholders, extract all config
-     expressions from the task's execution commands
+   - After resolving variant placeholders, extract **ALL** config
+     expressions from the task's execution commands (every single
+     placeholder in curly braces)
    - List them in dot notation (e.g., "project.beta.repo",
      "env.production.url")
    - The app will check if these exist in ~/.plsrc and prompt for
      missing values
+   - **CRITICAL**: If a task has multiple config placeholders, ALL
+     must be included in the config array
    - Example: Task with `cd {project.beta.repo}` and `cat
      {project.beta.config}` should include config:
      ["project.beta.repo", "project.beta.config"]
@@ -193,27 +204,51 @@ structure.
 
 ## Sequential and Multiple Requests
 
-When the user provides multiple requests separated by commas,
-semicolons, or the word "and":
+**CRITICAL**: When the user provides multiple requests separated by
+commas, semicolons, or the word "and", EVERY request must be
+represented as a separate task. DO NOT skip or merge any requests,
+even if they use the same action verb.
+
+**Sequential Processing Rules:**
+
+1. **Preserve ALL requests**: Each operation in the sequence creates a
+   separate task, in the exact order specified. Count the requests
+   carefully and verify each one is represented.
+
+2. **Same action, different subjects = separate tasks**: Multiple
+   requests using the same verb with different subjects are NOT
+   duplicates:
+   - "explain X, explain Y" → TWO separate answer tasks
+   - "process A, process B" → TWO separate task groups
+   - "show X, show Y" → TWO separate report/answer tasks
 
-1. **Preserve the sequence**: Each operation should be represented as a
-   separate task in the order specified
-2. **Independent skill matching**: For each operation, independently
+3. **Independent skill matching**: For each operation, independently
    check if it matches a skill:
    - If operation matches a skill → extract skill steps as subtasks
    - If operation does NOT match a skill → create "ignore" type task
    - **CRITICAL: Do NOT infer context or create generic execute tasks
      for unmatched operations**
-3. **No merging**: Keep operations separate even if they seem related.
-   The user's sequence is intentional.
+
+4. **No merging**: Keep operations separate even if they seem related.
+   The user's sequence is intentional and must be preserved exactly.
+
+5. **Verify completeness**: Before finalizing, count your tasks and
+   verify the count matches the number of distinct requests in the
+   user's input.
 
 **Examples:**
 
-- "explain docker, build production, then list the changes" → Three
-  separate task groups:
+- "explain docker, process data, explain kubernetes" → THREE
+  separate task groups (not two):
   - Task 1: "Explain Docker" (type: answer)
-  - Task 2: "Build production" (skill-based with subtasks)
-  - Task 3: "List the changes" (type: answer or report)
+  - Task 2: "Process data" (skill-based with subtasks)
+  - Task 3: "Explain Kubernetes" (type: answer)
+
+- "explain tdd, process files, explain tbd" → THREE separate task
+  groups:
+  - Task 1: "Explain Test-Driven Development" (type: answer)
+  - Task 2: "Process files" (skill-based with subtasks)
+  - Task 3: "Explain TBD" (type: answer)
 
 - "process files and validate" where only "process" has a skill →
   - Task 1: "Process files" (skill-based with subtasks)
@@ -270,14 +305,20 @@ Before finalizing, verify there are no duplicates.
      simple terms")
    - "list X completely" = ONE task (not "list X" + "be complete")
 
-2. **Synonymous verbs are duplicates**: Different verbs meaning the
-   same thing are duplicates
+2. **Synonymous verbs with SAME subject are duplicates**: Different
+   verbs meaning the same thing on the SAME subject are duplicates
    - "explain X" + "describe X" = DUPLICATE (choose one)
    - "show X" + "display X" = DUPLICATE (choose one)
    - "check X" + "verify X" = DUPLICATE (choose one)
 
-3. **Redundant operations are duplicates**: If two tasks would perform
-   the same operation
+3. **Same verb with DIFFERENT subjects are NOT duplicates**: This is
+   a sequential request and each must be preserved
+   - "explain X" + "explain Y" = TWO SEPARATE TASKS
+   - "process A" + "process B" = TWO SEPARATE TASKS
+   - "show X" + "show Y" = TWO SEPARATE TASKS
+
+4. **Redundant operations are duplicates**: If two tasks would perform
+   the same operation on the same target
    - "install and set up dependencies" = ONE task (setup is part of
      install)
    - "check and verify disk space" = ONE task (verify means check)
@@ -286,17 +327,22 @@ Before finalizing, verify there are no duplicates.
 
 Before finalizing the schedule, perform strict validation:
 
-1. Each task represents a distinct step in the user's request
-2. Tasks are ordered in the logical sequence they should execute
-3. Each task is clearly defined with specific action and parameters
-4. Tasks are NOT merged - preserve the user's intended sequence
-5. All operations from the user's request are represented
-6. No semantic duplicates exist (same operation with different words)
-7. For skill-based tasks, verify all required params are included
+1. **Count verification**: Count the distinct requests in the user's
+   input and verify your task list has the same number of top-level
+   tasks. If counts don't match, you've skipped or merged requests.
+2. Each task represents a distinct step in the user's request
+3. Tasks are ordered in the logical sequence they should execute
+4. Each task is clearly defined with specific action and parameters
+5. Tasks are NOT merged - preserve the user's intended sequence
+6. All operations from the user's request are represented (check each
+   one individually)
+7. No semantic duplicates exist (same verb on same subject), but same
+   verb on different subjects creates separate tasks
+8. For skill-based tasks, verify all required params are included
    (skill name, variant if applicable)
-8. For leaf tasks, verify type field is present
-9. For leaf tasks with config placeholders, verify config array is
-   populated
+9. For leaf tasks, verify type field is present
+10. For leaf tasks with config placeholders, verify config array is
+    populated
 
 ## Critical Guidelines
 

package/dist/tools/answer.tool.js

@@ -1,6 +1,6 @@
 export const answerTool = {
     name: 'answer',
-    description: 'Answer questions and provide up-to-date information using web search. Called after PLAN has identified an answer request and user has confirmed. Searches the web for current data and provides concise, helpful responses formatted for terminal display.',
+    description: 'Answer questions and provide up-to-date information using web search. Called after SCHEDULE has identified an answer request and user has confirmed. Searches the web for current data and provides concise, helpful responses formatted for terminal display.',
     input_schema: {
         type: 'object',
         properties: {

package/dist/tools/configure.tool.js

@@ -1,6 +1,6 @@
 export const configureTool = {
     name: 'configure',
-    description: 'Determine which configuration settings to show based on user query. Receives available config keys with descriptions and returns which keys the user wants to configure.',
+    description: 'Determine which configuration settings to show based on user query. Receives available configuration keys with descriptions and returns which keys the user wants to configure.',
     input_schema: {
         type: 'object',
         properties: {

package/dist/tools/execute.tool.js

@@ -1,6 +1,6 @@
 export const executeTool = {
     name: 'execute',
-    description: 'Execute shell commands from planned tasks. Translates task descriptions into specific shell commands that can be run in the terminal. Called after PLAN has created execute tasks and user has confirmed.',
+    description: 'Execute shell commands from scheduled tasks. Translates task descriptions into specific shell commands that can be run in the terminal. Called after SCHEDULE has created execute tasks and user has confirmed.',
     input_schema: {
         type: 'object',
         properties: {

package/dist/tools/introspect.tool.js

@@ -1,6 +1,6 @@
 export const introspectTool = {
     name: 'introspect',
-    description: 'Execute a task with type "introspect" to list available capabilities and skills. Called after PLAN has identified an introspection request and user has confirmed. Takes the task action and optional filter parameter to present built-in capabilities and user-defined skills.',
+    description: 'Execute a task with type "introspect" to list available capabilities and skills. Called after SCHEDULE has identified an introspection request and user has confirmed. Takes the task action and optional filter parameter to present built-in capabilities and user-defined skills.',
     input_schema: {
         type: 'object',
         properties: {
@@ -10,13 +10,13 @@ export const introspectTool = {
             },
             tasks: {
                 type: 'array',
-                description: 'Array of capabilities, each with type "introspect". Include built-in capabilities (PLAN, INTROSPECT, ANSWER, EXECUTE, REPORT, CONFIG) and user-defined skills from the Available Skills section.',
+                description: 'Array of capabilities, each with type "introspect". Include built-in capabilities (SCHEDULE, INTROSPECT, ANSWER, EXECUTE, REPORT, CONFIGURE) and user-defined skills from the Available Skills section.',
                 items: {
                     type: 'object',
                     properties: {
                         action: {
                             type: 'string',
-                            description: 'Capability name and description. Format: "NAME: Brief description". Maximum 64 characters. Examples: "PLAN: Break down requests into steps", "Deploy App: Build and deploy application".',
+                            description: 'Capability name and description. Format: "NAME: Brief description". Maximum 64 characters. Examples: "SCHEDULE: Break down requests into steps", "Deploy App: Build and deploy application".',
                         },
                         type: {
                             type: 'string',

package/dist/tools/schedule.tool.js

@@ -27,7 +27,7 @@ export const scheduleTool = {
                     },
                     type: {
                         type: 'string',
-                        description: 'Type: "group" for parent tasks with subtasks. For leaf tasks: "config", "execute", "answer", "introspect", "report", "define", "ignore"',
+                        description: 'Type: "group" for parent tasks with subtasks. For leaf tasks: "configure", "execute", "answer", "introspect", "report", "define", "ignore"',
                     },
                     params: {
                         type: 'object',

package/dist/ui/Introspect.js

@@ -11,7 +11,7 @@ import { ensureMinimumTime } from '../services/timing.js';
 import { Spinner } from './Spinner.js';
 const MIN_PROCESSING_TIME = 1000;
 const BUILT_IN_CAPABILITIES = new Set([
-    'CONFIG',
+    'CONFIGURE',
     'SCHEDULE',
     'INTROSPECT',
     'ANSWER',

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "prompt-language-shell",
-  "version": "0.7.4",
+  "version": "0.7.6",
   "description": "Your personal command-line concierge. Ask politely, and it gets things done.",
   "type": "module",
   "main": "dist/index.js",
@@ -17,8 +17,9 @@
     "dev": "npm run build && tsc --watch",
     "prepare": "husky",
     "prepublishOnly": "npm run check",
-    "test": "vitest run",
-    "test:watch": "vitest",
+    "test": "vitest run --exclude 'tests/integration/*.test.tsx'",
+    "test:watch": "vitest --exclude 'tests/integration/*.test.tsx'",
+    "test:llm": "vitest run tests/integration/schedule*.test.tsx",
     "format": "prettier --write '**/*.{ts,tsx}'",
     "format:check": "prettier --check '**/*.{ts,tsx}'",
     "lint": "eslint .",