stackops 26.9.1__tar.gz → 26.9.3__tar.gz

stackops-26.9.3/PKG-INFO

@@ -0,0 +1,163 @@
+Metadata-Version: 2.4
+Name: stackops
+Version: 26.9.3
+Summary: Developer Stack Manager
+Author-email: Alex Al-Saffar <programmer@usa.com>
+License: Apache 2.0
+Project-URL: Homepage, https://github.com/thisismygitrepo/stackops
+Project-URL: Bug Tracker, https://github.com/thisismygitrepo/stackops/issues
+Classifier: Programming Language :: Python :: 3
+Classifier: License :: OSI Approved :: Apache Software License
+Classifier: Operating System :: OS Independent
+Requires-Python: >=3.13
+Description-Content-Type: text/markdown
+Requires-Dist: fire>=0.7.1
+Requires-Dist: gitpython>=3.1.46
+Requires-Dist: psutil>=7.2.2
+Requires-Dist: pyyaml>=6.0.3
+Requires-Dist: questionary>=2.1.1
+Requires-Dist: randomname>=0.2.1
+Requires-Dist: requests>=2.32.5
+Requires-Dist: rich>=14.3.3
+Requires-Dist: tenacity>=9.1.4
+Requires-Dist: textual>=8.2.7
+Requires-Dist: typer>=0.24.1
+Provides-Extra: windows
+Provides-Extra: plot
+Requires-Dist: duckdb>=1.5.4; extra == "plot"
+Requires-Dist: duckdb-engine>=0.17.0; extra == "plot"
+Requires-Dist: ipykernel>=7.3.0; extra == "plot"
+Requires-Dist: ipython>=9.15.0; extra == "plot"
+Requires-Dist: jupyterlab>=4.6.0; extra == "plot"
+Requires-Dist: kaleido>=1.3.0; extra == "plot"
+Requires-Dist: matplotlib>=3.11.0; extra == "plot"
+Requires-Dist: nbformat>=5.10.4; extra == "plot"
+Requires-Dist: numpy>=2.5.0; extra == "plot"
+Requires-Dist: plotly>=6.8.0; extra == "plot"
+Requires-Dist: polars>=1.42.0; extra == "plot"
+Requires-Dist: python-magic>=0.4.27; extra == "plot"
+Requires-Dist: sqlalchemy>=2.0.51; extra == "plot"
+
+<div align="center">
+
+<h1>🗜 StackOps</h1>
+
+<strong>Developer workstation and workflow CLI.</strong>
+
+<p>
+  <a href="https://thisismygitrepo.github.io/stackops/"><img alt="Docs" src="https://img.shields.io/badge/docs-online-2f6f6f"></a>
+  <a href="https://pypi.org/project/stackops/"><img alt="PyPI package" src="https://img.shields.io/pypi/v/stackops?color=2f6f6f"></a>
+  <img alt="Python 3.13+" src="https://img.shields.io/badge/python-3.13%2B-3776AB">
+  <img alt="Installed with uv" src="https://img.shields.io/badge/install-uv-f05d23">
+</p>
+
+</div>
+
+StackOps coordinates packages, configuration, repositories, data, terminal layouts, and coding-agent resources around the tools you already use. Install selected packages, synchronize declared configuration, or launch an authored tmux workspace through focused commands. Available installers and integrations vary by operating system and external tool.
+
+See the [online docs](https://thisismygitrepo.github.io/stackops/) for full usage and reference material.
+
+## Install
+
+Choose your platform and expand only the commands you need.
+
+<details>
+<summary><strong>Linux</strong></summary>
+
+```bash
+curl -LsSf https://astral.sh/uv/install.sh | sh
+uv tool install --upgrade --python 3.14 stackops
+stackops --help
+```
+
+</details>
+
+<details>
+<summary><strong>macOS</strong></summary>
+
+```bash
+curl -LsSf https://astral.sh/uv/install.sh | sh
+uv tool install --upgrade --python 3.14 stackops
+stackops --help
+```
+
+</details>
+
+<details>
+<summary><strong>Windows PowerShell</strong></summary>
+
+```powershell
+powershell -ExecutionPolicy Bypass -c "irm https://astral.sh/uv/install.ps1 | iex"
+uv tool install --upgrade --python 3.14 stackops
+stackops --help
+```
+
+</details>
+
+
+## Codex Skill
+
+Install the StackOps skill for Codex with:
+
+```bash
+bunx skills add thisismygitrepo/stackops --skill stackops --global --agent codex --yes
+```
+
+
+## Start with a workflow
+
+Inspect the commands for the workflow you need:
+
+```bash
+devops install --help
+devops config sync --help
+terminal run --help
+```
+
+The [quickstart](https://thisismygitrepo.github.io/stackops/quickstart/) shows a selected-package example and configuration options.
+
+## Optional workstation setup
+
+This broader setup installs system and terminal package groups, copies bundled assets, applies public configuration mappings, and configures the default shell. Use it when you want those workstation conventions; existing customized systems can use individual commands instead. Package-group behavior depends on the platform and may invoke privileged package managers.
+
+```bash
+devops install --group sysabc
+devops config copy-assets all
+devops config sync down \
+  --sensitivity public \
+  --method copy \
+  --on-conflict throw-error \
+  --which all
+devops config terminal config-shell --which default
+devops install --group termabc
+```
+
+The scripted sync above copies configuration and stops on conflicts. The public copy/symlink choices in `devops config interactive` use `overwrite-default-path` and can replace existing targets; they are a different setup choice.
+
+
+## CLI
+
+StackOps exposes standalone commands and an umbrella wrapper:
+
+| Command | Purpose |
+| --- | --- |
+| `devops` | Package installation, repo automation, config/data sync, self-management, networking, script execution, vault |
+| `cloud` | Cloud sync, copy, mount, SSH transfer, and OneDrive helpers |
+| `terminal` | Terminal session and layout management |
+| `agents` | AI agent scaffolding, MCP catalog installs, prompt runs, parallel workflows |
+| `utils` | General-purpose utility commands |
+| `fire` | File, function, notebook, and app runner |
+| `preview` | File preview and `uv run` backend launcher |
+| `seek` | Interactive search across files, text matches, and symbols |
+| `stackops` | Umbrella wrapper that routes into all of the above |
+
+Run `<command> --help` for details, or `stackops --help` to see the command families.
+
+
+## Author
+
+Alex Al-Saffar. [email](mailto:programmer@usa.com)
+
+## Contributor
+
+Ruby Chan. [email](mailto:ruby.chan@sa.gov.au)

stackops-26.9.3/pyproject.toml

@@ -0,0 +1,179 @@
+[build-system]
+requires = ["setuptools>=80", "wheel"]
+build-backend = "setuptools.build_meta"
+# requires = ["hatchling"]
+# build-backend = "hatchling.build"
+
+[project]
+name = "stackops"
+version = "26.9.3"
+description = "Developer Stack Manager"
+readme = "README.md"
+license = {text = "Apache 2.0"}
+authors = [
+    {name = "Alex Al-Saffar", email = "programmer@usa.com"},
+]
+classifiers = [
+    "Programming Language :: Python :: 3",
+    "License :: OSI Approved :: Apache Software License",
+    "Operating System :: OS Independent",
+]
+requires-python = ">=3.13"
+dependencies = [
+    "fire>=0.7.1",
+    "gitpython>=3.1.46",
+    "psutil>=7.2.2",
+    "pyyaml>=6.0.3",
+    "questionary>=2.1.1",
+    "randomname>=0.2.1",
+    "requests>=2.32.5",
+    "rich>=14.3.3",
+    "tenacity>=9.1.4",
+    "textual>=8.2.7",
+    "typer>=0.24.1",
+]
+
+[project.optional-dependencies]
+windows = []
+plot = [
+    "duckdb>=1.5.4",
+    "duckdb-engine>=0.17.0",
+    "ipykernel>=7.3.0",
+    "ipython>=9.15.0",
+    "jupyterlab>=4.6.0",
+    "kaleido>=1.3.0",
+    "matplotlib>=3.11.0",
+    "nbformat>=5.10.4",
+    "numpy>=2.5.0",
+    "plotly>=6.8.0",
+    "polars>=1.42.0",
+    "python-magic>=0.4.27",
+    "sqlalchemy>=2.0.51",
+]
+
+
+[project.urls]
+"Homepage" = "https://github.com/thisismygitrepo/stackops"
+"Bug Tracker" = "https://github.com/thisismygitrepo/stackops/issues"
+
+[project.scripts]
+devops = "stackops.scripts.python.devops:main"
+cloud = "stackops.scripts.python.cloud:main"
+fire = "stackops.scripts.python.fire_jobs:main"
+agents = "stackops.scripts.python.agents:main"
+terminal = "stackops.scripts.python.terminal:main"
+preview = "stackops.scripts.python.preview:main"
+utils = "stackops.scripts.python.utils:main"
+stackops = "stackops.scripts.python.stackops_entry:main"
+seek = "stackops.scripts.python.seek:main"
+
+[tool.setuptools]
+package-dir = {"" = "src"}
+include-package-data = true
+license-files = []
+
+[tool.setuptools.packages.find]
+where = ["src"]
+
+[tool.setuptools.package-data]
+stackops = ["**/*.toml", "**/*.md", "**/*.sh", "**/*.ps1", "**/*.txt", "utils/schemas/**/*.json", "utils/schemas/**/*.yaml"]
+
+[dependency-groups]
+dev = [
+    "aider>=0.2.6",
+    "build>=1.5.0",
+    "cleanpy>=0.5.1",
+    "cowsay>=6.1",
+    "duckdb>=1.5.4",
+    "gdown>=6.1.0",
+    "griffe>=2.1.0",
+    "ipdb>=0.13.13",
+    "ipykernel>=7.3.0",
+    "ipython>=9.15.0",
+    "jsonschema>=4.26.0",
+    "kaleido>=1.3.0",
+    "marimo>=0.23.11",
+    "matplotlib>=3.11.0",
+    "mkdocstrings>=1.0.4",
+    "mkdocstrings-python>=2.0.5",
+    "mypy>=2.1.0",
+    "numpy>=2.5.0",
+    "pandas>=3.0.3",
+    "paramiko>=5.0.0",
+    "playwright>=1.62.0",
+    "plotly>=6.8.0",
+    "polars>=1.42.0",
+    "pre-commit>=4.6.0",
+    "pudb>=2025.1.5",
+    "py7zr>=1.1.3",
+    "pydantic>=2.13.4",
+    "pydeps>=3.0.6",
+    "pyinstaller>=6.21.0",
+    "pylint>=4.0.6",
+    "pylsp-mypy>=0.7.3",
+    "pymupdf>=1.27.2.3",
+    "pypdf>=6.14.2",
+    "pyrefly>=1.1.1",
+    "pyright>=1.1.411",
+    "pytest>=9.1.1",
+    "python-lsp-server[mypy]>=1.14.0",
+    "qrcode>=8.2",
+    "ruff>=0.15.20",
+    "ruff-lsp>=0.0.62",
+    "sqlalchemy>=2.0.51",
+    "trogon>=0.6.0",
+    "ty>=0.0.55",
+    "types-mysqlclient>=2.2.0.20260508",
+    "types-paramiko>=5.0.0.20260617",
+    "types-pytz>=2026.2.0.20260518",
+    "types-pyyaml>=6.0.12.20260518",
+    "types-requests>=2.33.0.20260518",
+    "types-sqlalchemy>=1.4.53.38",
+    "types-toml>=0.10.8.20260518",
+    "types-urllib3>=1.26.25.14",
+    "vt-py>=0.22.0",
+    "yapf>=0.43.0",
+    "zensical>=0.0.46",
+]
+other = [
+    "duckdb-engine>=0.17.0",
+    "pycrucible>=0.4.6",
+    "vt-py>=0.22.0",
+]
+plot = [
+    "duckdb>=1.5.4",
+    "ipykernel>=7.3.0",
+    "ipython>=9.15.0",
+    "jupyterlab>=4.6.0",
+    "kaleido>=1.3.0",
+    "matplotlib>=3.11.0",
+    "nbformat>=5.10.4",
+    "numpy>=2.5.0",
+    "plotly>=6.8.0",
+    "polars>=1.42.0",
+    "python-magic>=0.4.27",
+    "sqlalchemy>=2.0.51",
+]
+
+
+# [tool.uv]
+# default-groups = []
+
+[tool.pycrucible]
+entry = "src/stackops/scripts/python/devops.py"
+[tool.pycrucible.options]
+debug = false
+extract_to_temp = false
+delete_after_run = false
+offline_mode = false
+
+[tool.pycrucible.patterns]
+include = [
+    "**/*.py",
+    "**/*.ps1",
+    "**/*.sh",
+    "**/*.md",
+]
+exclude = [
+    "**/__pycache__/**",
+]

stackops-26.9.3/src/stackops/agents/prompts/prompts.yaml

@@ -0,0 +1,305 @@
+# yaml-language-server: $schema=./prompts.schema.json
+# prompts.yaml used by `agents run-prompt`
+# Top-level keys show up in interactive selection.
+# Nested keys can be selected via --context-name with dot-path syntax (example: team.backend).
+# Each entry can be a plain string or an object with prompt metadata.
+# entryExample: {prompt: replace me, description: short label}
+
+renameTmuxTabs:
+  description: Rename every tab in the current tmux session from its live activity.
+  prompt: |
+    Rename every window/tab in the current tmux session appropriately.
+
+    - Identify the current tmux session and limit all inspection and renaming to that session.
+    - Inspect every window before naming it. Use its pane working directories, foreground commands, titles, and recent visible output to infer its actual activity.
+    - Use concise, descriptive lower camel case names such as `javaScript`, with at most two words and no spaces, hyphens, underscores, or generic numbering.
+    - Give windows with the same working directory distinct activity-based names.
+    - Rename every window, including the current window. If a new window appears while working, inspect and rename it too.
+    - Do not interrupt running processes, send input to panes, change layouts, or switch the user's active window.
+    - Verify the final window list and report the resulting index-to-name mapping.
+
+findBugsOrImprovementRoom:
+  description: a generic prompt to improve a repo.
+  prompt: |
+    Please find either bugs or room to improve this repo.
+    * The thing is, the repo is huge, so you need to split work to N agents. The use must specify a concrete value for N, if not, stop and ask them for the value. Once you find out the value, you need to undestand the repo at a fairly high level and figure out a way to distribute the workload on those sub agents.
+    * Create the sub agents with the latest Herdr CLI: create a workspace with one clearly named tab per agent. Use the same agent harness as you unless the user specifies another, e.g. codex, pi, omp, opencode etc.
+    * you wait until they all finish, then collect the results from them and pass on the final reports back to the user so they decide on what to do next.
+    * Notice that so far, we didn't fix anything or improve anything, it was just anaylsis,
+    * The user then might ask you to approve the bug fix suggestions or improvements suggestions, in which case you proceed to launch sub agents, one per improvment/bug fix (exactly one), they go in a separate Herdr workspace and are launched in separate tabs, and they must be instucted with additional caveat """please fix this only if you think it is genuinely a bug/improvment space, if you disagree please leave as is, also, please take into consideration complexity and speed, if solution adds too much complexity, we skip, if solution slow down things significantly, we skip too. We are not super fussy about correctness, we are more about practicality and performance and maintainability. Please write down a comment where needed that this is a design choice and we are aware of its implications or this is not strictly correct but we choose to do so for reason x and y.""". This gives us extra reassurance that first work was not hallucination because the prior agent was handling too much and missed details. The bug finding operation might have been done already and you are asked to start working on fixes, in which case the above applies.
+    * When finished, please don't close the Herdr workspaces or tabs, as user might want followup questions with those agents.
+  
+
+ensureLightweightCommands:
+  description: we want typer cli files to remain light weight and prevent uncncessary upfront loading.
+  prompt: |
+    Use the `$agent-ops` skill with the `parallel-agents` command.
+
+    $caveman weynan full.
+    Please look into every cli typer py file that has (import typer).
+    In essense, we want to ensure that those typer cli remain lightweight so user doesn't experience delay.
+    We achieve this by,
+    * Avoid unncessary import to happen upfront, e.g. if only one command needs it, then the import can occur within that command (not global import)
+    * Only include global imports needed to type hint the variables and light weigh modules, and ensuer they come from modules that are lightweight themselves, otherwise some redesign need to occur with those imported files.
+    * We want to have both python API and CLI experirence of functions, so, the actual py function must exist somewhere, and the cli function is only calling that function internally and passing on (a cli interface to an existing py function).
+    Convey those messages to the new agent instances, but its up to you to decide which one is worth working on and which one is already reasonably optimized, plese don't be overzelous.
+
+    Because the number of files is too big, please spin up another veresion of you (whether you are codex, claude, opencode, copilot etc)
+    but not as a sub agent. Use Herdr workspaces, tabs, and panes as directed by the `$agent-ops` skill and give each agent a clear name matching its task.
+
+    # Instructions for agents:
+    * Pass sufficient instructions to them to be able to get the job done
+    * let them know that there exist other agents working on similar tasks for other files, so they are no surprised by occasional unexpected change of some shared code upstream.
+    * Additionally, tell them to use caveman weynan full skill.
+
+    # Agent Specs
+    * Each instance handle 5 files only, you distribute the load.
+    * Please start the agents interactively, i.e. start the cli, then paste/type the prompt intended for that agent and press enter to let it go at it.
+    * You want to make sure that they are actually working, by seeing some progress, just in case your launch failed, only then, you job is finished, you don't need to monitor them until they finish.
+
+    Do not use internal subagents. Use `$agent-ops parallel-agents`, submit each prompt, verify each agent accepted it, then report the Herdr targets and visible status.
+
+createParallelAgents:
+  description: Use agent-ops parallel-agents for an appended requirement.
+  prompt: |
+    Use the `$agent-ops` skill with the `parallel-agents` command for the appended user requirement.
+
+    You are preparing a StackOps external parallel-agent run for the user requirement in the appended prompt.
+
+    Your job:
+    1. Read the appended user requirement as the source of truth.
+    2. Design the full external-agent split: agent choice, task boundaries, context source, chunking, paths, and agent names.
+    3. Create task-specific standalone instructions needed for robust delegation.
+    4. Start Herdr-managed interactive agents through `$agent-ops parallel-agents`.
+    5. Submit the intended prompt to each agent and verify each agent accepted it.
+
+    This is an orchestration prompt. Do not pass this prompt itself to spawned agents. Write or select a prompt that tells spawned agents how to do the user's actual work.
+
+    Creation and launch contract:
+
+    - The purpose is to launch external interactive agents through `$agent-ops parallel-agents`.
+    - The purpose is not to create generated `agents parallel create` layout files.
+    - Do not use internal subagents.
+    - Do not use `agents parallel create`, `agents parallel run-parallel`, `--run`, `--Run`, or `-R`.
+    - After launch, report the Herdr targets, task split, and visible status.
+
+    Design rules:
+
+    - Use `codex` unless the user asks for another agent or the task clearly needs another installed agent.
+    - Use high reasoning for complex coding/research delegation when the selected agent supports it, unless the user asks otherwise.
+    - Prefer one task per agent when isolation matters; group small independent tasks only when that is more efficient.
+    - Use short filesystem-safe names for agent labels.
+    - Avoid destructive cleanup. If old agent sessions or work dirs exist, choose fresh labels unless the user explicitly requested replacement.
+    - Make every agent prompt standalone and include the exact files, commands, or context needed.
+
+    Simple three-agent example:
+
+    Suppose the appended user requirement is: "In a toy calculator project, split work across three agents: implement arithmetic, add tests, and update docs."
+
+    Delegate:
+
+    Agent 1 context:
+    Inspect `calculator.py`. Implement or fix `add(a, b)` and `subtract(a, b)`.
+    Keep the public function names stable.
+
+    Agent 2 context:
+    Inspect `calculator.py`. Implement or fix `multiply(a, b)` and `divide(a, b)`.
+    For division by zero, raise `ZeroDivisionError` with a clear message.
+
+    Agent 3 context:
+    Inspect the README and tests. Add usage examples for all four calculator operations and add focused tests for the expected behavior.
+
+    Final response after launching:
+
+    - State whether all prompts were accepted.
+    - Give the Herdr target names/ids.
+    - Summarize each agent's assignment.
+    - Mention any agent that failed to start or accept its prompt.
+
+stackopsMaintinanceUpdateInstaller:
+  description: Use agent-ops parallel-agents to update installer filename patterns.
+  prompt: |
+    Use the `$agent-ops` skill with the `parallel-agents` command.
+
+    Goal: coordinate external agents to update GitHub release filename patterns in `src/stackops/utils/schemas/installer/installer_data.json`.
+    Split installer entries across agents, with 10 entries per agent. Tell agents to edit only entries assigned to them.
+
+    Tell each agent:
+    - If `repoURL` is not a GitHub repository, skip that entry.
+    - Verify current release asset names before changing a `fileNamePattern`.
+    - Never add a literal `v` before `{version}` just because release tags or assets contain one.
+    - Do not touch values that are custom Python installer scripts such as `<name>.py`.
+    - Do not touch custom package install commands.
+    - Only edit `fileNamePattern` fields.
+    - Prefer musl Linux binaries over gnu binaries when both are available.
+
+    Do not use `agents parallel create`, `agents parallel run-parallel`, internal subagents, or generated layout workflows.
+    Start Herdr-managed interactive agents, submit their prompts, verify each accepted the prompt, then report the Herdr targets and visible status.
+
+stackopsMaintinanceUpdateTest:
+  description: Use agent-ops parallel-agents to write mirrored runtime tests.
+  prompt: |
+    Use the `$agent-ops` skill with the `parallel-agents` command.
+
+    Goal: coordinate external agents to add focused runtime tests for StackOps Python files.
+    Build the work list from git-visible `.py` files, excluding `tests` and ignored/generated directories. Give each agent about 10 files.
+
+    Tell each agent:
+    - Use `$caveman wenyan`.
+    - Create one test file per assigned Python file.
+    - Put tests under `tests/mirror/<same repo-relative path>`.
+    - Test runtime behavior that static type checking cannot catch.
+    - Do not write tests whose only value is checking type correctness.
+    - Keep edits scoped to assigned tests unless a tiny source fix is clearly necessary.
+
+    Do not use `agents parallel create`, `agents parallel run-parallel`, internal subagents, or generated layout workflows.
+    Start Herdr-managed interactive agents, submit their prompts, verify each accepted the prompt, then report the Herdr targets and visible status.
+
+stackopsMaintinanceUpdateDocs:
+  description: Use agent-ops parallel-agents to update CLI and API docs.
+  prompt: |
+    Use the `$agent-ops` skill with the `parallel-agents` command.
+
+    Goal: coordinate external agents to update documentation under `docs/cli` and `docs/api`.
+    Build the work list from git-visible Markdown files in those two directories. Give agents clear file chunks.
+
+    Tell each agent:
+    - Only edit files under `docs/cli` and `docs/api`.
+    - Do not edit `docs/index.md`, `docs/quickstart.md`, `docs/guide/**`, Home, User Guide, or other documentation tabs.
+    - Treat assigned context entries as docs files to update directly.
+    - Inspect current Python sources and CLI/API behavior as needed.
+    - Prefer current implemented behavior. Remove stale wording instead of documenting legacy behavior.
+
+    Do not use `agents parallel create`, `agents parallel run-parallel`, internal subagents, or generated layout workflows.
+    Start Herdr-managed interactive agents, submit their prompts, verify each accepted the prompt, then report the Herdr targets and visible status.
+
+stackopsMaintinanceUpdateLogic:
+  description: Use agent-ops parallel-agents to review command logic.
+  prompt: |
+    Use the `$agent-ops` skill with the `parallel-agents` command.
+
+    Goal: coordinate external agents to review StackOps CLI command logic and fix real issues.
+    Build the work list from CLI command source locations, with each task naming the repo-relative source file and command path.
+
+    Tell each agent:
+    - Use the assigned file and command path to find the command.
+    - Fix actual logic bugs, inconsistent behavior, or meaningful failure modes.
+    - If the command works as is, leave it alone.
+    - Keep CLI files fast by moving unnecessary heavy imports into the functions that need them.
+    - Do not over-split into tiny shim modules.
+    - Use modern Python style, including `| None` instead of `Optional`.
+    - Expect other external agents may edit nearby command code.
+
+    Do not use `agents parallel create`, `agents parallel run-parallel`, internal subagents, or generated layout workflows.
+    Start Herdr-managed interactive agents, submit their prompts, verify each accepted the prompt, then report the Herdr targets and visible status.
+
+stackopsUpdateAgentsConfig:
+  description: Use agent-ops parallel-agents to update agents add-config outputs, one external agent per supported target.
+  prompt: |
+    Use the `$agent-ops` skill with the `parallel-agents` command.
+
+    Please update StackOps `agents add-config` support against the latest official docs for every supported agent.
+
+    This is an orchestration prompt. Start by inspecting the live command, then discover the relevant implementation, templates, privacy helpers, and tests from the repository:
+    - `uv run stackops agents add-config --help`
+    - Use fast repository search to find the command registration, implementation, generated templates, privacy config helpers, and tests.
+    - Do not assume file locations from this prompt; verify the current source layout before editing.
+
+    Determine the supported `agents add-config --agent` values from the live command and current source. Do not rely on this prompt for a hardcoded agent list.
+
+    After determining the supported values, launch Herdr-managed interactive agents through `$agent-ops parallel-agents`:
+    - Start exactly one external agent per supported `agents add-config --agent` value.
+    - Give each spawned agent one supported target only, and name the Herdr target after that assigned target.
+    - Do not group multiple supported targets into one spawned agent.
+    - Do not split one supported target across multiple spawned agents unless the user explicitly asks for that later.
+    - Do not use internal subagents, `agents parallel create`, `agents parallel run-parallel`, generated layout workflows, `--run`, `--Run`, or `-R`.
+    - Submit every spawned-agent prompt and verify each agent accepted it before reporting launch status.
+
+    Tell each spawned agent to handle only its assigned supported target:
+    - Look up the latest official documentation for repository config, user config, instruction files, ignore files, privacy/telemetry controls, and any required config file names or locations.
+    - Prefer primary sources: official docs, official repos, and current CLI `--help` output.
+    - Compare the docs against what StackOps currently writes through `agents add-config`.
+    - Update generated config/instruction templates only where current StackOps output is stale, missing, or wrong.
+    - Configure maximum privacy wherever the agent supports it: disable telemetry, analytics, training/data sharing, prompt logging, crash/upload reporting, and remote diagnostics.
+    - Give the local agent maximum execution autonomy wherever the agent supports it: full tool/file/shell powers, no permission prompts, and no approval prompts.
+    - Keep generated defaults minimal, portable, and safe to commit unless the file is intentionally private.
+    - Preserve existing tests where behavior is still correct, and add focused tests for changed generated outputs or content.
+    - Do not make cosmetic rewrites unrelated to agent config correctness.
+    - Expect other external agents may edit adjacent agent config code or shared tests; keep changes scoped to the assigned target and reconcile conflicts conservatively.
+
+    Final response:
+    - List each agent checked.
+    - Report the Herdr target for each spawned agent and whether its prompt was accepted.
+    - Summarize which config outputs changed.
+    - Cite or name the official documentation used for any behavior change.
+
+benchmarkAgentContextOverhead:
+  description: Measure startup context overhead from globally installed agent skills, plugins, tools, and connectors.
+  prompt: |
+    Measure how much of this agent's usable context window is occupied at startup by globally installed extensions.
+
+    Treat any appended user text as optional overrides for the target agent, model, repetition count, experiment scope, or artifact location. Otherwise, benchmark the current agent and active model.
+
+    Treat skills, plugins, extensions, tools, connectors, MCP servers, hooks, and similar provider-specific mechanisms as "agent extensions." Keep the experiment provider-neutral: discover this agent's actual executable, version, configuration-home mechanism, model, context-window size, extension controls, diagnostics, and usage-reporting fields. Do not assume Codex names, flags, paths, tokenizers, or event formats.
+
+    Safety and scope:
+
+    - Do not uninstall extensions or modify the real global configuration.
+    - Read and obey repository instructions and privacy restrictions before inspecting configuration.
+    - Do not expose credentials, secrets, or private configuration contents in commands, artifacts, or the report.
+    - Prefer read-only diagnostics and an ephemeral, no-side-effect benchmark prompt.
+    - Use a temporary directory for artifacts and any alternate agent home. Report its path.
+    - Do not copy credentials into the alternate home. If a clean-home live run would require credential duplication, use the alternate home only for no-inference inspection and say so.
+    - A single minimal live A/B pair using the existing authenticated profile is acceptable when the agent supports disabling extensions without changing the real configuration. Ask before making additional paid repetitions.
+    - Ensure benchmark responses make no tool calls or repository changes. Discard a run if it invokes a tool or produces another model request.
+
+    Establish these experimental arms when the agent supports them:
+
+    1. Full: the normal global setup.
+    2. Extensions off: the same home and configuration, with extension/plugin/app loading disabled through documented temporary flags or overrides. This is the preferred causal comparison.
+    3. Minimal home: a newly created empty temporary agent home. This is a broad upper bound because it can also remove configuration, rules, permissions, instructions, authentication, and other state.
+    4. Config off, when independently supported: the same home with user configuration ignored and extensions disabled. Use this only when it helps separate extension overhead from other global configuration.
+
+    Keep every arm identical apart from the intended treatment:
+
+    - Use the same executable and version, model, reasoning level, working directory, sandbox, approval policy, feature flags, and prompt.
+    - Use an empty or neutral working directory without project-local agent configuration.
+    - Use an ephemeral session when supported.
+    - Use this benchmark prompt: `Reply exactly OK. Do not call tools.`
+    - Run arms close together. Input tokenization should be deterministic for identical requests; repeat in alternating order only if results vary.
+
+    Measure in this order:
+
+    1. Prefer a built-in diagnostic that renders the exact model-visible prompt or request without inference.
+    2. Inspect which extensions are installed, which are exposed to the current session, and which are merely cached or present on disk.
+    3. Tokenize rendered input with the model's documented tokenizer when available. Otherwise report bytes, characters, and a clearly labelled token estimate.
+    4. If available, run one minimal live Full versus Extensions-off pair and use the agent's per-request input-token usage as the authoritative complete-request measurement, including request-level tool schemas and framing.
+    5. Verify that both live arms returned exactly `OK` and emitted no tool calls.
+
+    Account for context correctly:
+
+    - Use per-request input tokens, not cumulative session usage.
+    - Cached input tokens are normally a subset of input tokens. Do not add them again, and do not treat caching as reclaimed context capacity.
+    - Distinguish compact startup metadata from full extension instructions loaded lazily after selection.
+    - Do not sum every installed skill or plugin file and call that startup overhead unless the rendered request proves those bodies are injected.
+    - Do not count deferred tool definitions as startup context unless they are actually materialized in the measured request.
+    - If the prompt renderer omits request-level tool schemas, state that limitation and use live reported usage for the complete-request delta when possible.
+
+    Calculate and report:
+
+    - Extension overhead = Full input tokens minus Extensions-off input tokens.
+    - Broad global-home overhead = Full rendered-input tokens minus Minimal-home rendered-input tokens.
+    - Extension overhead as a percentage of the agent's usable context window and nominal context window, when both are known.
+    - Extension overhead as a percentage of the Full initial request.
+    - A breakdown of skill/extension catalog metadata, generic wrappers, permissions/rules, environment metadata, and tool-schema or framing residuals when the evidence supports it.
+
+    Present a concise results table containing each arm, input tokens, cached input tokens, delta, and context-window percentage. Then explain:
+
+    - The best causal estimate and why it is preferable to the empty-home comparison.
+    - Which installed definitions contribute zero startup tokens because they are hidden, cached, disabled, or lazy-loaded.
+    - Any difference between interfaces or runtimes, such as desktop, CLI, IDE, local, remote, or cloud sessions.
+    - Whether the measured overhead is material enough to justify a separate minimal profile.
+    - Exact reproduction commands with secrets removed.
+    - Artifact locations and whether temporary files were retained or removed.
+
+    Support behavioral claims with current primary documentation for the agent being tested. Clearly distinguish authoritative live usage, exact local tokenization, and heuristic estimates.