@iaforged/context-code 1.3.5 → 1.3.6

package/dist/src/skills/bundled/scheduleRemoteAgents.js

@@ -115,158 +115,158 @@ function buildPrompt(opts) {
         : BASE_QUESTION;
     const firstStep = userArgs
         ? `The user has already told you what they want (see User Request at the bottom). Skip the initial question and go directly to the matching workflow.`
-        : `Your FIRST action must be a single ${ASK_USER_QUESTION_TOOL_NAME} tool call (no preamble). Use this EXACT string for the \`question\` field — do not paraphrase or shorten it:
-
-${jsonStringify(initialQuestion)}
-
+        : `Your FIRST action must be a single ${ASK_USER_QUESTION_TOOL_NAME} tool call (no preamble). Use this EXACT string for the \`question\` field — do not paraphrase or shorten it:
+
+${jsonStringify(initialQuestion)}
+
 Set \`header: "Action"\` and offer the four actions (create/list/update/run) as options. After the user picks, follow the matching workflow below.`;
-    return `# Schedule Remote Agents
-
-You are helping the user schedule, update, list, or run **remote** Context Code agents. These are NOT local cron jobs — each trigger spawns a fully isolated remote session (CCR) in Anthropic's cloud infrastructure on a cron schedule. The agent runs in a sandboxed environment with its own git checkout, tools, and optional MCP connections.
-
-## First Step
-
-${firstStep}
-${setupNotesSection}
-
-## What You Can Do
-
-Use the \`${REMOTE_TRIGGER_TOOL_NAME}\` tool (load it first with \`ToolSearch select:${REMOTE_TRIGGER_TOOL_NAME}\`; auth is handled in-process — do not use curl):
-
-- \`{action: "list"}\` — list all triggers
-- \`{action: "get", trigger_id: "..."}\` — fetch one trigger
-- \`{action: "create", body: {...}}\` — create a trigger
-- \`{action: "update", trigger_id: "...", body: {...}}\` — partial update
-- \`{action: "run", trigger_id: "..."}\` — run a trigger now
-
-You CANNOT delete triggers. If the user asks to delete, direct them to: https://claude.ai/code/scheduled
-
-## Create body shape
-
-\`\`\`json
-{
-  "name": "AGENT_NAME",
-  "cron_expression": "CRON_EXPR",
-  "enabled": true,
-  "job_config": {
-    "ccr": {
-      "environment_id": "ENVIRONMENT_ID",
-      "session_context": {
-        "model": "claude-sonnet-4-6",
-        "sources": [
-          {"git_repository": {"url": "${gitRepoUrl || 'https://github.com/ORG/REPO'}"}}
-        ],
-        "allowed_tools": ["Bash", "Read", "Write", "Edit", "Glob", "Grep"]
-      },
-      "events": [
-        {"data": {
-          "uuid": "<lowercase v4 uuid>",
-          "session_id": "",
-          "type": "user",
-          "parent_tool_use_id": null,
-          "message": {"content": "PROMPT_HERE", "role": "user"}
-        }}
-      ]
-    }
-  }
-}
-\`\`\`
-
-Generate a fresh lowercase UUID for \`events[].data.uuid\` yourself.
-
-## Available MCP Connectors
-
-These are the user's currently connected claude.ai MCP connectors:
-
-${connectorsInfo}
-
-When attaching connectors to a trigger, use the \`connector_uuid\` and \`name\` shown above (the name is already sanitized to only contain letters, numbers, hyphens, and underscores), and the connector's URL. The \`name\` field in \`mcp_connections\` must only contain \`[a-zA-Z0-9_-]\` — dots and spaces are NOT allowed.
-
-**Important:** Infer what services the agent needs from the user's description. For example, if they say "check Datadog and Slack me errors," the agent needs both Datadog and Slack connectors. Cross-reference against the list above and warn if any required service isn't connected. If a needed connector is missing, direct the user to https://claude.ai/settings/connectors to connect it first.
-
-## Environments
-
-Every trigger requires an \`environment_id\` in the job config. This determines where the remote agent runs. Ask the user which environment to use.
-
-${environmentsInfo}
-
-Use the \`id\` value as the \`environment_id\` in \`job_config.ccr.environment_id\`.
-${createdEnvironment ? `\n**Note:** A new environment \`${createdEnvironment.name}\` (id: \`${createdEnvironment.environment_id}\`) was just created for the user because they had none. Use this id for \`job_config.ccr.environment_id\` and mention the creation when you confirm the trigger config.\n` : ''}
-
-## API Field Reference
-
-### Create Trigger — Required Fields
-- \`name\` (string) — A descriptive name
-- \`cron_expression\` (string) — 5-field cron. **Minimum interval is 1 hour.**
-- \`job_config\` (object) — Session configuration (see structure above)
-
-### Create Trigger — Optional Fields
-- \`enabled\` (boolean, default: true)
-- \`mcp_connections\` (array) — MCP servers to attach:
-  \`\`\`json
-  [{"connector_uuid": "uuid", "name": "server-name", "url": "https://..."}]
-  \`\`\`
-
-### Update Trigger — Optional Fields
-All fields optional (partial update):
-- \`name\`, \`cron_expression\`, \`enabled\`, \`job_config\`
-- \`mcp_connections\` — Replace MCP connections
-- \`clear_mcp_connections\` (boolean) — Remove all MCP connections
-
-### Cron Expression Examples
-
-The user's local timezone is **${userTimezone}**. Cron expressions are always in UTC. When the user says a local time, convert it to UTC for the cron expression but confirm with them: "9am ${userTimezone} = Xam UTC, so the cron would be \`0 X * * 1-5\`."
-
-- \`0 9 * * 1-5\` — Every weekday at 9am **UTC**
-- \`0 */2 * * *\` — Every 2 hours
-- \`0 0 * * *\` — Daily at midnight **UTC**
-- \`30 14 * * 1\` — Every Monday at 2:30pm **UTC**
-- \`0 8 1 * *\` — First of every month at 8am **UTC**
-
-Minimum interval is 1 hour. \`*/30 * * * *\` will be rejected.
-
-## Workflow
-
-### CREATE a new trigger:
-
-1. **Understand the goal** — Ask what they want the remote agent to do. What repo(s)? What task? Remind them that the agent runs remotely — it won't have access to their local machine, local files, or local environment variables.
-2. **Craft the prompt** — Help them write an effective agent prompt. Good prompts are:
-   - Specific about what to do and what success looks like
-   - Clear about which files/areas to focus on
-   - Explicit about what actions to take (open PRs, commit, just analyze, etc.)
-3. **Set the schedule** — Ask when and how often. The user's timezone is ${userTimezone}. When they say a time (e.g., "every morning at 9am"), assume they mean their local time and convert to UTC for the cron expression. Always confirm the conversion: "9am ${userTimezone} = Xam UTC."
-4. **Choose the model** — Default to \`claude-sonnet-4-6\`. Tell the user which model you're defaulting to and ask if they want a different one.
-5. **Validate connections** — Infer what services the agent will need from the user's description. For example, if they say "check Datadog and Slack me errors," the agent needs both Datadog and Slack MCP connectors. Cross-reference with the connectors list above. If any are missing, warn the user and link them to https://claude.ai/settings/connectors to connect first.${gitRepoUrl ? ` The default git repo is already set to \`${gitRepoUrl}\`. Ask the user if this is the right repo or if they need a different one.` : ' Ask which git repos the remote agent needs cloned into its environment.'}
-6. **Review and confirm** — Show the full configuration before creating. Let them adjust.
-7. **Create it** \u2014 Call \`${REMOTE_TRIGGER_TOOL_NAME}\` with \`action: "create"\` and show the result. The response includes the trigger ID. Always output a link at the end: \`https://claude.ai/code/scheduled/{TRIGGER_ID}\`
-
-### UPDATE a trigger:
-
-1. List triggers first so they can pick one
-2. Ask what they want to change
-3. Show current vs proposed value
-4. Confirm and update
-
-### LIST triggers:
-
-1. Fetch and display in a readable format
-2. Show: name, schedule (human-readable), enabled/disabled, next run, repo(s)
-
-### RUN NOW:
-
-1. List triggers if they haven't specified which one
-2. Confirm which trigger
-3. Execute and confirm
-
-## Important Notes
-
-- These are REMOTE agents — they run in Anthropic's cloud, not on the user's machine. They cannot access local files, local services, or local environment variables.
-- Always convert cron to human-readable when displaying
-- Default to \`enabled: true\` unless user says otherwise
-- Accept GitHub URLs in any format (https://github.com/org/repo, org/repo, etc.) and normalize to the full HTTPS URL (without .git suffix)
-- The prompt is the most important part — spend time getting it right. The remote agent starts with zero context, so the prompt must be self-contained.
-- To delete a trigger, direct users to https://claude.ai/code/scheduled
-${needsGitHubAccessReminder ? `- If the user's request seems to require GitHub repo access (e.g. cloning a repo, opening PRs, reading code), remind them that ${getFeatureValue_CACHED_MAY_BE_STALE('tengu_cobalt_lantern', false) ? "they should run /web-setup to connect their GitHub account (or install the Claude GitHub App on the repo as an alternative) — otherwise the remote agent won't be able to access it" : "they need the Claude GitHub App installed on the repo — otherwise the remote agent won't be able to access it"}.` : ''}
+    return `# Schedule Remote Agents
+
+You are helping the user schedule, update, list, or run **remote** Context Code agents. These are NOT local cron jobs — each trigger spawns a fully isolated remote session (CCR) in Anthropic's cloud infrastructure on a cron schedule. The agent runs in a sandboxed environment with its own git checkout, tools, and optional MCP connections.
+
+## First Step
+
+${firstStep}
+${setupNotesSection}
+
+## What You Can Do
+
+Use the \`${REMOTE_TRIGGER_TOOL_NAME}\` tool (load it first with \`ToolSearch select:${REMOTE_TRIGGER_TOOL_NAME}\`; auth is handled in-process — do not use curl):
+
+- \`{action: "list"}\` — list all triggers
+- \`{action: "get", trigger_id: "..."}\` — fetch one trigger
+- \`{action: "create", body: {...}}\` — create a trigger
+- \`{action: "update", trigger_id: "...", body: {...}}\` — partial update
+- \`{action: "run", trigger_id: "..."}\` — run a trigger now
+
+You CANNOT delete triggers. If the user asks to delete, direct them to: https://claude.ai/code/scheduled
+
+## Create body shape
+
+\`\`\`json
+{
+  "name": "AGENT_NAME",
+  "cron_expression": "CRON_EXPR",
+  "enabled": true,
+  "job_config": {
+    "ccr": {
+      "environment_id": "ENVIRONMENT_ID",
+      "session_context": {
+        "model": "claude-sonnet-4-6",
+        "sources": [
+          {"git_repository": {"url": "${gitRepoUrl || 'https://github.com/ORG/REPO'}"}}
+        ],
+        "allowed_tools": ["Bash", "Read", "Write", "Edit", "Glob", "Grep"]
+      },
+      "events": [
+        {"data": {
+          "uuid": "<lowercase v4 uuid>",
+          "session_id": "",
+          "type": "user",
+          "parent_tool_use_id": null,
+          "message": {"content": "PROMPT_HERE", "role": "user"}
+        }}
+      ]
+    }
+  }
+}
+\`\`\`
+
+Generate a fresh lowercase UUID for \`events[].data.uuid\` yourself.
+
+## Available MCP Connectors
+
+These are the user's currently connected claude.ai MCP connectors:
+
+${connectorsInfo}
+
+When attaching connectors to a trigger, use the \`connector_uuid\` and \`name\` shown above (the name is already sanitized to only contain letters, numbers, hyphens, and underscores), and the connector's URL. The \`name\` field in \`mcp_connections\` must only contain \`[a-zA-Z0-9_-]\` — dots and spaces are NOT allowed.
+
+**Important:** Infer what services the agent needs from the user's description. For example, if they say "check Datadog and Slack me errors," the agent needs both Datadog and Slack connectors. Cross-reference against the list above and warn if any required service isn't connected. If a needed connector is missing, direct the user to https://claude.ai/settings/connectors to connect it first.
+
+## Environments
+
+Every trigger requires an \`environment_id\` in the job config. This determines where the remote agent runs. Ask the user which environment to use.
+
+${environmentsInfo}
+
+Use the \`id\` value as the \`environment_id\` in \`job_config.ccr.environment_id\`.
+${createdEnvironment ? `\n**Note:** A new environment \`${createdEnvironment.name}\` (id: \`${createdEnvironment.environment_id}\`) was just created for the user because they had none. Use this id for \`job_config.ccr.environment_id\` and mention the creation when you confirm the trigger config.\n` : ''}
+
+## API Field Reference
+
+### Create Trigger — Required Fields
+- \`name\` (string) — A descriptive name
+- \`cron_expression\` (string) — 5-field cron. **Minimum interval is 1 hour.**
+- \`job_config\` (object) — Session configuration (see structure above)
+
+### Create Trigger — Optional Fields
+- \`enabled\` (boolean, default: true)
+- \`mcp_connections\` (array) — MCP servers to attach:
+  \`\`\`json
+  [{"connector_uuid": "uuid", "name": "server-name", "url": "https://..."}]
+  \`\`\`
+
+### Update Trigger — Optional Fields
+All fields optional (partial update):
+- \`name\`, \`cron_expression\`, \`enabled\`, \`job_config\`
+- \`mcp_connections\` — Replace MCP connections
+- \`clear_mcp_connections\` (boolean) — Remove all MCP connections
+
+### Cron Expression Examples
+
+The user's local timezone is **${userTimezone}**. Cron expressions are always in UTC. When the user says a local time, convert it to UTC for the cron expression but confirm with them: "9am ${userTimezone} = Xam UTC, so the cron would be \`0 X * * 1-5\`."
+
+- \`0 9 * * 1-5\` — Every weekday at 9am **UTC**
+- \`0 */2 * * *\` — Every 2 hours
+- \`0 0 * * *\` — Daily at midnight **UTC**
+- \`30 14 * * 1\` — Every Monday at 2:30pm **UTC**
+- \`0 8 1 * *\` — First of every month at 8am **UTC**
+
+Minimum interval is 1 hour. \`*/30 * * * *\` will be rejected.
+
+## Workflow
+
+### CREATE a new trigger:
+
+1. **Understand the goal** — Ask what they want the remote agent to do. What repo(s)? What task? Remind them that the agent runs remotely — it won't have access to their local machine, local files, or local environment variables.
+2. **Craft the prompt** — Help them write an effective agent prompt. Good prompts are:
+   - Specific about what to do and what success looks like
+   - Clear about which files/areas to focus on
+   - Explicit about what actions to take (open PRs, commit, just analyze, etc.)
+3. **Set the schedule** — Ask when and how often. The user's timezone is ${userTimezone}. When they say a time (e.g., "every morning at 9am"), assume they mean their local time and convert to UTC for the cron expression. Always confirm the conversion: "9am ${userTimezone} = Xam UTC."
+4. **Choose the model** — Default to \`claude-sonnet-4-6\`. Tell the user which model you're defaulting to and ask if they want a different one.
+5. **Validate connections** — Infer what services the agent will need from the user's description. For example, if they say "check Datadog and Slack me errors," the agent needs both Datadog and Slack MCP connectors. Cross-reference with the connectors list above. If any are missing, warn the user and link them to https://claude.ai/settings/connectors to connect first.${gitRepoUrl ? ` The default git repo is already set to \`${gitRepoUrl}\`. Ask the user if this is the right repo or if they need a different one.` : ' Ask which git repos the remote agent needs cloned into its environment.'}
+6. **Review and confirm** — Show the full configuration before creating. Let them adjust.
+7. **Create it** \u2014 Call \`${REMOTE_TRIGGER_TOOL_NAME}\` with \`action: "create"\` and show the result. The response includes the trigger ID. Always output a link at the end: \`https://claude.ai/code/scheduled/{TRIGGER_ID}\`
+
+### UPDATE a trigger:
+
+1. List triggers first so they can pick one
+2. Ask what they want to change
+3. Show current vs proposed value
+4. Confirm and update
+
+### LIST triggers:
+
+1. Fetch and display in a readable format
+2. Show: name, schedule (human-readable), enabled/disabled, next run, repo(s)
+
+### RUN NOW:
+
+1. List triggers if they haven't specified which one
+2. Confirm which trigger
+3. Execute and confirm
+
+## Important Notes
+
+- These are REMOTE agents — they run in Anthropic's cloud, not on the user's machine. They cannot access local files, local services, or local environment variables.
+- Always convert cron to human-readable when displaying
+- Default to \`enabled: true\` unless user says otherwise
+- Accept GitHub URLs in any format (https://github.com/org/repo, org/repo, etc.) and normalize to the full HTTPS URL (without .git suffix)
+- The prompt is the most important part — spend time getting it right. The remote agent starts with zero context, so the prompt must be self-contained.
+- To delete a trigger, direct users to https://claude.ai/code/scheduled
+${needsGitHubAccessReminder ? `- If the user's request seems to require GitHub repo access (e.g. cloning a repo, opening PRs, reading code), remind them that ${getFeatureValue_CACHED_MAY_BE_STALE('tengu_cobalt_lantern', false) ? "they should run /web-setup to connect their GitHub account (or install the Claude GitHub App on the repo as an alternative) — otherwise the remote agent won't be able to access it" : "they need the Claude GitHub App installed on the repo — otherwise the remote agent won't be able to access it"}.` : ''}
 ${userArgs ? `\n## User Request\n\nThe user said: "${userArgs}"\n\nStart by understanding their intent and working through the appropriate workflow above.` : ''}`;
 }
 export function registerScheduleRemoteAgentsSkill() {

package/dist/src/skills/bundled/skillify.js

@@ -15,140 +15,140 @@ function extractUserMessages(messages) {
     })
         .filter(text => text.trim().length > 0);
 }
-const SKILLIFY_PROMPT = `# Skillify {{userDescriptionBlock}}
-
-You are capturing this session's repeatable process as a reusable skill.
-
-## Your Session Context
-
-Here is the session memory summary:
-<session_memory>
-{{sessionMemory}}
-</session_memory>
-
-Here are the user's messages during this session. Pay attention to how they steered the process, to help capture their detailed preferences in the skill:
-<user_messages>
-{{userMessages}}
-</user_messages>
-
-## Your Task
-
-### Step 1: Analyze the Session
-
-Before asking any questions, analyze the session to identify:
-- What repeatable process was performed
-- What the inputs/parameters were
-- The distinct steps (in order)
-- The success artifacts/criteria (e.g. not just "writing code," but "an open PR with CI fully passing") for each step
-- Where the user corrected or steered you
-- What tools and permissions were needed
-- What agents were used
-- What the goals and success artifacts were
-
-### Step 2: Interview the User
-
-You will use the AskUserQuestion to understand what the user wants to automate. Important notes:
-- Use AskUserQuestion for ALL questions! Never ask questions via plain text.
-- For each round, iterate as much as needed until the user is happy.
-- The user always has a freeform "Other" option to type edits or feedback -- do NOT add your own "Needs tweaking" or "I'll provide edits" option. Just offer the substantive choices.
-
-**Round 1: High level confirmation**
-- Suggest a name and description for the skill based on your analysis. Ask the user to confirm or rename.
-- Suggest high-level goal(s) and specific success criteria for the skill.
-
-**Round 2: More details**
-- Present the high-level steps you identified as a numbered list. Tell the user you will dig into the detail in the next round.
-- If you think the skill will require arguments, suggest arguments based on what you observed. Make sure you understand what someone would need to provide.
-- If it's not clear, ask if this skill should run inline (in the current conversation) or forked (as a sub-agent with its own context). Forked is better for self-contained tasks that don't need mid-process user input; inline is better when the user wants to steer mid-process.
-- Ask where the skill should be saved. Suggest a default based on context (repo-specific workflows → repo, cross-repo personal workflows → user). Options:
-  - **This repo** (\`.context/skills/<name>/SKILL.md\`) — for workflows specific to this project
-  - **Personal** (\`~/.context/skills/<name>/SKILL.md\`) — follows you across all repos
-
-**Round 3: Breaking down each step**
-For each major step, if it's not glaringly obvious, ask:
-- What does this step produce that later steps need? (data, artifacts, IDs)
-- What proves that this step succeeded, and that we can move on?
-- Should the user be asked to confirm before proceeding? (especially for irreversible actions like merging, sending messages, or destructive operations)
-- Are any steps independent and could run in parallel? (e.g., posting to Slack and monitoring CI at the same time)
-- How should the skill be executed? (e.g. always use a Task agent to conduct code review, or invoke an agent team for a set of concurrent steps)
-- What are the hard constraints or hard preferences? Things that must or must not happen?
-
-You may do multiple rounds of AskUserQuestion here, one round per step, especially if there are more than 3 steps or many clarification questions. Iterate as much as needed.
-
-IMPORTANT: Pay special attention to places where the user corrected you during the session, to help inform your design.
-
-**Round 4: Final questions**
-- Confirm when this skill should be invoked, and suggest/confirm trigger phrases too. (e.g. For a cherrypick workflow you could say: Use when the user wants to cherry-pick a PR to a release branch. Examples: 'cherry-pick to release', 'CP this PR', 'hotfix.')
-- You can also ask for any other gotchas or things to watch out for, if it's still unclear.
-
-Stop interviewing once you have enough information. IMPORTANT: Don't over-ask for simple processes!
-
-### Step 3: Write the SKILL.md
-
-Create the skill directory and file at the location the user chose in Round 2.
-
-Use this format:
-
-\`\`\`markdown
----
-name: {{skill-name}}
-description: {{one-line description}}
-allowed-tools:
-  {{list of tool permission patterns observed during session}}
-when_to_use: {{detailed description of when Claude should automatically invoke this skill, including trigger phrases and example user messages}}
-argument-hint: "{{hint showing argument placeholders}}"
-arguments:
-  {{list of argument names}}
-context: {{inline or fork -- omit for inline}}
----
-
-# {{Skill Title}}
-Description of skill
-
-## Inputs
-- \`$arg_name\`: Description of this input
-
-## Goal
-Clearly stated goal for this workflow. Best if you have clearly defined artifacts or criteria for completion.
-
-## Steps
-
-### 1. Step Name
-What to do in this step. Be specific and actionable. Include commands when appropriate.
-
-**Success criteria**: ALWAYS include this! This shows that the step is done and we can move on. Can be a list.
-
-IMPORTANT: see the next section below for the per-step annotations you can optionally include for each step.
-
-...
-\`\`\`
-
-**Per-step annotations**:
-- **Success criteria** is REQUIRED on every step. This helps the model understand what the user expects from their workflow, and when it should have the confidence to move on.
-- **Execution**: \`Direct\` (default), \`Task agent\` (straightforward subagents), \`Teammate\` (agent with true parallelism and inter-agent communication), or \`[human]\` (user does it). Only needs specifying if not Direct.
-- **Artifacts**: Data this step produces that later steps need (e.g., PR number, commit SHA). Only include if later steps depend on it.
-- **Human checkpoint**: When to pause and ask the user before proceeding. Include for irreversible actions (merging, sending messages), error judgment (merge conflicts), or output review.
-- **Rules**: Hard rules for the workflow. User corrections during the reference session can be especially useful here.
-
-**Step structure tips:**
-- Steps that can run concurrently use sub-numbers: 3a, 3b
-- Steps requiring the user to act get \`[human]\` in the title
-- Keep simple skills simple -- a 2-step skill doesn't need annotations on every step
-
-**Frontmatter rules:**
-- \`allowed-tools\`: Minimum permissions needed (use patterns like \`Bash(gh:*)\` not \`Bash\`)
-- \`context\`: Only set \`context: fork\` for self-contained skills that don't need mid-process user input.
-- \`when_to_use\` is CRITICAL -- tells the model when to auto-invoke. Start with "Use when..." and include trigger phrases. Example: "Use when the user wants to cherry-pick a PR to a release branch. Examples: 'cherry-pick to release', 'CP this PR', 'hotfix'."
-- \`arguments\` and \`argument-hint\`: Only include if the skill takes parameters. Use \`$name\` in the body for substitution.
-
-### Step 4: Confirm and Save
-
-Before writing the file, output the complete SKILL.md content as a yaml code block in your response so the user can review it with proper syntax highlighting. Then ask for confirmation using AskUserQuestion with a simple question like "Does this SKILL.md look good to save?" — do NOT use the body field, keep the question concise.
-
-After writing, tell the user:
-- Where the skill was saved
-- How to invoke it: \`/{{skill-name}} [arguments]\`
-- That they can edit the SKILL.md directly to refine it
+const SKILLIFY_PROMPT = `# Skillify {{userDescriptionBlock}}
+
+You are capturing this session's repeatable process as a reusable skill.
+
+## Your Session Context
+
+Here is the session memory summary:
+<session_memory>
+{{sessionMemory}}
+</session_memory>
+
+Here are the user's messages during this session. Pay attention to how they steered the process, to help capture their detailed preferences in the skill:
+<user_messages>
+{{userMessages}}
+</user_messages>
+
+## Your Task
+
+### Step 1: Analyze the Session
+
+Before asking any questions, analyze the session to identify:
+- What repeatable process was performed
+- What the inputs/parameters were
+- The distinct steps (in order)
+- The success artifacts/criteria (e.g. not just "writing code," but "an open PR with CI fully passing") for each step
+- Where the user corrected or steered you
+- What tools and permissions were needed
+- What agents were used
+- What the goals and success artifacts were
+
+### Step 2: Interview the User
+
+You will use the AskUserQuestion to understand what the user wants to automate. Important notes:
+- Use AskUserQuestion for ALL questions! Never ask questions via plain text.
+- For each round, iterate as much as needed until the user is happy.
+- The user always has a freeform "Other" option to type edits or feedback -- do NOT add your own "Needs tweaking" or "I'll provide edits" option. Just offer the substantive choices.
+
+**Round 1: High level confirmation**
+- Suggest a name and description for the skill based on your analysis. Ask the user to confirm or rename.
+- Suggest high-level goal(s) and specific success criteria for the skill.
+
+**Round 2: More details**
+- Present the high-level steps you identified as a numbered list. Tell the user you will dig into the detail in the next round.
+- If you think the skill will require arguments, suggest arguments based on what you observed. Make sure you understand what someone would need to provide.
+- If it's not clear, ask if this skill should run inline (in the current conversation) or forked (as a sub-agent with its own context). Forked is better for self-contained tasks that don't need mid-process user input; inline is better when the user wants to steer mid-process.
+- Ask where the skill should be saved. Suggest a default based on context (repo-specific workflows → repo, cross-repo personal workflows → user). Options:
+  - **This repo** (\`.context/skills/<name>/SKILL.md\`) — for workflows specific to this project
+  - **Personal** (\`~/.context/skills/<name>/SKILL.md\`) — follows you across all repos
+
+**Round 3: Breaking down each step**
+For each major step, if it's not glaringly obvious, ask:
+- What does this step produce that later steps need? (data, artifacts, IDs)
+- What proves that this step succeeded, and that we can move on?
+- Should the user be asked to confirm before proceeding? (especially for irreversible actions like merging, sending messages, or destructive operations)
+- Are any steps independent and could run in parallel? (e.g., posting to Slack and monitoring CI at the same time)
+- How should the skill be executed? (e.g. always use a Task agent to conduct code review, or invoke an agent team for a set of concurrent steps)
+- What are the hard constraints or hard preferences? Things that must or must not happen?
+
+You may do multiple rounds of AskUserQuestion here, one round per step, especially if there are more than 3 steps or many clarification questions. Iterate as much as needed.
+
+IMPORTANT: Pay special attention to places where the user corrected you during the session, to help inform your design.
+
+**Round 4: Final questions**
+- Confirm when this skill should be invoked, and suggest/confirm trigger phrases too. (e.g. For a cherrypick workflow you could say: Use when the user wants to cherry-pick a PR to a release branch. Examples: 'cherry-pick to release', 'CP this PR', 'hotfix.')
+- You can also ask for any other gotchas or things to watch out for, if it's still unclear.
+
+Stop interviewing once you have enough information. IMPORTANT: Don't over-ask for simple processes!
+
+### Step 3: Write the SKILL.md
+
+Create the skill directory and file at the location the user chose in Round 2.
+
+Use this format:
+
+\`\`\`markdown
+---
+name: {{skill-name}}
+description: {{one-line description}}
+allowed-tools:
+  {{list of tool permission patterns observed during session}}
+when_to_use: {{detailed description of when Claude should automatically invoke this skill, including trigger phrases and example user messages}}
+argument-hint: "{{hint showing argument placeholders}}"
+arguments:
+  {{list of argument names}}
+context: {{inline or fork -- omit for inline}}
+---
+
+# {{Skill Title}}
+Description of skill
+
+## Inputs
+- \`$arg_name\`: Description of this input
+
+## Goal
+Clearly stated goal for this workflow. Best if you have clearly defined artifacts or criteria for completion.
+
+## Steps
+
+### 1. Step Name
+What to do in this step. Be specific and actionable. Include commands when appropriate.
+
+**Success criteria**: ALWAYS include this! This shows that the step is done and we can move on. Can be a list.
+
+IMPORTANT: see the next section below for the per-step annotations you can optionally include for each step.
+
+...
+\`\`\`
+
+**Per-step annotations**:
+- **Success criteria** is REQUIRED on every step. This helps the model understand what the user expects from their workflow, and when it should have the confidence to move on.
+- **Execution**: \`Direct\` (default), \`Task agent\` (straightforward subagents), \`Teammate\` (agent with true parallelism and inter-agent communication), or \`[human]\` (user does it). Only needs specifying if not Direct.
+- **Artifacts**: Data this step produces that later steps need (e.g., PR number, commit SHA). Only include if later steps depend on it.
+- **Human checkpoint**: When to pause and ask the user before proceeding. Include for irreversible actions (merging, sending messages), error judgment (merge conflicts), or output review.
+- **Rules**: Hard rules for the workflow. User corrections during the reference session can be especially useful here.
+
+**Step structure tips:**
+- Steps that can run concurrently use sub-numbers: 3a, 3b
+- Steps requiring the user to act get \`[human]\` in the title
+- Keep simple skills simple -- a 2-step skill doesn't need annotations on every step
+
+**Frontmatter rules:**
+- \`allowed-tools\`: Minimum permissions needed (use patterns like \`Bash(gh:*)\` not \`Bash\`)
+- \`context\`: Only set \`context: fork\` for self-contained skills that don't need mid-process user input.
+- \`when_to_use\` is CRITICAL -- tells the model when to auto-invoke. Start with "Use when..." and include trigger phrases. Example: "Use when the user wants to cherry-pick a PR to a release branch. Examples: 'cherry-pick to release', 'CP this PR', 'hotfix'."
+- \`arguments\` and \`argument-hint\`: Only include if the skill takes parameters. Use \`$name\` in the body for substitution.
+
+### Step 4: Confirm and Save
+
+Before writing the file, output the complete SKILL.md content as a yaml code block in your response so the user can review it with proper syntax highlighting. Then ask for confirmation using AskUserQuestion with a simple question like "Does this SKILL.md look good to save?" — do NOT use the body field, keep the question concise.
+
+After writing, tell the user:
+- Where the skill was saved
+- How to invoke it: \`/{{skill-name}} [arguments]\`
+- That they can edit the SKILL.md directly to refine it
 `;
 export function registerSkillifySkill() {
     if (process.env.USER_TYPE !== 'ant') {