agentleFS
Sign inStart free
vekzz-devvekzz-dev/opencode-skills/skills/github-essentials/SKILL.md

github-essentials

Skill4 starsChanged 40 days agoMITView on GitHub

Trigger: .github setup, community health files, issue templates, PR template, CODEOWNERS, SECURITY.md, dependabot, release workflow. Bootstrap a repository's .github directory.

The file

We split this skill into the rules it gives an agent

6 rules. About 0 are common, 3 are distinctive, and 3 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈3

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 3

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Do not load for README authoring (create-readme), changelog upkeep (changelog-maintenance), or CI pipelines.

    line 14
  2. Distinctive:

    Never write a file the user did not approve.

    line 18
  3. Very specific:

    Never leave a placeholder in a written file.

    line 19
  4. Distinctive:

    Never write test, lint, build, or registry-publish workflows.

    line 20
  5. Very specific:

    Use issue forms (.yml), never legacy .md issue templates.

    line 21
  6. Distinctive:

    Write templates in the language the repository already uses.

    line 23

≈ “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

Activation Contract

Load when the user asks to set up, complete, or audit a .github/ directory: issue templates, pull request template, release workflow, CODEOWNERS, SECURITY.md, or dependabot.

Do not load for README authoring (create-readme), changelog upkeep (changelog-maintenance), or CI pipelines. Only the release workflow is in scope here.

Hard Rules

  • Never write a file the user did not approve. Present the plan and STOP first.
  • Never leave a placeholder in a written file. Resolve __OWNER__, __REPO__, __CODEOWNER__, __SECURITY_EMAIL__, and __PACKAGE_ECOSYSTEM__ from repository evidence. If a value cannot be resolved, ask instead of guessing.
  • Never write test, lint, build, or registry-publish workflows. Release only.
  • Use issue forms (.yml), never legacy .md issue templates.
  • The release workflow triggers on push: tags only, never on workflow_dispatch or release.
  • Write templates in the language the repository already uses; default English.

Decision Gates

ConditionAction
Repository already has a .github/ fileRead it and propose a merge. Never silently overwrite.
Org-wide .github repositorySkip ISSUE_TEMPLATE/config.yml contact links: they resolve per consuming repository
CODEOWNERS target unknownRead git config user.email and git log -1 --format='%an'; confirm with the user before writing
Stack undetected for dependabot.ymlRead manifests and lockfiles. If ambiguous, ask
User requests registry publishingOut of scope. Report it and stop

Execution Steps

  1. Inspect: git remote get-url origin, git symbolic-ref --short refs/remotes/origin/HEAD, existing .github/, lockfiles and manifests, and git tag --list 'v*' to infer the current version line.
  2. Derive every placeholder value from that evidence. Mark anything unresolved as a question.
  3. Present the file list with each resolved value. STOP and wait for approval.
  4. Copy the approved files from assets/ into .github/, substituting every placeholder.
  5. Validate with references/validation.md: leftover placeholders, YAML parse, CODEOWNERS syntax, tag regex against the project's versioning.
  6. Report results and the exact command that publishes the first release.

Output Contract

Return a table of every path written with its one-line purpose, the resolved values (owner, repo, codeowner, security email, ecosystem), every file skipped and why, and the commands to verify locally:

grep -rn "__[A-Z_]*__" .github/ || echo "no placeholders left"
python3 -c "import sys,yaml; [yaml.safe_load(open(f)) for f in sys.argv[1:]]" .github/*.yml

References

  • assets/ — one template per .github artifact.
  • references/release-workflow.md — tag-driven release design and failure modes.
  • references/validation.md — pre-delivery checklist.

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.

Check your setup, free