claude-dev-env 1.93.1 → 1.95.0

package/skills/usage-pause/SKILL.md

@@ -1,10 +1,6 @@
 ---
 name: usage-pause
-description: >-
-  Waits out the account's 5-hour usage window in ScheduleWakeup stages that keep
-  every agent context warm. Accepts a manual override like '/usage-pause
-  10:20pm' or '/usage-pause 74m'. Triggers: '/usage-pause', 'pause until the
-  usage window resets', 'wait out the usage limit', 'usage limit pause'.
+description: 5-hour usage window, agent context warm, weekly limit is near its cap. Triggers: '/usage-pause', 'pause until the usage window resets', 'wait out the usage limit', 'usage limit pause', 'usage limit', 'pause usage', 'usage pause'.
 argument-hint: "[reset time like 10:20pm | duration like 74m]"
 ---
 
@@ -37,27 +33,27 @@ On exit 0 the script prints one JSON object:
 | `session_utilization` | Percent of the 5-hour window spent (null on override) |
 | `weekly_utilization` | Percent of the weekly window spent (null on override) |
 | `weekly_resets_at` | When the weekly window resets (null on override) |
-| `weekly_near_cap` | True when the weekly meter is at or past 90 percent |
+| `weekly_near_cap` | True when the weekly meter is at or past the warn threshold |
 
 On exit 2 the script prints `{"error": ...}`. Ask the user for a manual reset time via AskUserQuestion (offer clock-time and duration examples), then rerun with `--override`.
 
 ### Probe mechanism
 
-The resolver gets a bearer token from one of two sources and sends `GET https://api.anthropic.com/api/oauth/usage` with `Authorization: Bearer <token>` and `anthropic-beta: oauth-2025-04-20`. This is the same endpoint the interactive `/usage` panel reads. The response carries a `five_hour` bucket and a `seven_day` bucket, each with `utilization` (percent spent) and `resets_at`.
+`scripts/resolve_usage_window.py` is the source of truth for live probe behavior. Endpoint URL, header names/values, credential path and token keys, response bucket keys, stage sizing, and the weekly warn threshold all live in `scripts/usage_pause_constants/resolve_usage_window_constants.py` — read those modules for the current values; do not restate them here.
 
-Token sources, in order:
+In short: the resolver picks a bearer token, probes the OAuth usage endpoint the interactive `/usage` panel uses, and returns the session and weekly buckets with utilization and reset times. Token sources, in order:
 
-- The Claude Code CLI's OAuth access token in `~/.claude/.credentials.json` (`claudeAiOauth.accessToken`, honored only while its `expiresAt` sits in the future).
-- The session ingress token in the file named by the `CLAUDE_SESSION_INGRESS_TOKEN_FILE` environment variable, read when the credential file token is unavailable. Claude Code cloud sessions set this variable and omit the credential file.
+1. The Claude Code CLI's stored OAuth access token (honored only while unexpired).
+2. The session ingress bearer token file named by `CLAUDE_SESSION_INGRESS_TOKEN_FILE` (cloud sessions).
 
-Fallbacks, in order: no usable token from either source, a failed request, or a response with no readable `five_hour` reset time all end in exit 2 — the manual-override ask above. The manual path works with no probe at all, so the skill functions even when both token sources are stale.
+Fallbacks, in order: both token sources unavailable (expired/unreadable credential and no ingress file), a failed request, or a response with no readable session-window reset time all end in exit 2 — the manual-override ask above. The manual path works with no probe at all, so the skill functions even when both token sources are unavailable.
 
 Why this probe and not the others:
 
 - The interactive `/usage` panel shows the same data but has no scriptable output.
 - `claude -p --output-format json` spends usage to answer and its metadata reports per-call token counts, not the account window clock.
 - `anthropic-ratelimit-*` response headers cover API-key Messages traffic, not the subscription session window, and reading them also costs a request.
-- Refreshing the OAuth token from a script is out of scope: token rotation would desync the refresh token the CLI has on disk and log the CLI out. The resolver only ever reads its token sources.
+- Refreshing the OAuth token from a script is out of scope: token rotation would desync the refresh token the CLI has on disk and log the CLI out. The resolver only ever reads tokens (credential file or session ingress file).
 
 ## Weekly limit guard
 
@@ -70,7 +66,7 @@ Before the first sleep:
 1. List active recurring loops (CronList). Record each one's schedule and prompt, then cancel it (CronDelete). Carry the recorded list inside the wakeup prompts so the state survives every stage.
 2. Schedule the first stage with ScheduleWakeup, using the first duration in `stages_seconds` and the stage prompt template below.
 
-The stage plan keeps every stage at or under 58 minutes (3480 seconds, inside the 3600-second clamp) and ends with a roughly 2-minute tail stage so the final firing lands just past the reset. A leftover too short to stand alone folds into the tail.
+The stage plan (`stages_seconds` from the resolver) keeps every stage under the maximum stage length and ends with a short tail so the final firing lands just past the reset. Stage sizing constants live in `scripts/usage_pause_constants/resolve_usage_window_constants.py`; a leftover too short to stand alone folds into the tail.
 
 Every wakeup does exactly three things — ping, record, schedule — and dispatches no new work. The cache rationale: an unpinged idle agent left past the cache window resumes cold and re-reads its whole transcript, so pings run tighter than the cache lifetime and keep each agent's next real invocation cheap.
 
@@ -110,7 +106,7 @@ Fill each `<slot>` at schedule time: `<remaining_stage_durations>` is the tail o
 | `SKILL.md` | This flow: resolve, weekly guard, stage chain, templates |
 | `scripts/resolve_usage_window.py` | The window resolver and stage planner CLI |
 | `scripts/test_resolve_usage_window.py` | Behavioral tests for parsing, staging, token reading, extraction, CLI |
-| `scripts/usage_pause_constants/resolve_usage_window_constants.py` | Endpoint, credential keys, the session ingress token env var, stage sizing, thresholds, result keys |
+| `scripts/usage_pause_constants/resolve_usage_window_constants.py` | Endpoint, credential keys, stage sizing, thresholds, result keys |
 
 ## Gotchas
 

package/system-prompts/software-engineer.xml

@@ -140,7 +140,8 @@
   Apply an outside-in BDD reasoning protocol before writing any code. Outside-in BDD is the
   required development protocol; apply it in place of any Red-Green-Refactor heuristic. The
   full anti-pattern catalog, Example Mapping algorithm, and solo-developer guidance live in
-  the bdd-protocol skill; this section carries the core four-phase sequence.
+  the long-form BDD references (`~/.claude/docs/BDD_DISCOVERY_PROTOCOL.md`,
+  `~/.claude/docs/BDD_SCENARIO_QUALITY.md`); this section carries the core four-phase sequence.
 
   Deliberate Discovery. Before writing any specification or code, reason explicitly about
   what the code should do, what constraints apply, and what concrete examples demonstrate the
@@ -159,8 +160,9 @@
   it pass. Assess each green state for structural improvement; refactor when a specific
   naming, cohesion, or duplication problem is identified.
 
-  Reference the bdd-protocol skill for Smart and Molak §7.6 patterns, the Example Mapping
-  algorithm, and guidance on applying this protocol in a solo-developer context.
+  Reference `~/.claude/docs/BDD_SCENARIO_QUALITY.md` and `~/.claude/docs/BDD_DISCOVERY_PROTOCOL.md`
+  for Smart and Molak §7.6 patterns, the Example Mapping algorithm, and guidance on applying this
+  protocol in a solo-developer context.
 </behavior_protocol>
 
 <scope_discipline>
@@ -231,11 +233,10 @@
 </agent_workflow>
 
 <code_review_response>
-  When responding to GitHub PR review feedback, follow this mandatory protocol using the
-  pr-review-responder skill.
+  When responding to GitHub PR review feedback, follow this mandatory protocol.
 
   Fetch all reviewer comments before making any fixes. Obtain the full comment set from the
-  PR using `gh pr view --comments` or the pr-review-responder skill.
+  PR using `gh pr view --comments`.
 
   Create a TodoWrite checklist with one item per comment.
 

package/hooks/validators/test_verify_paths.py

@@ -1,32 +0,0 @@
-"""Tests for validator path verification script."""
-
-import pytest
-
-from .verify_paths import extract_validator_paths
-
-
-def test_extract_validator_paths_finds_validator_references() -> None:
-    """Test that validator references are extracted from markdown content."""
-    content = """
-    **Validator:** `validators/import_checks.py`
-    Some text here.
-    **Validator:** `validators/style_checks.py`
-    """
-
-    result = extract_validator_paths(content)
-
-    assert "import_checks.py" in result
-    assert "style_checks.py" in result
-
-
-def test_extract_validator_paths_deduplicates() -> None:
-    """Test that duplicate validator references are deduplicated."""
-    content = """
-    **Validator:** `validators/import_checks.py`
-    **Validator:** `validators/import_checks.py`
-    **Validator:** `validators/import_checks.py`
-    """
-
-    result = extract_validator_paths(content)
-
-    assert result.count("import_checks.py") == 1

package/hooks/validators/verify_paths.py

@@ -1,57 +0,0 @@
-"""Verify all validator paths referenced in SKILL.md exist."""
-
-import re
-import sys
-from pathlib import Path
-
-
-SKILL_MD_PATH = Path(__file__).parent.parent.parent / "skills" / "pr-review-responder" / "SKILL.md"
-VALIDATORS_DIR = Path(__file__).parent
-
-
-def extract_validator_paths(content: str) -> list[str]:
-    """Extract validator file paths from SKILL.md content."""
-    pattern = r"validators[/\\](\w+\.py)"
-    matches = re.findall(pattern, content)
-    return list(set(matches))
-
-
-def verify_validators() -> int:
-    """Verify all referenced validators exist.
-
-    Returns:
-        Exit code: 0 if all exist, 1 if any missing
-    """
-    if not SKILL_MD_PATH.exists():
-        print(f"ERROR: SKILL.md not found at {SKILL_MD_PATH}")
-        return 1
-
-    content = SKILL_MD_PATH.read_text(encoding="utf-8")
-    referenced_validators = extract_validator_paths(content)
-
-    print(f"Found {len(referenced_validators)} validator references in SKILL.md")
-    print()
-
-    missing = []
-    for validator_file in sorted(referenced_validators):
-        validator_path = VALIDATORS_DIR / validator_file
-        if validator_path.exists():
-            print(f"  [OK] {validator_file}")
-        else:
-            print(f"  [MISSING] {validator_file}")
-            missing.append(validator_file)
-
-    print()
-
-    if missing:
-        print(f"ERROR: {len(missing)} validator(s) missing:")
-        for validator_file in missing:
-            print(f"  - {validator_file}")
-        return 1
-
-    print("All referenced validators exist.")
-    return 0
-
-
-if __name__ == "__main__":
-    sys.exit(verify_validators())

package/skills/bdd-protocol/CLAUDE.md

@@ -1,26 +0,0 @@
-# bdd-protocol
-
-**Trigger:** `/bdd-protocol`, "Example Mapping", "BDD anti-patterns", "§7.6", writing executable specifications, BDD scenario quality, "the one where" discovery examples.
-
-On-demand BDD depth layered on top of the always-on `<behavior_protocol>` in the system prompt. The skill adds the Example Mapping algorithm (Smart & Molak §6.4), the scenario quality catalog (§7.6), outside-in test layout, and solo BDD patterns.
-
-## Subdirectories
-
-| Directory | Role |
-|---|---|
-| `references/` | Loaded reference docs: Example Mapping algorithm and the anti-patterns catalog. |
-
-## Key files
-
-| File | Role |
-|---|---|
-| `SKILL.md` | Entry point. `@`-imports both reference files so they load with the skill. Lists authorities and scope boundaries. |
-| `references/example-mapping.md` | Example Mapping algorithm: core moves ("The one where …"), the chat algorithm for solo use, time-boxing guidance. Source: Smart & Molak §6.4. |
-| `references/anti-patterns.md` | §7.6 scenario quality catalog: anti-patterns to avoid and the criteria for a good scenario. |
-
-## What the skill adds
-
-The base `<behavior_protocol>` (Deliberate Discovery → Illustrate → Formulate → Automate) is always active. This skill adds depth only when:
-- The task needs Example Mapping steps or parking-lot question management.
-- Scenarios need the §7.6 quality bar applied.
-- Tests need outside-in layout using describe / when / should.

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`.