agentleFS
actionsactions/javascript-action/.github/copilot-instructions.md

javascript-action

Copilot instructions1.2k starsChanged 3 years agoMITView on GitHub

This GitHub Action is written in JavaScript and transpiled to a single file. Both the JavaScript sources and the generated JavaScript code are contained in this repository. The JavaScript sources are contained in the src directory and the code invoked by GitHub Actions is contained in the dist directory. A GitHub Actions workflow checks that the JavaScript code in dist is up-to-date. Therefore, you should not review any changes to the contents of the dist folder and it is expected…

  • Reads credentials
  • Installs packages

We split this copilot-instructions.md into the rules it gives an agent

18 rules. About 1 is common, 15 are distinctive, and 2 are very specific to this project.

  • ≈1

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈15

    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:

    Ensure all unit tests pass by running:

    line 50
  2. Distinctive:

    Follow standard JavaScript coding conventions and best practices

    line 70
  3. Distinctive:

    Document changes clearly and thoroughly, including updates to existing comments when appropriate

    line 72
  4. Distinctive:

    Do not include basic, unnecessary comments that simply restate what the code is doing (focus on explaining _why_, not _what_)

    line 74
  5. Common:

    Use consistent error handling patterns throughout the codebase

    line 76
  6. Distinctive:

    Keep functions focused and manageable

    line 77
  7. Distinctive:

    Use descriptive variable and function names that clearly convey their purpose

    line 78
  8. Distinctive:

    Use JSDoc comments to document functions, classes, and complex logic

    line 79
  9. Very specific:

    After doing any refactoring, ensure to run npm run test to ensure that all tests still pass and coverage requirements are met

    line 80
  10. Distinctive:

    When suggesting code changes, always opt for the most maintainable approach.

    line 82
  11. Distinctive:

    Avoid unnecessary complexity and always consider the long-term maintainability of the code

    line 85
  12. Distinctive:

    When writing unit tests, try to consider edge cases as well as the main path of success.

    line 87
  13. Very specific:

    Use the @actions/core package for logging over console to ensure compatibility with GitHub Actions logging features

    line 90
  14. Distinctive:

    When creating a pull request (PR), please ensure that:

    line 102
  15. Distinctive:

    Keep changes focused and minimal (avoid large changes, or consider breaking them into separate, smaller PRs)

    line 104
  16. Distinctive:

    If necessary, the README.md file is updated to reflect any changes in functionality or usage

    line 111
  17. Distinctive:

    When performing a code review, please follow these guidelines:

    line 123
  18. Distinctive:

    If there are changes that modify the functionality/usage of the action, validate that there are changes in the README.md file that document …

    line 125

≈ “Common” is an estimate: at least 1 in 5 of the 3,669 Copilot instructions 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
copilot-instructions.md

Copilot Instructions

This GitHub Action is written in JavaScript and transpiled to a single file. Both the JavaScript sources and the generated JavaScript code are contained in this repository. The JavaScript sources are contained in the src directory and the code invoked by GitHub Actions is contained in the dist directory. A GitHub Actions workflow checks that the JavaScript code in dist is up-to-date. Therefore, you should not review any changes to the contents of the dist folder and it is expected that the JavaScript code in dist closely mirrors the code it is generated from.

Repository Structure

PathDescription
__fixtures__/Unit Test Fixtures
__tests__/Unit Tests
.devcontainer/Development Container Configuration
.github/GitHub Configuration
.licenses/License Information
.vscode/Visual Studio Code Configuration
badges/Badges for readme
dist/Generated JavaScript Code
src/JavaScript Source Code
.env.exampleEnvironment Variables Example for @github/local-action
.licensed.ymlLicensed Configuration
.markdown-lint.ymlMarkdown Linter Configuration
.node-versionNode.js Version Configuration
.prettierrc.ymlPrettier Formatter Configuration
.yaml-lint.ymlYAML Linter Configuration
action.ymlGitHub Action Metadata
CODEOWNERSCode Owners File
eslint.config.mjsESLint Configuration
jest.config.jsJest Configuration
LICENSELicense File
package.jsonNPM Package Configuration
README.mdProject Documentation
rollup.config.jsRollup Bundler Configuration

Environment Setup

Install dependencies by running:

npm install

Testing

Ensure all unit tests pass by running:

npm run test

Unit tests should exist in the __tests__ directory. They are powered by jest. Fixtures should be placed in the __fixtures__ directory.

Bundling

Any time files in the src directory are changed, you should run the following command to bundle the JavaScript code into the dist directory:

npm run bundle

General Coding Guidelines

  • Follow standard JavaScript coding conventions and best practices
  • Changes should maintain consistency with existing patterns and style
  • Document changes clearly and thoroughly, including updates to existing comments when appropriate
  • Do not include basic, unnecessary comments that simply restate what the code is doing (focus on explaining why, not what)
  • Use consistent error handling patterns throughout the codebase
  • Keep functions focused and manageable
  • Use descriptive variable and function names that clearly convey their purpose
  • Use JSDoc comments to document functions, classes, and complex logic
  • After doing any refactoring, ensure to run npm run test to ensure that all tests still pass and coverage requirements are met
  • When suggesting code changes, always opt for the most maintainable approach. Try your best to keep the code clean and follow "Don't Repeat Yourself" (DRY) principles
  • Avoid unnecessary complexity and always consider the long-term maintainability of the code
  • When writing unit tests, try to consider edge cases as well as the main path of success. This will help ensure that the code is robust and can handle unexpected inputs or situations
  • Use the @actions/core package for logging over console to ensure compatibility with GitHub Actions logging features

Versioning

GitHub Actions are versioned using branch and tag names. Please ensure the version in the project's package.json is updated to reflect the changes made in the codebase. The version should follow Semantic Versioning principles.

Pull Request Guidelines

When creating a pull request (PR), please ensure that:

  • Keep changes focused and minimal (avoid large changes, or consider breaking them into separate, smaller PRs)
  • Formatting checks pass
  • Linting checks pass
  • Unit tests pass and coverage requirements are met
  • The action has been transpiled to JavaScript and the dist directory is up-to-date with the latest changes in the src directory
  • If necessary, the README.md file is updated to reflect any changes in functionality or usage

The body of the PR should include:

  • A summary of the changes
  • A special note of any changes to dependencies
  • A link to any relevant issues or discussions
  • Any additional context that may be helpful for reviewers

Code Review Guidelines

When performing a code review, please follow these guidelines:

  • If there are changes that modify the functionality/usage of the action, validate that there are changes in the README.md file that document the new or modified functionality

Download now (ZIP)

Trending

Quiet this year.thin dataabout the whole repository

Dec 2025: 0 mentionsJan 2026: 0 mentionsFeb 2026: 0 mentionsMar 2026: 0 mentionsApr 2026: 0 mentionsMay 2026: 0 mentionsJun 2026: 0 mentionsJul 2026: 0 mentionsAug 2026: 0 mentionsSep 2026: 0 mentionsOct 2026: 0 mentionsNov 2026: 0 mentions
Dec 2025Jun 2026Nov 2026
Mentions a month of the actions/javascript-action repository that our weekly crawl found: only 2 in all, so this is a hint, not a trend. There is no adoption data for this file yet.

Who's talking about actions/javascript-action

The biggest 2 of 2 mentions linking to the repository that our crawl found. Each line is their own headline.

  • Where files are headingNew Copilot instructions files have more rules about branches and pull requests, and fewer about code style.

    Of the Copilot instructions files we read, the 2,297 first seen in the last six months, against the older ones: the kind of rule that gained most share, and the kind that lost most. About files like this in general, not this one, and an estimate, since a kind is a pattern in the words.

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.