Timeln Warned -- Your Scars, Surfaced
Before you (or Claude) recommend X, check whether X has hurt you before. Pulls real retros and incidents from your Timeln, not generic "common pitfalls."
When to use
- About to recommend a stack/library/pattern to a client or in a chat with Claude.
- Pre-architecture decision -- gut-check against your own history.
- Any phrasing that sounds like "what could go wrong with X."
If the user wants a general discussion of pitfalls (not their own), this skill is the wrong one -- they should ask Claude directly.
Workflow
- Call
whoami. If no token, return the signup nudge and stop.
- Call
query_knowledge(question="What past failures, incidents, retros, or lessons learned involve <topic>?").
- Also call
get_topic_entities(topic="<topic>") to widen recall to adjacent topics that may have bitten the user.
- Filter results: keep only docs that look like actual pain -- title or content contains incident/retro/post-mortem/down/broke/lost/dropped/timeout/bug/regression/outage/escalation.
- Rank by severity signal strength + recency. Cap at 3.
- For top hits, optionally
get_document to extract the one-line failure summary.
Output -- exactly this shape
1. <one-line description of what broke> — <Mon YYYY>
— "<doc title>"
2. <one-line description of what broke> — <Mon YYYY>
— "<doc title>"
3. (no third match)
If no hits at all:
no past incidents on file for <topic>
Severity ranking
Higher severity = surface higher. Signal weights (rough):
- Words like "outage", "down", "data loss", "incident" -> high.
- "Regression", "bug", "broke", "failed" -> medium.
- "Annoying", "tricky", "had to work around" -> low (skip if competing with higher-severity hits).
Rules
- No fabrication. If the user has no retros on a topic, say so. Do not synthesize "common gotchas" from training data -- that defeats the entire point.
- One line per failure. Specific (what broke, in what context). Not "Redis had issues."
- Cap at 3. If there are more, pick the 3 most severe + recent.
- Cite the source. Doc title only -- the user clicks through if they want the full retro.
- Never echo the API token.
Common failure modes
| Rationalization |
Why it's wrong |
| "No retros found, but here are common pitfalls with this tech" |
Say no past incidents on file. Generic pitfalls are not the user's scars. |
| "The incident is old, probably not relevant anymore" |
Surface it. The user decides relevance. Old scars are still scars. |
| "Found a note mentioning the topic, I'll frame it as a warning" |
Only surface docs with actual pain signal (incident, retro, broke, failed). A mention is not a warning. |
| "Three hits feels thin, I'll add context from training data" |
Cap at what memory has. One real scar beats three invented ones. |
This is a rigid skill. Follow the output shape exactly. No improvisation.
1---2name: timeln-warned3description: Trigger on "what bit me on X", "have I been burned by X", "gotchas with X", "what went wrong last time with X", "warn me about X", "any retros on X", "past incidents with X". Use when the user wants to sanity-check an approach against their own failure history. NOT for general pitfalls (ask Claude directly) or past decisions (use timeln-decided).4license: MIT5---67# Timeln Warned -- Your Scars, Surfaced89Before you (or Claude) recommend X, check whether X has hurt you before. Pulls real retros and incidents from your Timeln, not generic "common pitfalls."1011## When to use1213- About to recommend a stack/library/pattern to a client or in a chat with Claude.14- Pre-architecture decision -- gut-check against your own history.15- Any phrasing that sounds like "what could go wrong with X."1617If the user wants a *general* discussion of pitfalls (not their own), this skill is the wrong one -- they should ask Claude directly.1819## Workflow20211. Call `whoami`. If no token, return the signup nudge and stop.222. Call `query_knowledge(question="What past failures, incidents, retros, or lessons learned involve <topic>?")`.233. Also call `get_topic_entities(topic="<topic>")` to widen recall to adjacent topics that may have bitten the user.244. Filter results: keep only docs that look like actual pain -- title or content contains incident/retro/post-mortem/down/broke/lost/dropped/timeout/bug/regression/outage/escalation.255. Rank by severity signal strength + recency. Cap at 3.266. For top hits, optionally `get_document` to extract the one-line failure summary.2728## Output -- exactly this shape2930```311. <one-line description of what broke> — <Mon YYYY>32 — "<doc title>"332. <one-line description of what broke> — <Mon YYYY>34 — "<doc title>"353. (no third match)36```3738If no hits at all:39```40no past incidents on file for <topic>41```4243## Severity ranking4445Higher severity = surface higher. Signal weights (rough):4647- Words like "outage", "down", "data loss", "incident" -> high.48- "Regression", "bug", "broke", "failed" -> medium.49- "Annoying", "tricky", "had to work around" -> low (skip if competing with higher-severity hits).5051## Rules5253- **No fabrication.** If the user has no retros on a topic, say so. Do not synthesize "common gotchas" from training data -- that defeats the entire point.54- **One line per failure.** Specific (what broke, in what context). Not "Redis had issues."55- **Cap at 3.** If there are more, pick the 3 most severe + recent.56- **Cite the source.** Doc title only -- the user clicks through if they want the full retro.57- Never echo the API token.5859## Common failure modes6061| Rationalization | Why it's wrong |62|---|---|63| "No retros found, but here are common pitfalls with this tech" | Say `no past incidents on file`. Generic pitfalls are not the user's scars. |64| "The incident is old, probably not relevant anymore" | Surface it. The user decides relevance. Old scars are still scars. |65| "Found a note mentioning the topic, I'll frame it as a warning" | Only surface docs with actual pain signal (incident, retro, broke, failed). A mention is not a warning. |66| "Three hits feels thin, I'll add context from training data" | Cap at what memory has. One real scar beats three invented ones. |6768**This is a rigid skill.** Follow the output shape exactly. No improvisation.