skill-updater
- Repo stars 1,104
- License Complete terms in LICENSE.txt
- Author updated Live
- Author repo archive
- Domain
- Engineering
- Compatible agents
-
- Claude Code
- Cursor
- Cline
- Codex
- Windsurf
- Gemini CLI
- +20
- Trust score
- 94 / 100 · audit passed
- Author / version / license
- @dp-archive · Complete terms in LICENSE.txt
- Token usage
- Lean
- Setup complexity
- Plug-and-play
- External API key
- Not required
- Operating systems
- Unspecified (assume cross-platform)
- Runtime requirements
- No special requirements
- Permissions
-
- Read-only
- Write / modify
- Network behavior
- Local-only
- Install commands
- 26 variants
Profile is derived at build time from SKILL.md and install vectors. Subject to drift from author intent.
Heads up: 未限定 allowed-tools,默认拥有全部工具权限。
---
name: skill-updater
description: Update existing skills based on feedback. Use when users want to improve or modify an existing s…
category: engineering
runtime: no special runtime
---
# skill-updater output preview
## PART A: Task fit
- Use case: Update existing skills based on feedback. Use when users want to improve or modify an existing skill by providing feedback about what needs to change. Triggers on requests like "update this skill", "improve the skill based on feedback", "fix the skill", or when users provide feedback about skill performance..
- Inputs: target material, constraints, expected output, and acceptance criteria.
- Evidence boundary: follow “When to Use / Required Inputs / Update Process” and do not present inference as author intent.
## PART B: Execution result
- **01** The card summarizes the use case; runtime output centers on “Update existing skills based on feedback. Use when users want to improve or modify an existing skill by providing feedback about what needs to change. Triggers on requests like "update this skill", "improve the skill based on feedback", "fix the skill", or when users provide feedback about skill performance.”.
- **02** When the source has headings, the agent prioritizes “When to Use / Required Inputs / Update Process” so the result follows the author’s structure.
- **03** Typical output includes task judgment, concrete steps, required commands or file edits, validation, and follow-up options.
- **04** Risk context follows the fingerprint: read files, write/modify files; mostly runs locally; usually needs no extra API key.
## Running Rules
- read files, write/modify files; mostly runs locally; usually needs no extra API key.
- Validate with a small sample before expanding scope.
- Return the result, validation criteria, and next iteration options. The source mentions slash commands such as `/tmp`; use them first when your agent supports command triggers.
Name target files or source material, expected output, forbidden changes, and whether network or shell access is allowed. Permission fingerprint: read files, write/modify files.
Start with a small task and check whether the result follows “When to Use / Required Inputs / Update Process”. Inspect diffs, logs, previews, or tests before expanding scope.
Confirm the final output includes a concrete result, evidence, and next action. If it stays generic, tighten inputs, boundaries, and acceptance criteria.
---
name: skill-updater
description: Update existing skills based on feedback. Use when users want to improve or modify an existing s…
category: engineering
source: dp-archive/archive
---
# skill-updater
## When to use
- Update existing skills based on feedback. Use when users want to improve or modify an existing skill by providing feed…
- Use it when the task has clear inputs, repeatable steps, and validation criteria.
## What to provide
- Target material, scope, expected result, and forbidden changes.
- Whether network, commands, file writes, or external services are allowed.
## Execution rules
- Organize steps around “When to Use / Required Inputs / Update Process” and keep inference separate from source facts.
- read files, write/modify files; mostly runs locally; usually needs no extra API key.
- Validate with a small sample before expanding the task.
## Output requirements
- Return the deliverable, key evidence, validation method, and next action.
- Mark missing information as unknown; do not invent commands, platforms, or dependencies. The author source anchors workflow facts; repository files anchor sources and commands; Fluxly only adds fit, limitations, and quality judgment.
skill "skill-updater" {
input -> user goal + target files + boundaries + acceptance criteria
context -> When to Use / Required Inputs / Update Process
rules -> SKILL.md triggers / order / output contract
runtime -> no special runtime | read files, write/modify files | mostly runs locally
guardrails -> usually needs no extra API key + small-sample validation + diff/log review
output -> copyable result + checklist + next iteration
} Skill Updater
This skill provides guidance for updating existing skills based on user feedback.
When to Use
Use this skill when:
- User provides feedback about an existing skill's performance
- User wants to improve or modify a skill
- User reports issues or bugs with a skill
- User wants to add new functionality to an existing skill
Required Inputs
- Skill Path: Path to the skill directory or .skill file to update
- Feedback: Description of what needs to change, improve, or be fixed
Update Process
Step 1: Load and Understand the Skill
Use the analyze_skill.py script to get a quick overview:
scripts/analyze_skill.py <skill-path>
This shows:
- Skill name and description
- SKILL.md line/word count
- All bundled resources (scripts/, references/, assets/)
- Any structural issues
Then read SKILL.md to understand the detailed instructions:
cat <skill-path>/SKILL.md
For .skill files (zip archives), extract first:
unzip <skill-path>.skill -d /tmp/skill-extract/
Step 2: Analyze the Feedback
Categorize the feedback into one or more types:
| Type | Example Feedback | Typical Changes |
|---|---|---|
| Bug fix | "The script fails when..." | Fix scripts, add error handling |
| Missing feature | "It should also support..." | Add new functionality |
| Clarity | "Instructions are confusing" | Improve SKILL.md documentation |
| Performance | "Too slow/uses too much context" | Optimize scripts, reduce SKILL.md |
| Trigger | "Doesn't activate when I say..." | Update description in frontmatter |
Step 3: Plan the Changes
Before making changes, create a clear plan:
- List specific files to modify
- Describe what changes each file needs
- Identify any new files to create or files to delete
- Consider impact on other parts of the skill
Step 4: Implement Changes
Apply changes following skill design principles:
For SKILL.md changes:
- Keep body under 500 lines
- Use imperative form
- Move detailed content to references/ if approaching limit
- Ensure frontmatter description captures all trigger scenarios
For script changes:
- Test scripts after modification
- Maintain existing interfaces unless feedback requires changes
- Add error handling for reported edge cases
For reference changes:
- Keep references one level deep from SKILL.md
- Update SKILL.md to reference new files
Step 5: Validate and Package
After implementing changes:
# Validate the skill
scripts/quick_validate.py <skill-path>
# Package if validation passes
scripts/package_skill.py <skill-path>
Common Update Patterns
Pattern 1: Fixing Script Bugs
- Read the failing script
- Identify the bug based on feedback
- Apply fix
- Test with the scenario from feedback
- Package
Pattern 2: Improving Trigger Accuracy
- Review current frontmatter description
- Identify missing trigger phrases from feedback
- Update description to include new triggers
- Ensure description remains concise (<100 words)
Pattern 3: Adding New Functionality
- Determine if new functionality needs:
- New script in scripts/
- New reference in references/
- New asset in assets/
- Updates to SKILL.md instructions
- Implement required components
- Update SKILL.md to document new functionality
- Test end-to-end
Pattern 4: Reducing Context Usage
- Identify verbose sections in SKILL.md
- Move detailed content to references/
- Replace with concise summary + link
- Remove redundant examples
- Verify skill still functions correctly
Best Practices
- Minimal changes: Only change what the feedback requires
- Test after changes: Run scripts and validate skill structure
- Preserve intent: Maintain the skill's original purpose
- Document changes: Update SKILL.md if behavior changes
- Version awareness: If the skill has users, consider backward compatibility
Decide Fit First
Design Intent
How To Use It
Boundaries And Review