Remove internal-only bundled skills and mock helpers (#376)
* Remove internal-only bundled skills and mock rate-limit behavior This takes the next planned Phase C-lite slice by deleting bundled skills that only ever registered for internal users and replacing the internal mock rate-limit helper with a stable no-op external stub. The external build keeps the same behavior while removing a concentrated block of USER_TYPE-gated dead code. Constraint: Limit this PR to isolated internal-only helpers and avoid bridge, oauth, or rebrand behavior Rejected: Broad USER_TYPE cleanup across mixed runtime surfaces | too risky for the next medium-sized PR Confidence: high Scope-risk: moderate Reversibility: clean Directive: The next cleanup pass should continue with similarly isolated USER_TYPE helpers before touching main.tsx or protocol-heavy code Tested: bun run build Tested: bun run smoke Tested: bun run verify:privacy Tested: bun run test:provider Tested: bun run test:provider-recommendation Not-tested: Full repo typecheck (upstream baseline remains noisy) * Align internal-only helper removal with remaining user guidance This follow-up fixes the mock billing stub to be a true no-op and removes stale user-facing references to /verify and /skillify from the same PR. It also leaves a clearer paper trail for review: the deleted verify skill was explicitly ant-gated before removal, and the remaining mock helper callers still resolve to safe no-op returns in the external build. Constraint: Keep the PR focused on consistency fixes and reviewer-requested evidence, not new cleanup scope Rejected: Leave stale guidance for a later PR | would make this branch internally inconsistent after skill removal Confidence: high Scope-risk: narrow Reversibility: clean Directive: When deleting gated features, always sweep user guidance and coordinator prompts in the same pass Tested: bun run build Tested: bun run smoke Tested: bun run verify:privacy Tested: bun run test:provider Tested: bun run test:provider-recommendation Not-tested: Full repo typecheck (upstream baseline remains noisy; changed-file scan still shows only pre-existing tipRegistry errors outside edited lines) * Clarify generic workflow wording after skill removal This removes the last generic verification-skill wording that could still be read as pointing at a deleted bundled command. The guidance now talks about project workflows rather than a specific bundled verify skill. Constraint: Keep the follow-up limited to reviewer-facing wording cleanup on the same PR Rejected: Leave generic wording as-is | still too easy to misread after the explicit /verify references were removed Confidence: high Scope-risk: narrow Reversibility: clean Directive: When removing bundled commands, scrub both explicit and generic references in the same branch Tested: bun run build Tested: bun run smoke Not-tested: Additional checks unchanged by wording-only follow-up --------- Co-authored-by: anandh8x <test@example.com>
This commit is contained in:
Anandan
GitHub
@@ -4,12 +4,8 @@ import { registerBatchSkill } from './batch.js'
|
||||
import { registerClaudeInChromeSkill } from './claudeInChrome.js'
|
||||
import { registerDebugSkill } from './debug.js'
|
||||
import { registerKeybindingsSkill } from './keybindings.js'
|
||||
import { registerLoremIpsumSkill } from './loremIpsum.js'
|
||||
import { registerRememberSkill } from './remember.js'
|
||||
import { registerSimplifySkill } from './simplify.js'
|
||||
import { registerSkillifySkill } from './skillify.js'
|
||||
import { registerUpdateConfigSkill } from './updateConfig.js'
|
||||
import { registerVerifySkill } from './verify.js'
|
||||
|
||||
/**
|
||||
* Initialize all bundled skills.
|
||||
@@ -23,11 +19,7 @@ import { registerVerifySkill } from './verify.js'
|
||||
export function initBundledSkills(): void {
|
||||
registerUpdateConfigSkill()
|
||||
registerKeybindingsSkill()
|
||||
registerVerifySkill()
|
||||
registerDebugSkill()
|
||||
registerLoremIpsumSkill()
|
||||
registerSkillifySkill()
|
||||
registerRememberSkill()
|
||||
registerSimplifySkill()
|
||||
registerBatchSkill()
|
||||
if (feature('KAIROS') || feature('KAIROS_DREAM')) {
|
||||
|
||||
@@ -1,282 +0,0 @@
|
||||
import { registerBundledSkill } from '../bundledSkills.js'
|
||||
|
||||
// Verified 1-token words (tested via API token counting)
|
||||
// All common English words confirmed to tokenize as single tokens
|
||||
const ONE_TOKEN_WORDS = [
|
||||
// Articles & pronouns
|
||||
'the',
|
||||
'a',
|
||||
'an',
|
||||
'I',
|
||||
'you',
|
||||
'he',
|
||||
'she',
|
||||
'it',
|
||||
'we',
|
||||
'they',
|
||||
'me',
|
||||
'him',
|
||||
'her',
|
||||
'us',
|
||||
'them',
|
||||
'my',
|
||||
'your',
|
||||
'his',
|
||||
'its',
|
||||
'our',
|
||||
'this',
|
||||
'that',
|
||||
'what',
|
||||
'who',
|
||||
// Common verbs
|
||||
'is',
|
||||
'are',
|
||||
'was',
|
||||
'were',
|
||||
'be',
|
||||
'been',
|
||||
'have',
|
||||
'has',
|
||||
'had',
|
||||
'do',
|
||||
'does',
|
||||
'did',
|
||||
'will',
|
||||
'would',
|
||||
'can',
|
||||
'could',
|
||||
'may',
|
||||
'might',
|
||||
'must',
|
||||
'shall',
|
||||
'should',
|
||||
'make',
|
||||
'made',
|
||||
'get',
|
||||
'got',
|
||||
'go',
|
||||
'went',
|
||||
'come',
|
||||
'came',
|
||||
'see',
|
||||
'saw',
|
||||
'know',
|
||||
'take',
|
||||
'think',
|
||||
'look',
|
||||
'want',
|
||||
'use',
|
||||
'find',
|
||||
'give',
|
||||
'tell',
|
||||
'work',
|
||||
'call',
|
||||
'try',
|
||||
'ask',
|
||||
'need',
|
||||
'feel',
|
||||
'seem',
|
||||
'leave',
|
||||
'put',
|
||||
// Common nouns & adjectives
|
||||
'time',
|
||||
'year',
|
||||
'day',
|
||||
'way',
|
||||
'man',
|
||||
'thing',
|
||||
'life',
|
||||
'hand',
|
||||
'part',
|
||||
'place',
|
||||
'case',
|
||||
'point',
|
||||
'fact',
|
||||
'good',
|
||||
'new',
|
||||
'first',
|
||||
'last',
|
||||
'long',
|
||||
'great',
|
||||
'little',
|
||||
'own',
|
||||
'other',
|
||||
'old',
|
||||
'right',
|
||||
'big',
|
||||
'high',
|
||||
'small',
|
||||
'large',
|
||||
'next',
|
||||
'early',
|
||||
'young',
|
||||
'few',
|
||||
'public',
|
||||
'bad',
|
||||
'same',
|
||||
'able',
|
||||
// Prepositions & conjunctions
|
||||
'in',
|
||||
'on',
|
||||
'at',
|
||||
'to',
|
||||
'for',
|
||||
'of',
|
||||
'with',
|
||||
'from',
|
||||
'by',
|
||||
'about',
|
||||
'like',
|
||||
'through',
|
||||
'over',
|
||||
'before',
|
||||
'between',
|
||||
'under',
|
||||
'since',
|
||||
'without',
|
||||
'and',
|
||||
'or',
|
||||
'but',
|
||||
'if',
|
||||
'than',
|
||||
'because',
|
||||
'as',
|
||||
'until',
|
||||
'while',
|
||||
'so',
|
||||
'though',
|
||||
'both',
|
||||
'each',
|
||||
'when',
|
||||
'where',
|
||||
'why',
|
||||
'how',
|
||||
// Common adverbs
|
||||
'not',
|
||||
'now',
|
||||
'just',
|
||||
'more',
|
||||
'also',
|
||||
'here',
|
||||
'there',
|
||||
'then',
|
||||
'only',
|
||||
'very',
|
||||
'well',
|
||||
'back',
|
||||
'still',
|
||||
'even',
|
||||
'much',
|
||||
'too',
|
||||
'such',
|
||||
'never',
|
||||
'again',
|
||||
'most',
|
||||
'once',
|
||||
'off',
|
||||
'away',
|
||||
'down',
|
||||
'out',
|
||||
'up',
|
||||
// Tech/common words
|
||||
'test',
|
||||
'code',
|
||||
'data',
|
||||
'file',
|
||||
'line',
|
||||
'text',
|
||||
'word',
|
||||
'number',
|
||||
'system',
|
||||
'program',
|
||||
'set',
|
||||
'run',
|
||||
'value',
|
||||
'name',
|
||||
'type',
|
||||
'state',
|
||||
'end',
|
||||
'start',
|
||||
]
|
||||
|
||||
function generateLoremIpsum(targetTokens: number): string {
|
||||
let tokens = 0
|
||||
let result = ''
|
||||
|
||||
while (tokens < targetTokens) {
|
||||
// Sentence: 10-20 words
|
||||
const sentenceLength = 10 + Math.floor(Math.random() * 11)
|
||||
let wordsInSentence = 0
|
||||
|
||||
for (let i = 0; i < sentenceLength && tokens < targetTokens; i++) {
|
||||
const word =
|
||||
ONE_TOKEN_WORDS[Math.floor(Math.random() * ONE_TOKEN_WORDS.length)]
|
||||
result += word
|
||||
tokens++
|
||||
wordsInSentence++
|
||||
|
||||
if (i === sentenceLength - 1 || tokens >= targetTokens) {
|
||||
result += '. '
|
||||
} else {
|
||||
result += ' '
|
||||
}
|
||||
}
|
||||
|
||||
// Paragraph break every 5-8 sentences (roughly 20% chance per sentence)
|
||||
if (wordsInSentence > 0 && Math.random() < 0.2 && tokens < targetTokens) {
|
||||
result += '\n\n'
|
||||
}
|
||||
}
|
||||
|
||||
return result.trim()
|
||||
}
|
||||
|
||||
export function registerLoremIpsumSkill(): void {
|
||||
if (process.env.USER_TYPE !== 'ant') {
|
||||
return
|
||||
}
|
||||
|
||||
registerBundledSkill({
|
||||
name: 'lorem-ipsum',
|
||||
description:
|
||||
'Generate filler text for long context testing. Specify token count as argument (e.g., /lorem-ipsum 50000). Outputs approximately the requested number of tokens. Ant-only.',
|
||||
argumentHint: '[token_count]',
|
||||
userInvocable: true,
|
||||
async getPromptForCommand(args) {
|
||||
const parsed = parseInt(args)
|
||||
|
||||
if (args && (isNaN(parsed) || parsed <= 0)) {
|
||||
return [
|
||||
{
|
||||
type: 'text',
|
||||
text: 'Invalid token count. Please provide a positive number (e.g., /lorem-ipsum 10000).',
|
||||
},
|
||||
]
|
||||
}
|
||||
|
||||
const targetTokens = parsed || 10000
|
||||
|
||||
// Cap at 500k tokens for safety
|
||||
const cappedTokens = Math.min(targetTokens, 500_000)
|
||||
|
||||
if (cappedTokens < targetTokens) {
|
||||
return [
|
||||
{
|
||||
type: 'text',
|
||||
text: `Requested ${targetTokens} tokens, but capped at 500,000 for safety.\n\n${generateLoremIpsum(cappedTokens)}`,
|
||||
},
|
||||
]
|
||||
}
|
||||
|
||||
const loremText = generateLoremIpsum(cappedTokens)
|
||||
|
||||
// Just dump the lorem ipsum text into the conversation
|
||||
return [
|
||||
{
|
||||
type: 'text',
|
||||
text: loremText,
|
||||
},
|
||||
]
|
||||
},
|
||||
})
|
||||
}
|
||||
@@ -1,82 +0,0 @@
|
||||
import { isAutoMemoryEnabled } from '../../memdir/paths.js'
|
||||
import { registerBundledSkill } from '../bundledSkills.js'
|
||||
|
||||
export function registerRememberSkill(): void {
|
||||
if (process.env.USER_TYPE !== 'ant') {
|
||||
return
|
||||
}
|
||||
|
||||
const SKILL_PROMPT = `# Memory Review
|
||||
|
||||
## Goal
|
||||
Review the user's memory landscape and produce a clear report of proposed changes, grouped by action type. Do NOT apply changes — present proposals for user approval.
|
||||
|
||||
## Steps
|
||||
|
||||
### 1. Gather all memory layers
|
||||
Read CLAUDE.md and CLAUDE.local.md from the project root (if they exist). Your auto-memory content is already in your system prompt — review it there. Note which team memory sections exist, if any.
|
||||
|
||||
**Success criteria**: You have the contents of all memory layers and can compare them.
|
||||
|
||||
### 2. Classify each auto-memory entry
|
||||
For each substantive entry in auto-memory, determine the best destination:
|
||||
|
||||
| Destination | What belongs there | Examples |
|
||||
|---|---|---|
|
||||
| **CLAUDE.md** | Project conventions and instructions for Claude that all contributors should follow | "use bun not npm", "API routes use kebab-case", "test command is bun test", "prefer functional style" |
|
||||
| **CLAUDE.local.md** | Personal instructions for Claude specific to this user, not applicable to other contributors | "I prefer concise responses", "always explain trade-offs", "don't auto-commit", "run tests before committing" |
|
||||
| **Team memory** | Org-wide knowledge that applies across repositories (only if team memory is configured) | "deploy PRs go through #deploy-queue", "staging is at staging.internal", "platform team owns infra" |
|
||||
| **Stay in auto-memory** | Working notes, temporary context, or entries that don't clearly fit elsewhere | Session-specific observations, uncertain patterns |
|
||||
|
||||
**Important distinctions:**
|
||||
- CLAUDE.md and CLAUDE.local.md contain instructions for Claude, not user preferences for external tools (editor theme, IDE keybindings, etc. don't belong in either)
|
||||
- Workflow practices (PR conventions, merge strategies, branch naming) are ambiguous — ask the user whether they're personal or team-wide
|
||||
- When unsure, ask rather than guess
|
||||
|
||||
**Success criteria**: Each entry has a proposed destination or is flagged as ambiguous.
|
||||
|
||||
### 3. Identify cleanup opportunities
|
||||
Scan across all layers for:
|
||||
- **Duplicates**: Auto-memory entries already captured in CLAUDE.md or CLAUDE.local.md → propose removing from auto-memory
|
||||
- **Outdated**: CLAUDE.md or CLAUDE.local.md entries contradicted by newer auto-memory entries → propose updating the older layer
|
||||
- **Conflicts**: Contradictions between any two layers → propose resolution, noting which is more recent
|
||||
|
||||
**Success criteria**: All cross-layer issues identified.
|
||||
|
||||
### 4. Present the report
|
||||
Output a structured report grouped by action type:
|
||||
1. **Promotions** — entries to move, with destination and rationale
|
||||
2. **Cleanup** — duplicates, outdated entries, conflicts to resolve
|
||||
3. **Ambiguous** — entries where you need the user's input on destination
|
||||
4. **No action needed** — brief note on entries that should stay put
|
||||
|
||||
If auto-memory is empty, say so and offer to review CLAUDE.md for cleanup.
|
||||
|
||||
**Success criteria**: User can review and approve/reject each proposal individually.
|
||||
|
||||
## Rules
|
||||
- Present ALL proposals before making any changes
|
||||
- Do NOT modify files without explicit user approval
|
||||
- Do NOT create new files unless the target doesn't exist yet
|
||||
- Ask about ambiguous entries — don't guess
|
||||
`
|
||||
|
||||
registerBundledSkill({
|
||||
name: 'remember',
|
||||
description:
|
||||
'Review auto-memory entries and propose promotions to CLAUDE.md, CLAUDE.local.md, or shared memory. Also detects outdated, conflicting, and duplicate entries across memory layers.',
|
||||
whenToUse:
|
||||
'Use when the user wants to review, organize, or promote their auto-memory entries. Also useful for cleaning up outdated or conflicting entries across CLAUDE.md, CLAUDE.local.md, and auto-memory.',
|
||||
userInvocable: true,
|
||||
isEnabled: () => isAutoMemoryEnabled(),
|
||||
async getPromptForCommand(args) {
|
||||
let prompt = SKILL_PROMPT
|
||||
|
||||
if (args) {
|
||||
prompt += `\n## Additional context from user\n\n${args}`
|
||||
}
|
||||
|
||||
return [{ type: 'text', text: prompt }]
|
||||
},
|
||||
})
|
||||
}
|
||||
@@ -1,197 +0,0 @@
|
||||
import { getSessionMemoryContent } from '../../services/SessionMemory/sessionMemoryUtils.js'
|
||||
import type { Message } from '../../types/message.js'
|
||||
import { getMessagesAfterCompactBoundary } from '../../utils/messages.js'
|
||||
import { registerBundledSkill } from '../bundledSkills.js'
|
||||
|
||||
function extractUserMessages(messages: Message[]): string[] {
|
||||
return messages
|
||||
.filter((m): m is Extract<typeof m, { type: 'user' }> => m.type === 'user')
|
||||
.map(m => {
|
||||
const content = m.message.content
|
||||
if (typeof content === 'string') return content
|
||||
return content
|
||||
.filter(
|
||||
(b): b is Extract<typeof b, { type: 'text' }> => b.type === 'text',
|
||||
)
|
||||
.map(b => b.text)
|
||||
.join('\n')
|
||||
})
|
||||
.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** (\`.claude/skills/<name>/SKILL.md\`) — for workflows specific to this project
|
||||
- **Personal** (\`~/.claude/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(): void {
|
||||
if (process.env.USER_TYPE !== 'ant') {
|
||||
return
|
||||
}
|
||||
|
||||
registerBundledSkill({
|
||||
name: 'skillify',
|
||||
description:
|
||||
"Capture this session's repeatable process into a skill. Call at end of the process you want to capture with an optional description.",
|
||||
allowedTools: [
|
||||
'Read',
|
||||
'Write',
|
||||
'Edit',
|
||||
'Glob',
|
||||
'Grep',
|
||||
'AskUserQuestion',
|
||||
'Bash(mkdir:*)',
|
||||
],
|
||||
userInvocable: true,
|
||||
disableModelInvocation: true,
|
||||
argumentHint: '[description of the process you want to capture]',
|
||||
async getPromptForCommand(args, context) {
|
||||
const sessionMemory =
|
||||
(await getSessionMemoryContent()) ?? 'No session memory available.'
|
||||
const userMessages = extractUserMessages(
|
||||
getMessagesAfterCompactBoundary(context.messages),
|
||||
)
|
||||
|
||||
const userDescriptionBlock = args
|
||||
? `The user described this process as: "${args}"`
|
||||
: ''
|
||||
|
||||
const prompt = SKILLIFY_PROMPT.replace('{{sessionMemory}}', sessionMemory)
|
||||
.replace('{{userMessages}}', userMessages.join('\n\n---\n\n'))
|
||||
.replace('{{userDescriptionBlock}}', userDescriptionBlock)
|
||||
|
||||
return [{ type: 'text', text: prompt }]
|
||||
},
|
||||
})
|
||||
}
|
||||
@@ -1,48 +0,0 @@
|
||||
import { parseFrontmatter } from '../../utils/frontmatterParser.js'
|
||||
import { registerBundledSkill } from '../bundledSkills.js'
|
||||
|
||||
function loadVerifyContent(): { skillMd: string; skillFiles: Record<string, string> } {
|
||||
try {
|
||||
/* eslint-disable @typescript-eslint/no-require-imports */
|
||||
const { SKILL_FILES, SKILL_MD } = require('./verifyContent.js') as {
|
||||
SKILL_FILES: Record<string, string>
|
||||
SKILL_MD: string
|
||||
}
|
||||
/* eslint-enable @typescript-eslint/no-require-imports */
|
||||
return { skillMd: SKILL_MD, skillFiles: SKILL_FILES }
|
||||
} catch {
|
||||
return {
|
||||
skillMd:
|
||||
'# Verify\n\nVerify a code change does what it should by running the app.',
|
||||
skillFiles: {},
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
export function registerVerifySkill(): void {
|
||||
if (process.env.USER_TYPE !== 'ant') {
|
||||
return
|
||||
}
|
||||
|
||||
const { skillMd, skillFiles } = loadVerifyContent()
|
||||
const { frontmatter, content: skillBody } = parseFrontmatter(skillMd)
|
||||
|
||||
const description =
|
||||
typeof frontmatter.description === 'string'
|
||||
? frontmatter.description
|
||||
: 'Verify a code change does what it should by running the app.'
|
||||
|
||||
registerBundledSkill({
|
||||
name: 'verify',
|
||||
description,
|
||||
userInvocable: true,
|
||||
files: skillFiles,
|
||||
async getPromptForCommand(args) {
|
||||
const parts: string[] = [skillBody.trimStart()]
|
||||
if (args) {
|
||||
parts.push(`## User Request\n\n${args}`)
|
||||
}
|
||||
return [{ type: 'text', text: parts.join('\n\n') }]
|
||||
},
|
||||
})
|
||||
}
|
||||
Reference in New Issue
Block a user