claude-dev-env 1.38.1 → 1.39.0

package/skills/dream/SKILL.md

@@ -1,118 +0,0 @@
----
-name: dream
-description: Consolidate, prune, and reorganize auto memory files. Simulates Auto Dream -- fixes format drift, deduplicates facts, enforces index structure. Use when memory feels stale or cluttered. Triggers on '/dream', 'consolidate memory', 'clean up memory', 'dream'.
-disable-model-invocation: true
----
-
-# Dream: Memory Consolidation
-
-## Overview
-
-Consolidate auto memory by enforcing the format contract, pruning stale content, deduplicating facts, and rebuilding MEMORY.md as a clean index.
-
-**Announce at start:** "Running memory consolidation (dream)."
-
-**Context:** Standalone maintenance utility. Run periodically or when memory feels cluttered. Simulates the Auto Dream feature that is in gradual rollout.
-
-## The Format Contract
-
-Source: Claude Code client system prompt + [official docs](https://code.claude.com/docs/en/memory).
-
-**MEMORY.md is an index, not a memory.** It should contain only one-line pointers to topic files:
-- Format: `- [Title](file.md) -- one-line hook`
-- Target: under ~150 characters per entry
-- Hard limit: 200 lines / 25KB (only this much loads at session start)
-- No content, tables, or multi-line facts directly in MEMORY.md
-
-**Topic files require frontmatter:**
-```yaml
----
-name: {{topic name}}
-description: {{one-line description}}
-type: {{user | feedback | project | reference}}
----
-```
-
-**Organization:** Semantic by topic, not chronological by session.
-
-## The Process
-
-### Phase 1: Audit
-
-Read MEMORY.md and every file in the memory directory. For each file, check:
-
-1. **Frontmatter present?** Must have name, description, type fields.
-2. **Type correct?** Must be one of: user, feedback, project, reference.
-3. **Named by topic?** Files named `session-YYYY-MM-DD-*` should be renamed to their actual topic.
-
-For MEMORY.md, check:
-1. **Index entries only?** Flag any line that is NOT a `- [Title](file.md)` link or a `##` section header.
-2. **Content leaking into index?** Flag inline facts, tables, multi-line bullet points.
-3. **Under 200 lines?** Flag if approaching the limit.
-
-### Phase 2: Propose Changes
-
-Present a structured report to the user with these sections:
-
-**Format violations** -- files missing frontmatter, content in MEMORY.md
-**Stale content** -- items older than 14 days with forward-looking TODOs or "Next/Pending" sections that may be completed
-**Duplicates** -- facts that appear in both topic files and MEMORY.md inline, or across multiple topic files
-**Rename candidates** -- session-dated files that should be topic-named
-**Proposed actions** -- numbered list of specific changes (extract, merge, prune, rename, add frontmatter)
-
-Do NOT execute any changes yet. Wait for user approval.
-
-### Phase 3: Execute
-
-After user approves (all or selected items):
-
-1. **Extract** inline MEMORY.md content into new or existing topic files with proper frontmatter.
-2. **Add frontmatter** to files that lack it.
-3. **Rename** session-dated files to topic names.
-4. **Deduplicate** by removing redundant copies (keep the most complete version).
-5. **Prune** stale forward-looking content (TODOs, "Next" sections) from old files.
-6. **Rebuild MEMORY.md** as a clean index -- one-line entries only, grouped by `##` section headers.
-
-### Phase 4: Verify
-
-After execution, read the rebuilt MEMORY.md and confirm:
-- Every entry is a one-line link
-- Every referenced file exists and has valid frontmatter
-- No orphaned files (files in directory but not in index)
-- Total line count under 200
-
-Report the results: files changed, lines saved, violations fixed.
-
-## Output Format
-
-Phase 2 report structure:
-
-```
-## Dream Report
-
-### Format Violations (X found)
-- [file] -- [issue]
-
-### Stale Content (X flagged)
-- [file] -- [what's stale] -- [age]
-
-### Duplicates (X found)
-- [fact] -- appears in [file1] and [file2]
-
-### Proposed Actions
-1. [action] -- [file] -- [reason]
-2. ...
-
-Approve all, select by number, or cancel?
-```
-
-## After Completion
-
-Report summary: files modified, created, renamed, deleted. Line count before/after.
-
-## Best Practices
-
-- Run after long sessions or when starting fresh on a project
-- Check stale flags manually -- dream cannot verify if TODOs were completed without reading the actual codebase
-- The 14-day staleness threshold is a heuristic, not a hard rule
-- When in doubt about whether to prune, flag it for the user rather than proposing deletion

package/skills/ingest/SKILL.md

@@ -1,40 +0,0 @@
----
-name: ingest
-description: Digest the codebase using gitingest into LLM-friendly text files, one per top-level folder. Use when user wants to create a text digest/summary of their repo for AI consumption.
-user_invocable: true
----
-
-# Ingest Codebase with GitIngest
-
-## Steps
-
-1. **Ensure gitingest is installed**: `pip install gitingest`
-
-2. **Clone repo locally** (avoids network drive slowness and enables long paths):
-   ```bash
-   REMOTE=$(git remote get-url origin)
-   TEMP_DIR=$(mktemp -d)/gitingest_repo
-   git clone --depth 1 -c core.longpaths=true "$REMOTE" "$TEMP_DIR"
-   ```
-
-3. **Identify top-level folders** in the clone to ingest (skip `.git`, `.Codex`, `.planning`, etc.)
-
-4. **Run gitingest Python API on each folder separately** (running separately avoids spaces-in-names breaking CLI glob patterns):
-   ```python
-   from gitingest import ingest
-
-   summary, tree, content = ingest(
-       folder_path,
-       include_patterns=["*.py", "*.md", "*.json", "*.yaml", "*.yml", "*.cfg", "*.toml", "*.txt"],
-       exclude_patterns=["**/venv/**", "**/logs/**", "**/__pycache__/**", "**/Archive/**",
-                         "**/*.png", "**/*.jpg", "**/*.mp4", "**/*.gif", "**/*.pyc",
-                         "**/*.rdp", "**/node_modules/**", "**/.git/**"],
-       max_file_size=102400,
-   )
-   ```
-
-5. **Save each digest** as `digest_<folder_name>.txt` in the corresponding source folder on the original working directory (not the temp clone)
-
-6. **Clean up** the temp clone directory
-
-7. **Report** file count, token count, and output paths for each folder

package/skills/npm-creator/SKILL.md

@@ -1,187 +0,0 @@
----
-name: npm-creator
-description: Scaffold an npm-installable package for any Claude Code plugin repo. Detects plugin directories (rules/, hooks/, agents/, etc.), asks about package metadata, then generates package.json and a cross-platform Node.js installer (bin/install.mjs). Use when turning a plugin repo into an npx-installable package.
-user_invocable: true
----
-
-# npm-creator
-
-## Overview
-
-Scaffold a cross-platform npm package for Claude Code plugin repos so users can install via `npx <package-name>`.
-
-**Core principle:** The installer copies plugin files to ~/.claude/ using only Node.js built-ins. Zero external dependencies, works on Linux, macOS, and Windows.
-
-**Announce at start:** "I'm using the npm-creator skill to scaffold an npm package for this plugin repo."
-
-**Context:** Use after a plugin repo has its content files (rules, hooks, agents, etc.) in place. This skill adds the packaging layer on top.
-
-## The Process
-
-### Step 1: Detect Plugin Structure
-
-Scan the current repo root for these directories:
-
-| Directory | Purpose | Install destination |
-|-----------|---------|-------------------|
-| `rules/` | Behavioral rules (.md) | `~/.claude/rules/` |
-| `docs/` | Reference documents (.md) | `~/.claude/docs/` |
-| `commands/` | Slash commands (.md) | `~/.claude/commands/` |
-| `agents/` | Agent definitions (.md) | `~/.claude/agents/` |
-| `skills/` | Skill packages (subdirs) | `~/.claude/skills/` |
-| `hooks/` | Hook scripts (+ optional hooks.json manifest) | Merge into `~/.claude/settings.json` |
-
-Use Glob to find which directories exist and count files in each. Report findings to the user.
-
-If the repo has no recognized directories, say so and ask if the structure uses different names.
-
-### Step 2: Gather Package Metadata
-
-Ask the user (use AskUserQuestion, one call with all questions):
-
-1. **Package name** — suggest the repo directory name. Ask if scoped (@org/) or unscoped.
-2. **Description** — suggest based on detected content ("Claude Code plugin with X rules, Y agents, Z hooks").
-3. **CLAUDE.md generation** — should the installer concatenate rules + docs into a CLAUDE.md? (Yes if both rules/ and docs/ exist.)
-4. **Python detection** — does the plugin use Python hooks? (Yes if hooks/ contains .py files.) If yes, the installer will detect python3/python/py at install time.
-
-### Step 3: Generate package.json
-
-Create `package.json` at the repo root with:
-
-- `name`: from Step 2
-- `version`: "1.0.0"
-- `description`: from Step 2
-- `type`: "module"
-- `bin`: `{ "<package-name>": "./bin/install.mjs" }`
-- `files`: array of detected directories + `["bin/"]`
-- `keywords`: `["claude-code", "plugin", "cli"]`
-- `license`: "MIT"
-- `repository`: detect from `git remote get-url origin` if available
-
-### Step 4: Generate bin/install.mjs
-
-Create `bin/install.mjs` with a shebang (`#!/usr/bin/env node`) and these capabilities:
-
-**Imports:** Only `node:fs`, `node:path`, `node:os`, `node:child_process`, `node:url`.
-
-**Path resolution:**
-- `CLAUDE_HOME` = `path.join(os.homedir(), '.claude')`
-- `PACKAGE_ROOT` = resolve from `import.meta.url` using `fileURLToPath` and `path.dirname`
-
-**Install mode (default — no flags):**
-
-For each detected directory from Step 1:
-- Copy files from package to CLAUDE_HOME, preserving directory structure
-- For skills/, copy recursively (each skill is a subdirectory)
-- For each file, log with status icon:
-  - New file: `  ✓ rules/bdd.md (new)`
-  - Existing file: `  ↻ rules/bdd.md (updated)`
-
-If CLAUDE.md generation is enabled:
-- Concatenate all rules/*.md under `# Project Rules (from <package-name> plugin)`
-- Concatenate all docs/*.md under `# Reference Docs`
-- Each file gets an `## {filename without extension}` header
-- Write to `CLAUDE_HOME/CLAUDE.md`
-
-If Python hooks detected:
-- Try `python3 --version`, then `python --version` (verify Python 3), then `py -3 --version`
-- Use the first that succeeds
-- If none work: print error and exit with code 1
-
-If hooks/hooks.json exists:
-- Read it and the destination `CLAUDE_HOME/settings.json` (create `{}` if missing)
-- For each event type, for each matcher group:
-  - Replace `python3` with detected python command (if applicable)
-  - Replace `${CLAUDE_PLUGIN_ROOT}` with the absolute CLAUDE_HOME hooks path
-  - Check for duplicate matcher groups (idempotent — skip if already present)
-  - Append new groups
-- Write settings.json with `JSON.stringify(data, null, 4)`
-
-Important runtime note:
-- `~/.claude/settings.json` is the runtime source of truth for hooks.
-- `hooks/hooks.json` is a packaging/install manifest input for merge workflows, not a runtime file Claude reads directly.
-
-Print summary:
-```
-Installed <package-name>:
-  Rules: N files (X new, Y updated)
-  Agents: N files (X new, Y updated)
-  Hooks: N groups merged into settings.json
-  Python: python3
-```
-
-**Uninstall mode (`--uninstall` flag):**
-- Remove only files matching the package's file list (never delete user-created files)
-- Log each removal: `  ✗ rules/bdd.md (removed)`
-- Remove hook entries from settings.json by matching command paths
-- Remove generated CLAUDE.md if it exists
-- Print removal summary
-
-**Error handling:**
-- Create CLAUDE_HOME with `fs.mkdirSync(path, { recursive: true })` if missing
-- If settings.json is malformed JSON, print error and exit (never clobber)
-- Skip missing source directories with a warning
-
-### Step 5: Update README.md
-
-If a README.md exists, offer to update the install section with:
-
-```
-## Install
-
-\`\`\`bash
-npx <package-name>
-\`\`\`
-
-To uninstall:
-
-\`\`\`bash
-npx <package-name> --uninstall
-\`\`\`
-```
-
-Preserve all other README content.
-
-## Output Format
-
-Two new files created:
-1. `package.json` at repo root
-2. `bin/install.mjs` at bin/ directory
-
-One file optionally updated:
-3. `README.md` install section
-
-## After Completion
-
-Suggest the user test locally:
-- `node bin/install.mjs` (install)
-- `node bin/install.mjs --uninstall` (uninstall)
-- Verify files appeared in `~/.claude/`
-- Verify hooks merged into `~/.claude/settings.json`
-
-When ready to publish: `npm publish`
-
-## Red Flags - STOP
-
-- Repo has no recognized plugin directories (rules/, hooks/, agents/, etc.)
-- hooks.json references tools or paths outside the plugin structure
-- Package name conflicts with an existing npm package (suggest checking npmjs.com)
-- Plugin files contain secrets or credentials that would be published
-
-## Rationalization Prevention
-
-| Excuse | Reality |
-|--------|---------|
-| "I'll add cross-platform support later" | Use path.join() and os.homedir() from the start. Retrofitting is painful. |
-| "Shell commands are simpler for file copying" | Shell commands break on Windows. fs APIs work everywhere. |
-| "One big install function is fine" | Separate install/uninstall/detect functions keep each under 50 lines. |
-| "We can skip idempotency" | Users will run the installer multiple times. Duplicate hooks break sessions. |
-
-## Remember
-
-- Zero external dependencies — only Node.js built-ins
-- If present, hooks.json in the repo stays canonical (python3 + ${CLAUDE_PLUGIN_ROOT})
-- Rewriting happens only in the destination settings.json (runtime source of truth)
-- path.join() everywhere — never concatenate paths with `/` or `\`
-- Idempotent: running twice produces the same result
-- Log every file action so the user sees what changed

package/skills/readability-review/SKILL.md

@@ -1,127 +0,0 @@
----
-name: readability-review
-description: 8-dimension readability rubric scoring code so a 6-year-old could understand it through structure alone. Scores functions, then FIXES anything below threshold. Use after writing code and before committing. Triggers on "readability review", "clean code", "score readability".
----
-
-# Readability Review
-
-## Overview
-
-Score every function across 8 readability dimensions (160 points total), then automatically fix anything scoring below threshold by rewriting and applying via Edit tool.
-
-**Core principle:** A 6-year-old could understand what every line does -- through code structure alone, not comments.
-
-**Announce at start:** "I'm using the readability-review skill to score and fix code readability across 8 dimensions."
-
-**Context:** Use after code is written but before committing. Complements code-quality-reviewer (architectural patterns) and review-code (standards compliance). This skill focuses purely on structural readability.
-
-## Comment Preservation (ABSOLUTE RULE)
-
-**NEVER remove ANY existing comments. ALL existing comments are SACRED.**
-
-This is an unconditional rule. Do not evaluate, judge, or clean up existing comments. If you are not modifying the code on that line, do not touch its comments.
-
-- Do not add NEW inline comments -- write self-documenting code instead
-- Docstrings for new files/methods/classes are allowed
-- If code is untouched, its comments are untouched
-- Scope: Only evaluate comments on lines YOU are actively changing
-
-## The 8 Dimensions (20 points each, 160 total)
-
-### 1. Naming Quality (20 pts)
-Every name reads as natural English. No mental translation required. No single-letter variables.
-Red flags: result, data, output, response, value, item, temp as variable names.
-
-### 2. Function SRP (20 pts)
-Every function does exactly one thing. Its name IS its documentation.
-
-### 3. Abstraction Consistency (20 pts)
-Each function operates at ONE conceptual level.
-
-### 4. Control Flow Clarity (20 pts)
-Zero nesting. Guard clauses first. Flat happy path.
-
-### 5. Domain Language Fidelity (20 pts)
-Code uses business vocabulary, not computer vocabulary.
-
-### 6. Call Site Readability (20 pts)
-Function calls read as English sentences at the call site.
-
-### 7. State and Assignment Clarity (20 pts)
-Variables never change meaning.
-
-### 8. Visual Rhythm and Code Shape (20 pts)
-Code has paragraph breaks. Related lines group together.
-
-## The Process
-
-### Step 1: Discover Changed Files
-
-Identify all files modified in the current session using `git diff --name-only`. Focus on production code files, not test files or config.
-
-### Step 2: Read Every Changed File
-
-Read the ENTIRE file, not just the diff. Readability depends on context -- a function name that seems clear in isolation may be confusing alongside its neighbors.
-
-### Step 3: Score Each Function
-
-Apply all 8 dimensions to every function in the changed files. Be specific with scores -- a function scoring 14/20 on Naming Quality needs concrete feedback on which names fail.
-
-### Step 4: Rewrite and APPLY to Source Files
-
-For every function scoring below 16/20 in ANY dimension, write the 160/160 version and USE THE EDIT TOOL to replace the original function in-place. Verify the file on disk contains the rewritten version. NEVER remove existing comments during rewrites.
-
-### Step 5: Report What Was Fixed
-
-Show the before/after scores for each function that was rewritten. Include which dimensions improved and by how much.
-
-## Output Format
-
-```
-## Readability Review: [File Name]
-
-### [function_name] - Score: [X]/160
-| Dimension | Score | Notes |
-|-----------|-------|-------|
-| Naming Quality | /20 | ... |
-| Function SRP | /20 | ... |
-| ... | ... | ... |
-
-**Action:** [Fixed / Acceptable]
-```
-
-## After Completion
-
-If any functions were rewritten, run the test suite to verify no behavior changed. Report the final score for all reviewed functions.
-
-**If score is below 120/160 overall:**
-- Perform deeper architectural analysis inline: check DRY violations, unnecessary abstractions, and mixed abstraction levels
-
-## Red Flags - STOP
-
-- Function names that require reading the body to understand
-- Variables reused for different purposes (meaning changes mid-function)
-- Mixed abstraction levels (SQL query next to business logic)
-- Deeply nested conditionals (more than 1 level)
-- Computer vocabulary where domain vocabulary exists (e.g., "handler" instead of "validator")
-- No visual grouping -- wall of code with no paragraph breaks
-
-## Rationalization Prevention
-
-| Excuse | Reality |
-|--------|---------|
-| "The naming is close enough" | Close enough means the next reader pauses. Pausing means it's not readable. |
-| "Refactoring this function would be too risky" | The Edit tool preserves behavior. If tests pass, the rewrite is safe. |
-| "It's only one dimension below threshold" | One weak dimension drags down comprehension of the entire function. |
-| "This is how the rest of the codebase looks" | Existing low scores are not a license to add more. Fix what you touch. |
-| "Adding guard clauses would make it longer" | Flat code reads faster than nested code, even if it has more lines. |
-
-## Remember
-
-- Score ALL 8 dimensions for EVERY function -- no shortcuts
-- Threshold is 16/20 in ANY single dimension, not average
-- Fix without asking permission -- just fix and report
-- Preserve all existing functionality and test assertions
-- NEVER add comments -- code must be self-documenting
-- NEVER remove existing comments -- they are sacred
-- Read entire files, not just diffs -- context matters