Memory Informed Refactor

---
name: memory-informed-refactor
description: "Pre-refactor context loading -- queries Pensyve memory for past decisions, failures, and patterns related to a refactoring target, then compiles a briefing. Use when starting a refactor to avoid repeating past mistakes."
version: 1.0.0
---

# Memory-Informed Refactor

Load historical context from Pensyve memory before starting a refactor. Surfaces past decisions, failed approaches, known pitfalls, and relevant patterns to avoid repeating mistakes.

## Instructions

> This skill follows the memory reflex defined in `skills/shared/memory-reflex.md`. Recall before refactoring; observe when a refactor insight lands (abandoned approach, invariant discovered, regression cause).

When this skill is invoked with a refactoring target, follow these steps:

### Step 1: Query Memory for Context

Run multiple `pensyve_recall` queries to gather comprehensive context about the target:

1. **Direct matches**: `pensyve_recall` with query `"<target>"` (limit: 10)
2. **Refactor history**: `pensyve_recall` with query `"<target> refactor"` (limit: 5)
3. **Past failures**: `pensyve_recall` with query `"<target> failed"` (limit: 5)
4. **Past failures (alternate)**: `pensyve_recall` with query `"<target> error"` (limit: 5)
5. **Design decisions**: `pensyve_recall` with query `"<target> decided"` (limit: 5)
6. **Dependencies**: `pensyve_recall` with query `"<target> depends"` (limit: 5)

### Step 2: Inspect the Entity

If the target matches an entity name, also call `pensyve_inspect` with `entity: "<target>"` to get the full memory inventory for that entity.

### Step 3: Compile Briefing

Organize the findings into a structured briefing. Deduplicate results that appear across multiple queries.

> **Refactor Briefing: `<target>`**
>
> ### Known Facts
>
> - List of semantic memories about the target, ordered by confidence
> - Include confidence scores
>
> ### Past Decisions
>
> - Architecture or design decisions related to this target
> - Include the reasoning if available ("chose X because Y")
>
> ### Past Outcomes
>
> - Previous refactoring attempts and their results
> - Bug fixes and their root causes
> - What worked and what did not
>
> ### Known Pitfalls
>
> - Failed approaches (flagged clearly so they are not repeated)
> - Edge cases or gotchas discovered in past sessions
> - Dependencies that may be affected
>
> ### Procedural Knowledge
>
> - Action-outcome patterns with reliability scores
> - Proven workflows related to this target
>
> ### Recommendations
>
> - Synthesize the above into 2-5 actionable recommendations
> - Flag any conflicts or contradictions in the memory
>
> ### Memory Gaps
>
> - Areas where no relevant memories exist
> - Suggest what to watch for during the refactor

If no relevant memories are found for a section, omit that section entirely rather than showing an empty one. If no memories are found at all, say so clearly and proceed without historical context.

### Step 4: Episode Tracking

The current session's episode is already active (started by the SessionStart hook). This refactor's observations and any captured lessons will be part of that episode — no additional `pensyve_episode_start` call is needed.

### Capture refactor lessons as they land

When any of these occur during the refactor, call the memory reflex immediately:

- An invariant is discovered (semantic)
- An abandoned approach is confirmed not-viable (episodic)
- A dependency chain was traced that surprised us (episodic)
- A known-good refactoring sequence emerged (procedural)

Do not batch these to Stop — capture at landing, surface one-line.

## Constraints

- **Never read or write `.claude/` memory files.** All memory operations go through the Pensyve MCP tools exclusively.
- Do not fabricate or infer memories that are not in the query results. Only report what the MCP tools return.
- Present the briefing before any refactoring work begins. The purpose is to inform, not to act.
- Entity names MUST be lowercase and hyphenated.
- Do not start the refactor itself -- this skill only provides the briefing. The user decides when and how to proceed.
- If the MCP server returns errors, present whatever partial results were obtained and note which queries failed.

## Error Handling

- If `pensyve_recall` returns errors on some queries, present results from the successful queries and note the failures.
- If `pensyve_inspect` fails, skip the entity inspection and rely on recall results.
- If the MCP server is not connected, inform the user and suggest checking their MCP server configuration.