skill-development
- Repo stars 3,922
- Author updated Live
- Author repo claude-scholar
- Domain
- Engineering
- Compatible agents
-
- Claude Code
- Cursor
- Cline
- Codex
- Windsurf
- Gemini CLI
- +20
- Trust score
- 92 / 100 · audit passed
- Author / version / license
- @Galaxy-Dawn · v0.2.0 · no license declared
- 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-development
description: This skill should be used when the user asks to create a new skill, repair an existing skill, im…
category: engineering
runtime: no special runtime
---
# skill-development output preview
## PART A: Task fit
- Use case: This skill should be used when the user asks to create a new skill, repair an existing skill, improve trigger descriptions, reorganize skill structure, or make a Claude skill more reusable and internally consistent. Use this skill to create or repair Claude skills in the current local environment, not in an abstract plugin template. runs entirely locally.….
- Inputs: target material, constraints, expected output, and acceptance criteria.
- Evidence boundary: follow “Goal / Core rules / Default workflow” and do not present inference as author intent.
## PART B: Execution result
- **01** The card summarizes the use case; runtime output centers on “This skill should be used when the user asks to create a new skill, repair an existing skill, improve trigger descriptions, reorganize skill structure, or make a Claude skill more reusable and internally consistent. Use this skill to create or repair Claude skills in the current local environment, not in an abstract plugin template. runs entirely locally.…”.
- **02** When the source has headings, the agent prioritizes “Goal / Core rules / Default workflow” 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. Choose the trigger
The source does not require a stable slash command. After installation, invoke the skill by name and describe the task.
Provide inputs and boundaries
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.
Validate with a small run
Start with a small task and check whether the result follows “Goal / Core rules / Default workflow”. Inspect diffs, logs, previews, or tests before expanding scope.
Review before delivery
Confirm the final output includes a concrete result, evidence, and next action. If it stays generic, tighten inputs, boundaries, and acceptance criteria.
---
name: skill-development
description: This skill should be used when the user asks to create a new skill, repair an existing skill, im…
category: engineering
source: Galaxy-Dawn/claude-scholar
---
# skill-development
## When to use
- This skill should be used when the user asks to create a new skill, repair an existing skill, improve trigger descript…
- 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 “Goal / Core rules / Default workflow” 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. Evidence boundary and execution chain
The author source anchors workflow facts; repository files anchor sources and commands; Fluxly only adds fit, limitations, and quality judgment.
skill "skill-development" {
input -> user goal + target files + boundaries + acceptance criteria
context -> Goal / Core rules / Default workflow
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 Development
Use this skill to create or repair Claude skills in the current local environment, not in an abstract plugin template.
Goal
Produce a skill that is:
- easy to trigger,
- lean at the
SKILL.mdlayer, - backed by real
references/,examples/, andscripts/files when they are mentioned, - free of dead local references.
Core rules
- Keep one skill = one durable job.
- Treat the frontmatter description as the main trigger surface.
- Keep
SKILL.mdfocused on workflow and boundaries. - Move detailed catalogs, templates, and long explanations into
references/orexamples/. - Do not mention files that do not exist.
- Do not inherit stale names, agents, or sibling skill references without verifying they exist locally.
Default workflow
1. Inspect the current environment first
Before writing anything:
- inspect the target skill directory,
- inspect neighboring skills that already solve a similar problem,
- verify which agents, commands, and sibling skills actually exist,
- identify stale references before adding new ones.
Use the local inventory as the authority. Do not write guidance against an imagined plugin layout.
2. Lock the skill contract
Define four things before editing:
- what the skill does,
- what triggers it,
- what it explicitly does not do,
- which bundled resources are actually needed.
If the skill only needs a short workflow, keep it short. Do not create references/, examples/, or scripts/ just because the directories are conventional.
3. Write or repair the frontmatter
The frontmatter should:
- use the real skill identifier in
name, - use a third-person trigger description,
- include concrete phrases a user would naturally say,
- stay short enough to scan quickly.
Prefer descriptions of this form:
---
name: skill-name
description: This skill should be used when the user asks to "...", "...", or needs help with ....
---4. Keep the main file lean
A good SKILL.md should usually contain:
- a short goal section,
- role boundaries,
- a default workflow,
- safety or quality rules,
- a short list of additional resources.
Move these out of the main file when they get long:
- templates,
- exhaustive checklists,
- edge-case catalogs,
- sample outputs,
- long examples.
5. Add only real bundled resources
Use bundled resources deliberately:
references/for detailed guidance that may be loaded selectively,examples/for real example outputs or scaffolds,scripts/for deterministic helper logic.
If a resource is mentioned in SKILL.md, it must exist.
If a resource exists but is never referenced or used, delete it.
6. Run integrity checks before closing
At minimum, verify:
- frontmatter parses,
- referenced local files exist,
- sibling skill or agent references are real,
SKILL.mdis not overloaded with material that belongs in references,- temporary logs, caches, and editor artifacts are not left inside the skill directory.
Typical repair patterns
When the skill is too long
- keep the trigger and workflow in
SKILL.md, - move catalogs and deep detail into
references/, - keep a short read order so another model knows what to load first.
When the skill is too thin
- add a default workflow,
- add at least one concrete example or checklist,
- make the boundaries explicit so the skill is not just a slogan.
When the skill has stale references
- remove dead paths immediately,
- replace historical names with current local names,
- re-check neighboring agents/commands/skills against the live directory.
Recommended output shape
When creating or repairing a skill, prefer ending with:
- what changed,
- which files were created or updated,
- what integrity checks were run,
- what still needs manual follow-up, if anything.
References
Load only what is needed:
references/checklist.md- compact quality checklist before closing a skill editreferences/integrity-checks.md- concrete local checks for missing files, dead references, and driftreferences/skill-creator-original.md- legacy background reference; use for context, not as the live source of truth
Decide Fit First
Design Intent
How To Use It
Boundaries And Review