google-common-lisp-style

Applies Google's Common Lisp style guide when writing or reviewing Lisp code.

Updated Aug 22, 2026
One-click install
npx skills add https://github.com/chughtapan/google-guide-skills --skill google-common-lisp-style-chughtapan
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: google-common-lisp-style
Source: https://github.com/chughtapan/google-guide-skills/tree/main/skills/google-common-lisp-style
Command: npx skills add https://github.com/chughtapan/google-guide-skills --skill google-common-lisp-style-chughtapan

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Common Lisp codebases drift into inconsistent naming, formatting, macro usage, and error handling without a shared standard, making reviews subjective and code harder to maintain. This Skill encodes Google's Common Lisp Style Guide so agents apply the same rules every time. ## Core Features & Use Cases - Formatting and naming rules: Enforces line length, indentation, whitespace, semicolon comment conventions, lowercase hyphenated symbols, predicate -P suffixes, and earmuff/plus naming for globals and constants. - Language usage guidance: Covers packages, CLOS, macros, EVAL-WHEN, assertions versus conditions, functional style, recursion versus iteration, and prohibitions on runtime EVAL and INTERN. - RFC 2119 rule levels: Distinguishes MUST, SHOULD, and MAY guidelines so reviewers know which violations require permission versus judgment. - Use Case: While reviewing a pull request that adds a new Common Lisp module, the agent flags double-colon package access, missing docstrings on public functions, and ASSERT used for input validation instead of ERROR. ## Quick Start Review this Common Lisp file using the google-common-lisp-style guide and list any violations of naming, formatting, or error-handling rules.

Frequently Asked Questions about google-common-lisp-style

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I apply Google's Common Lisp style guide to my code?

Load this Skill and ask the agent to write or review Common Lisp code. It enforces Google's rules on naming, formatting, docstrings, packages, macros, and error handling, with each rule graded as MUST, SHOULD, or MAY.

What naming conventions does the Google Common Lisp style guide require?

Symbols use lowercase with hyphens between words, predicates end in P or -P, global variables get earmuff asterisks, and constants get plus-sign delimiters. Names should denote intent rather than data structure types like list or array.

Does this style guide work for Scheme or Clojure code?

No, the guide targets Common Lisp specifically and should not be applied to other Lisp dialects without checking compatibility. Rules about packages, CLOS, conditions, and EVAL-WHEN are Common Lisp-specific.

When should I use ASSERT versus ERROR in Common Lisp?

Use ASSERT only to detect internal bugs where failure means the software itself is broken. Use ERROR with an explicit condition type for invalid user input or unusual outcomes, and document signaled conditions in the function's contract.

What are the limitations of this Common Lisp style skill?

It provides guidance only and cannot enforce rules automatically in a compiler or linter. Repository-specific requirements and newer authoritative guidance take precedence over the guide's recommendations.