agentsclimarketplace

Code quality

Skill S3YED/appie-kit/skills/ops/code-quality

Build Your Own AI Employee. The complete starter kit for OpenClaw + Hermes Agent. 155 deduplicated skills, drag-and-drop workspace, case studies, install scripts.

Install
npx -y skills add S3YED/appie-kit --skill code-quality

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 6 stars6 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Code quality and verification: codebase metrics, post-implementation cleanup, and pre-commit verification pipeline.

The file declares its own license as MIT. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.

SKILL.md

6.9 KB, ~1.7k tokens by cl100k_base, as published. Nobody here has run it

Code Quality & Verification

Three complementary tools for ensuring code quality at different stages of development:

ModeWhenToolWhat it does
Codebase MetricsExplore/adopt a repopygountAnalyze LOC, language breakdown, code-vs-comment ratios
Simplify CodeAfter implementing changes3 parallel subagentsClean up recent changes for reuse, quality, efficiency
Pre-Commit VerificationBefore git commitAutomated pipelineSecurity scan, quality gates, independent reviewer, auto-fix

Section 1: Codebase Metrics (pygount)

Analyze repositories for lines of code, language breakdown, file counts, and code-vs-comment ratios.

When to Use

  • User asks for LOC (lines of code) count
  • User wants a language breakdown of a repo
  • User asks about codebase size or composition
  • General "how big is this repo" questions

Prerequisites

pip install --break-system-packages pygount 2>/dev/null || pip install pygount

Basic Summary

cd /path/to/repo
pygount --format=summary \
  --folders-to-skip=".git,node_modules,venv,.venv,__pycache__,.cache,dist,build,.next,.tox,.eggs,*.egg-info" \
  .

IMPORTANT: Always use --folders-to-skip to exclude dependency/build directories, otherwise pygount will crawl them and hang.

Common Folder Exclusions

# Python projects
--folders-to-skip=".git,venv,.venv,__pycache__,.cache,dist,build,.tox,.eggs,.mypy_cache"

# JavaScript/TypeScript projects
--folders-to-skip=".git,node_modules,dist,build,.next,.cache,.turbo,coverage"

Filter by Language

# Only count Python files
pygount --suffix=py --format=summary .

# Only count Python and YAML
pygount --suffix=py,yaml,yml --format=summary .

Output Formats

pygount --format=summary .        # Summary table
pygount --format=json .           # JSON for programmatic use

Interpreting Results

The summary table columns: Language, Files, Code (executable lines), Comment (documentation lines), % (percentage of total).

Special pseudo-languages: __empty__ (empty files), __binary__ (binary), __generated__ (auto-generated), __duplicate__ (identical content), __unknown__ (unrecognized types).

Pitfalls

  1. Always exclude .git, node_modules, venv — without --folders-to-skip, pygount crawls everything and may hang
  2. Markdown shows 0 code lines — pygount classifies all Markdown as comments, not code (expected)
  3. JSON files show low code counts — use wc -l for accurate JSON line counts
  4. Large monorepos — use --suffix to target specific languages rather than scanning everything

Section 2: Simplify Code — Parallel Review & Cleanup

Review recent code changes with three focused reviewers running in parallel, aggregate findings, and apply fixes.

Core principle: Three narrow reviewers beat one broad reviewer. Each deeply searches the codebase for a single class of problem.

When to Use

  • "simplify" / "simplify my changes" / "review my code"
  • "/simplify" (Claude Code habit)

Optional modifiers: Focus (reuse/quality/efficiency), Dry run (report only), Scope (last commit / staged / specific file)

Phase 1 — Identify Changes

# Default: uncommitted working-tree changes
git diff

# If empty, include staged
git diff HEAD

# Scoped variants:
git diff --staged              # staged changes
git diff HEAD~1                # last commit
git diff main...HEAD           # this branch/PR
git diff -- src/foo.py         # specific file

Phase 2 — Launch Three Reviewers

Use delegate_task batch mode — pass all three tasks in one tasks array:

Reviewer 1 — Code Reuse: Search for code that duplicates existing functionality. Check utility modules, shared helpers, adjacent files for existing functions to reuse.

Reviewer 2 — Code Quality: Look for redundant state, parameter sprawl, copy-paste-with-variation, leaky abstractions, stringly-typed code.

Reviewer 3 — Efficiency: Look for unnecessary work, missed concurrency, hot-path bloat, TOCTOU anti-patterns, memory issues, overly broad reads.

Each gets the complete diff plus repo path and toolsets [terminal, file, search].

Phase 3 — Aggregate and Apply

  1. Merge findings, dedup overlaps
  2. Discard false positives
  3. Resolve conflicts: correctness > user's focus > readability > micro-perf
  4. Apply fixes with patch/write_file (or dry run)
  5. Verify: run targeted tests + linter
  6. Summarize what changed and what was skipped

Pitfalls

  • Don't fan out wider than ~3 reviewers
  • Give the WHOLE diff to each reviewer
  • Require file:line evidence from reviewers
  • Keep edits scoped to what the diff touched
  • Check AGENTS.md / CLAUDE.md for project conventions

Section 3: Pre-Commit Verification

Automated verification pipeline before code lands. Static scans, baseline-aware quality gates, an independent reviewer subagent, and an auto-fix loop.

Core principle: No agent should verify its own work. Fresh context finds what you miss.

When to Use

  • After implementing a feature or bug fix, before git commit or git push
  • When user says "commit", "push", "ship", "done", "verify", or "review before merge"
  • After completing a task with 2+ file edits in a git repo

Skip for: documentation-only changes, pure config tweaks, or explicit "skip verification".

Step 1 — Get the Diff

git diff --cached

If empty, try git diff then git diff HEAD~1 HEAD. If diff exceeds 15K chars, split by file.

Step 2 — Static Security Scan

Scan added lines for hardcoded secrets, shell injection, dangerous eval/exec, unsafe deserialization, SQL injection:

git diff --cached | grep "^+" | grep -iE "(api_key|secret|password|token|passwd)\s*=\s*['\"][^'\"]{6,}['\"]"
git diff --cached | grep "^+" | grep -E "os\.system\(|subprocess.*shell=True"
git diff --cached | grep "^+" | grep -E "\beval\(|\bexec\("
git diff --cached | grep "^+" | grep -E "pickle\.loads?\("
git diff --cached | grep "^+" | grep -E "execute\(f\"|\.format\(.*SELECT|\.format\(.*INSERT"

Step 3 — Baseline Tests and Linting

Detect the project language and run appropriate tools. Capture baseline BEFORE changes (stash changes, run, pop). Only NEW failures block commit.

Test frameworks (auto-detect):

python -m pytest --tb=no -q 2>&1 | tail -5
npm test -- --passWithNoTests 2>&1 | tail -5
cargo test 2>&1 | tail -5
go test ./... 2>&1 | tail -5

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.

Keep looking

Skills are one crate of 326,984. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.