@bastani/atomic 0.9.16-alpha.5 → 0.9.16-alpha.7

package/CHANGELOG.md

@@ -2,6 +2,13 @@
 
 ## [Unreleased]
 
+## [0.9.16-alpha.6] - 2026-08-26
+
+### Changed
+
+- The default system prompt now teaches repository-intent inference when a shell tool is available: review recent commits, open and merged PRs, issues and their comments, and project/board status to learn maintainer conventions, and identify the requesting user (`git config user.name`/`user.email`, `gh api user`) to interpret ambiguous requests through their own patterns.
+- The ask_user_question fallback guideline now instructs the agent, when no human input channel exists, to choose the interpretation best supported by the repository and stated objective — mining git history, commits, PRs, issues, and the user's own comments to infer how they would decide — state the assumption, and continue fully autonomously instead of stalling.
+
 ## [0.9.16-alpha.5] - 2026-08-26
 
 ### Added

package/dist/builtin/intercom/index.bundle.mjs

@@ -16007,7 +16007,10 @@ Current working directory: ${promptCwd}
     }
   }
   if (shouldIncludeAskUserFallbackGuidance) {
-    addGuideline("Clarify ambiguous requirements using the ask_user_question tool if available.");
+    addGuideline("Clarify ambiguous requirements using the ask_user_question tool if available. When it is unavailable and no human input channel exists, do not stall on a question: choose the interpretation best supported by the repository and the stated objective — mine git history, commits, PRs, issues, and the user's own comments to infer how they would decide — state the assumption in your response, and continue fully autonomously on best judgment.");
+  }
+  if (hasBash || hasPowerShell) {
+    addGuideline("**Repository intent**: When working in a repository, infer how its maintainers actually work before imposing defaults: review recent commits, open and merged PRs, issues and their comments, and project/board status when tooling allows (for example `git log` and the `gh` CLI) to learn conventions, priorities, and scope norms. Better, identify the requesting user (`git config user.name`/`user.email`, `gh api user`) and study their own commits, PRs, reviews, and issue comments so you interpret ambiguous requests the way they would, aligning style, scope, and process with their patterns.");
   }
   for (const guideline of promptGuidelines ?? []) {
     const normalized = guideline.trim();

package/dist/builtin/intercom/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@bastani/intercom",
-  "version": "0.9.16-alpha.5",
+  "version": "0.9.16-alpha.7",
   "private": true,
   "description": "Atomic extension providing a private coordination channel between parent and child agent sessions. Fork of: https://github.com/nicobailon/pi-intercom",
   "contributors": [

package/dist/builtin/mcp/index.bundle.mjs

@@ -16007,7 +16007,10 @@ Current working directory: ${promptCwd}
     }
   }
   if (shouldIncludeAskUserFallbackGuidance) {
-    addGuideline("Clarify ambiguous requirements using the ask_user_question tool if available.");
+    addGuideline("Clarify ambiguous requirements using the ask_user_question tool if available. When it is unavailable and no human input channel exists, do not stall on a question: choose the interpretation best supported by the repository and the stated objective — mine git history, commits, PRs, issues, and the user's own comments to infer how they would decide — state the assumption in your response, and continue fully autonomously on best judgment.");
+  }
+  if (hasBash || hasPowerShell) {
+    addGuideline("**Repository intent**: When working in a repository, infer how its maintainers actually work before imposing defaults: review recent commits, open and merged PRs, issues and their comments, and project/board status when tooling allows (for example `git log` and the `gh` CLI) to learn conventions, priorities, and scope norms. Better, identify the requesting user (`git config user.name`/`user.email`, `gh api user`) and study their own commits, PRs, reviews, and issue comments so you interpret ambiguous requests the way they would, aligning style, scope, and process with their patterns.");
   }
   for (const guideline of promptGuidelines ?? []) {
     const normalized = guideline.trim();

package/dist/builtin/mcp/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@bastani/mcp",
-  "version": "0.9.16-alpha.5",
+  "version": "0.9.16-alpha.7",
   "private": true,
   "description": "Atomic extension that adapts MCP (Model Context Protocol) servers into the coding agent. Fork of: https://github.com/nicobailon/pi-mcp-adapter",
   "contributors": [

package/dist/builtin/subagents/CHANGELOG.md

@@ -2,6 +2,12 @@
 
 ## [Unreleased]
 
+## [0.9.16-alpha.7] - 2026-08-26
+
+### Added
+
+- New bundled `qlty` skill for code-quality verification through the [qlty](https://qlty.sh) CLI: linting (`qlty check`), auto-formatting (`qlty fmt`), maintainability metrics (`qlty metrics`), and code smells such as duplication and deep nesting (`qlty smells`). The skill triggers on requests for verifiers or high code quality, directs the agent to `https://docs.qlty.sh/llms.txt` as the authoritative documentation index, instructs it to enable the qlty plugins and linter extensions that fit the codebase rather than invoking per-tool linters ad hoc, and ships source-attributed reference excerpts under `skills/qlty/references/`.
+
 ## [0.9.16-alpha.5] - 2026-08-26
 
 ### Changed

package/dist/builtin/subagents/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@bastani/subagents",
-  "version": "0.9.16-alpha.5",
+  "version": "0.9.16-alpha.7",
   "private": true,
   "description": "Atomic extension for delegating tasks to subagents with parallel execution. Fork of: https://github.com/nicobailon/pi-subagents",
   "contributors": [

package/dist/builtin/subagents/skills/qlty/SKILL.md

@@ -0,0 +1,123 @@
+---
+name: qlty
+description: Code quality checks, formatting, and metrics via qlty CLI. Use when asked to verify code quality, add or run verifiers, make sure code is high quality before commit or handoff, lint or auto-format a codebase, measure complexity, cohesion, or lines of code, or find code smells like duplication and deep nesting.
+---
+
+# Qlty Code Quality
+
+`qlty` is a universal code quality tool: one CLI that drives 70+ linters, auto-formatters, and security scanners across 40+ languages and technologies, plus its own static analysis for metrics and code smells.
+
+**Prefer the `qlty` CLI over ad-hoc per-tool linter invocations.** Do not reach for `eslint`, `ruff`, `rubocop`, `shellcheck`, `prettier`, `gofmt`, and friends one at a time. Run them through `qlty check` / `qlty fmt` so every language in the repository is covered by one command, with one config, one cache, and one consistent issue format. Fall back to invoking a tool directly only when the repository's own scripts require it (for example a project's `npm run check`) or when qlty has no plugin for it.
+
+## Documentation
+
+**Reference <https://docs.qlty.sh/llms.txt> heavily.** It is the authoritative index of every qlty documentation page, each available as Markdown by appending `.md` to the page URL. Fetch the index first, then fetch the specific pages you need — command pages under `https://docs.qlty.sh/cli/commands/`, concepts under `https://docs.qlty.sh/cli/concepts/`, and language support under `https://docs.qlty.sh/languages/`.
+
+Local excerpts of the most-used pages live in [references/](references/), each attributed to its upstream URL:
+
+- [references/quickstart.md](references/quickstart.md) — install, `qlty init`, first run
+- [references/commands.md](references/commands.md) — `check`, `fmt`, `metrics`, `smells`, `init`, `plugins`
+- [references/plugins-and-extensions.md](references/plugins-and-extensions.md) — enabling plugins, linter extensions, `qlty.toml`
+- [references/coding-with-ai-agents.md](references/coding-with-ai-agents.md) — upstream's own guidance for agents
+
+The local copies are point-in-time excerpts. When they disagree with the live docs, the live docs win — fetch from `llms.txt`.
+
+## When to Use
+
+- **Check code for linting issues before commit or handoff.** `qlty check` is the last gate before you hand work to a human or another stage.
+- **Auto-fix formatting and style issues.** `qlty fmt` rewrites files; `qlty check --fix` applies lint auto-fixes.
+- **Calculate code metrics** — complexity, lines of code, cohesion, duplication — with `qlty metrics`.
+- **Find code smells** — duplicated code, deeply nested control flow, overly complex functions — with `qlty smells`.
+- **When a user asks for "verifiers", or asks you to make sure the code is high quality, use this skill.** Those requests mean: enable the right linters for this codebase, then run the check/fmt/metrics/smells loop and fix what it reports.
+
+## Install
+
+Skip this if `qlty --version` already works.
+
+```bash
+# macOS & Linux
+curl https://qlty.sh | bash
+```
+
+Upstream documents the same installer as `curl https://qlty.sh | sh`; both work, the script is POSIX `sh`.
+
+```powershell
+# Windows
+powershell -c "iwr https://qlty.sh | iex"
+```
+
+The binary lands in `~/.qlty/bin` and **that directory must be on `PATH`**. The installer appends an export to your shell rc file, which does not help a non-interactive or already-running shell — export it yourself when a command reports `qlty: command not found`:
+
+```bash
+export PATH="$HOME/.qlty/bin:$PATH"
+```
+
+Two useful installer environment variables: `QLTY_INSTALL_BIN_PATH` puts the binary somewhere already on `PATH` (for example `$HOME/.local/bin`), and `QLTY_NO_MODIFY_PATH=1` suppresses the rc-file edit. qlty supports macOS and Linux on x64 and arm64 (glibc and musl); Windows support is newer, so verify it rather than assuming.
+
+## Enable the right plugins for this codebase
+
+Blindly running `qlty check` in a repository with no configuration finds nothing. Tailor the plugin set to the codebase first — this is what turns qlty from a lint runner into a quality bar.
+
+```bash
+qlty init                      # detect file types, write .qlty/qlty.toml with a baseline plugin set
+qlty plugins list              # every available plugin
+qlty plugins enable eslint     # enable one the baseline missed
+```
+
+Then review `.qlty/qlty.toml` against what the repository actually uses: a TypeScript repo usually wants `eslint` plus `prettier`, Python wants `ruff`, Go wants `staticcheck`/`gofmt`, shell wants `shellcheck`/`shfmt`, and almost every repo benefits from `trivy` or `gitleaks` for secrets and vulnerabilities. Enable security and type-checking plugins deliberately; they are the ones that catch defects rather than style.
+
+Also enable **linter extensions** — the plugin ecosystem of each linter (`eslint-plugin-react`, `eslint-plugin-security`, RuboCop extensions, Ruff/Pylint/Bandit packages). In `qlty.toml`, either list them with `extra_packages` or point at the project's own dependency manifest with `package_file`:
+
+```toml
+[[plugin]]
+name = "eslint"
+version = "8.57.0"
+extra_packages = ["eslint-plugin-react@7.33.2", "eslint-plugin-security@3.0.1"]
+```
+
+See [references/plugins-and-extensions.md](references/plugins-and-extensions.md) and <https://docs.qlty.sh/cli/linter-extensions.md>.
+
+`qlty init` writes `.qlty/qlty.toml` into the repository. In someone else's checkout that is a real, reviewable change — say so before running it, and do not leave it behind uncommitted in a repository you were only asked to inspect.
+
+## Core commands
+
+All of `check`, `fmt`, and `smells` must run inside a Git repository with qlty initialized, and default to **changed files only**; pass `--all` or explicit paths to widen. `check` and `fmt` install any missing plugins and language runtimes on demand, so the first run is slow and needs network access.
+
+```bash
+qlty check                                   # lint changed files
+qlty check --all                             # lint the whole repository
+qlty check --all --filter=eslint             # one plugin only
+qlty check --fix --level=low                 # apply auto-fixes, surface low-severity and up
+qlty check --upstream origin/main            # only what this branch changed
+
+qlty fmt                                     # auto-format changed files
+qlty fmt --all                               # auto-format everything
+
+qlty metrics --all --max-depth 2             # per-directory summary
+qlty metrics --all --sort complexity --limit 10   # the 10 most complex files
+qlty metrics --functions path/to/file.ts     # function-level complexity
+
+qlty smells --all                            # duplication, deep nesting, high complexity
+qlty smells --upstream origin/main           # smells introduced by this branch
+```
+
+`--level` sets what is displayed (`note`, `fmt`, `low`, `medium`, `high`); `--fail-level` sets what makes the command exit non-zero. `--sarif` emits SARIF for tooling.
+
+## Offline use
+
+The `qlty` binary is self-contained, but its commands split on network needs:
+
+- **Offline-safe:** `qlty metrics` and `qlty smells` use qlty's own built-in static analysis — no plugin or runtime downloads, so they work with no network at all.
+- **Network on first use:** `qlty check` and `qlty fmt` install the enabled plugins and any qlty-managed language runtimes on demand, per repository, on their first run. With no network that first run fails.
+
+In a network-restricted environment (sandboxes, locked-down CI, benchmark runs), either pre-warm the cache while you still have network — run `qlty init` and one `qlty check --all` in the target repository so plugins and runtimes land in `~/.qlty` — or scope quality verification to `qlty metrics` and `qlty smells` and say so in your report rather than presenting them as full lint coverage.
+
+## Working loop
+
+Upstream's own recommendation for agents, and a good default here:
+
+1. `qlty fmt` before committing — formatting churn should never reach a reviewer.
+2. `qlty check --fix --level=low` before finishing, then fix by hand whatever it could not auto-fix.
+3. For a quality-focused request, add `qlty smells --all` and `qlty metrics --all --sort complexity --limit 10`, and act on the worst offenders rather than reporting the numbers.
+
+Report what you ran and what it found. A clean `qlty check` is evidence; "I made it high quality" is not.

package/dist/builtin/subagents/skills/qlty/references/coding-with-ai-agents.md

@@ -0,0 +1,64 @@
+# Coding with AI Agents
+
+> **Source:** <https://docs.qlty.sh/cli/coding-with-ai-agents.md> (retrieved 2026-08-26).
+> Copied verbatim from the upstream page; only the MDX `<Note>` wrapper was rendered as a
+> Markdown blockquote and relative links were expanded to absolute URLs.
+
+## Use Qlty CLI with AI Coding Agents
+
+Qlty CLI gives your AI coding tools a universal "quality gate" for code linting, auto-formatting, and maintainability checks. When you let your coding agent run Qlty as part of its workflow, it can automatically clean up code, catch issues early, and ship changes that pass the same standards you expect from human contributors.
+
+## Requirements
+
+* Qlty CLI installed and available on `$PATH`.
+* A Qlty analysis config (`.qlty/qlty.toml`) tailored to your project.
+
+## Compatibility
+
+Qlty can be integrated with most AI coding agents that can run shell commands. Popular options include:
+
+* Claude Code
+* GitHub Copilot
+* Cursor IDE
+* OpenAI Codex
+* Other agents that can run shell commands
+
+> **Note:** Network access must be available from the agent environment.
+
+## Integration methods
+
+Because `qlty` is a command-line tool, it can be integrated into your AI agent's workflow in several ways:
+
+1. Project memory/instructions (simplest) -- e.g. `CLAUDE.md`
+2. Git hooks -- This method works automatically for both humans and agents.
+3. Agent-specific hooks -- e.g. Claude Code [hooks](https://docs.anthropic.com/en/docs/claude-code/hooks)
+
+The `qlty` command is run with CLI arguments and reads code files from the local filesystem. Output is printed to standard out, and exit codes indicate success or failure. This simple interface avoids the need for Model Context Protocol (MCP) server or API integration.
+
+### Project memory integration
+
+Each AI Agent offer ways to integrate custom instructions. When coding, agents read these instructions and follow them as part of their workflow. You can add instructions to run the `qlty` command at the right time.
+
+The necessary instructions can be as simple as the following:
+
+```md
+- Before committing, ALWAYS run auto-formatting with `qlty fmt`
+- Before finishing, ALWAYS run `qlty check --fix --level=low` and fix any lint errors
+```
+
+You can customize these instructions to fit the particulars of your desired workflow.
+
+Each AI coding agent has different paths that it will check for instructions files. Some examples include:
+
+* Claude Code: `CLAUDE.md`
+* Cursor: `AGENTS.md`
+* OpenAI Codex: `AGENTS.md`
+* GitHub Copilot: `.github/copilot-instructions.md`
+
+Please refer to the documentation of your chosen agent for details on how to add custom instructions.
+
+### Git hooks integration
+
+The Qlty CLI can be run through Git hooks to enforce quality gates for both human and AI commits. This method works with any AI agent that can commit code via Git.
+
+The typical configuration is to set up a pre-commit hook to run `qlty fmt` and a pre-push hook to run `qlty check`. See [Qlty Git Hooks](https://docs.qlty.sh/cli/git-hooks.md) for more details.

package/dist/builtin/subagents/skills/qlty/references/commands.md

@@ -0,0 +1,291 @@
+# Qlty CLI Command Reference
+
+> **Sources** (all retrieved 2026-08-26), one section per upstream page:
+> <https://docs.qlty.sh/cli/commands/init.md>, <https://docs.qlty.sh/cli/commands/check.md>,
+> <https://docs.qlty.sh/cli/commands/fmt.md>, <https://docs.qlty.sh/cli/commands/metrics.md>,
+> <https://docs.qlty.sh/cli/commands/smells.md>, <https://docs.qlty.sh/cli/commands/plugins-list.md>,
+> <https://docs.qlty.sh/cli/commands/plugins-enable.md>.
+> Prose, flag descriptions, and examples are copied from those pages unchanged; the MDX
+> `<AccordionGroup>` / `<Accordion>` option lists are rendered as Markdown bullet lists and the
+> per-example captions are rendered as code-block comments. `initializd` is upstream's typo,
+> preserved. For any flag not listed here, fetch the live page via <https://docs.qlty.sh/llms.txt>.
+
+---
+
+## `init`
+
+```bash
+qlty init [OPTIONS]
+```
+
+Set up Qlty in the current repository
+
+This command will generate an initial project configuration file based on the contents of the repository and write it to `.qlty/qlty.toml` at the repository root.
+
+When run without the `--skip-plugins` command, initialization will try to determine a reasonable set of linters and formatters to enable. Certain linters and formatters are enabled based on the detection of a linter configuration file. Others are enabled just based on the presence of target files of the programming language.
+
+Following initialization, the command will print a summary of the configuration.
+
+After generating a configuration file, the command will ask if you want to *sample* the results of the enabled plugins. Sampling runs each plugin against a small set of targets.
+
+If Qlty is already initialized in the current repository, this command will exit with an error.
+
+### Arguments
+
+* `-y, --yes` — Answer yes to all prompts
+* `-n, --no` — Answer no to all prompts
+* `--skip-plugins` — Skip enabling plugins
+* `--dry-run` — Print the generated configuration to stdout instead of saving to disk
+* `--skip-default-source` — Initialize without default source
+* `--source <SOURCE>` — A custom source to use for plugins. This can be a URL(name=url) or a path to a local directory(name=directory)
+
+### Examples
+
+```bash
+# Generate a Qlty config for the current repository
+qlty init
+
+# Generate a Qlty config and skip prompts
+qlty init --no
+
+# Generate a Qlty config with no plugins
+qlty init --skip-plugins
+```
+
+---
+
+## `check`
+
+```bash
+qlty check [OPTIONS] [PATHS]...
+```
+
+Run linters
+
+By default, only changed files are analyzed. Use `--all` or specify paths to override this behavior.
+
+Installs plugins and their required runtimes as needed before analyzing.
+
+By default, issues are cached locally to speed up subsequent runs.
+
+Must be run within a Git repository with Qlty initializd.
+
+### Arguments
+
+* `[PATHS]...` — Files to analyze
+* `-a, --all` — Check all files, not just changed
+* `--fix` — Apply all auto-fix suggestions automatically. When combined with `--ai`, AI-generated fixes are applied without prompting for review. See [AI Autofixes Security Considerations](https://docs.qlty.sh/cloud/ai-autofixes.md#security-considerations) for important guidance when using this flag.
+* `--no-fix` — Do not apply auto-fix suggestions
+* `--ai` — Generate AI-powered fixes using a large language model (requires Qlty Cloud authentication). AI fixes should be reviewed before applying. Using `--ai` with `--fix` applies AI suggestions automatically without review—see [Security Considerations](https://docs.qlty.sh/cloud/ai-autofixes.md#security-considerations).
+* `--unsafe` — Allow fixes for rules that may produce incorrect results and require careful human review. By default, fixes for certain rules are blocked because they are more likely to need manual judgment. This flag removes those restrictions.
+* `--no-formatters` — Disable formatter checks
+* `--no-progress` — Disable progress bar
+* `--no-fail` — Exit successfully regardless of what issues are found
+* `--no-error` — Exit successfully regardless of linter errors
+* `--sample <SAMPLE>` — Sample results from a number of files for each linter
+* `--level <LEVEL>` — Minimum level of issues to show [default: note] [possible values: note, fmt, low, medium, high]
+* `-j, --jobs <JOBS>` — Maximum number of concurrent jobs
+* `--filter <FILTER>` — Filter by plugin or check
+* `-v, --verbose...` — Print verbose output
+* `--summary` — Print a summary of issues
+* `--upstream <UPSTREAM>` — Upstream base ref to compare against
+* `--no-cache` — Disable caching issues
+* `--print-errors` — Print errors to stderr
+* `--fail-level <FAIL_LEVEL>` — Minimum level of issues to fail on [default: fmt] [possible values: note, fmt, low, medium, high]
+* `--sarif` — SARIF output
+
+### Examples
+
+```bash
+# Run linters on changed files on your current branch
+qlty check
+
+# Run linters on all files
+qlty check --all
+
+# Run only ESLint on all files
+qlty check --all --filter=eslint
+
+# Run linters on the web/ folder
+qlty check web/
+```
+
+---
+
+## `fmt`
+
+```bash
+qlty fmt [OPTIONS] [PATHS]...
+```
+
+Auto-format files by rewriting them
+
+By default, only changed files are auto-formatted. Use `--all` or specify paths to override this behavior.
+
+Installs plugins and their required runtimes as needed before analyzing.
+
+Must be run within a Git repository with Qlty initializd.
+
+### Arguments
+
+* `[PATHS]...` — Files to analyze
+* `-a, --all` — Check all files, not just changed
+* `--no-progress` — Disable progress bar
+* `--no-error` — Exit successfully regardless of linter errors
+* `--sample <SAMPLE>` — Sample results from a number of files for each linter
+* `--jobs <JOBS>` — Maximum number of concurrent jobs
+* `--filter <FILTER>` — Filter by plugin or check
+* `--trigger <TRIGGER>` — [default: manual] [possible values: manual, pre-commit, pre-push, build]
+* `-v, --verbose...` — Print verbose output
+* `--upstream <UPSTREAM>` — Upstream base ref to compare against
+* `--index` — Format files in the Git index
+* `--index-file <INDEX_FILE>` — Format files in the specified Git index file
+
+### Examples
+
+```bash
+# Auto-format changed files on your current branch
+qlty fmt
+
+# Auto-format all files with prettier
+qlty fmt --all --filter=prettier
+
+# Auto-format files in a directory
+qlty fmt web/
+```
+
+---
+
+## `metrics`
+
+```bash
+qlty metrics [OPTIONS] [PATHS]...
+```
+
+Compute code quality metrics
+
+Calculate metrics like classes count, complexity, lines of code, and cohesion for [supported languages](https://docs.qlty.sh/languages.md) using our custom built static analysis.
+
+### Arguments
+
+* `[PATHS]...` — Files to analyze
+* `-a, --all` — Compute metrics for all files, not just changed
+* `-d, --dirs` — Print per-directory stats
+* `--functions` — Print function stats
+* `--max-depth <MAX_DEPTH>` — Directory depth to print, this flag will also set to print per-directory stats
+* `--sort <SORT>` — Sort output by column [possible values: name, classes, functions, fields, lines, loc, complexity, lcom]
+* `--limit <LIMIT>` — Maximum rows to print
+* `--exclude-tests` — Exclude tests
+* `--upstream <UPSTREAM>` — Upstream base ref to compare against
+* `--quiet` — Only show results
+
+### Examples
+
+```bash
+# Summarize metrics across directories
+qlty metrics --all --max-depth 2
+
+# Review the 10 most complex files
+qlty metrics --all --sort complexity --limit 10
+
+# View function-level metrics for a file
+qlty metrics --functions remix/app/root.tsx
+```
+
+---
+
+## `smells`
+
+```bash
+qlty smells [OPTIONS] [PATHS]...
+```
+
+Find code smells like duplication and complexity
+
+Detect issues like duplication (copy and pasted code), high complexity, deeply nested control flows, etc. for [supported languages](https://docs.qlty.sh/languages.md) using our custom built static analysis.
+
+### Arguments
+
+* `[PATHS]...` — Files to analyze
+* `-a, --all` — Compute smells for all files, not just changed
+* `--no-duplication` — Don't check for duplication
+* `--include-tests` — Include tests
+* `--no-snippets` — Don't show code snippets
+* `--upstream <UPSTREAM>` — Upstream base ref to compare against
+* `--quiet` — Only show results
+
+### Examples
+
+```bash
+# Analyze your current branch
+qlty smells
+
+# Analyze your entire project for code smells
+qlty smells --all
+
+# Analyze specific paths for code smells
+qlty smells example-app/components/ui react-app/utils
+
+# Analyze a specific file for code smells
+qlty smells example-app/components/ui/Dropdown.tsx
+
+# Skip duplication analysis
+qlty smells --all --no-duplication
+
+# Analyze for code smells against a specific upstream branch
+qlty smells --upstream origin/main
+```
+
+---
+
+## `plugins list`
+
+```bash
+qlty plugins list [OPTIONS]
+```
+
+List all available plugins
+
+This command lists all available plugins based on the sources declared in the current project's `qlty.toml` configuration file.
+
+### Examples
+
+```bash
+# List all available plugins
+qlty plugins list
+```
+
+---
+
+## `plugins enable`
+
+```bash
+qlty plugins enable [OPTIONS] [PLUGINS]...
+```
+
+Enable plugins for the current project
+
+The command edits the current project's `qlty.toml` file to enable plugins.
+
+### Arguments
+
+* `[PLUGINS]...` — Plugins to enable specified as name=version
+
+### Examples
+
+```bash
+# Enable the latest version of shellcheck
+qlty plugins enable shellcheck
+
+# Enable shellcheck version 1.2.3
+qlty plugins enable shellcheck=1.2.3
+
+# Enable rubocop and eslint
+qlty plugins enable rubocop eslint
+```
+
+### See also
+
+`qlty plugins upgrade`, `qlty plugins disable` — see
+<https://docs.qlty.sh/cli/commands/plugins-upgrade.md> and
+<https://docs.qlty.sh/cli/commands/plugins-disable.md>.