Failure Memory Log

Automatic failure pattern recording and recall system. Prevents repeating the same mistakes by logging errors with context, root cause, and resolution. Use w...

Security Scan

The skill's files and runtime instructions match its stated purpose of recording and recalling failure patterns; nothing requested or installed is disproportionate or unrelated.

Purpose & Capability

The name/description say "failure memory" and the skill implements an append-only markdown log (memory/failures.md), search guidance (grep / optional memory_search), and an init script to create the file. No unrelated credentials, binaries, or installs are requested. The requested artifacts are proportional to the stated purpose.

Instruction Scope

SKILL.md confines activity to creating, appending, searching, and summarizing memory/failures.md which is consistent with purpose. However, it instructs automatic recording of errors and to include exact error messages and context; that can inadvertently capture sensitive information (secrets, tokens, PII) from stack traces or command output. The skill does not provide sanitization, redaction, or retention guidance beyond 'don't record certain things', and it references optional 'memory_search' (vector search) which could imply an external service — ensure any vector DB used is trusted. This is a privacy/data-leakage caution rather than a coherence problem.

Install Mechanism

Instruction-only skill with a small local init script (scripts/init.sh) that creates the memory directory and a markdown file. The script is straightforward, uses only local filesystem operations, and performs no network or unexpected actions. No install-time risks detected.

Credentials

No environment variables, credentials, or config paths are requested. The lack of sensitive requirements is proportional to the described functionality.

Persistence & Privilege

The skill does not request 'always: true', does not modify other skills' configs, and only writes a file under the specified memory directory. Autonomous invocation on the platform is allowed by default but not excessive for this kind of helper.

Assessment

This skill appears coherent and low-risk for its stated purpose, but take these precautions before installing: (1) Run scripts/init.sh in a controlled repository/directory so the failures file is stored where you expect. (2) Decide and enforce file permissions (e.g., chmod 600) and retention/rotation so sensitive logs aren't broadly accessible. (3) Add or require redaction/sanitization rules before automatic recording — error messages and stack traces often contain secrets. (4) If you enable or connect a vector search (memory_search), verify the vector DB/service is private and encrypted; sending logs to a third-party vector service can leak secrets. (5) Review any agent components that will perform automated appends to ensure they only write intended failure info and don't capture unrelated files or credentials. Following these steps will reduce the risk of accidental data exposure while keeping the skill's benefits.

Failure Memory

Record failures. Learn from them. Never repeat them.

Core Concept

Every failure has three parts:

1. What happened (error message, symptom)
2. Why it happened (root cause)
3. How to fix/avoid it (resolution)

This skill stores them in a searchable markdown file and provides a recall mechanism before starting similar tasks.

File Structure

memory/
└── failures.md      # All failure records (append-only log)

Recording a Failure

When an error occurs during work, append to memory/failures.md:

## [YYYY-MM-DD HH:mm] <short title>

- **Category:** <build|deploy|config|api|permissions|data|logic|network|dependency>
- **Context:** <what you were trying to do>
- **Error:** `<exact error message or symptom>`
- **Root Cause:** <why it happened>
- **Resolution:** <what fixed it>
- **Prevention:** <how to avoid next time>
- **Tags:** <comma-separated keywords for search>

When to Record

Record AUTOMATICALLY when:

• A shell command exits non-zero and you identify why
• An API call fails and you find the cause
• A config/setup step fails and you resolve it
• You catch yourself repeating a previously-solved mistake
• A sub-agent reports an error with resolution

Do NOT record:

• Transient network timeouts (unless pattern emerges)
• Intentional test failures
• User-cancelled operations

Pre-Task Recall

Before starting any significant task, search failures for relevant history:

grep -i "<keyword>" memory/failures.md

Or use memory_search if vector search is available:

memory_search query="<task description> failure error"

If matches found, mention them briefly:

⚠️ Known pitfall: [title] — [prevention tip]

Failure Report

When asked for a failure report or review, generate a summary:

1. Read memory/failures.md
2. Group by category
3. Identify repeat patterns (same root cause appearing multiple times)
4. Suggest systemic fixes for patterns

Report Format

# Failure Report — YYYY-MM-DD

## Stats
- Total: N failures recorded
- Top category: <category> (N occurrences)
- Repeat offenders: N patterns seen 2+ times

## Repeat Patterns
### <pattern name>
- Seen: N times
- Root cause: <shared cause>
- Systemic fix: <recommendation>

## Recent Failures (last 7 days)
- [date] <title> — <resolution>

Initialization

Run scripts/init.sh to set up the failures file:

bash scripts/init.sh [memory_dir]

Default memory_dir: ./memory

Best Practices

1. Be specific — "EACCES on /var/run/docker.sock" beats "permission error"
2. Include the exact error — Future grep depends on it
3. Tag generously — More tags = better recall
4. Review monthly — Patterns reveal systemic issues
5. Link to fixes — Reference commits, PRs, or config changes when possible