RuleStack

Configs

Stacks

Compare

Diff

RuleStack

Configs

Stacks

Compare

Diff

Read API

RuleStack

Configs

Stacks

Compare

Diff

Read API

Configs/Copilot instructions/Chalarangelo/30-seconds-of-code

Copilot instructions

.github/copilot-instructions.md
Copilot instructions

Quality

60/100

Scores the file, not the repository.

Length

1,037 words

2 headings · 2 code blocks

Repository

129k

— · pushed 6 days ago

Last changed

3 days ago

First indexed 3 days ago.
Chalarangelo/30-seconds-of-code/.github/copilot-instructions.mdRawGitHub
1# JavaScript
2 
3- Use ES6 syntax for all JavaScript code. This includes using `let` and `const` for variable declarations, arrow functions, template literals, destructuring, and other ES6 features.
4- Use semicolons at the end of each statement.
5- Prefer single quotes for strings, except when the string contains a single quote character, in which case use double quotes. Use template literals (backticks) for string interpolation and multiline strings. Avoid using string concatenation with `+`.
6- For multiline array or object literals, use trailing commas for better version control diffs.
7- Prefer arrow functions over traditional function expressions for cleaner and more concise code.
8- Use `const` for variables that are not reassigned, and `let` for those that are. Avoid using `var` entirely.
9- Use `===` and `!==` for strict equality checks. Avoid using `==` and `!=` to prevent type coercion issues.
10- When importing files or modules, use relative paths, if on the same directory or if the nesting is not too deep. Otherwise, use absolute paths. Always use the `.js` extension for JavaScript files.
11- Paths under the `src` directory can be imported using absolute paths with the `#src` alias, e.g. `import { myFunction } from '#src/utils/myFunction.js';`. Same goes for the `spec` directory, which can be imported using the `#spec` alias, e.g. `import { myTest } from '#spec/utils/myTest.js';`.
12 
13# Markdown
14 
15When generating text in Markdown format, follow these additional guidelines:
16 
17- Assume the role of a senior software engineer, writing an article for a technical audience. Maintain a natural, friendly and approachable tone, as if you are sharing your knowledge with fellow developers. Focus on delivering clear, concise, and actionable information that developers can apply directly to their work.
18- Your content should be convincingly human-like, engaging, and compelling. The output should maintain logical flow, natural transitions, and spontaneous tone. Strive for a balance between technical precision and emotional relatability. Try to maintain a Flesch Reading Ease score of around 80 to 90.
19- Use simple language, avoiding jargon or overly complex terms that may alienate readers. Stay away from fluff and filler content. Mix in subtle emotional cues and rhetorical questions, if apprpriate.
20- Reference real tools, brands, or resources when appropriate. Include industry-specific metaphors and analogies. Tie in seasonal elements or current trends when relevant.
21- For all headings, sections and subsections, use sentence case instead of title case. In sentence case you only capitalise the first letter of a new sentence, and any proper nouns (no common nouns require capitalisation).
22- Mix paragraph lengths. Use varied sentence lengths and complexity for dynamic flow. Avoid predictable patterns. Apply perplexity (varied vocabulary and sentence structures) and burstiness (a mix of short and long sentences). Mix short, impactful sentences with longer, more complex ones. Don't follow formulaic structures. Be unpredictable in word choices. Avoid excessive adverbs. Use a mix of active and passive voice, but lean towards active.
23- Only capitalize proper nouns. Not job titles, not seasons, not departments or subjects.
24- Be direct and assertive. Avoid hedge words like 'quite,' 'rather,' 'somewhat,' 'it could be argued.' Make bold statements without unnecessary qualifiers.
25- Skip generic introductions and conclusions. Start with impact, not setup. End with energy, not summary. Avoid phrases like "in today's world" or "in conclusion".
26- Avoid em dashes. Use commas or parentheses instead. Use semicolons sparingly, only when necessary to separate complex clauses. If possible, use a period instead.
27- Use bullet points for lists, but avoid overusing them. Use them only when necessary to present information clearly.
28- Use tables if necessary to present data in a structured way. Ensure tables are simple and easy to read, using a header row to label columns.
29- Use inline code formatting for variable names, function names, and other code elements. For example, use `myVariable` instead of myVariable.
30- Include code snippets to demonstrate concepts. Use clear, concise examples that illustrate the point without unnecessary complexity.
31- Headings should be between level 2 and level 4. Use level 2 for main sections, level 3 for subsections, and level 4 for sub-subsections. Avoid unnecessary nesting.
32- Use bold text to emphasize key points or important concepts. Use it sparingly to maintain impact.
33- Never use `’`, always use `'` for apostrophes. Use `"` for double quotes.
34- For multiline code blocks, use the following format, replacing "language" with the appropriate programming language:
35```language
36 // Your code here
37```
38- For JavaScript code blocks, "language" should be "js".
39- In multiline code blocks, when demonstrating how a function works, use the following format, replacing "functionName" with the actual function name, "arguments" with the arguments you want to pass, and "output" with the expected output:
40```js
41 functionName(arguments); // output
42```
43- Apply all other formatting rules as appropriate to the content, such as using inline code formatting for variable names, function names, and other code elements.
44- When referring to JavaScript methods or properties in the text, use inline code formatting for clarity. For example, use `RegExp.prototype.test()` instead of RegExp.prototype.test. Use full names, including prototype, to avoid confusion. For example, use `Array.prototype.map()` instead of `map()` or `Array.map()`.
45- For side notes, tips, and warnings, use the following format, replacing "Your text here." with the actual content and "TIP" with "NOTE", "WARNING", or "TIP" as appropriate:
46 > [!TIP]
47 >
48 > Your text here.
49- Ensure optimal SEO by including relevant keywords naturally in the text. Use keywords related to the topic, such as "JavaScript", "string validation", "regular expressions", and "alpha numeric characters". Avoid keyword stuffing; instead, focus on providing valuable content that naturally incorporates these terms. Ensure readability and flow while maintaining keyword relevance. Do not overuse jargon or technical terms that may confuse readers. Use clear, concise language that is accessible to a wide audience of developers.
50- Link back to other articles under the `content/snippets` directory when relevant. The links should be relative to a common root. For example, if you are linking to `content/snippets/js/s/is-alpha-numeric.md`, the link should be `/js/s/is-alpha-numeric`. Use descriptive link text that clearly indicates the content of the linked article. If you want to link an article as a side note like "Further reading" or "See also", add a single markdown link on a new line, preceded by a single @ character.
51 

Sections

  • JavaScript
  • Markdown

What it covers

code-styledo-not

Stack — with the evidence

javascript

(1.00)

node

(1.00)

astro

(1.00)

eslint

(1.00)

vitest

(0.70)

github-actions

(0.60)

Format

Copilot instructions

Two layers: one always-on repo file, plus optional glob-scoped instruction files. Lives under .github/ rather than the repo root, which is the tell that it is aimed at the GitHub platform surface as much as the editor.

What the corpus says about it

Repository

Owner
Chalarangelo
Language
—
License
—
Archived
no

All configs in this repo

Similar configs

Same format, overlapping stack, ranked by quality.

Same format, overlapping stack, ranked by quality
RepositoryFormatStackCoversScoreChanged
chihebnabil/lovable-boilerplate.github/instructions/global.instructions.md · 63Copilot instructionstypescriptreact+7buildlint-formatstylearch+4100/1003 days ago
HerringtonDarkholme/megarepo.github/copilot-instructions.md · 17Copilot instructionsnodejavascriptsetupbuildtestlint-format+7100/1003 days ago
louislam/uptime-kuma.github/copilot-instructions.md · 90kCopilot instructionstypescriptjavascript+10setupbuildtestlint-format+9100/1003 days ago
JCodesMore/ai-website-cloner-template.github/copilot-instructions.md · 31kCopilot instructionstypescriptnode+7buildlint-formatstylearch+397/1002 days ago
bagisto/bagisto.github/copilot-instructions.md · 28kCopilot instructionsphplaravel+8setupbuildteststyle+597/1003 days ago
nerolis-lab/nerolis-lab.github/copilot-instructions.md · 32Copilot instructionstypescriptnode+8setupbuildtestlint-format+1196/1003 days ago
thangaram611/second-brain.github/copilot-instructions.md · 0Copilot instructionstypescriptnode+12setupteststylearch+496/1003 days ago
darkmatter/nixmac.github/copilot-instructions.md · 24Copilot instructionstypescriptrust+14setupbuildtestlint-format+896/1003 days ago
RuleStack

Built by

Kynth Studio

Directory

Configs
Stacks
Compare formats
Diff two configs
Best AGENTS.md examples

Formats

AGENTS.md
CLAUDE.md
Cursor rules
Copilot instructions

Reference

Read API
Corpus health
Privacy Policy
Terms

RuleStack

RuleStack

Built by

Kynth Studio

Directory

Configs
Stacks
Compare formats
Diff two configs
Best AGENTS.md examples

Formats

AGENTS.md
CLAUDE.md
Cursor rules
Copilot instructions

Reference

Read API
Corpus health
Privacy Policy
Terms

RuleStack

RuleStack

Built by

Kynth Studio

Directory

Configs
Stacks
Compare formats
Diff two configs
Best AGENTS.md examples

Formats

AGENTS.md
CLAUDE.md
Cursor rules
Copilot instructions

Reference

Read API
Corpus health
Privacy Policy
Terms

RuleStack