claude-improve-config

$npx mdskill add anam-org/metaxy/claude-improve-config

Analyze the current session for errors, mistakes, or inefficiencies and propose improvements to the `.claude` configuration to prevent similar issues in the future.

SKILL.md

.github/skills/claude-improve-configView on GitHub ↗
---
name: claude-improve-config
description: Self-reflect on the current session to identify mistakes and propose improvements to .claude configuration (CLAUDE.md, hooks, skills).
---

# Claude Config Self-Improvement

Analyze the current session for errors, mistakes, or inefficiencies and propose improvements to the `.claude` configuration to prevent similar issues in the future.

## When to Use

- After a session with significant mistakes or rework
- When you notice patterns that could be prevented with better configuration
- When explicitly requested via `/claude-improve-config`
- Automatically triggered by the `SessionEnd` hook

## Self-Reflection Process

### 1. Analyze the Session

Review the conversation for:

- **Repeated mistakes**: Same error made multiple times
- **Misunderstandings**: User had to correct Claude's interpretation
- **Inefficient workflows**: Better approaches discovered late in the session
- **Tool misuse**: Wrong tool for the job, excessive tool calls
- **Missing context**: Information that would have helped if in CLAUDE.md
- **Ignored instructions**: Existing CLAUDE.md rules that were violated

### 2. Categorize Issues

Rate severity:

- **Critical**: Caused significant rework or user frustration
- **Moderate**: Caused delays or minor corrections needed
- **Minor**: Slight inefficiency but didn't impact outcome

Only propose changes for **critical** or **moderate** issues.

### 3. Propose Configuration Changes

Changes can include:

**CLAUDE.md Updates:**

- New guardrails or constraints
- Clarified existing instructions
- Project-specific patterns to follow

**New Hooks:**

- PreToolUse hooks to prevent specific mistakes
- PostToolUse hooks to validate outputs
- Stop hooks to enforce checks before completion

**New Skills:**

- Reusable knowledge for recurring tasks
- Best practices for specific domains

### 4. Format the Proposal

Present proposals clearly:

```markdown
## Session Reflection

### Issues Identified

1. **[Critical/Moderate]** Brief description of the issue
   - What happened: ...
   - Why it happened: ...
   - Impact: ...

### Proposed Changes

#### Change 1: [Type - CLAUDE.md/Hook/Skill]

**Rationale:** Why this change prevents the issue

**Implementation:**
[Show the exact changes to make]

#### Change 2: ...
```

## Guidelines

- Only propose changes that are **generalizable** - don't add rules for one-off situations
- Keep CLAUDE.md **concise** - prefer hooks for enforcement over verbose instructions
- Test proposed hooks mentally - ensure they won't block legitimate workflows
- Prefer **minimal changes** - one well-designed rule is better than many narrow ones
- Consider **false positives** - hooks should not create friction for normal operations

## Example Proposals

### Example 1: Missing Test Verification

**Issue:** Claude claimed tests passed without running them.

**Proposal:** Add to CLAUDE.md:

```markdown
**Test verification**: Never claim tests pass without showing actual test output. Always run `uv run pytest` with the specific test file before marking test-related tasks complete.
```

### Example 2: Repeated Lint Failures

**Issue:** Code was submitted with lint errors multiple times.

**Proposal:** Add PostToolUse hook for Write/Edit:

```json
{
  "matcher": "Write|Edit",
  "hooks": [
    {
      "type": "command",
      "command": "ruff check --select=E,F $TOOL_INPUT.file_path 2>/dev/null || true"
    }
  ]
}
```

### Example 3: Wrong Branch for PR

**Issue:** PR was created against wrong base branch.

**Proposal:** Add to CLAUDE.md:

```markdown
**Pull requests**: Always verify the target branch before creating a PR. For this project, PRs should target `main` unless explicitly specified otherwise.
```

## Non-Examples (Do NOT Propose)

- One-off mistakes that won't recur
- User preference differences (not errors)
- Issues already covered by existing configuration
- Overly specific rules that won't generalize
- Changes that would slow down normal workflows significantly

More from anam-org/metaxy

SkillDescription
docs-page-frontmatterWrite YAML front matter for documentation pages with appropriate titles and descriptions for social cards.
hypothesisUse Hypothesis for property-based testing to automatically generate comprehensive test cases, find edge cases, and write more robust tests with minimal example shrinking. Includes Polars parametric testing integration.
metaxyThis skill should be used when the user asks to "define a feature", "create a BaseFeature class", "track feature versions", "set up metadata store", "field-level lineage", "FieldSpec", "FeatureDep", "run metaxy CLI", "metaxy migrations", "metaxy lock", "lock features", "external features", "multi-environment", "monorepo features", "enable Map datatype", "enable_map_datatype", or needs guidance on metaxy feature definitions, versioning, metadata stores, CLI commands, testing patterns, feature locking, Map datatype configuration, or multi-environment configuration.
narwhalsEffectively use Narwhals to write dataframe-agnostic code that works seamlessly across multiple Python dataframe libraries. Write correct type annotations for code using Narwhals.
sybilUse Sybil for testing code examples in documentation and docstrings. Covers pytest integration, parsers, skip directives, and namespace management.
syrupyUse syrupy for pytest snapshot testing to ensure the immutability of computed results, manage snapshots, customize serialization, and handle complex data structures with built-in matchers and filters.
tachThis skill should be used when the user asks to "add a tach module", "configure tach layers", "define module boundaries", "set up interfaces", "run tach check", "check module boundaries", "tach sync", "tach show", "deprecate a dependency", "tach-ignore", "unchecked modules", "tach test", "skip tests with tach", "configure tach.toml", "source roots", "forbid circular dependencies", "enforce module boundaries", "set up architectural layers", or "tach init".