Przejdź do treści
Biblioteka skilli
Programowanie · Analiza

memory-debugging

/memory-debugging

Pomaga debugować błędy i śledzić ich przyczynę, wskazując, skąd pochodzi wyjątek, kto wywołuje daną metodę i dlaczego endpoint zwraca 500.

Repozytorium
hoangsa ↗
Licencja
MIT
Ostatnia zmiana repozytorium
27.07.2026

Ocena i bezpieczeństwo

100/ 100Klasa: dobry
Format25 / 25
Frontmatter z nazwą i opisem, poprawna nazwa, opis do 1024 znaków, nazwa zgodna z folderem.
Odkrywalność25 / 25
Opis mówi, kiedy użyć skilla, ma sensowną długość i jest w 3. osobie.
Treść35 / 35
Co najmniej 150 słów i do 500 linii, nagłówki, listy kroków, przykłady albo kod.
Higiena15 / 15
Bez zaślepek typu TODO, bez ścieżek Windows, z licencją.
Ryzykobrak sygnałów w skanie
Pliki w paczce
1
Skrypty
0
Komentarze HTML
0
Adresy URL w SKILL.md
0
Przestarzałość

Brak sygnałów. Repozytorium zmienione 27.07.2026, bez odwołań do wycofanych modeli i API.

Licencja

MIT, otwarta: można używać i zmieniać, z zachowaniem informacji o autorze.

Co robi i kiedy

Pomaga debugować błędy i śledzić ich przyczynę, wskazując, skąd pochodzi wyjątek, kto wywołuje daną metodę i dlaczego endpoint zwraca 500.

Wyzwalacze z opisu

why is X failing?where does this error come from?trace this bugwho calls this method?this endpoint returns 500
Oryginalny opis (EN)

Use when the user is debugging a bug, tracing an error, or asking why something fails. Examples: "why is X failing?", "where does this error come from?", "trace this bug", "who calls this method?", "this endpoint returns 500".

Jak działa

  1. When to Use
  2. Workflow
  3. Anti-patterns
  4. When the symptom isn't indexed
Sekcje z nagłówków SKILL.md, w oryginale · 122 linii, 637 słów
Podgląd SKILL.md
---
name: memory-debugging
description: >
  Use when the user is debugging a bug, tracing an error, or asking
  why something fails. Examples: "why is X failing?", "where does this
  error come from?", "trace this bug", "who calls this method?",
  "this endpoint returns 500".
metadata:
  version: "0.0.1"
---

# Debugging with hoangsa-memory

Find the origin of a bug by walking the graph backwards from the
symptom. Recall locates the suspect symbol; `memory_symbol_context`
walks its callers until you reach the real cause.

## When to Use

- "Why is this function failing?"
- "Trace where this error comes from"
- "Who calls this method?"
- "This endpoint returns 500, what's upstream?"
- Any investigation that starts with a symptom and wants a root cause.

## Workflow

```
1. resources/read hoangsa-memory://memory/LESSONS.md           → known-bug lessons first
2. memory_recall({query: "<error or symptom>"})        → find the suspect
3. memory_symbol_context({fqn: <suspect>})             → callers / callees
4. memory_impact({fqn, direction: "up"})               → full upstream
5. Read the suspect + its callers carefully
6. After the fix: memory_remember_lesson
```

### 1. Check LESSONS.md first

A past session may have hit this bug. `LESSONS.md` entries are keyed
on trigger strings — scan for anything matching the symptom. If a
lesson says "this exact error comes from X", start there.

```
resources/read { uri: "hoangsa-memory://memory/LESSONS.md" }
```

### 2. Recall the symptom

Feed the error message literally. Retrieval is strongest on exact
tokens (function names, error strings, log lines). For example:

```
memory_recall { query: "connection refused retry pool exhausted" }
```

Include the error type, a noun from the failing operation, and any
concrete identifier (module, handler, queue name).

### 3. Drill with symbol_context

Once recall returns a candidate FQN:

```
memory_symbol_context { fqn: "pool::checkout" }
```

Pay special attention to:

- **`callers`** — who invoked the failing path. Bugs often live in the
  caller's assumptions, not the callee.
- **`callees`** — what the suspect delegates to. The actual throw site
  may be 1–2 hops deeper.
- **`references`** — non-call uses. A misconfigured trait impl, a
  generic bound violation, a type that escapes.

### 4. Walk upstream when stuck

If context doesn't make the cause obvious, run:

```
memory_impact { fqn: <suspect>, direction: "up", depth: 3 }
```

The depth-1 callers are the contexts in which the bug manifests.
Often the bug is "caller A passes a value the callee doesn't handle";
seeing all callers at once exposes the outlier.

### 5. Read the code

Once you have a narrow set of suspect files, use `Read` with line
ranges from the graph results — don't load whole files. The graph
already gave you `path:line` for every hit.

### 6. Reflect after the fix

When the fix lands and tests pass, if the bug is durable and non-obvious
(not a typo), persist a lesson:

```
memory_remember_lesson {
  trigger: "seeing ETIMEDOUT from the pool on cold start",
  advice: "pool::checkout has a 5s dial timeout; raise it or pre-warm
           via pool::ensure_min in the init path."
}
```

Keep the trigger as a **situation description**, not a command.
Lessons fire on situation match; imperatives don't match future
recalls.

## Anti-patterns

- **Recalling the fix instead of the symptom.** "Fix retry on
  connection failure" matches the wrong chunks. Search what you see
  (the error), not what you want (the fix).
- **Reading whole files on a guess.** The graph gives exact
  `path:line`; use it. Reading a 2000-line file to find a 5-line bug
  burns context.
- **Fix-then-forget.** If the bug was subtle and the fix was non-obvious,
  a lesson saves 30 minutes next time. If the bug was a typo, skip.
- **Assuming the top recall hit is the bug.** Top-ranked ≠ guilty.
  Read the top 3 chunks; the guilty one is often #2 because the
  retriever rewarded surface similarity over actual behaviour.

## When the symptom isn't indexed

If the error message lives in a dependency (e.g. `reqwest: connection
refused`), recall won't find it — the error text isn't in your code.
Recall for the *call site* instead: `"reqwest get client"` or the
wrapper function's name. The graph will lead you to the caller, which
*is* in your code.

Wersje

W bazie nie ma innych skilli o nazwie memory-debugging.

Identyczna treść występuje jeszcze w 1 innych folderach na GitHubie. Tu pokazujemy jedną, najlepiej ocenioną kopię.

Migawka bazy z 28.10.2026 · wersja paczki aaad3aa477c6 (skrót SHA-256 całej paczki)

Zgłoś problem z tym skillem: szkodliwa treść, błędny opis albo prośba autora o usunięcie.

Podobne skille

  • 100gitnexus-debugging
    Pomaga debugować błędy i śledzić ich źródło w kodzie z użyciem grafu wiedzy GitNexus, gdy trzeba ustalić, dlaczego coś zawodzi i skąd pochodzi błąd.
  • 100gitnexus-debugging
    Pomaga debugować błędy i śledzić ich źródło w kodzie z użyciem grafu wiedzy GitNexus, gdy trzeba ustalić, dlaczego coś zawodzi i skąd pochodzi błąd.
  • 100anvien-debugging
    Pomaga debugować błędy, śledzić pochodzenie komunikatów i ustalać, dlaczego coś zawodzi w kodzie.
  • 100gitnexus-debugging
    Pomaga debugować błędy w kodzie z użyciem GitNexus, śledzić pochodzenie błędów i ustalać, dlaczego coś zawodzi.
  • 100investigate
    Pomaga badać błędy w kodzie, śledzić źródło komunikatów o błędach i diagnozować problemy w projekcie.
  • 100phx-trace
    Śledzi, jak wartość lub żądanie dociera do kodu Elixir, ustala, kto wywołuje daną funkcję, i pomaga zaplanować zmianę sygnatury.

Uwagi i zgłoszenia

Wiadomość trafi do Bartosza Sokolińskiego. Adres e-mail jest potrzebny tylko do odpowiedzi. Szczegóły w polityce prywatności.