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

package/dist/builtin/subagents/skills/qlty/references/plugins-and-extensions.md

@@ -0,0 +1,228 @@
+# Plugins and Linter Extensions
+
+> **Sources** (retrieved 2026-08-26): <https://docs.qlty.sh/cli/concepts/plugins.md> and
+> <https://docs.qlty.sh/cli/linter-extensions.md>.
+> Copied from those pages. Text and TOML examples are unchanged; MDX `<Note>`, `<Warning>`, and
+> `<CodeGroup>` wrappers are rendered as Markdown blockquotes and separate code blocks, and
+> relative links are expanded to absolute URLs. Full `qlty.toml` reference:
+> <https://docs.qlty.sh/cli/qlty-toml.md>.
+
+---
+
+## Plugins
+
+Qlty integrates with linters, auto-formatters, security scanners, and other static analysis tools as plugins.
+
+> **Note:** Looking for plugin-specific configuration options, supported versions, or invocation
+> details? Each plugin lives in its own folder under
+> [qltysh/qlty/qlty-plugins](https://github.com/qltysh/qlty/tree/main/qlty-plugins) on GitHub —
+> check the plugin's `plugin.toml` and `README.md` for specifics.
+
+Each plugin consists of two components:
+
+1. A plugin definition in a TOML configuration file
+2. A results parser implemented in Rust
+
+Here is a simplified example plugin definition for [Ruff](https://github.com/astral-sh/ruff):
+
+```toml
+# plugin.toml for ruff
+config_version = "0"
+
+[plugins.definitions.ruff]
+runtime = "python"
+package = "ruff"
+file_types = ["python"]
+version_command = "ruff version"
+config_files = ["ruff.toml"]
+issue_url_format = "https://docs.astral.sh/ruff/rules/${rule}"
+
+[plugins.definitions.ruff.drivers.lint]
+script = "ruff check --exit-zero --output-format sarif --output-file ${tmpfile}  ${target}"
+success_codes = [0]
+output = "tmpfile"
+output_format = "sarif"
+batch = true
+```
+
+Gitleaks supports outputting results in the [SARIF](https://sarifweb.azurewebsites.net/) standard format, so a custom results parser is not needed. For tools which do not support SARIF, a results parser is implemented within the Qlty CLI and referenced by name.
+
+### Auto-Formatters
+
+Auto-formatters are a special type of plugin because they *rewrite* files rather than outputting findings. Therefore, they do not require results parsers.
+
+Here is an example of a plugin definition for the [shfmt](https://github.com/mvdan/sh) auto-formatter:
+
+```toml
+# plugin.toml for shfmt
+config_version = "0"
+
+[plugins.definitions.shfmt]
+package = "mvdan.cc/sh/v${major_version}/cmd/shfmt"
+runtime = "go"
+file_types = ["shell"]
+version_command = "shfmt --version"
+affects_cache = [".editorconfig"]
+
+[plugins.definitions.shfmt.drivers.format]
+script = "shfmt -w -s ${target}"
+success_codes = [0, 1]
+output = "rewrite"
+cache_results = true
+batch = true
+driver_type = "formatter"
+```
+
+Note the specification of `output = "rewrite"` and `driver_type = "formatter"`.
+
+---
+
+## Linter Extensions
+
+Linter extensions are additional packages or plugins that extend the functionality of base linter tools that Qlty uses. Depending on the linter, extensions can add:
+
+* Additional rule sets
+* Custom rules
+* Language support
+* Framework-specific checks
+* Additional parsers
+
+For example, ESLint has numerous plugins like `eslint-plugin-react`, `eslint-plugin-security`, and `eslint-plugin-jest` that add specialized rules for React development, security checks, and Jest testing, respectively.
+
+### Supported Package Managers
+
+Qlty supports linter extensions through the following package managers:
+
+* **NPM** (Node.js) - For JavaScript/TypeScript tools like ESLint, Stylelint, etc.
+* **RubyGems** (Ruby) - For Ruby tools like RuboCop, Standard, etc.
+* **PIP** (Python) - For Python tools like Ruff, Pylint, Bandit, etc.
+* **Composer** (PHP) - For PHP tools like PHP\_CodeSniffer, PHPStan, etc.
+
+### Managing linter extensions
+
+Qlty provides two mutually exclusive ways to configure linter extensions in your `qlty.toml` file: `extra_packages` and `package_file`.
+
+#### `extra_packages`
+
+The `extra_packages` property allows you to explicitly list additional packages that should be installed alongside the main linter package (including their versions).
+
+```toml
+# qlty.toml
+[[plugin]]
+name = "eslint"
+version = "8.57.0"
+extra_packages = [
+  "eslint-plugin-react@7.33.2",
+  "eslint-plugin-jest@27.6.0"
+]
+```
+
+This works best when your project contains a very limited set of extra packages (1-2), but does not scale well for moderate to complex projects.
+
+**Pros:**
+
+* Simple, direct specification
+* Version pinning
+* Works without existing package files
+
+**Cons:**
+
+* Duplicates existing dependency management (e.g. package.json)
+* May diverge from project dependencies
+* Supports external packages only (not, e.g. in Project packages)
+
+#### `package_file`
+
+The `package_file` property allows you to reference a package manager file (like `package.json` or `Gemfile`) to manage dependencies. Depending on your use case, you can point the `package_file` either at your project's main package file or at a specific file that contains the linter-related packages.
+
+```toml
+# Project package file
+[[plugin]]
+name = "eslint"
+version = "8.57.0"
+package_file = "package.json"
+```
+
+```toml
+# Linter package file
+[[plugin]]
+name = "eslint"
+version = "8.57.0"
+package_file = ".qlty/configs/package.json"
+```
+
+**Pros:**
+
+* Take advantage of package manager's dependency resolution
+* Consistent with project dependencies (if pointing to the main package file)
+
+**Cons:**
+
+* Project's main package file contains many dependencies
+
+##### `package_filters`
+
+When using `package_file`, you can use `package_filters` to selectively include only specific packages from the package file. This will cause Qlty to *filter* the packages in the package file and only install the ones that match the filters.
+
+This is most useful when you are pointing the `package_file` directive to your project's main package file, and you want to install only the linter-related packages. This can be used to speed up the installation of linters.
+
+> **Warning:** You can achieve the same goal as package\_filters by using a separate package file
+> which only contains linter dependencies. Because a separate package file's dependencies can be
+> fully resolved using a lock file, we prefer this option.
+
+```toml
+# qlty.toml
+[[plugin]]
+name = "eslint"
+version = "8.57.0"
+package_file = "package.json"
+package_filters = ["eslint"]
+```
+
+The `package_filters` option can offer a performance speed up or workaround issues installing the app dependencies at the tradeoff of additional complexity.
+
+### Lock files
+
+Package lock files (like `package-lock.json`, `Gemfile.lock`, `yarn.lock`) can impact how Qlty installs and manages linter extensions:
+
+* When using `package_file`, Qlty respects the locked versions for reliability
+* When using `package_file` with `package_filters`, the lock files are ignored
+* For `extra_packages`, lock files are not used and specific versions are installed directly
+
+### Limitations
+
+Qlty currently does not support:
+
+* **Private linter extensions** - Extensions from private Git repositories or private package registries that require authentication
+* **Git-based dependencies** - Extensions referenced directly as Git repositories
+* **Local file dependencies outside the repository** - Extensions referenced from paths outside the repository
+
+### Troubleshooting
+
+1. **Version conflicts**
+
+   If you see errors like "Dependency conflict" or "Incompatible versions", try:
+
+   * Aligning versions between your package file and extra\_packages
+   * Using `package_filters` to selectively include compatible packages
+
+2. **Missing extensions**
+
+   If a linter reports missing plugins or rules:
+
+   * Verify the extension is correctly specified in `extra_packages` or `package_file`.
+   * Check for typos in package names.
+   * Ensure compatible versions are specified.
+
+3. **Slow performance**
+
+   If linter installation becomes slow with extensions:
+
+   * Use either `package_filters` to filter installations, or create a separate package file for linter-related packages.
+
+4. **Configuration issues**
+
+   If the linter can't find the extension configuration:
+
+   * Ensure your configuration file correctly references the extensions.
+   * Check that the extension is properly installed.

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

@@ -0,0 +1,110 @@
+# Getting Started with the Qlty CLI
+
+> **Source:** <https://docs.qlty.sh/cli/quickstart.md> (retrieved 2026-08-26).
+> Copied from the upstream page. Text is unchanged; the page's MDX wrappers (`<Steps>`,
+> `<CodeGroup>`, `<Accordion>`) and its embedded video iframes are rendered as plain Markdown
+> headings and code blocks. Fetch the live page via <https://docs.qlty.sh/llms.txt> when in doubt.
+
+## 1. Install the CLI
+
+First, install our CLI onto your local machine:
+
+```shell
+# macOS & Linux
+curl https://qlty.sh | sh
+```
+
+```shell
+# Windows
+powershell -c "iwr https://qlty.sh | iex"
+```
+
+Qlty CLI supports macOS and Linux on X64 and ARM64, with Windows support in development.
+
+### Alternative: Installing with verification
+
+We provide GitHub attestations powered by Sigstore that allow you to verify the authenticity of the Qlty CLI before installing it.
+
+**Prerequisites:** [GitHub CLI (`gh`)](https://cli.github.com/manual/installation) must be installed.
+
+**Example (macOS Apple Silicon):**
+
+```shell
+# Download the archive from https://github.com/qltysh/qlty/releases
+curl -LO https://github.com/qltysh/qlty/releases/latest/download/qlty-aarch64-apple-darwin.tar.xz
+
+# Verify the attestation
+gh attestation verify --owner qltysh qlty-aarch64-apple-darwin.tar.xz
+
+# Unpack and install
+tar -xJf qlty-aarch64-apple-darwin.tar.xz
+sudo mv qlty-aarch64-apple-darwin/qlty /usr/local/bin/
+```
+
+For other platforms, download the appropriate archive from [GitHub releases](https://github.com/qltysh/qlty/releases).
+
+Learn more: [GitHub artifact attestations documentation](https://docs.github.com/en/actions/concepts/security/artifact-attestations)
+
+## 2. Initialize your repository
+
+From your Git repository, run:
+
+```shell
+qlty init
+```
+
+This will generate a baseline configuration based on the file types within your project and store it as `.qlty/qlty.toml` in your repository.
+
+You can find more plugins with `qlty plugins list` and enable them with `qlty plugins enable [plugin]`.
+
+## 3. Identify code smells and review quality metrics
+
+Check the code quality (for [supported programming languages](https://docs.qlty.sh/languages.md)):
+
+```bash
+# Scan for code smells like duplication
+qlty smells --all
+```
+
+```bash
+# Review a summary of quality metrics
+qlty metrics --all --max-depth=2 --sort complexity --limit 10
+```
+
+## 4. Lint your project
+
+```bash
+# Run linters on changed files on your current branch
+qlty check
+```
+
+```bash
+# Run linters on all files
+qlty check --all
+```
+
+```bash
+# Run only the shellcheck linter on all files
+qlty check --all --filter=shellcheck
+```
+
+```bash
+# Run linters on the web/ folder
+qlty check web/
+```
+
+## 5. Auto-format your code
+
+```bash
+# Auto-format changed files on your current branch
+qlty fmt
+```
+
+## System requirements
+
+> **Source:** <https://docs.qlty.sh/cli/system-requirements.md> (retrieved 2026-08-26).
+
+The Qlty CLI runs on macOS and Linux on X64 and ARM64. Note that the quickstart page and the
+system-requirements page disagree about Windows: the quickstart says "Windows support is in
+development" while the system-requirements table lists Windows 11+ on X86 as supported. Verify
+Windows behavior against the live docs rather than relying on either statement.

package/dist/builtin/subagents/src/extension/index.bundle.mjs

@@ -17434,7 +17434,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/web-access/index.bundle.mjs

@@ -16013,7 +16013,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/web-access/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@bastani/web-access",
-  "version": "0.9.16-alpha.5",
+  "version": "0.9.16-alpha.7",
   "private": true,
   "description": "Atomic extension for web search, URL fetching, GitHub repo cloning, PDF/video extraction. Fork of: https://github.com/nicobailon/pi-web-access",
   "contributors": [

package/dist/builtin/workflows/CHANGELOG.md

@@ -6,6 +6,22 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
 
 ## [Unreleased]
 
+## [0.9.16-alpha.7] - 2026-08-26
+
+### Changed
+
+- Builtin `goal` and `ralph` stage prompts now carry a shared `code_quality_verification` section pointing stages at the `qlty` skill (or `skill: "qlty"` delegation) for linting, auto-formatting, complexity and duplication metrics, and code smells — weighted higher when the objective asks for verifiers or high code quality. It reaches the goal controller, goal orchestrator, goal reviewer, ralph orchestrator, and both ralph reviewers, alongside the existing end-to-end verification guidance. Repository-defined checks in AGENTS.md/CLAUDE.md, package scripts, and CI remain authoritative.
+- Builtin `goal` and `ralph` stage prompts now carry a shared `repository_intent` section instructing implementers and reviewers to infer maintainer and requesting-user conventions by mining repository behavior — git history (including `git log --show-signature`), merged PRs, issues and their comments, review comments, commit subjects and trailers, and CI/branch-protection config — for unwritten norms such as commit signing, message style and issue linking, changelog discipline, PR size and review etiquette. The dominant, recent, intentional pattern wins over accidental drift, the requesting user's own activity weighs highest, implementers match inferred conventions in delivered work, and reviewers report deviations as evidence-backed convention findings. Behavioral evidence fills contract gaps and never overrides the literal objective, acceptance criteria, or explicit AGENTS.md/CLAUDE.md guidance. It reaches the same call sites as the code-quality guidance: goal controller, goal orchestrator, goal reviewer, ralph orchestrator, and both ralph reviewers.
+- The `workflow` tool's routing guidance adds a repository-intent clause to the pre-launch architecture pass: for coding tasks, mine git history, merged PRs, issues, commits, and review comments before freezing authored workflow objectives and acceptance criteria so they capture unwritten conventions, weighing the requesting user's own activity highest; non-coding tasks mine their analogous available context sources (issue trackers, long-form docs, chat/comment threads, prior artifacts) the same way.
+
+## [0.9.16-alpha.6] - 2026-08-26
+
+### Changed
+
+- The `workflow` tool description, agent routing guidance, and workflow docs now treat a blocked run as continuable by default: resume resumable blocks, answer pending prompts, steer past the obstacle, or start a follow-up workflow past a terminal block (inline only when the remaining work is minimal), stopping for user input only when the task is so ambiguous that judgment cannot infer intent from the objective and repository evidence — git history, commits, PRs, issues, and the user's own comments. When `ask_user_question` or human input is unavailable, the agent is instructed to continue fully autonomously on the interpretation best supported by that evidence and to record the assumption.
+- `WORKFLOW BLOCKED` lifecycle notices now carry that continuation instruction in their text: resume or steer the run, or continue with a follow-up workflow (inline only if what remains is minimal), and ask the user only when intent cannot be inferred from repository evidence.
+- A budget-exceeded stop is now reported as its own blocked-notice variant (`stopped at its <dimension> budget limit`, with `budgetExceeded`/`budgetDimension` details and a `/workflow resume` hint) whose text instructs the agent to summarize progress and estimated next steps, ask the user whether to proceed — preferring the `ask_user_question` tool when available — and resume with a raised `budget` only after approval. Matching guidance was added to the routing prompts and docs.
+
 ## [0.9.16-alpha.5] - 2026-08-26
 
 ### Changed

package/dist/builtin/workflows/README.md

@@ -58,6 +58,8 @@ Workflow lifecycle notices are enabled by default. They send steer prompts into
 
 Set `enabled` to `false` to disable all lifecycle notices, or narrow `notifyOn` to a non-empty list of selected events. Completion, failure, and blocked lifecycle notices are emitted for top-level workflow runs, use steer delivery, and wake an idle model so the lifecycle update enters the model context when it happens. When a fulfilled workflow body leaves admitted tool failures, the engine promotes the first admission and persists that exact tool origin for the failed notice. Ordinary body rejections retain their original error and failed graph nodes without claiming a tool origin because transparent native promises do not expose the source promise; this prevents a caught tool rejection from being misattributed when body code later throws the same object or primitive. Nested child workflow completion/failure is reflected inside the expanded parent graph instead of producing separate top-level completion cards. Awaiting-input states are tracked for dedupe/restore, but workflows do not enqueue main-chat `/workflow connect` cards for them; prompt state remains visible through workflow status/connect surfaces, avoiding stale actionable cards if a prompt resolves while the main chat is streaming.
 
+Treat a blocked run as continuable by default; the blocked notice text itself carries this instruction. On a `WORKFLOW BLOCKED` notice or a blocked status, keep the work moving: resume a resumable block, answer the pending prompt, steer the stage past the obstacle, or start a follow-up workflow that carries the remaining tracked work past a terminal block — continue inline only if the remaining work is minimal. Stop for user input only when the task is so ambiguous that competing interpretations lead to materially different outcomes and judgment cannot infer intent from the stated objective and repository evidence; mine git history, commits, PRs, issues, and the user's own comments before asking. When `ask_user_question` or another human input channel is unavailable, continue fully autonomously on the interpretation best supported by that evidence, and record the assumption in the result or an artifact. A budget-exceeded stop (the resumable `budget_exceeded` blocked rail) is the exception, and its notice says so: the exhausted budget is a boundary someone chose, so summarize progress and the estimated next steps, ask the user whether to proceed — prefer the `ask_user_question` tool when it is available — and resume with a raised `budget` only after approval.
+
 Control notices report deliberate actions on a top-level run: `/workflow <name>` produces a `WORKFLOW STARTED` card (`▶`), `/workflow pause` a `WORKFLOW PAUSED` card (`⏸`, warning tone), `/workflow quit` a `WORKFLOW QUIT` card (`⏹`, warning tone, plus a `resumable` field), and `/workflow resume` a `WORKFLOW RESUMED` card (`▶`). All four travel the same steer delivery, capped-backoff retry, and card path as the failure notice. The paused and quit text says the stop was deliberate and user-requested and instructs the model not to resume the run or take the work over unless asked, hinting `/workflow resume <run-id>`; the resumed text does not, since the run is progressing again.
 
 Only user actions notify. The matching `workflow({ action: "run" | "pause" | "quit" | "resume" })` tool calls stay silent, because the tool result already reports them to the agent, and `/workflow interrupt` raises nothing. Engine-internal transitions stay silent too — a notice exists only when a control path named an actor — which is what keeps answering a human-in-the-loop prompt, per-stage control, and the resume-acknowledgement pass from flooding the chat.
@@ -677,7 +679,7 @@ Raw stage-chat prompt answer replay is live-memory only. `StageSnapshot.promptAn
 ```json
 {
   "name": "workflow",
-  "description": "Run named builtin, project, user, or package workflows; custom definitions may import reusable project/package workflows or builtin definitions from @bastani/workflows/builtin and nest them with ctx.workflow(...), including deeper composition within the configured maxDepth; when workflow execution fits but another shape would better achieve the task, author a custom TypeScript workflow({...}) inline with normal coding tools, reload it, and run it; after successfully creating and reloading a newly authored custom workflow, report the folder containing its generated code as 'Custom workflow created. You can inspect its code at: <workflow-folder-path>'; do this only for newly created custom workflows, never builtin or pre-existing workflows; discover with list/get/inputs/models, list session runs with status (no runId; statusFilter narrows the list), inspect status/stages/stage details, send prompt answers or steering only while the root workflow is nonterminal, pause/resume/interrupt/quit runs, and reload workflow resources. For action 'run' and 'resume', budget accepts per-field duration, token, cost, and warning overrides; fields resolve over the workflow declaration and config, and 0 disables a field. Pass budget only when the user asked for a limit; otherwise omit it entirely and inherit the declaration and config rather than inventing a cap. For primitive prompt answers, use booleans or the documented confirm labels, exact case-insensitive select labels or 1-based indexes, and text strings for input/editor; an invalid answer remains pending and returns guidance instead of choosing a default. For large stage handoffs, write context to files/artifacts, pass paths via reads, and prompt downstream agents to 'Read the file at <path>...' instead of injecting large previous text. Wrap critical parts of run inputs and steering messages in <keepContext>...</keepContext> so compaction preserves them verbatim in the stages that inherit them; tag role constraints, prohibitions, must-hold criteria, and identifiers, not background or bulk reference material. For transcripts, prefer status/stages/stage to get sessionFile/transcriptPath, quote the exact path without rewriting separators (Windows backslashes are valid), then search it with rg/grep and read small ranges; transcript is path-only by default when sessionFile/transcriptPath exists, explicit tail/limit returns bounded previews, and missing transcript paths fall back to a small preview. Use action 'models' to inspect models in the configured catalog; the result is a configured-auth snapshot showing what's present in the registry with configured authentication, not proof of credentials, entitlements, OAuth freshness, or live provider access. When authoring a workflow that should dynamically select a model, first call workflow({ action: 'models' }) to inspect the configured catalog, then select from the returned provider/id entries considering the isCurrent marker and available thinking levels.",
+  "description": "Run named builtin, project, user, or package workflows; custom definitions may import reusable project/package workflows or builtin definitions from @bastani/workflows/builtin and nest them with ctx.workflow(...), including deeper composition within the configured maxDepth; when workflow execution fits but another shape would better achieve the task, author a custom TypeScript workflow({...}) inline with normal coding tools, reload it, and run it; after successfully creating and reloading a newly authored custom workflow, report the folder containing its generated code as 'Custom workflow created. You can inspect its code at: <workflow-folder-path>'; do this only for newly created custom workflows, never builtin or pre-existing workflows; discover with list/get/inputs/models, list session runs with status (no runId; statusFilter narrows the list), inspect status/stages/stage details, send prompt answers or steering only while the root workflow is nonterminal, pause/resume/interrupt/quit runs, and reload workflow resources. Treat a blocked run as continuable by default: resume resumable blocks, answer pending prompts, steer past the obstacle, or start a follow-up workflow past a terminal block, and escalate to the user only when the blocked result is so ambiguous that human input or steering must settle it; when ask_user_question or human input is unavailable, continue fully autonomously on the interpretation best supported by the objective and repository evidence, and record the assumption. For action 'run' and 'resume', budget accepts per-field duration, token, cost, and warning overrides; fields resolve over the workflow declaration and config, and 0 disables a field. Pass budget only when the user asked for a limit; otherwise omit it entirely and inherit the declaration and config rather than inventing a cap. For primitive prompt answers, use booleans or the documented confirm labels, exact case-insensitive select labels or 1-based indexes, and text strings for input/editor; an invalid answer remains pending and returns guidance instead of choosing a default. For large stage handoffs, write context to files/artifacts, pass paths via reads, and prompt downstream agents to 'Read the file at <path>...' instead of injecting large previous text. Wrap critical parts of run inputs and steering messages in <keepContext>...</keepContext> so compaction preserves them verbatim in the stages that inherit them; tag role constraints, prohibitions, must-hold criteria, and identifiers, not background or bulk reference material. For transcripts, prefer status/stages/stage to get sessionFile/transcriptPath, quote the exact path without rewriting separators (Windows backslashes are valid), then search it with rg/grep and read small ranges; transcript is path-only by default when sessionFile/transcriptPath exists, explicit tail/limit returns bounded previews, and missing transcript paths fall back to a small preview. Use action 'models' to inspect models in the configured catalog; the result is a configured-auth snapshot showing what's present in the registry with configured authentication, not proof of credentials, entitlements, OAuth freshness, or live provider access. When authoring a workflow that should dynamically select a model, first call workflow({ action: 'models' }) to inspect the configured catalog, then select from the returned provider/id entries considering the isCurrent marker and available thinking levels.",
   "parameters": {
     "workflow": "string (optional) — workflow ID or normalized name",
     "inputs": "object (optional) — key/value map of workflow inputs",

package/dist/builtin/workflows/builtin/goal-prompts.ts

@@ -1,11 +1,13 @@
 import {
   ACCEPTANCE_MATRIX_CONTRACT,
+  CODE_QUALITY_VERIFICATION_GUIDANCE,
   CONTRACT_FIDELITY_AUDIT,
   E2E_VERIFICATION_GUIDANCE,
   EVIDENCE_CLOSURE_POLICY,
   FINDINGS_CONSOLIDATION_CONTRACT,
   LITERAL_OBJECTIVE_CONTRACT,
   REGRESSION_EVIDENCE_CONTRACT,
+  REPO_INTENT_MINING_GUIDANCE,
   REVIEW_CODE_DELTA_CONTRACT,
   REVIEWER_INDEPENDENT_VERIFICATION_CONTRACT,
   REVIEWER_INTERCOM_COORDINATION_PROTOCOL,
@@ -137,6 +139,8 @@ export function renderGoalContinuationPrompt(
     ["worktree_discipline", WORKTREE_DISCIPLINE_CONTRACT],
     ["pr_handoff_policy", INTERMEDIATE_PR_HANDOFF_GUARDRAIL],
     ["e2e_verification", E2E_VERIFICATION_GUIDANCE],
+    ["code_quality_verification", CODE_QUALITY_VERIFICATION_GUIDANCE],
+    ["repository_intent", REPO_INTENT_MINING_GUIDANCE],
     ["goal_guidelines", GOAL_CONTINUATION_REFERENCE],
     ["objective", ["Continue working toward the active goal using the ledger as authoritative state for status, receipts, reviews, blockers, reducer decisions, and lifecycle events.", `The same blocker must repeat for at least ${blockerThreshold} controller observations before blocked status is available.`, "Reviewer quorum plus the reducer decides completion from reviewers' authoritative stop_review_loop signals."].join("\n")],
   ]);
@@ -170,6 +174,8 @@ export function renderReviewerPrompt(args: {
     ["pr_handoff_policy", INTERMEDIATE_PR_HANDOFF_GUARDRAIL],
     ["auditability", RECEIPT_EXPECTATIONS],
     ["e2e_verification", E2E_VERIFICATION_GUIDANCE],
+    ["code_quality_verification", CODE_QUALITY_VERIFICATION_GUIDANCE],
+    ["repository_intent", REPO_INTENT_MINING_GUIDANCE],
     ["final_action_policy", args.createPr ? "PR/MR/review creation is an authorized post-approval final action. If implementation and validation are proven and only that action remains, set goal_oracle_satisfied=true and stop_review_loop=true with no blocking findings, and record it as the remaining final action." : "PR/MR/review creation is not enabled; do not require or attempt it during review."],
     ["project_guidance", [
       "Apply AGENTS.md/CLAUDE.md and nearby code, test, script, config, generated-artifact, and CI conventions; specific project guidance overrides general guidance.",

package/dist/builtin/workflows/builtin/ralph-reviewer-prompt.ts

@@ -1,9 +1,11 @@
 import {
   ACCEPTANCE_MATRIX_CONTRACT,
+  CODE_QUALITY_VERIFICATION_GUIDANCE,
   E2E_VERIFICATION_GUIDANCE,
   EVIDENCE_CLOSURE_POLICY,
   LITERAL_OBJECTIVE_CONTRACT,
   REGRESSION_EVIDENCE_CONTRACT,
+  REPO_INTENT_MINING_GUIDANCE,
   REVIEW_CODE_DELTA_CONTRACT,
   REVIEWER_INDEPENDENT_VERIFICATION_CONTRACT,
   REVIEWER_INTERCOM_COORDINATION_PROTOCOL,
@@ -49,6 +51,8 @@ export function renderRalphReviewerPrompt(args: {
     ["reviewer_coordination", REVIEWER_INTERCOM_COORDINATION_PROTOCOL],
     ["regression_evidence", REGRESSION_EVIDENCE_CONTRACT],
     ["e2e_verification", E2E_VERIFICATION_GUIDANCE],
+    ["code_quality_verification", CODE_QUALITY_VERIFICATION_GUIDANCE],
+    ["repository_intent", REPO_INTENT_MINING_GUIDANCE],
     ["qa_e2e_video_review", renderE2eQaVideoReviewGuidance(args.qaVideoPath)],
     ["evidence_closure", EVIDENCE_CLOSURE_POLICY],
     [

package/dist/builtin/workflows/builtin/ralph-runner.ts

@@ -10,10 +10,12 @@ import {
 import { createWorkflowArtifactDirectory } from "../src/shared/workflow-artifacts.js";
 import {
   ACCEPTANCE_MATRIX_CONTRACT,
+  CODE_QUALITY_VERIFICATION_GUIDANCE,
   CONTRACT_FIDELITY_AUDIT,
   FINDINGS_CONSOLIDATION_CONTRACT,
   LITERAL_OBJECTIVE_CONTRACT,
   REGRESSION_EVIDENCE_CONTRACT,
+  REPO_INTENT_MINING_GUIDANCE,
   SCOPE_DISCIPLINE_CONTRACT,
   WORKER_PREFLIGHT_CONTRACT,
   WORKTREE_DISCIPLINE_CONTRACT,
@@ -148,6 +150,8 @@ export async function runRalphWorkflow(
         ["project_setup", WORKER_PREFLIGHT_CONTRACT],
         ["worktree_discipline", WORKTREE_DISCIPLINE_CONTRACT],
         ["qa_e2e_video", renderQaE2eVideoGuidance(qaVideoPath)],
+        ["code_quality_verification", CODE_QUALITY_VERIFICATION_GUIDANCE],
+        ["repository_intent", REPO_INTENT_MINING_GUIDANCE],
         [
           "delegation",
           [

package/dist/builtin/workflows/builtin/shared-prompts.ts

@@ -69,6 +69,31 @@ export const E2E_VERIFICATION_GUIDANCE = [
   "If E2E remains impractical, record the commands attempted, observed failure output, smallest missing prerequisite, and narrower validation run; an unattempted assumption is never valid grounds to skip.",
 ].join("\n");
 
+/**
+ * Code-quality verification is the lint/format/metrics/smells counterpart to
+ * E2E_VERIFICATION_GUIDANCE, and is included at the same call sites so goal and
+ * ralph stages — implementation, orchestrator, and reviewer alike — receive it.
+ */
+export const CODE_QUALITY_VERIFICATION_GUIDANCE = [
+  "For code-quality verification — linting, auto-formatting, complexity and duplication metrics, and code smells — use the qlty skill or delegate with `skill: \"qlty\"`; it drives one CLI across the repository's languages instead of ad-hoc per-tool linter invocations.",
+  "Weight this higher when the objective asks for verifiers or high code quality: enable the qlty plugins that fit this codebase, then run the check/format/metrics/smells loop and act on what it reports.",
+  "Repository-defined checks in AGENTS.md/CLAUDE.md, package scripts, and CI stay authoritative; qlty supplements them rather than replacing them, and its findings count as evidence only with the command and observed output recorded.",
+].join("\n");
+
+/**
+ * Repositories carry behavioral norms written docs never state — commit
+ * signing, message style, changelog discipline, review etiquette — and they
+ * are inferable from history. Included at the same goal/ralph call sites as
+ * the E2E and code-quality guidance so implementers match inferred
+ * conventions and reviewers check delivered work against them.
+ */
+export const REPO_INTENT_MINING_GUIDANCE = [
+  "Infer maintainer and requesting-user intent from repository behavior, not only written docs: mine git history (`git log`, `git log --show-signature`), merged PRs, issues and their comments, review comments, commit subjects and trailers, and CI/branch-protection config for unwritten conventions.",
+  "Read for commit-signing habits, commit-message style and issue linking, changelog discipline, PR size and stacking norms, review etiquette, formatting and lint norms, and branch naming. Prefer the dominant, recent, intentional pattern over accidental drift; when signals conflict, the requesting user's own commits, PRs, and comments weigh highest — different users of one repository keep different preferences.",
+  "Match inferred conventions in delivered work (for example, sign commits when the surrounding history is signed rather than skipping signing because no doc required it); in review, report deviations as convention findings backed by the mined evidence.",
+  "Behavioral evidence fills gaps where the contract is silent; it never overrides the literal objective, acceptance criteria, or explicit AGENTS.md/CLAUDE.md guidance, and it does not license new contract requirements.",
+].join("\n");
+
 export function renderE2eQaVideoReviewGuidance(
   knownVideoPath?: string,
 ): string {

package/dist/builtin/workflows/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@bastani/workflows",
-  "version": "0.9.16-alpha.5",
+  "version": "0.9.16-alpha.7",
   "private": true,
   "description": "Atomic extension for multi-stage workflow authoring and execution.",
   "contributors": [