/setup

description: First-run configuration for the autocontext plugin

Run the autocontext first-run setup wizard. Use AskUserQuestion for each step. Group questions into batches of 2 (up to 4 per AskUserQuestion call) to keep the flow efficient.

Setup workflow

This skill guides you through initial configuration of the autocontext plugin. Your answers will be saved to `~/.claude/autocontext.json` for use across all projects.

If `~/.claude/autocontext.json` already exists, read it first and present current values as defaults. The user is re-running setup to change settings.

Batch 1 (steps 1-2)

Step 1: Identity

Identity is required for lesson attribution. No automatic fallback, you must explicitly set it.

**Question:** What should we call you in lesson attribution?

**Options:**

• Your name (text input)
• Username (text input)
• Email address (text input)
• Other (text input)

Step 2: Test quality rules

Select which automated test quality checks you want enabled when reviewing test code.

**Question:** Which built-in test quality rules do you want enabled?

**Available rules (multi-select):**

• Tautological test check, flags tests that describe code instead of testing behavior
• No mock everything, warns when mocks are the assertions instead of testing actual behavior
• No happy path only, requires error cases and edge case tests alongside happy path
• No bare assertions, flags `assert True`, `assert is not None`, and similar weak assertions
• Test independence, flags tests that pass without their feature code present

You can enable all, some, or none of these. They can be toggled later.

Batch 2 (steps 3-4)

Step 3: Lesson loading aggressiveness

Configure how many lessons to load at session start based on relevance confidence.

**Question:** How aggressively should lessons be loaded at session start?

**Options:**

• Conservative, load up to 5 lessons with confidence >= 0.7. Minimal context, high precision.
• Balanced (Recommended), load up to 15 lessons with confidence >= 0.3. Good mix of depth and specificity.
• Aggressive, load up to 25 lessons with confidence >= 0.1. Maximum context, may include tangential material.

Conservative is safer for focused work. Balanced provides good coverage. Aggressive helps when exploring unfamiliar codebases.

Step 4: Lesson persistence

Choose how new lessons discovered during sessions should be saved.

**Question:** How should new lessons be persisted at session end?

**Options:**

• Auto-persist with curator validation (Recommended), new lessons are automatically added, but marked for review. You can curate them later with `/autocontext:review`.
• Always ask before persisting, each new lesson prompts for approval before being added.
• Auto-persist everything, new lessons are immediately added without any review step.

Batch 3 (steps 5-6)

Step 5: Staleness and decay

Controls when unused lessons start losing confidence. After the staleness window, confidence drops by 0.1 every 30 days until the lesson is effectively forgotten.

**Question:** How long before unused lessons start losing confidence?

**Options:**

• 30 days (rapid turnover), best for fast-moving prototypes where context changes quickly.
• 60 days (Recommended), balanced for most projects with regular development cadence.
• 120 days (long-running), for stable projects where lessons stay relevant longer.
• 180 days (archival), minimal decay, good for slow-moving or reference-heavy codebases.

**Config mapping:**

• 30 days → `staleness_days: 30`
• 60 days → `staleness_days: 60`
• 120 days → `staleness_days: 120`
• 180 days → `staleness_days: 180`

Step 6: Pre-tool-use injection

The pre-tool-use hook checks loaded lessons before every Edit, Write, and Bash call. If a lesson's tags match the file being edited or command being run, it injects a brief warning. Some users find this helpful as a guardrail; others find mid-flow interruptions disruptive.

**Question:** Should autocontext inject lesson-based warnings before edits?

**Options:**

• Enabled (Recommended), inject relevant warnings before Edit/Write/Bash. Catches known gotchas before you hit them.
• Errors only, only inject warnings for lessons tagged as bugs, errors, or breaking changes. Quieter.
• Disabled, no pre-tool warnings. Lessons are still loaded at session start but don't interrupt workflow.

**Config mapping:**

• Enabled → `pretooluse_hook: "enabled"`
• Errors only → `pretooluse_hook: "errors_only"`
• Disabled → `pretooluse_hook: "disabled"`

Note: for backwards compatibility, `true` is treated as `"enabled"` and `false` as `"disabled"`.

Batch 4 (steps 7-8)

Step 7: Correction sensitivity

Controls how aggressively the system captures user corrections as lesson candidates. The user-prompt-submit hook pattern-matches messages for correction phrases and queues them for curation.

**Question:** How sensitive should correction detection be?

**Options:**

• High, capture any redirect, including soft phrases like "actually", "remember that", "keep in mind". Catches more but may pick up non-corrections.
• Medium (Recommended), capture explicit corrections like "no, use X instead", "that's wrong", "don't do that", "you forgot". Good signal-to-noise ratio.
• Low, only capture strong rejections like "that's wrong", "stop doing", "don't do that". Fewest false positives.

**Config mapping:**

• High → `correction_sensitivity: "high"`, all patterns active
• Medium → `correction_sensitivity: "medium"`, exclude soft patterns ("actually", "remember that/this", "keep in mind")
• Low → `correction_sensitivity: "low"`, only: "that's wrong", "don't do that", "stop doing", "no, use X instead"

Step 8: Performance baselines

Tracks test and build command execution times. When a command takes more than 10% longer than its baseline, a warning is injected. Useful for catching performance regressions early.

**Question:** Should autocontext track test/build performance baselines?

*