CtrlK
BlogDocsLog inGet started
Tessl Logo

deepkuba/google-java-style

Generate, edit, refactor, and review Java source code according to the Google Java Style Guide. Use when Codex is asked to write Java code, update .java files, format Java snippets, review Java style, or keep Java output compliant with Google style conventions for file structure, imports, formatting, naming, comments, programming practices, and Javadoc.

72

Quality

90%

Does it follow best practices?

Impact

No eval scenarios have been run

SecuritybySnyk

Passed

No known issues

Overview
Quality
Evals
Security
Files

SKILL.md

name:
google-java-style
description:
Generate, edit, refactor, and review Java source code according to the Google Java Style Guide. Use when Codex is asked to write Java code, update .java files, format Java snippets, review Java style, or keep Java output compliant with Google style conventions for file structure, imports, formatting, naming, comments, programming practices, and Javadoc.

Google Java Style

Workflow

Apply Google Java Style to every Java source file or Java snippet produced by the task.

  1. Read references/google-java-style-checklist.md before generating or modifying Java unless the request is only a very small style question already covered by SKILL.md.
  2. Prefer project-local conventions where the Google guide intentionally leaves choices open, but do not violate explicit Google Java Style rules.
  3. If google-java-format, Maven, Gradle, or another configured formatter is available in the project, run the formatter after edits when it is practical and in scope.
  4. Run relevant compile, test, or formatting checks when the repository provides them and the task changes Java code.
  5. Before final output, review generated code against the checklist, especially imports, 2-space indentation, 100-column wrapping, naming, switch exhaustiveness, @Override, and Javadoc requirements. If violations are found, fix them and re-review until the output is clean before finalizing.

Generation Rules

  • Produce complete .java files with license header, package declaration, imports, and exactly one top-level class when the user asks for a file.
  • Include a package declaration for ordinary Java files unless the user is explicitly working with module-info.java, package-info.java, or a snippet that cannot include one.
  • Avoid wildcard imports, module imports, unused imports, and static imports for nested classes.
  • Keep implementation comments sparse and useful. Use Javadoc for visible APIs or when explaining the purpose or behavior of a class or member.
  • Avoid adding TODO comments unless the user asks for intentionally temporary code or a tracked follow-up exists.
  • Preserve semantics first when editing existing code; style-only rewrites should be tightly scoped unless the user asks for broader formatting.

Minimal Well-Formed Java File Template

Use this structure as the baseline for any new .java file:

// Copyright 2024 Example Corp.
//
// Licensed under the Apache License, Version 2.0 (the "License");
// you may not use this file except in compliance with the License.

package com.example.myapp;

import java.util.List;
import java.util.Optional;

/**
 * One-sentence summary of what this class does.
 *
 * <p>Optional extended description in a second paragraph.
 */
public final class MyClass {

  private final List<String> items;

  /** Constructs a {@code MyClass} with the given items. */
  public MyClass(List<String> items) {
    this.items = items;
  }

  /**
   * Returns the first item, or {@link Optional#empty()} if there are none.
   */
  public Optional<String> firstItem() {
    return items.stream().findFirst();
  }
}

Review Rules

When reviewing Java code for style:

  • Report concrete violations with file and line references when available.
  • Separate style violations from design suggestions.
  • Prefer formatter-backed fixes for formatting-only findings.
  • Do not enforce example-only choices from the guide as if they were mandatory rules.

SKILL.md

tile.json