SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillscodeguard-init

codeguard-init

Agents & models

View repository

Updated 10-15 21:48

About this skill

Initialize project onboarding to codeguard

Workflow

Step 1: Detect project language

python3 "${CLAUDE_PLUGIN_ROOT}/scripts/detect_lang.py" .

Step 2: Copy the corresponding linter configuration file

Detected language Copy to project root
Java linters/checkstyle/p3c-javadoc-enforced.xml → checkstyle.xml
Java linters/checkstyle/checkstyle-suppressions.xml → checkstyle-suppressions.xml
Rust linters/clippy/strict.toml → clippy.toml
TypeScript linters/eslint/recommended.cjs → eslint.config.js
Python Append linters/ruff/pyproject-snippet.toml the [tool.ruff] block to pyproject.toml

Step 3: Write .pre-commit-config.yaml

If the project rootdoes not have .pre-commit-config.yaml, copy from linters/pre-commit/.pre-commit-config.template.yaml and tailor it to this project's languagetrim(remove inapplicable language blocks).

Ifalready has .pre-commit-config.yaml, ask the user: "An existing pre-commit configuration was detected. Merge the codeguard entries?"

Step 4: Incrementally update AGENTS.md

If there is no AGENTS.md, create it and write:

# AGENTS.md

## 代码规范（由 codeguard 插件管理）

- 项目使用 [codeguard](https://github.com/partme-ai/partme-codeguard-plugin)
- 检测到的语言：<从步骤 1 输出>
- Linter：checkstyle (Java) / clippy (Rust) / eslint (TS) / ruff (Python)
- **AI 写代码会被 PostToolUse 钩子强制 lint**；失败会阻塞继续
- **用户要求「提交/push」时** UserPromptSubmit 钩子会再次确认全部通过

If there is already AGENTS.md，Appendthe above section; do not overwrite existing content.

Step 5: Write GitHub Actions CI (optional)

If the project rootdoes not have .github/workflows/, ask the user: "Generate a GitHub Actions workflow?"

If yes, write .github/workflows/lint.yml：

name: lint
on: [push, pull_request]
jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-java@v4   # Java 项目需要
        with: { distribution: temurin, java-version: 17 }
      - uses: actions/setup-python@v5  # Python 项目需要
        with: { python-version: '3.10' }
      - uses: actions/setup-node@v4    # TS 项目需要
        with: { node-version: '20' }
      - uses: arduino/setup-protoc@v1  # 仅 Rust 需要（如适用）
      - run: pip install pre-commit
      - run: pre-commit run --all-files

Step 6: Ask the user

Output the installation command (do not execute it automatically):

pip install pre-commit
pre-commit install

And remind: "pre-commit is configured. The linter will now run automatically on every git commit."

Boundaries

  • Do not delete or overwrite the project's existing .pre-commit-config.yaml / checkstyle.xml / eslint.config.js
  • Do not overwrite existing AGENTS.md content (append sections only)
  • Do not automatically execute pre-commit install(let the user decide)

Out of scope (when not to use)

  • The user only wants a one-off lint check and does not want to modify the repository configuration.
  • The repository already has another managed quality gate, but it has not yet been decided whether to merge or keep it.
  • A global CLI install, modification of a developer's local hooks, or publishing CI is required without explicit authorization.

Data and security

Initialization should be completed locally, without collecting, uploading, or logging repository code or credentials. When generating CI, do not write tokens, passwords, or internal network addresses into the workflow; use secret name placeholders and explain the minimum permissions required.

Controlled Workflow

Step 1: Read repository instructions

Confirm the Git root, branch, uncommitted changes, AGENTS/CLAUDE instructions, and existing CI/spec documents.

Step 2: Read-only inventory

List existing linters, formatters, pre-commit, CI, ignore, suppression, and generated-file rules, and mark each file as create/merge/skip.

Step 3: Detect language and verify capabilities

Cross-validate the codeguard detect results against the repository's actual build files; for planned languages, do not generate fake gates.

Step 4: Generate a merge plan

Before writing files, show the targets to be created, modified, and preserved, along with the risks. If existing configuration conflicts, stop and ask the user to decide.

Step 5: Perform minimal onboarding

Make incremental modifications only to approved files; preserve existing versions, custom rules, and user comments.

Step 6: Verify configuration

Run the configuration parser, Codeguard detect/check dry-run, and CI syntax check; when tools are unavailable, report UNVERIFIED。

Step 7: Deliver manual actions

Clearly list the tools the user needs to install, hook enablement, secret configuration, and initial CI verification; do not pretend they are already completed.

Rules

  1. Always merge any existing configuration first; do not overwrite directly.
  2. Do not delete team custom rules in order to enable Codeguard.
  3. Do not automatically install global tools, Git hooks, or CI secrets.
  4. Only gates that have actually been executed and passed may be reported as integrated.
  5. Configuration changes must come with a diff summary and a rollback method.

Output template

Codeguard init 结果
- 仓库/模块：<scope>
- 语言：<detected + evidence>
- 现有门禁：<inventory>
- 文件处理：<create/merge/skip>
- 已验证：<commands and exits>
- 未验证：<missing tools/CI/secrets>
- 用户待执行：<hook/install/publish actions>

Gotchas

  1. YAML merging is not text appending: duplicate keys can cause CI configuration to be silently overwritten.
  2. A pre-commit hook and CI are not the same evidence: a locally installed hook does not mean the remote workflow can run.
  3. Tool version drift: reuse the repository's existing version pinning wherever possible.
  4. monorepo scope: the root configuration may not apply to every subpackage; the working-directory must be made explicit.
  5. Existing uncommitted files: overlapping modifications must not be overwritten with generated templates.
  6. Generating files alone does not mean integration is complete: actual parser, check, and CI run evidence is still required.

Load resources on demand

  • When inventorying existing configuration, read references/rules/merge-policy.md。
  • When designing the integration order and rollback, read references/operations/adoption-playbook.md。
  • Based on the current repository state, read only the corresponding examples in examples/ .