사용 방법
- 설치 명령을 복사하고 자신의 에이전트 환경에 설치하기 전에 소스 패키지를 확인하세요.
- 필요한 도구, 인증 정보, 지원 환경은 원본 문서에서 확인하세요.
- 입력과 원하는 산출물을 설명하고 출처와 결과를 대조하세요.
npx skills add https://github.com/zereight/gitlab-mcp --skill remember시작 전 확인
- 설치에는 모델 구독, API 한도, 파일 접근 권한이 포함되지 않습니다.
- 별점 수와 설치 수는 활동 지표이며 독립적인 품질·보안 검증이 아닙니다.
원본 Skill 문서
원본 저장소의 제목, 예시, 코드, 표, 링크, 이미지를 유지해 표시합니다.
Remember
Promote durable, reusable knowledge into the right memory surface instead of leaving it buried in chat history.
When to Use
- User wants to preserve knowledge discovered during a session
- Organizing scattered findings into structured memory
- Cleaning up duplicate or conflicting stored information
When NOT to Use
- Ephemeral task notes → just keep in conversation
- Already documented in code or docs → reference directly
Memory Surfaces
| Surface | Use For | Durability |
|---|---|---|
| Project memory | Durable team/project knowledge | Permanent |
| Session context | Short-lived working notes | Session only |
| Docs / Instructions | Conventions, instructions | Permanent |
Workflow
- Gather the relevant session findings
- Classify each item:
- Durable project fact
- Temporary working note
- Operator preference or instruction
- Duplicate / stale / conflicting information
- Propose the best destination for each item
- Write or update only the appropriate memory surface
- Call out duplicates or conflicts that should be cleaned up
Rules
- Do not dump everything into one store
- Prefer project memory for durable team knowledge
- Keep entries concise and actionable
- If something is uncertain, mark it as uncertain rather than storing it as fact
Output
- What was stored
- Where it was stored
- Any duplicates/conflicts found
Quality Gate (Before Storing)
Before committing anything to memory, apply this 3-question filter. Skip storage if the answer to any question is "No":
| Question | Rationale |
|---|---|
| Is it actionable? "Does this tell someone what to DO in a future situation?" | Observations are not memory entries; decisions are. |
| Is it durable? "Will this still be true in 3 months, or is it tied to a temporary workaround?" | Ephemeral findings belong in session notes, not project memory. |
| Is it unique? "Does something close already exist in memory that covers this?" | Duplicate entries create confusion; prefer updating existing entries. |
Examples
| Item | Actionable? | Durable? | Unique? | Store? |
|---|---|---|---|---|
"Use bcrypt cost=12 for passwords in this project" | ✅ | ✅ | ✅ | YES |
| "API was slow today because server was rebooting" | ❌ | ❌ | ✅ | NO — ephemeral |
"Always run npm run build before pushing" | ✅ | ✅ | Check existing | YES if not already stored |
| "The login page has a bug in dark mode" | ❌ | ❌ | ✅ | NO — file a bug, not a memory entry |
"We prefer interface over type for object shapes" | ✅ | ✅ | Check existing | YES if not in coding-standards |
When to Update vs Create
- UPDATE an existing entry if the new information refines, corrects, or supersedes it
- CREATE a new entry only if no existing entry covers the topic
- DELETE entries that are provably outdated (check with user first)
See Also
/coding-standards— canonical rules reference (no need to duplicate into memory)/skill-stocktake— audit memory surfaces for quality
