agentleFS
Scientific-ToolingScientific-Tooling/structured-intelligence/skills/structured-intelligence-skill-creator/SKILL.md

structured-intelligence-skill-creator

Skill4 starsChanged 12 days agoMITView on GitHub

Create or update repository skills that conform to local templates, provider metadata requirements, registry rules, and validation workflows.

The file

We split this skill into the rules it gives an agent

9 rules. About 0 are common, 7 are distinctive, and 2 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈7

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 2

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Read only the local files needed to stay aligned with the repository:

    line 29
  2. Very specific:

    If bundled scripts are available, run scripts/run.sh <skill-id> [repo-root]

    line 36
  3. Distinctive:

    Keep the bundle minimal:

    line 42
  4. Distinctive:

    Add scripts only when deterministic execution or repeated logic is useful

    line 43
  5. Very specific:

    Add references only when they reduce SKILL.md size or hold project-specific detail

    line 44
  6. Distinctive:

    Do not add generic changelogs, installation guides, or duplicate documentation

    line 45
  7. Distinctive:

    Do not overwrite an existing skill blindly.

    line 65
  8. Distinctive:

    Do not leave placeholder strings from the template.

    line 66
  9. Distinctive:

    Do not introduce a registry entry without a real folder and matching config.

    line 67

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Skill: structured-intelligence-skill-creator

Use When

  • A user wants to create a new skill in this repository under skills/<skill-id>/.
  • A user wants to update an existing repository skill without breaking local conventions.
  • The task must produce a Codex- and Claude-compatible skill bundle with matching registry metadata.

Inputs

  • Required:
    • skill-id in kebab-case
    • human-friendly skill name
    • one-line description
  • Optional:
    • owner override
    • version override
    • whether the skill needs scripts/, references/, or assets/
    • example prompts, input schema, or output contract

Workflow

  1. Confirm the task is a skill, not an agent. Skill folders live under skills/<id>/.
  2. Read only the local files needed to stay aligned with the repository:
    • docs/conventions.md
    • skills/README.md
    • skills/registry.yaml
    • skills/_templates/skill/*
    • references/project-skill-checklist.md from this skill when exact requirements are needed
  3. For a new skill, prefer deterministic scaffolding:
    • If bundled scripts are available, run scripts/run.sh <skill-id> [repo-root]
    • Otherwise run the repository helper: ./scripts/bootstrap_new_skill.sh <skill-id>
  4. Replace all template placeholders before finishing:
    • config.yaml: id, name, version, owner, description
    • SKILL.md: use conditions, inputs, workflow, output contract, limits
    • agents/openai.yaml and agents/claude.yaml: matching display text and provider-specific default prompt
  5. Keep the bundle minimal:
    • Add scripts only when deterministic execution or repeated logic is useful
    • Add references only when they reduce SKILL.md size or hold project-specific detail
    • Do not add generic changelogs, installation guides, or duplicate documentation
  6. Register the skill in skills/registry.yaml and keep id, name, and version identical to config.yaml.
  7. Validate with ./scripts/validate_structure.sh before returning the task as complete.
  8. Report the created or updated files, validation result, and install commands for both tools.

Output Contract

  • skills/<skill-id>/config.yaml with valid metadata
  • skills/<skill-id>/SKILL.md with explicit inputs, outputs, and limits
  • skills/<skill-id>/agents/openai.yaml
  • skills/<skill-id>/agents/claude.yaml
  • optional scripts/, references/, and assets/ only when justified
  • matching entry in skills/registry.yaml
  • validation status from ./scripts/validate_structure.sh
  • install commands:
    • ./scripts/install_skill.sh <skill-id>
    • ./scripts/install_skill.sh <skill-id> --tool claude

Limits

  • Do not overwrite an existing skill blindly; read the current bundle first.
  • Do not leave placeholder strings from the template.
  • Do not introduce a registry entry without a real folder and matching config.
  • Common failure cases:
    • invalid kebab-case id
    • semver mismatch between registry and config.yaml
    • missing agents/openai.yaml or agents/claude.yaml
    • using the wrong default prompt format ($skill-id for OpenAI, bare skill-id for Claude)
    • skipping ./scripts/validate_structure.sh

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.