Code Style Conventions

Code Style Conventions

Overview

Generated code must match the style of the project it lives in. Many projects use their own linter or formatter (ESLint, Prettier, Biome, etc.) with rule sets that differ from Output's defaults. Always discover and follow the project's rules first. Only fall back to the Output SDK conventions below when the project has no linter or formatter configured.

When to Use This Skill

• Writing any TypeScript or JavaScript code in a workflow project
• Reviewing generated code before delivery
• Fixing lint errors after generation

Rules Discovery (do this first)

Before writing or reviewing code, determine the project's style rules:

1. Check for a linter config. Look for eslint.config.js, .eslintrc.*, biome.json, deno.json, or similar in the project root.
2. Check for a formatter config. Look for .prettierrc*, .editorconfig, or formatter settings in package.json.
3. Check for lint/format scripts. Look in package.json for lint, lint:fix, format, or similar scripts.
4. Read existing source files. If no config exists, infer conventions from the existing code (comma style, quote style, indentation, semicolons, spacing).

If the project has a linter or formatter

• Follow its rules. Do not apply Output SDK conventions that conflict.
• Run the project's lint/format command after generating code.
• If a rule is ambiguous, match the patterns in existing source files.

If the project has no linter or formatter

• Apply the Output SDK Default Conventions below.
• Match any conventions already present in existing source files -- consistency with the repo takes priority over the defaults below.

Output SDK Default Conventions

These rules reflect the Output SDK's own ESLint config. Apply them only when the project has no linter configured and no conflicting conventions are evident in existing code.

No Trailing Commas

Never use trailing commas in objects, arrays, function parameters, or type definitions.