seandylan1982/full-stack-dev-assist icon
public
Published on 7/7/2025
FullStack Development Assistant

Assist a developer in completing coding tasks focusing on simplicity and direct contribution to the ultimate goal. Keep the ultimate goal in mind. Ensure every task contributes directly to achieving this goal. Avoid distractions. Redirect the conversation if it strays from the task. Simplicity and Reliability: Main programming language: JavaScript, TypeScript Backend: nodejs, expressjs, mongodb (mongoose), Frontend: reactjs (vite + javascript template), tailwindcss for styling

Rules
Models
Context
gemini Gemini 2.0 Flash model icon

Gemini 2.0 Flash

gemini

1048kinput·8.192koutput
openai OpenAI GPT-4o model icon

OpenAI GPT-4o

OpenAI

128kinput·16.384koutput
lmstudio deepseek-r1 8b model icon

deepseek-r1 8b

lmstudio

deepinfra Qwen2.5 Coder 32B Instruct model icon

Qwen2.5 Coder 32B Instruct

deepinfra

lmstudio qwen2.5-coder 32b model icon

qwen2.5-coder 32b

lmstudio

lmstudio autodetect model icon

autodetect

lmstudio

lmstudio deepseek-r1 qwen-7b model icon

deepseek-r1 qwen-7b

lmstudio

lmstudio mistral 7b model icon

mistral 7b

lmstudio

lmstudio qwen2.5-coder 14b model icon

qwen2.5-coder 14b

lmstudio

anthropic Claude 4 Opus model icon

Claude 4 Opus

anthropic

200kinput·32koutput
anthropic Claude 3.7 Sonnet model icon

Claude 3.7 Sonnet

anthropic

200kinput·8.192koutput
anthropic Claude 3.5 Haiku model icon

Claude 3.5 Haiku

anthropic

200kinput·8.192koutput
anthropic Claude 4 Sonnet model icon

Claude 4 Sonnet

anthropic

200kinput·64koutput
# Airbnb JavaScript Style Guide - Summary

## Types
  - Primitives: access by value (`string`, `number`, `boolean`, `null`, `undefined`, `symbol`, `bigint`)
  - Complex: access by reference (`object`, `array`, `function`)

## References
  - Use `const` for all references; avoid `var`
  - Use `let` only if reassigning references
  - Both `const` and `let` are block-scoped, unlike function-scoped `var`

## Objects
  - Use literal syntax for object creation
  - Use computed property names when creating objects with dynamic properties
  - Use object method and property value shorthand
  - Group shorthand properties at the beginning
  - Only quote invalid identifier properties
  - Don't call `Object.prototype` methods directly
  - Prefer object spread (`{...obj}`) over `Object.assign`

## Arrays
  - Use literal syntax for array creation
  - Use `Array#push` instead of direct assignment
  - Use array spreads `...` to copy arrays
  - Use `...` for iterable conversion; `Array.from` for array-like objects
  - Use return statements in array method callbacks
  - Use line breaks after opening and before closing array brackets for multiline arrays

## Destructuring
  - Use object destructuring when accessing multiple properties
  - Use array destructuring
  - Use object destructuring for multiple return values, not array destructuring

## Strings
  - Use single quotes (`''`) for strings
  - Don't write strings that cause line breaks over 100 characters
  - Use template literals for string composition
  - Never use `eval()` on strings
  - Don't unnecessarily escape characters

## Functions
  - Use named function expressions instead of function declarations
  - Wrap IIFEs in parentheses
  - Never declare functions in non-function blocks
  - Never name a parameter `arguments`
  - Use rest syntax (`...`) instead of `arguments`
  - Use default parameter syntax rather than mutating function arguments
  - Avoid side effects with default parameters
  - Always put default parameters last
  - Never use the Function constructor

## Arrow Functions
  - Use arrow functions for anonymous functions
  - Omit braces and use implicit return when function body is a single expression
  - Wrap expressions over multiple lines in parentheses
  - Always include parentheses around arguments
  - Avoid confusing arrow function syntax with comparison operators

## Classes & Constructors
  - Use `class` syntax; avoid manipulating `prototype` directly
  - Use `extends` for inheritance
  - Methods can return `this` for method chaining
  - Don't use empty constructors or ones that just delegate to parent
  - Avoid duplicate class members
  - Class methods should use `this` or be static

## Modules
  - Always use ES modules (`import`/`export`) over non-standard module systems
  - Don't use wildcard imports
  - Don't export directly from an import
  - Only import from a path in one place
  - Don't export mutable bindings
  - Prefer default export for single exports
  - Put all imports above non-import statements
  - Multi-line imports should follow proper indentation

## Iterators and Generators
  - Prefer JavaScript's higher-order functions over loops
  - Don't use generators for now (poor ES5 transpilation)

## Properties
  - Use dot notation when accessing properties
  - Use bracket notation `[]` when accessing properties with a variable
  - Use exponentiation operator (`**`) when calculating exponentiations

## Variables
  - Always use `const` or `let`, never undeclared variables
  - Use one declaration per variable or assignment
  - Group all `const`s and then all `let`s
  - Assign variables where you need them in a reasonable place
  - Don't chain variable assignments
  - Avoid unary increments and decrements (`++`, `--`)
  - Avoid linebreaks before or after `=` in assignments

## Comparison Operators & Equality
  - Use `===` and `!==` over `==` and `!=`
  - Use shortcuts for booleans, but explicit comparisons for strings and numbers
  - Use braces for case/default clauses with lexical declarations
  - Keep ternaries simple and on single lines when possible
  - Avoid unneeded ternary statements
  - Use parentheses when mixing operators
  - Use nullish coalescing (`??`) only for `null`/`undefined` cases

## Blocks
  - Use braces with multiline blocks
  - Put `else` on same line as closing brace of `if`
  - Avoid unnecessary `else` blocks when `if` contains a return

## Control Statements
  - Break long conditions onto multiple lines with operators at the start of lines
  - Don't use selection operators in place of control statements

## Comments
  - Use `/** ... */` for multiline comments
  - Use `//` for single line comments above the subject
  - Start comments with a space for readability
  - Prefix comments with `FIXME:` or `TODO:` for actionable items

## Whitespace
  - Use soft tabs (2 spaces)
  - Place 1 space before leading braces
  - Place 1 space before parentheses in control statements
  - Set off operators with spaces
  - End files with a single newline
  - Use indentation for long method chains with leading dots
  - Leave a blank line after blocks and before statements
  - Don't pad blocks with blank lines or use multiple blank lines

## Commas
  - Use trailing commas, not leading
  - Include additional trailing commas for cleaner diffs

## Semicolons
  - Use semicolons at the end of statements

## Type Casting & Coercion
  - Perform type coercion at the beginning of statements
  - Use explicit conversion functions: `String()`, `Number()`, `parseInt()`, `Boolean()`

## Naming Conventions
  - Be descriptive; avoid single letter names
  - Use camelCase for objects, functions, and instances
  - Use PascalCase for classes and constructors
  - Don't use leading/trailing underscores
  - Don't save references to `this`; use arrow functions or bind
  - Filename should match default export name
  - Acronyms should be all uppercase or all lowercase

## Accessors
  - Accessor functions aren't required but be consistent if used
  - Use verb prefixes like `get`, `set`, `is`, `has` appropriately

## Events
  - Pass objects with data rather than raw values when triggering events

## jQuery
  - Prefix jQuery objects with `$`
  - Cache jQuery lookups
  - Use optimal selectors and scoping for DOM queries

## Testing
  - Write tests for all code
  - Aim for high test coverage
  - Write regression tests when fixing bugs
# Airbnb React/JSX Style Guide - Summary

- **Component Structure**
  - One React component per file (multiple stateless components allowed)
  - Always use JSX syntax instead of `React.createElement`
  - Use `class extends React.Component` for stateful components
  - Use function declarations for stateless components
  - Don't use mixins

- **Naming & Files**
  - Use `.jsx` extension for React components
  - Use PascalCase for component filenames and references
  - Use camelCase for component instances
  - Use composite names for HOCs (e.g., `withFoo(Bar)`)

- **Syntax & Formatting**
  - Use double quotes for JSX attributes, single quotes for JS
  - Include a space in self-closing tags
  - Don't pad JSX curly braces with spaces
  - Wrap multiline JSX in parentheses
  - Always self-close tags without children

- **Props**
  - Use camelCase for prop names
  - Omit value when prop is explicitly `true`
  - Always include `alt` attributes on `<img>` tags
  - Don't use array index as `key` prop
  - Define defaultProps for all non-required props
  - Use spread props sparingly

- **Methods & Events**
  - Use arrow functions to close over local variables
  - Bind event handlers in the constructor
  - Don't use underscore prefix for internal methods
  - Always return a value in render methods

- **Component Organization**
  - Follow specific ordering for lifecycle methods
  - Follow specific patterns for defining propTypes and defaultProps
  - Don't use `isMounted` (anti-pattern)
# Node.js Style Guide
- **Formatting**
  - Use 2 spaces for indentation (no tabs)
  - Use UNIX-style newlines (`\n`)
  - No trailing whitespace
  - Use semicolons
  - Limit lines to 80 characters
  - Use single quotes (except for JSON)
  - Opening braces go on the same line
  - Declare one variable per `var` statement

- **Naming Conventions**
  - Use `lowerCamelCase` for variables, properties and function names
  - Use `UpperCamelCase` for class names
  - Use `UPPERCASE` for constants
  - Use descriptive names (avoid single characters and uncommon abbreviations)

- **Variables**
  - Use trailing commas in multiline object and array literals
  - Put short declarations on a single line
  - Only quote object keys when necessary

- **Conditionals**
  - Always use the `===` operator
  - Use multi-line format for ternary operators
  - Use descriptive variables for non-trivial conditions

- **Functions**
  - Write small functions (aim for ~15 lines or less)
  - Return early from functions to avoid deep nesting
  - Name your closures for better debugging
  - Avoid nested closures
  - For method chaining, use one method per line with indentation

- **Comments**
  - Use slashes for both single line and multi-line comments
  - Write comments that explain higher-level mechanisms
  - Don't comment on obvious code

- **Best Practices**
  - Avoid `Object.freeze`, `Object.preventExtensions`, `Object.seal`, `with`, and `eval`
  - Put all requires at the top of file
  - Avoid using getters and setters with side effects
  - Never extend built-in prototypes

No Docs configured

Prompts

Learn more

No Prompts configured

Context

Learn more
@diff
Reference all of the changes you've made to your current branch
@codebase
Reference the most relevant snippets from your codebase
@url
Reference the markdown converted contents of a given URL
@folder
Uses the same retrieval mechanism as @Codebase, but only on a single folder
@terminal
Reference the last command you ran in your IDE's terminal and its output
@code
Reference specific functions or classes from throughout your project
@file
Reference any file in your current workspace

No Data configured

MCP Servers

Learn more

Playwright

npx -y @executeautomation/playwright-mcp-server

Memory

npx -y @modelcontextprotocol/server-memory

Browser MCP

npx -y @browsermcp/mcp@latest

GitHub

npx -y @modelcontextprotocol/server-github