knowledge-base-update
SkillAI & modelsUse this skill whenever you learn something important during a conversation: a key architectural decision, a project-specific convention, a bug root-cause, a 3rd-party API quirk, or any fact that would help a future agent avoid re-doing the same research. Writes structured entries to the project's knowledge base so that context persists across conversations and agents.
Available today. Use it from your connected AI after setup.
No other account needed.
Connect ahel once, and every AI you use reads what you have installed.
Then ask your AI: use the knowledge-base-update skill
What this skill tells your AI
The instructions your AI receives, as published by omergocmen/vibe-coder-kit in .agent/skills/knowledge-base-update/SKILL.md and read by ahel’s review.
Knowledge Base Update Skill
When to Trigger
Activate this skill when any of the following occur:
- An architectural or tech-stack decision is made (and the why matters)
- A non-obvious bug is fixed (root cause + fix documented)
- A 3rd-party service/API has a quirk, limit, or gotcha discovered
- A project convention is established (naming, folder structure, patterns)
- A research question is answered after significant investigation
- A "we tried X and it failed because Y" moment happens
Step-by-Step Process
1. Identify the Entry Type
Choose the category that best describes what was learned:
| Type | When to Use |
|---|---|
decision | Architecture, tech choices, trade-offs |
convention | Naming rules, code patterns, folder structures |
bug | Root cause + fix for a non-obvious problem |
gotcha | 3rd-party quirk, env issue, edge case trap |
research | Answer to a question requiring significant investigation |
2. Determine the File Path
Write to: .agent/knowledge/<slug>.md
slug= kebab-case summary of the topic (e.g.,auth-token-refresh-strategy)- If an entry for this topic already exists, update it rather than creating a new file
- Group related topics under subfolders:
.agent/knowledge/auth/,.agent/knowledge/infra/, etc.
3. Write the Entry
Use this exact template:
---
type: <decision|convention|bug|gotcha|research>
topic: <Short human-readable title>
date: <YYYY-MM-DD>
tags: [<tag1>, <tag2>]
---
## Summary
<One or two sentences — what was learned, bottom line up front>
## Context
<Why this came up. What problem were we solving?>
## Decision / Finding
<The actual content. Be specific. Include code snippets if helpful.>
## Rationale
<Why this choice over alternatives. What alternatives were rejected and why.>
## Consequences
<What does this affect going forward? What to watch out for?>
## References
- <File path, PR link, conversation snippet, or external URL>
4. Update the Index
After writing the entry, append a one-line summary to .agent/knowledge/INDEX.md:
| <date> | <type> | [<topic>](./<path>.md) | <one-line summary> |
If INDEX.md doesn't exist yet, create it with this header first:
# Project Knowledge Base
| Date | Type | Topic | Summary |
|------|------|-------|---------|
5. Confirm to User
After writing, report:
- What was saved and where
- The one-line summary that was added to the index
Rules
- Never summarize vaguely. "We decided to use X" is useless without why.
- Include the anti-pattern. If something was tried and rejected, document it — that's often the most valuable knowledge.
- Keep entries atomic. One topic per file. Don't bundle unrelated decisions.
- Date is mandatory. Future agents need to know how fresh this knowledge is.
- If in doubt, write it. The cost of a redundant entry is low. The cost of a missing one is re-doing the work.
Signals
- GitHub stars
- 92
- Forks
- 9
- Last commit
- Jun 2026
Advanced
- Catalog kind
- skill
- Gateway key
knowledge-base-update- Source
- github.com/omergocmen/vibe-coder-kit