claude-dev-env 1.93.1 → 1.94.0

package/skills/bdd-protocol/SKILL.md

@@ -1,30 +0,0 @@
----
-name: bdd-protocol
-description: >-
-  On-demand BDD depth: Example Mapping, scenario quality and anti-patterns, solo
-  minimal BDD, and outside-in test layout. Use when expanding `<behavior_protocol>`,
-  writing executable specifications, or giving 'the one where' examples.
-  Triggers: bdd-protocol, Example Mapping, BDD anti-patterns, §7.6.
----
-@~/.claude/skills/bdd-protocol/references/example-mapping.md
-@~/.claude/skills/bdd-protocol/references/anti-patterns.md
-
-# BDD protocol (on-demand)
-
-The always-on sequence lives in `~/.claude/system-prompts/software-engineer.xml` under `<behavior_protocol>` (Deliberate Discovery → Illustrate → Formulate → Automate). This skill adds **depth** you load when you need algorithms, catalogs, or layout guidance.
-
-## When to use this skill
-
-- The user or task needs **Example Mapping** steps, parking-lot questions, or "the one where …" phrasing.
-- You are writing or reviewing **scenarios** and need the **§7.6** quality bar and anti-patterns.
-- You are organizing **tests by behavior** (describe / when / should) or using **soap-opera personas** for solo work.
-
-## Authority
-
-- John Ferguson Smart & Jan Molak, *BDD in Action* 2e (Manning, 2023) — §2.3.7 outside-in, §5.4 Deliberate Discovery, §6.4 Example Mapping, §7.6 scenario quality, §16.5.5 test layout.
-- Dan North, "Introducing BDD" (2006).
-- John Ferguson Smart, Minimal BDD (learnbdd.com; Wayback-cited in tracking issue).
-
-## What stays in the system prompt
-
-Do not duplicate the four-phase sequence here; keep a single source of truth in `<behavior_protocol>`.

package/skills/bdd-protocol/references/CLAUDE.md

@@ -1,10 +0,0 @@
-# references
-
-Reference documentation loaded by the `bdd-protocol` skill. Both files are `@`-imported in `SKILL.md` and load when the skill activates.
-
-## Key files
-
-| File | Role |
-|---|---|
-| `example-mapping.md` | Example Mapping algorithm (Smart & Molak §6.4). Covers core moves, the "The one where …" phrasing, probes, parking-lot questions, the solo chat algorithm, and time-boxing guidance. |
-| `anti-patterns.md` | §7.6 scenario quality catalog. Lists anti-patterns to avoid and the criteria for a well-formed BDD scenario. |

package/skills/bdd-protocol/references/anti-patterns.md

@@ -1,26 +0,0 @@
-# Scenario quality and anti-patterns (§7.6 and related)
-
-Use this as a **checklist** when writing or reviewing scenarios and developer-facing specifications. Phrasing follows *BDD in Action* 2e and the catalog summarized in [claude-dev-env#82](https://github.com/jl-cmd/claude-dev-env/issues/82).
-
-## Positive targets (what "good" looks like)
-
-- **Declarative focus (§7.6.3):** Scenarios describe **business behavior** and user goals, not low-level UI click scripts.
-- **Single-rule focus (§7.6.4):** One **business rule** per scenario; split when a scenario grows hard to read.
-- **Meaningful actors (§7.6.5):** Personas can be **lightweight** (e.g. soap-opera introductions) when full UX research is unavailable — name + role, grow detail as scenarios demand.
-- **Essential detail (§7.6.6):** Include data and columns that **change outcomes**; omit neutral or redundant columns.
-- **State clarity (§7.6.6):** Make **initial** and **final** state explicit when data illustrates behavior.
-- **Outcome description (§7.6.7):** Outcomes are **observable and measurable** — not hidden behind vague "verify" steps.
-- **Independence (§7.6.8):** Each scenario sets up **its own** data and state so it can run alone.
-
-## Anti-patterns to refuse or rewrite
-
-- **Imperative scenarios** that read like automation scripts (especially pure UI step lists).
-- **Multi-concern** scenarios that mix unrelated rules.
-- **Incidental detail** that does not serve the rule under test.
-- **Test scripts in disguise** — heavy use of **verify** / **check** without stating the business outcome.
-- **Dependent scenarios** that only pass in order.
-- **Gherkin without conversation** (BAs or testers writing scenarios in isolation) — structured specs are an **output** of discovery, not a substitute for it (Minimal BDD).
-
-## Executable specs at the code level
-
-Prefer **"should …"** phrasing in names (Dan North, 2006). Nest by **behavior context** (e.g. when / given groupings) rather than mirroring production file layout when that obscures intent (§16.5.5 attitude: tests as documentation).

package/skills/bdd-protocol/references/example-mapping.md

@@ -1,23 +0,0 @@
-# Example Mapping (Smart & Molak §6.4)
-
-Lightweight, breadth-first discovery before code. Sessions are typically **25–30 minutes**.
-
-## Core moves
-
-- State **rules**, then ask for an **example of each** rule. Examples often use **"The one where …"** phrasing (Daniel Terhorst-North; sometimes called "Friends episode notation").
-- For each example, probe with **"What if …?"**, **"Is this always the case?"**, **"Are there examples where this rule behaves differently?"** Probes can surface **new rules**; add examples for those rules.
-- **Pink cards**: questions that cannot be answered yet — **park** them; do not pretend they are specifications.
-
-## Chat algorithm (solo-friendly)
-
-1. **Restate the rule or feature** until it is clearly defined.
-2. Generate **3–5** "the one where …" examples from simple to complex.
-3. For each example, run the **three probes** above.
-4. If probes reveal a **new rule** or materially different behavior, add **2–3** examples for that rule and continue probing.
-5. Repeat until examples for each rule are probed.
-6. Compile **rules + examples + parked questions**; confirm with the user before automating tests.
-7. **Time-box** discovery; proceed to failing tests only after the map is agreed.
-
-## Parking lot discipline
-
-Unanswered questions stay **out of automated tests** until resolved or explicitly accepted as follow-up work.

package/skills/bg-agent/CLAUDE.md

@@ -1,17 +0,0 @@
-# bg-agent
-
-Delegates a task to a background agent so the main session stays free. Triggered by `/bg-agent`, `bg-agent`, or `background agent for this`.
-
-## Purpose
-
-This skill picks a suitable agent type for the task, spawns it via the `Agent` tool with `run_in_background: true`, and returns control at once. The spawned agent notifies on completion. Other skills (such as `gotcha`) invoke this skill to offload their own PR-creation steps.
-
-## Key file
-
-| File | Purpose |
-|---|---|
-| `SKILL.md` | Full instructions: how to parse the task argument, how to pick an agent type, how to write a self-contained spawn prompt, and how to report spawn to the user. |
-
-## How this skill is invoked
-
-The user types `/bg-agent <task description>` or a calling skill invokes it by name. The skill always spawns with `run_in_background: true` — it never runs the task inline in the main session.

package/skills/bg-agent/SKILL.md

@@ -1,69 +0,0 @@
----
-name: bg-agent
-description: Delegates a task to a background agent. Invoked as "bg-agent [task to do]". Claude picks a suitable agent type from the available agents list and spawns it via Agent with run_in_background: true. Triggers on "/bg-agent", "bg-agent", "background agent for this".
----
-
-# bg-agent
-
-## Overview
-
-Delegates a task to a background agent so the main session can continue without waiting. This is the programmatic invocation path for background work — other skills (e.g. gotcha) and the user can both invoke it.
-
-**Announce at start:** "Delegating to a background agent: `<one-line summary of task>`."
-
-## Instructions
-
-### Step 1 — Parse the task
-
-The user (or calling skill) provides a task description after `bg-agent`. Example:
-
-```
-bg-agent add a gotcha to the rebase skill about force-push lease format
-```
-
-Extract the full task description from the arguments.
-
-### Step 2 — Select the right agent
-
-Review the available agent types (listed in the system prompt's Agent tool description) and pick the most suitable one for the task:
-
-- **Read-only tasks** (research, search, exploring code) → Explore agent or general-purpose agent.
-- **Code authoring tasks** (writing/editing skill files, creating PRs) → general-purpose agent with `run_in_background: true`.
-- **Specialized tasks** → pick the agent whose description best matches the task. For example, use `pr-description-writer` for PR descriptions, `git-commit-crafter` for commits.
-
-If no specialized agent fits, use the general-purpose agent.
-
-### Step 3 — Spawn the background agent
-
-Use the `Agent` tool with `run_in_background: true`. Write a self-contained prompt that:
-
-- States the exact goal and expected output.
-- Lists the files or directories involved (from the caller's context).
-- Includes any constraints (do not create a PR, do not push, etc.).
-- Specifies what success looks like.
-
-Example for a gotcha-adding task:
-
-```
-Agent({
-  description: "Add gotcha to skill file",
-  prompt: "Add a gotcha entry to packages/claude-dev-env/skills/rebase/SKILL.md. The gotcha is: 'force-push --force-with-lease requires the full <branch>:<sha> format, not just the branch name.' Add it under the ## Gotchas section. If no ## Gotchas section exists, create one at the bottom of the file.",
-  subagent_type: "general-purpose",
-  run_in_background: true
-})
-```
-
-### Step 4 — Report spawn
-
-Confirm the agent was spawned and state its task in one sentence. The caller does not need to wait for completion — background agents notify on completion automatically.
-
-## Constraints
-
-- Always use `run_in_background: true`. This skill is specifically for background delegation.
-- Never run the task inline in the main session. The point is to offload it.
-- If the task requires a PR, the spawned agent handles the full flow (branch → commit → push → PR).
-- Return control to the caller immediately after spawning. Do not poll for completion.
-
-## Gotchas
-
-See the gotcha reference at the bottom of this file. When a new gotcha is discovered during use, invoke `/gotcha` to add it here.

package/skills/bugteam/scripts/bugteam_scripts_constants/bugteam_code_rules_gate_constants.py

@@ -1,55 +0,0 @@
-"""Configuration constants for the bugteam CODE_RULES gate script."""
-
-from __future__ import annotations
-
-import re
-
-BUGTEAM_CODE_RULES_GATE_PREFIX: str = "bugteam_code_rules_gate: "
-EXIT_CODE_ENFORCER_MISSING: int = 2
-HUNK_HEADER_RAW_PATTERN: str = r"^@@ -\d+(?:,\d+)? \+(\d+)(?:,(\d+))? @@"
-MAXIMUM_ISSUES_TO_REPORT: int = 3
-MAX_VIOLATIONS_PER_CHECK: int = 3
-MAXIMUM_COLUMN_TUPLE_ELEMENT_COUNT: int = 2
-PYTHON_FILE_EXTENSION: str = ".py"
-VIOLATION_LINE_RAW_PATTERN: str = r"^Line (\d+):"
-
-FUNCTION_LENGTH_VIOLATION_PATTERN: re.Pattern[str] = re.compile(
-    r"\(defined at line (\d+)\) is (\d+) lines"
-)
-FUNCTION_LENGTH_DEFINITION_LINE_GROUP_INDEX: int = 1
-FUNCTION_LENGTH_SPAN_GROUP_INDEX: int = 2
-
-ISOLATION_VIOLATION_PATTERN: re.Pattern[str] = re.compile(
-    r"\(defined at line (\d+), spanning (\d+) lines\)"
-)
-ISOLATION_DEFINITION_LINE_GROUP_INDEX: int = 1
-ISOLATION_SPAN_GROUP_INDEX: int = 2
-
-BANNED_NOUN_VIOLATION_PATTERN: re.Pattern[str] = re.compile(
-    r"\(binding span at line (\d+), spanning (\d+) lines\)"
-)
-BANNED_NOUN_DEFINITION_LINE_GROUP_INDEX: int = 1
-BANNED_NOUN_SPAN_GROUP_INDEX: int = 2
-
-INLINE_DUPLICATE_BODY_VIOLATION_PATTERN: re.Pattern[str] = re.compile(
-    r"\(inline duplicate body spans: helper at line (\d+) spanning (\d+) lines, "
-    r"enclosing at line (\d+) spanning (\d+) lines\)"
-)
-INLINE_DUPLICATE_BODY_HELPER_LINE_GROUP_INDEX: int = 1
-INLINE_DUPLICATE_BODY_HELPER_SPAN_GROUP_INDEX: int = 2
-INLINE_DUPLICATE_BODY_ENCLOSING_LINE_GROUP_INDEX: int = 3
-INLINE_DUPLICATE_BODY_ENCLOSING_SPAN_GROUP_INDEX: int = 4
-
-ALL_CODE_FILE_EXTENSIONS: frozenset[str] = frozenset(
-    {".py", ".js", ".ts", ".tsx", ".jsx"}
-)
-ALL_COLUMN_MAGIC_FALSE_VALUES: frozenset[str] = frozenset(
-    {"true", "false", "none", "null"}
-)
-ALL_GIT_DIFF_CACHED_ARGS: tuple[str, ...] = (
-    "git",
-    "diff",
-    "--cached",
-    "--name-only",
-    "-z",
-)

package/skills/bugteam/scripts/bugteam_scripts_constants/bugteam_fix_hookspath_constants.py

@@ -1,26 +0,0 @@
-"""Configuration constants for bugteam_fix_hookspath auto-remediation script."""
-
-from __future__ import annotations
-
-HOOKS_PATH_SUFFIX: str = "hooks/git-hooks"
-
-ALL_CANONICAL_HOOKS_DIRECTORY_COMPONENTS: tuple[str, str, str] = (
-    ".claude",
-    "hooks",
-    "git-hooks",
-)
-
-ALL_HOME_ENV_VAR_NAMES: tuple[str, str] = ("HOME", "USERPROFILE")
-
-PREFLIGHT_NO_PYTEST_FLAG: str = "--no-pytest"
-
-PREFLIGHT_REPO_ROOT_FLAG: str = "--repo-root"
-
-ALL_GLOBAL_HOOKS_PATH_ARGUMENTS: tuple[str, ...] = (
-    "git",
-    "config",
-    "--global",
-    "--get",
-    "core.hooksPath",
-)
-GIT_DIRECTORY_NAME: str = ".git"

package/skills/bugteam/scripts/bugteam_scripts_constants/bugteam_preflight_constants.py

@@ -1,35 +0,0 @@
-"""Configuration constants for the bugteam preflight check script."""
-
-from __future__ import annotations
-
-BUGTEAM_PREFLIGHT_SKIP_ENV_VAR_NAME: str = "BUGTEAM_PREFLIGHT_SKIP"
-EXPECTED_HOOKS_PATH_SUFFIX: str = "hooks/git-hooks"
-ENFORCEMENT_ABSENT_MESSAGE: str = (
-    "Git-side CODE_RULES enforcement is not active on this host.\n"
-    "Run: npx claude-dev-env .\n"
-    "Or set core.hooksPath at any scope, e.g.:\n"
-    "  git config --global core.hooksPath ~/.claude/hooks/git-hooks"
-)
-PYTEST_EXIT_CODE_NO_TESTS_COLLECTED: int = 5
-EXIT_CODE_HOOKS_PATH_CHECK_FAILED: int = 1
-ALL_DISCOVERY_IGNORE_DIRECTORIES: frozenset[str] = frozenset(
-    {"site-packages", ".venv", "venv", "node_modules"}
-)
-BUGTEAM_PREFLIGHT_PREFIX: str = "bugteam_preflight: "
-
-
-ALL_GIT_CONFIG_HOOKS_PATH_ARGUMENTS: tuple[str, ...] = (
-    "config",
-    "--get",
-    "core.hooksPath",
-)
-ALL_PRE_COMMIT_ARGUMENTS: tuple[str, ...] = (
-    "pre-commit",
-    "run",
-    "--all-files",
-)
-GIT_DIRECTORY_NAME: str = ".git"
-PYTEST_INI_FILENAME: str = "pytest.ini"
-PYPROJECT_FILENAME: str = "pyproject.toml"
-PYPROJECT_PYTEST_SECTION_PREFIX: str = "[tool.pytest"
-PRE_COMMIT_CONFIG_FILENAME: str = ".pre-commit-config.yaml"

package/skills/caveman/CLAUDE.md

@@ -1,15 +0,0 @@
-# caveman
-
-Trims noise from conversational text in the current turn. Triggered by `/caveman`, `caveman this`, `trim this`, `make it terse`, or `caveman voice`.
-
-## Purpose
-
-The inline counterpart to the `caveman` agent. When the user wants preamble, hedging, filler transitions, restatements, empty future-proofing, dead examples, or pleasantries stripped from the last assistant message or from text passed as an argument, this skill performs the trim directly in the main session — no `Agent` spawn. The entire reply is the trimmed text; no report, no commentary about what was cut.
-
-Use the `caveman` agent (`subagent_type: caveman`) when the input is a file path, a multi-section artifact that needs a structured report, or a delegated workflow.
-
-## Key file
-
-| File | Purpose |
-|---|---|
-| `SKILL.md` | Instructions: resolve the source (argument or prior message), noise categories to cut, what to preserve verbatim, and the escape hatch for load-bearing spans. |

package/skills/caveman/SKILL.md

@@ -1,38 +0,0 @@
----
-name: caveman
-description: "Inline counterpart to the caveman agent — trim noise from `$ARGUMENTS` (or the previous assistant message) and reply with the trimmed text only, no report, no Agent spawn. Triggers: /caveman, caveman this, trim this, make it terse, caveman voice."
-argument-hint: "[text to trim, or omit and the model uses the previous assistant message]"
----
-
-# Caveman
-
-Inline counterpart to the `caveman` agent at `packages/claude-dev-env/agents/caveman.md`. Use this skill when the trim target is conversational text in the current turn rather than a separate file or multi-section artifact. The model performs the trim itself in the next reply — no `Agent` invocation, no structured report, just the trimmed text.
-
-## Instructions
-
-1. **Resolve the source.** If `$ARGUMENTS` is non-empty, that text is the trim source. Otherwise the source is the previous assistant message in the current conversation.
-
-2. **Trim the same noise categories the agent trims:**
-
-   | Noise type | Example |
-   |---|---|
-   | Preamble / recap | "As discussed above, this skill will..." |
-   | Hedging | "This might, in some cases, potentially..." |
-   | Filler transitions | "Now, moving on to..." / "It's worth noting that..." |
-   | Restatement | the same point made twice in different words |
-   | Empty future-proofing | parameters, sections, or fields with no current consumer |
-   | Dead examples | examples that duplicate another example without adding coverage |
-   | Pleasantries | "Hope this helps." / "Feel free to..." |
-   | Vague qualifiers | "various", "several", "a number of" — replace with the actual count or cut |
-
-3. **Preserve verbatim:** code, commands, paths, URLs, errors, JSON, schemas, frontmatter, counts, version strings, identifiers, safety/destructive-op language, and anything the user explicitly flagged as keep-as-is.
-
-4. **Output only the trimmed text.** No `trimmed / removed / preserved-verbatim / flagged` report. No commentary about what was cut. No preamble like "Here is the trimmed version:". The trimmed text is the entire reply.
-
-## Escape hatch
-
-If trimming would drop a safety warning, collapse a deliberate distinction, or you are unsure whether a span is load-bearing, leave that span in place verbatim. Do not flag, narrate, or ask about the preserved span — instruction 4 still applies, so the trimmed text (with the preserved span included) remains the entire reply. Terse is for noise, not for substance.
-
-## When NOT to use
-
-Use the `caveman` agent (via `Task` / `Agent` tool with `subagent_type: caveman`) when the input is a file path, a multi-section artifact requiring the structured `trimmed / removed / preserved-verbatim / flagged` report, or any delegated workflow. This skill is for inline conversational text only.

package/skills/code/CLAUDE.md

@@ -1,17 +0,0 @@
-# code
-
-Activates strict code standards for the entire implementation session. Triggered by `/code`, `code standards`, `strict code`, `enforce standards`, or `implement with standards`.
-
-## Purpose
-
-Prepends a set of binary completion criteria to every implementation task: no `Any`, no `cast()`, no `# type: ignore`, treated-as-immutable TypedDicts with explicit `_encode_*`/`_decode_*` functions, 100% statement and branch coverage, zero mocks, zero stubs, zero fallbacks, and proper module structure. Every criterion is pass-or-fail; partial credit does not exist.
-
-## Key file
-
-| File | Purpose |
-|---|---|
-| `SKILL.md` | Sixteen numbered criteria (typing strictness, error handling, test coverage, DI hooks, DRY, TypedDict protocol, Redis boundary, TOML boundary, JSON recursive types, ASGI boundaries, dynamic import pattern, documentation, build infrastructure, lint gates, Protocol signature match, auth/credentials), plus gotchas for Windows PowerShell invocation and per-module `_test_hooks.py` placement. |
-
-## Invocation note
-
-Invoke at the start of an implementation task. The standards persist for the full session. The skill refuses research or planning tasks and redirects them to `/anthropic-plan`.

package/skills/code/SKILL.md

@@ -1,178 +0,0 @@
----
-name: code
-description: >-
-  Prepends strict code standards to every implementation session. Enforces
-  strong typing, no Any, no casts, no type: ignore, treated-as-immutable
-  TypedDicts, 100% test coverage, DRY, no mocks, no stubs, no fallbacks, and
-  proper module structure. Triggers: /code, code standards, strict code, enforce
-  standards, implement with standards.
----
-
-# Code Standards Enforcer
-
-Prepends these standards to every implementation session. Every criterion is binary — pass or fail. No partial credit.
-
-## When this applies
-
-Invoke at the start of any implementation task. The standards persist for the entire session.
-
-**Refusal cases — first match wins:**
-
-- **Not an implementation task.** "This skill applies to code implementation. Ask me to implement something specific."
-- **Exploratory research or planning.** "Code standards are for implementation. Use /anthropic-plan for planning, then invoke /code when implementing."
-
-## Gotchas
-
-- **`make check` must run from pwsh, not bash.** The Bash tool routes through Git Bash on Windows, where `make` may not be on PATH. Always use `pwsh -NoProfile -Command 'make check 2>&1 | Select-Object -Last 100; exit $LASTEXITCODE'` so the pipeline does not mask a non-zero exit code from make.
-- **`New-Item`, `Get-ChildItem`, `Remove-Item` are pwsh cmdlets.** Don't use them inside Bash tool calls. Use the PowerShell tool or prefix with `pwsh -NoProfile -Command`.
-- **`TypedDict` encode/decode must be manual.** Pydantic and similar frameworks bypass the strict validation pattern. Write `_encode_*` and `_decode_*` functions by hand.
-- **`_test_hooks.py` is per-module, not per-package.** Every module that has dependencies needs its own hooks file. A single `conftest.py` with mocks does not satisfy this rule.
-- **Protocol must match the real API exactly.** If the real class has `async def fetch(self, key: str) -> bytes`, the Protocol must declare the same signature. A mismatch is caught at type-check time by mypy strict mode.
-
----
-
-## Completion criteria
-
-Every criterion below must be met before the change is complete.
-
-### 1. Typing strictness
-
-Zero violations across the project's source, test, and script directories (adapt `src/`, `tests/`, `scripts/` to the project's actual layout):
-
-- No `Any`, `cast()`, `# type: ignore`, `# noqa`.
-- No `.pyi` files, stubs, or shims.
-- Mypy strict mode exits 0 with no errors.
-- All TypedDicts are treated as immutable after construction and carry explicit `_encode_*` / `_decode_*` functions.
-- All decode functions call `require_*` validation on every field.
-- Internal encoder is typed — no untyped dict intermediaries.
-
-### 2. Error handling
-
-- No `try`/`except` in core logic that recovers, softens, or best-efforts a failure.
-- Failures propagate. Callers decide whether to handle.
-- APIs signal failure points through naming, docstrings, and test expectations — not by catching.
-
-### 3. Test coverage
-
-- Test runner exits 0 with full statement and branch coverage (e.g. `pytest -n auto --cov --cov-branch --cov-report=term-missing` with paths adapted to the project layout) (requires pytest-xdist and pytest-cov).
-- Statement coverage: 100%. Branch coverage: 100%.
-- Zero mocks. Every test exercises actual code paths through fakes injected via DI hooks (see criterion 4).
-- Zero weak assertions. Every assert checks a specific, falsifiable property.
-- Zero fake tests (tests that pass without validating behavior).
-
-### 4. Dependency injection
-
-- Every module that has external dependencies provides a `_test_hooks.py` with internal DI hooks (underscore = private). The hook file lives alongside the module it services.
-- A shared testing utility module exports public test helpers for consumers (adapt the path to the project's conventions, e.g. `Libs/testing.py`).
-- Production code sets hooks to real implementations at startup. Tests set them to fakes.
-- No `if`/`else` branching on test vs. production — call the hook directly.
-
-### 5. Codebase standards
-
-- DRY: zero duplicate function bodies longer than 3 lines. Zero duplicate constant definitions.
-- No placeholder code, no dead code, no commented-out blocks.
-- No fallback paths, no back-compat shims, no legacy code.
-- No `TypeAlias`, no `TYPE_CHECKING` import guards.
-
-### 6. TypedDict protocol
-
-- Every TypedDict has a paired `_encode_*` and `_decode_*` function.
-- Every decode calls `require_*` (non-null, type-check, range-check) on every field before returning.
-- Decode functions are the single point where untyped data becomes typed.
-
-### 7. Redis boundary
-
-- Use module-level helper functions or a Protocol.
-- Never reference `Redis[Any]` in type annotations.
-
-### 8. TOML boundary
-
-- No `TYPE_CHECKING` guard for TOML types.
-- Parse untyped dicts from TOML, then convert into TypedDict (no dataclasses) before use.
-
-### 9. JSON recursive types
-
-- Bypass framework validation (e.g., Pydantic).
-- Parse with `json.loads()`, validate immediately with internal `_decode_*` / `_load_json_*` functions before any other use.
-
-### 10. ASGI / framework boundaries
-
-- Define a Protocol for the minimal interface (e.g., `async def body() -> bytes`).
-- Never use `dict[str, Any]` in ASGI scopes.
-- Parse at the edge, validate immediately, propagate as strict types.
-
-### 11. Dynamic import pattern
-
-When using `importlib.import_module()` + `getattr()`, the intermediate variables are untyped. Bind the final instance through a typed wrapper so the result carries a concrete type rather than `Any`:
-
-```python
-import importlib
-from collections.abc import Callable
-
-mod = importlib.import_module("module_name")
-cls = getattr(mod, "ClassName")
-
-def _construct(klass: Callable[..., TheProtocol]) -> TheProtocol:
-    return klass()
-
-instance = _construct(cls)
-```
-
-### 12. Documentation
-
-Google-style docstrings on every public function, method, and class:
-
-```python
-def load_config(config_path: str) -> AppConfig:
-    """Load and validate the application configuration from disk.
-
-    Args:
-        config_path: Absolute path to the TOML configuration file.
-
-    Returns:
-        A fully validated AppConfig TypedDict.
-
-    Raises:
-        FileNotFoundError: If config_path does not exist.
-        ValidationError: If the parsed config fails require_* checks.
-    """
-```
-
-For a public function whose behavior needs a picture, lead the narrative with a diagram: one summary line, then a `::` literal block or a doctest showing a concrete input and its marked outcome, then a couple of short prose lines, then the `Args:` / `Returns:` sections. See `../../rules/plain-illustrative-docstrings.md` for the shape and a worked example.
-
-### 13. Build infrastructure
-
-The project under development must contain:
-
-- `Makefile` with targets: `check`, `lint`, `test`, `coverage`.
-- `pyproject.toml` with `[tool.mypy]` strict mode, `[tool.pytest.ini_options]` with `addopts = -n auto` (requires pytest-xdist).
-- A lint guard script that covers the project's source, test, and script directories.
-
-### 14. Lint gates
-
-- `make lint` runs mypy (strict), ruff, and the project's guard script.
-- All linters cover the project's source, test, and script directories.
-- `make lint` exits 0 before `make test` is valid.
-
-### 15. Protocol signature match
-
-- Every Protocol's method signatures match the real API they abstract.
-- If the real API changes, the Protocol fails type-checking — no silent drift.
-
-### 16. Auth, credentials, multi-tenancy
-
-- Auth and credential handling is explicit, typed, and testable.
-- Multi-tenant DB access uses typed connection factories, not string-formatted queries.
-- MCP-shared resources follow the same strictness as application code.
-
----
-
-## Verification
-
-Each criterion returns either **at least one finding** OR **exactly one proof-of-absence** with at least 3 adversarial probes specific to that criterion. A criterion returning neither is a protocol gap.
-
-## File index
-
-| File | Purpose |
-|------|---------|
-| `SKILL.md` | Hub — binary criteria, gotchas, when-to-apply, verification protocol |

package/skills/deep-research/CLAUDE.md

@@ -1,17 +0,0 @@
-# deep-research
-
-Runs an iterative multi-source research pipeline that produces a comprehensive Obsidian report with citations. Triggered by `/deep-research [topic]`.
-
-## Purpose
-
-The skill operates in two phases. Phase 1 (main thread) turns the raw topic into a precise research brief through a short AskUserQuestion session covering audience, scope, recency, and depth. Phase 2 delegates to the `deep-research` agent with the confirmed brief and an iteration budget (8 / 15 / 25 based on depth preference). The agent handles iteration, state tracking, and Obsidian output.
-
-## Key file
-
-| File | Purpose |
-|---|---|
-| `SKILL.md` | Phase 1 steps (classify, ask, construct `<research_brief>` XML, set iteration budget) and Phase 2 spawn instructions, including `mode: bypassPermissions` for unrestricted web access. |
-
-## Post-run cleanup
-
-After the agent returns, the skill summarizes the Obsidian path, source counts, and any gaps, then deletes the `.deep-research-state.md` temp file.

package/skills/deep-research/SKILL.md

@@ -1,80 +0,0 @@
----
-name: deep-research
-description: "Deep Research mode — iterative multi-source research producing comprehensive Obsidian reports with citations. Official-docs-first methodology. Triggers: '/deep-research [topic]'"
-argument-hint: "TOPIC or RESEARCH QUESTION"
----
-
-# Deep Research
-
-You orchestrate a two-phase deep research pipeline. Phase 1 happens here (main thread). Phase 2 is delegated to the `deep-research` agent.
-
-## Phase 1: Build the Research Prompt (Interactive Q&A)
-
-The user's raw topic is: `$ARGUMENTS`
-
-Your job is to turn this raw topic into a precise, well-scoped research brief using prompt-generator methodology. Follow these steps:
-
-### Step 1: Classify and assess
-
-Silently determine:
-- **Complexity**: Is this a narrow factual question or a broad landscape survey?
-- **Ambiguity**: Can you research this as-is, or does it need scoping?
-- **Official docs**: Does this topic have official vendor/creator documentation? If yes, that is the primary source and must be consulted first.
-
-### Step 2: Ask clarifying questions
-
-Use AskUserQuestion to ask 1-3 questions. Choose from these dimensions based on what's genuinely unclear — skip any that are obvious from context:
-
-- **Audience**: "Who is this research for?" (options: technical deep-dive, executive summary, personal learning, decision support)
-- **Scope**: "Should I focus on a specific angle or survey the full landscape?" (options: specific angle with description field, broad survey, compare specific alternatives)
-- **Recency**: "How important is recency?" (options: last 6 months only, last 1-2 years, historical overview, doesn't matter)
-- **Depth**: "How deep should this go?" (options: quick overview 5-10 sources, standard 15-20 sources, exhaustive 25+ sources)
-
-Skip clarification entirely only if the topic is already narrow, unambiguous, and the audience is obvious.
-
-### Step 3: Construct the research brief
-
-From the user's answers, write a structured research brief:
-
-```
-<research_brief>
-  <topic>The original topic, cleaned up</topic>
-  <official_docs>Known official documentation sources, or "none identified" if the topic lacks vendor docs</official_docs>
-  <scope>Exactly what to research — boundaries, inclusions, exclusions</scope>
-  <audience>Who this is for and what they need</audience>
-  <depth>Target source count and iteration budget</depth>
-  <output>What the final deliverable looks like</output>
-  <key_questions>
-    1. Specific question the research must answer
-    2. Another specific question
-    3. ...
-  </key_questions>
-</research_brief>
-```
-
-Show the brief to the user. Ask: "Does this capture what you need, or should I adjust the scope?"
-
-### Step 4: Set iteration budget
-
-Map the user's depth preference to iteration count:
-- Quick overview: 8 iterations
-- Standard (default): 15 iterations
-- Exhaustive: 25 iterations
-
-## Phase 2: Launch the Research Agent
-
-Once the brief is confirmed, spawn the `deep-research` agent using the Agent tool with:
-
-- **subagent_type**: `deep-research`
-- **prompt**: The full `<research_brief>` XML block from Step 3, plus the iteration budget
-- **mode**: `bypassPermissions` (research agent needs unrestricted tool access for web searches)
-- **description**: "Deep research: [short topic summary]"
-
-The agent handles everything from here: iteration, state tracking, and Obsidian output.
-
-When the agent returns, summarize:
-1. Where the report was saved (Obsidian path)
-2. How many sources were consulted (official vs secondary)
-3. Any gaps or limitations noted
-
-Then clean up temporary files: `.deep-research-state.md`