mirror of
https://github.com/affaan-m/everything-claude-code.git
synced 2026-04-06 09:13:31 +08:00
feat: restore reusable ops skills from hermes branch
This commit is contained in:
@@ -1,6 +1,6 @@
|
||||
# Everything Claude Code (ECC) — Agent Instructions
|
||||
|
||||
This is a **production-ready AI coding plugin** providing 38 specialized agents, 156 skills, 72 commands, and automated hook workflows for software development.
|
||||
This is a **production-ready AI coding plugin** providing 38 specialized agents, 159 skills, 72 commands, and automated hook workflows for software development.
|
||||
|
||||
**Version:** 1.10.0
|
||||
|
||||
@@ -146,7 +146,7 @@ Troubleshoot failures: check test isolation → verify mocks → fix implementat
|
||||
|
||||
```
|
||||
agents/ — 38 specialized subagents
|
||||
skills/ — 156 workflow skills and domain knowledge
|
||||
skills/ — 159 workflow skills and domain knowledge
|
||||
commands/ — 72 slash commands
|
||||
hooks/ — Trigger-based automations
|
||||
rules/ — Always-follow guidelines (common + per-language)
|
||||
|
||||
@@ -236,7 +236,7 @@ For manual install instructions see the README in the `rules/` folder. When copy
|
||||
/plugin list everything-claude-code@everything-claude-code
|
||||
```
|
||||
|
||||
**That's it!** You now have access to 38 agents, 156 skills, and 72 legacy command shims.
|
||||
**That's it!** You now have access to 38 agents, 159 skills, and 72 legacy command shims.
|
||||
|
||||
### Multi-model commands require additional setup
|
||||
|
||||
@@ -1131,7 +1131,7 @@ The configuration is automatically detected from `.opencode/opencode.json`.
|
||||
|---------|-------------|----------|--------|
|
||||
| Agents | PASS: 38 agents | PASS: 12 agents | **Claude Code leads** |
|
||||
| Commands | PASS: 72 commands | PASS: 31 commands | **Claude Code leads** |
|
||||
| Skills | PASS: 156 skills | PASS: 37 skills | **Claude Code leads** |
|
||||
| Skills | PASS: 159 skills | PASS: 37 skills | **Claude Code leads** |
|
||||
| Hooks | PASS: 8 event types | PASS: 11 events | **OpenCode has more!** |
|
||||
| Rules | PASS: 29 rules | PASS: 13 instructions | **Claude Code leads** |
|
||||
| MCP Servers | PASS: 14 servers | PASS: Full | **Full parity** |
|
||||
@@ -1240,7 +1240,7 @@ ECC is the **first plugin to maximize every major AI coding tool**. Here's how e
|
||||
|---------|------------|------------|-----------|----------|
|
||||
| **Agents** | 38 | Shared (AGENTS.md) | Shared (AGENTS.md) | 12 |
|
||||
| **Commands** | 72 | Shared | Instruction-based | 31 |
|
||||
| **Skills** | 156 | Shared | 10 (native format) | 37 |
|
||||
| **Skills** | 159 | Shared | 10 (native format) | 37 |
|
||||
| **Hook Events** | 8 types | 15 types | None yet | 11 types |
|
||||
| **Hook Scripts** | 20+ scripts | 16 scripts (DRY adapter) | N/A | Plugin hooks |
|
||||
| **Rules** | 34 (common + lang) | 34 (YAML frontmatter) | Instruction-based | 13 instructions |
|
||||
|
||||
@@ -106,7 +106,7 @@ cp -r everything-claude-code/rules/perl ~/.claude/rules/
|
||||
/plugin list everything-claude-code@everything-claude-code
|
||||
```
|
||||
|
||||
**完成!** 你现在可以使用 38 个代理、156 个技能和 72 个命令。
|
||||
**完成!** 你现在可以使用 38 个代理、159 个技能和 72 个命令。
|
||||
|
||||
### multi-* 命令需要额外配置
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# Everything Claude Code (ECC) — 智能体指令
|
||||
|
||||
这是一个**生产就绪的 AI 编码插件**,提供 38 个专业代理、156 项技能、72 条命令以及自动化钩子工作流,用于软件开发。
|
||||
这是一个**生产就绪的 AI 编码插件**,提供 38 个专业代理、159 项技能、72 条命令以及自动化钩子工作流,用于软件开发。
|
||||
|
||||
**版本:** 1.10.0
|
||||
|
||||
@@ -147,7 +147,7 @@
|
||||
|
||||
```
|
||||
agents/ — 38 个专业子代理
|
||||
skills/ — 156 个工作流技能和领域知识
|
||||
skills/ — 159 个工作流技能和领域知识
|
||||
commands/ — 72 个斜杠命令
|
||||
hooks/ — 基于触发的自动化
|
||||
rules/ — 始终遵循的指导方针(通用 + 每种语言)
|
||||
|
||||
@@ -209,7 +209,7 @@ npx ecc-install typescript
|
||||
/plugin list everything-claude-code@everything-claude-code
|
||||
```
|
||||
|
||||
**搞定!** 你现在可以使用 38 个智能体、156 项技能和 72 个命令了。
|
||||
**搞定!** 你现在可以使用 38 个智能体、159 项技能和 72 个命令了。
|
||||
|
||||
***
|
||||
|
||||
@@ -1096,7 +1096,7 @@ opencode
|
||||
|---------|-------------|----------|--------|
|
||||
| 智能体 | PASS: 38 个 | PASS: 12 个 | **Claude Code 领先** |
|
||||
| 命令 | PASS: 72 个 | PASS: 31 个 | **Claude Code 领先** |
|
||||
| 技能 | PASS: 156 项 | PASS: 37 项 | **Claude Code 领先** |
|
||||
| 技能 | PASS: 159 项 | PASS: 37 项 | **Claude Code 领先** |
|
||||
| 钩子 | PASS: 8 种事件类型 | PASS: 11 种事件 | **OpenCode 更多!** |
|
||||
| 规则 | PASS: 29 条 | PASS: 13 条指令 | **Claude Code 领先** |
|
||||
| MCP 服务器 | PASS: 14 个 | PASS: 完整 | **完全对等** |
|
||||
@@ -1208,7 +1208,7 @@ ECC 是**第一个最大化利用每个主要 AI 编码工具的插件**。以
|
||||
|---------|------------|------------|-----------|----------|
|
||||
| **智能体** | 38 | 共享 (AGENTS.md) | 共享 (AGENTS.md) | 12 |
|
||||
| **命令** | 72 | 共享 | 基于指令 | 31 |
|
||||
| **技能** | 156 | 共享 | 10 (原生格式) | 37 |
|
||||
| **技能** | 159 | 共享 | 10 (原生格式) | 37 |
|
||||
| **钩子事件** | 8 种类型 | 15 种类型 | 暂无 | 11 种类型 |
|
||||
| **钩子脚本** | 20+ 个脚本 | 16 个脚本 (DRY 适配器) | N/A | 插件钩子 |
|
||||
| **规则** | 34 (通用 + 语言) | 34 (YAML 前页) | 基于指令 | 13 条指令 |
|
||||
|
||||
@@ -205,6 +205,7 @@
|
||||
"skills/continuous-learning-v2",
|
||||
"skills/e2e-testing",
|
||||
"skills/eval-harness",
|
||||
"skills/hookify-rules",
|
||||
"skills/iterative-retrieval",
|
||||
"skills/plankton-code-quality",
|
||||
"skills/project-guidelines-example",
|
||||
@@ -316,8 +317,10 @@
|
||||
"paths": [
|
||||
"skills/connections-optimizer",
|
||||
"skills/customer-billing-ops",
|
||||
"skills/github-ops",
|
||||
"skills/google-workspace-ops",
|
||||
"skills/jira-integration",
|
||||
"skills/knowledge-ops",
|
||||
"skills/project-flow-ops",
|
||||
"skills/workspace-surface-audit"
|
||||
],
|
||||
|
||||
144
skills/github-ops/SKILL.md
Normal file
144
skills/github-ops/SKILL.md
Normal file
@@ -0,0 +1,144 @@
|
||||
---
|
||||
name: github-ops
|
||||
description: GitHub repository operations, automation, and management. Issue triage, PR management, CI/CD operations, release management, and security monitoring using the gh CLI. Use when the user wants to manage GitHub issues, PRs, CI status, releases, contributors, stale items, or any GitHub operational task beyond simple git commands.
|
||||
origin: ECC
|
||||
---
|
||||
|
||||
# GitHub Operations
|
||||
|
||||
Manage GitHub repositories with a focus on community health, CI reliability, and contributor experience.
|
||||
|
||||
## When to Activate
|
||||
|
||||
- Triaging issues (classifying, labeling, responding, deduplicating)
|
||||
- Managing PRs (review status, CI checks, stale PRs, merge readiness)
|
||||
- Debugging CI/CD failures
|
||||
- Preparing releases and changelogs
|
||||
- Monitoring Dependabot and security alerts
|
||||
- Managing contributor experience on open-source projects
|
||||
- User says "check GitHub", "triage issues", "review PRs", "merge", "release", "CI is broken"
|
||||
|
||||
## Tool Requirements
|
||||
|
||||
- **gh CLI** for all GitHub API operations
|
||||
- Repository access configured via `gh auth login`
|
||||
|
||||
## Issue Triage
|
||||
|
||||
Classify each issue by type and priority:
|
||||
|
||||
**Types:** bug, feature-request, question, documentation, enhancement, duplicate, invalid, good-first-issue
|
||||
|
||||
**Priority:** critical (breaking/security), high (significant impact), medium (nice to have), low (cosmetic)
|
||||
|
||||
### Triage Workflow
|
||||
|
||||
1. Read the issue title, body, and comments
|
||||
2. Check if it duplicates an existing issue (search by keywords)
|
||||
3. Apply appropriate labels via `gh issue edit --add-label`
|
||||
4. For questions: draft and post a helpful response
|
||||
5. For bugs needing more info: ask for reproduction steps
|
||||
6. For good first issues: add `good-first-issue` label
|
||||
7. For duplicates: comment with link to original, add `duplicate` label
|
||||
|
||||
```bash
|
||||
# Search for potential duplicates
|
||||
gh issue list --search "keyword" --state all --limit 20
|
||||
|
||||
# Add labels
|
||||
gh issue edit <number> --add-label "bug,high-priority"
|
||||
|
||||
# Comment on issue
|
||||
gh issue comment <number> --body "Thanks for reporting. Could you share reproduction steps?"
|
||||
```
|
||||
|
||||
## PR Management
|
||||
|
||||
### Review Checklist
|
||||
|
||||
1. Check CI status: `gh pr checks <number>`
|
||||
2. Check if mergeable: `gh pr view <number> --json mergeable`
|
||||
3. Check age and last activity
|
||||
4. Flag PRs >5 days with no review
|
||||
5. For community PRs: ensure they have tests and follow conventions
|
||||
|
||||
### Stale Policy
|
||||
|
||||
- Issues with no activity in 14+ days: add `stale` label, comment asking for update
|
||||
- PRs with no activity in 7+ days: comment asking if still active
|
||||
- Auto-close stale issues after 30 days with no response (add `closed-stale` label)
|
||||
|
||||
```bash
|
||||
# Find stale issues (no activity in 14+ days)
|
||||
gh issue list --label "stale" --state open
|
||||
|
||||
# Find PRs with no recent activity
|
||||
gh pr list --json number,title,updatedAt --jq '.[] | select(.updatedAt < "2026-03-01")'
|
||||
```
|
||||
|
||||
## CI/CD Operations
|
||||
|
||||
When CI fails:
|
||||
|
||||
1. Check the workflow run: `gh run view <run-id> --log-failed`
|
||||
2. Identify the failing step
|
||||
3. Check if it is a flaky test vs real failure
|
||||
4. For real failures: identify the root cause and suggest a fix
|
||||
5. For flaky tests: note the pattern for future investigation
|
||||
|
||||
```bash
|
||||
# List recent failed runs
|
||||
gh run list --status failure --limit 10
|
||||
|
||||
# View failed run logs
|
||||
gh run view <run-id> --log-failed
|
||||
|
||||
# Re-run a failed workflow
|
||||
gh run rerun <run-id> --failed
|
||||
```
|
||||
|
||||
## Release Management
|
||||
|
||||
When preparing a release:
|
||||
|
||||
1. Check all CI is green on main
|
||||
2. Review unreleased changes: `gh pr list --state merged --base main`
|
||||
3. Generate changelog from PR titles
|
||||
4. Create release: `gh release create`
|
||||
|
||||
```bash
|
||||
# List merged PRs since last release
|
||||
gh pr list --state merged --base main --search "merged:>2026-03-01"
|
||||
|
||||
# Create a release
|
||||
gh release create v1.2.0 --title "v1.2.0" --generate-notes
|
||||
|
||||
# Create a pre-release
|
||||
gh release create v1.3.0-rc1 --prerelease --title "v1.3.0 Release Candidate 1"
|
||||
```
|
||||
|
||||
## Security Monitoring
|
||||
|
||||
```bash
|
||||
# Check Dependabot alerts
|
||||
gh api repos/{owner}/{repo}/dependabot/alerts --jq '.[].security_advisory.summary'
|
||||
|
||||
# Check secret scanning alerts
|
||||
gh api repos/{owner}/{repo}/secret-scanning/alerts --jq '.[].state'
|
||||
|
||||
# Review and auto-merge safe dependency bumps
|
||||
gh pr list --label "dependencies" --json number,title
|
||||
```
|
||||
|
||||
- Review and auto-merge safe dependency bumps
|
||||
- Flag any critical/high severity alerts immediately
|
||||
- Check for new Dependabot alerts weekly at minimum
|
||||
|
||||
## Quality Gate
|
||||
|
||||
Before completing any GitHub operations task:
|
||||
- all issues triaged have appropriate labels
|
||||
- no PRs older than 7 days without a review or comment
|
||||
- CI failures have been investigated (not just re-run)
|
||||
- releases include accurate changelogs
|
||||
- security alerts are acknowledged and tracked
|
||||
128
skills/hookify-rules/SKILL.md
Normal file
128
skills/hookify-rules/SKILL.md
Normal file
@@ -0,0 +1,128 @@
|
||||
---
|
||||
name: hookify-rules
|
||||
description: This skill should be used when the user asks to create a hookify rule, write a hook rule, configure hookify, add a hookify rule, or needs guidance on hookify rule syntax and patterns.
|
||||
---
|
||||
|
||||
# Writing Hookify Rules
|
||||
|
||||
## Overview
|
||||
|
||||
Hookify rules are markdown files with YAML frontmatter that define patterns to watch for and messages to show when those patterns match. Rules are stored in `.claude/hookify.{rule-name}.local.md` files.
|
||||
|
||||
## Rule File Format
|
||||
|
||||
### Basic Structure
|
||||
|
||||
```markdown
|
||||
---
|
||||
name: rule-identifier
|
||||
enabled: true
|
||||
event: bash|file|stop|prompt|all
|
||||
pattern: regex-pattern-here
|
||||
---
|
||||
|
||||
Message to show Claude when this rule triggers.
|
||||
Can include markdown formatting, warnings, suggestions, etc.
|
||||
```
|
||||
|
||||
### Frontmatter Fields
|
||||
|
||||
| Field | Required | Values | Description |
|
||||
|-------|----------|--------|-------------|
|
||||
| name | Yes | kebab-case string | Unique identifier (verb-first: warn-*, block-*, require-*) |
|
||||
| enabled | Yes | true/false | Toggle without deleting |
|
||||
| event | Yes | bash/file/stop/prompt/all | Which hook event triggers this |
|
||||
| action | No | warn/block | warn (default) shows message; block prevents operation |
|
||||
| pattern | Yes* | regex string | Pattern to match (*or use conditions for complex rules) |
|
||||
|
||||
### Advanced Format (Multiple Conditions)
|
||||
|
||||
```markdown
|
||||
---
|
||||
name: warn-env-api-keys
|
||||
enabled: true
|
||||
event: file
|
||||
conditions:
|
||||
- field: file_path
|
||||
operator: regex_match
|
||||
pattern: \.env$
|
||||
- field: new_text
|
||||
operator: contains
|
||||
pattern: API_KEY
|
||||
---
|
||||
|
||||
You're adding an API key to a .env file. Ensure this file is in .gitignore!
|
||||
```
|
||||
|
||||
**Condition fields by event:**
|
||||
- bash: `command`
|
||||
- file: `file_path`, `new_text`, `old_text`, `content`
|
||||
- prompt: `user_prompt`
|
||||
|
||||
**Operators:** `regex_match`, `contains`, `equals`, `not_contains`, `starts_with`, `ends_with`
|
||||
|
||||
All conditions must match for rule to trigger.
|
||||
|
||||
## Event Type Guide
|
||||
|
||||
### bash Events
|
||||
Match Bash command patterns:
|
||||
- Dangerous commands: `rm\s+-rf`, `dd\s+if=`, `mkfs`
|
||||
- Privilege escalation: `sudo\s+`, `su\s+`
|
||||
- Permission issues: `chmod\s+777`
|
||||
|
||||
### file Events
|
||||
Match Edit/Write/MultiEdit operations:
|
||||
- Debug code: `console\.log\(`, `debugger`
|
||||
- Security risks: `eval\(`, `innerHTML\s*=`
|
||||
- Sensitive files: `\.env$`, `credentials`, `\.pem$`
|
||||
|
||||
### stop Events
|
||||
Completion checks and reminders. Pattern `.*` matches always.
|
||||
|
||||
### prompt Events
|
||||
Match user prompt content for workflow enforcement.
|
||||
|
||||
## Pattern Writing Tips
|
||||
|
||||
### Regex Basics
|
||||
- Escape special chars: `.` to `\.`, `(` to `\(`
|
||||
- `\s` whitespace, `\d` digit, `\w` word char
|
||||
- `+` one or more, `*` zero or more, `?` optional
|
||||
- `|` OR operator
|
||||
|
||||
### Common Pitfalls
|
||||
- **Too broad**: `log` matches "login", "dialog" — use `console\.log\(`
|
||||
- **Too specific**: `rm -rf /tmp` — use `rm\s+-rf`
|
||||
- **YAML escaping**: Use unquoted patterns; quoted strings need `\\s`
|
||||
|
||||
### Testing
|
||||
```bash
|
||||
python3 -c "import re; print(re.search(r'your_pattern', 'test text'))"
|
||||
```
|
||||
|
||||
## File Organization
|
||||
|
||||
- **Location**: `.claude/` directory in project root
|
||||
- **Naming**: `.claude/hookify.{descriptive-name}.local.md`
|
||||
- **Gitignore**: Add `.claude/*.local.md` to `.gitignore`
|
||||
|
||||
## Commands
|
||||
|
||||
- `/hookify [description]` - Create new rules (auto-analyzes conversation if no args)
|
||||
- `/hookify-list` - View all rules in table format
|
||||
- `/hookify-configure` - Toggle rules on/off interactively
|
||||
- `/hookify-help` - Full documentation
|
||||
|
||||
## Quick Reference
|
||||
|
||||
Minimum viable rule:
|
||||
```markdown
|
||||
---
|
||||
name: my-rule
|
||||
enabled: true
|
||||
event: bash
|
||||
pattern: dangerous_command
|
||||
---
|
||||
Warning message here
|
||||
```
|
||||
154
skills/knowledge-ops/SKILL.md
Normal file
154
skills/knowledge-ops/SKILL.md
Normal file
@@ -0,0 +1,154 @@
|
||||
---
|
||||
name: knowledge-ops
|
||||
description: Knowledge base management, ingestion, sync, and retrieval across multiple storage layers (local files, MCP memory, vector stores, Git repos). Use when the user wants to save, organize, sync, deduplicate, or search across their knowledge systems.
|
||||
origin: ECC
|
||||
---
|
||||
|
||||
# Knowledge Operations
|
||||
|
||||
Manage a multi-layered knowledge system for ingesting, organizing, syncing, and retrieving knowledge across multiple stores.
|
||||
|
||||
Prefer the live workspace model:
|
||||
- code work lives in the real cloned repos
|
||||
- active execution context lives in GitHub, Linear, and repo-local working-context files
|
||||
- broader human-facing notes can live in a non-repo context/archive folder
|
||||
- durable cross-machine memory belongs in the knowledge base, not in a shadow repo workspace
|
||||
|
||||
## When to Activate
|
||||
|
||||
- User wants to save information to their knowledge base
|
||||
- Ingesting documents, conversations, or data into structured storage
|
||||
- Syncing knowledge across systems (local files, MCP memory, Supabase, Git repos)
|
||||
- Deduplicating or organizing existing knowledge
|
||||
- User says "save this to KB", "sync knowledge", "what do I know about X", "ingest this", "update the knowledge base"
|
||||
- Any knowledge management task beyond simple memory recall
|
||||
|
||||
## Knowledge Architecture
|
||||
|
||||
### Layer 1: Active execution truth
|
||||
- **Sources:** GitHub issues, PRs, discussions, release notes, Linear issues/projects/docs
|
||||
- **Use for:** the current operational state of the work
|
||||
- **Rule:** if something affects an active engineering plan, roadmap, rollout, or release, prefer putting it here first
|
||||
|
||||
### Layer 2: Claude Code Memory (Quick Access)
|
||||
- **Path:** `~/.claude/projects/*/memory/`
|
||||
- **Format:** Markdown files with frontmatter
|
||||
- **Types:** user preferences, feedback, project context, reference
|
||||
- **Use for:** quick-access context that persists across conversations
|
||||
- **Automatically loaded at session start**
|
||||
|
||||
### Layer 3: MCP Memory Server (Structured Knowledge Graph)
|
||||
- **Access:** MCP memory tools (create_entities, create_relations, add_observations, search_nodes)
|
||||
- **Use for:** Semantic search across all stored memories, relationship mapping
|
||||
- **Cross-session persistence with queryable graph structure**
|
||||
|
||||
### Layer 4: Knowledge base repo / durable document store
|
||||
- **Use for:** curated durable notes, session exports, synthesized research, operator memory, long-form docs
|
||||
- **Rule:** this is the preferred durable store for cross-machine context when the content is not repo-owned code
|
||||
|
||||
### Layer 5: External Data Store (Supabase, PostgreSQL, etc.)
|
||||
- **Use for:** Structured data, large document storage, full-text search
|
||||
- **Good for:** Documents too large for memory files, data needing SQL queries
|
||||
|
||||
### Layer 6: Local context/archive folder
|
||||
- **Use for:** human-facing notes, archived gameplans, local media organization, temporary non-code docs
|
||||
- **Rule:** writable for information storage, but not a shadow code workspace
|
||||
- **Do not use for:** active code changes or repo truth that should live upstream
|
||||
|
||||
## Ingestion Workflow
|
||||
|
||||
When new knowledge needs to be captured:
|
||||
|
||||
### 1. Classify
|
||||
What type of knowledge is it?
|
||||
- Business decision -> memory file (project type) + MCP memory
|
||||
- Active roadmap / release / implementation state -> GitHub + Linear first
|
||||
- Personal preference -> memory file (user/feedback type)
|
||||
- Reference info -> memory file (reference type) + MCP memory
|
||||
- Large document -> external data store + summary in memory
|
||||
- Conversation/session -> knowledge base repo + short summary in memory
|
||||
|
||||
### 2. Deduplicate
|
||||
Check if this knowledge already exists:
|
||||
- Search memory files for existing entries
|
||||
- Query MCP memory with relevant terms
|
||||
- Check whether the information already exists in GitHub or Linear before creating another local note
|
||||
- Do not create duplicates. Update existing entries instead.
|
||||
|
||||
### 3. Store
|
||||
Write to appropriate layer(s):
|
||||
- Always update Claude Code memory for quick access
|
||||
- Use MCP memory for semantic searchability and relationship mapping
|
||||
- Update GitHub / Linear first when the information changes live project truth
|
||||
- Commit to the knowledge base repo for durable long-form additions
|
||||
|
||||
### 4. Index
|
||||
Update any relevant indexes or summary files.
|
||||
|
||||
## Sync Operations
|
||||
|
||||
### Conversation Sync
|
||||
Periodically sync conversation history into the knowledge base:
|
||||
- Sources: Claude session files, Codex sessions, other agent sessions
|
||||
- Destination: knowledge base repo
|
||||
- Generate a session index for quick browsing
|
||||
- Commit and push
|
||||
|
||||
### Workspace State Sync
|
||||
Mirror important workspace configuration and scripts to the knowledge base:
|
||||
- Generate directory maps
|
||||
- Redact sensitive config before committing
|
||||
- Track changes over time
|
||||
- Do not treat the knowledge base or archive folder as the live code workspace
|
||||
|
||||
### GitHub / Linear Sync
|
||||
When the information affects active execution:
|
||||
- update the relevant GitHub issue, PR, discussion, release notes, or roadmap thread
|
||||
- attach supporting docs to Linear when the work needs durable planning context
|
||||
- only mirror a local note afterwards if it still adds value
|
||||
|
||||
### Cross-Source Knowledge Sync
|
||||
Pull knowledge from multiple sources into one place:
|
||||
- Claude/ChatGPT/Grok conversation exports
|
||||
- Browser bookmarks
|
||||
- GitHub activity events
|
||||
- Write status summary, commit and push
|
||||
|
||||
## Memory Patterns
|
||||
|
||||
```
|
||||
# Short-term: current session context
|
||||
Use TodoWrite for in-session task tracking
|
||||
|
||||
# Medium-term: project memory files
|
||||
Write to ~/.claude/projects/*/memory/ for cross-session recall
|
||||
|
||||
# Long-term: GitHub / Linear / KB
|
||||
Put active execution truth in GitHub + Linear
|
||||
Put durable synthesized context in the knowledge base repo
|
||||
|
||||
# Semantic layer: MCP knowledge graph
|
||||
Use mcp__memory__create_entities for permanent structured data
|
||||
Use mcp__memory__create_relations for relationship mapping
|
||||
Use mcp__memory__add_observations for new facts about known entities
|
||||
Use mcp__memory__search_nodes to find existing knowledge
|
||||
```
|
||||
|
||||
## Best Practices
|
||||
|
||||
- Keep memory files concise. Archive old data rather than letting files grow unbounded.
|
||||
- Use frontmatter (YAML) for metadata on all knowledge files.
|
||||
- Deduplicate before storing. Search first, then create or update.
|
||||
- Prefer one canonical home per fact set. Avoid parallel copies of the same plan across local notes, repo files, and tracker docs.
|
||||
- Redact sensitive information (API keys, passwords) before committing to Git.
|
||||
- Use consistent naming conventions for knowledge files (lowercase-kebab-case).
|
||||
- Tag entries with topics/categories for easier retrieval.
|
||||
|
||||
## Quality Gate
|
||||
|
||||
Before completing any knowledge operation:
|
||||
- no duplicate entries created
|
||||
- sensitive data redacted from any Git-tracked files
|
||||
- indexes and summaries updated
|
||||
- appropriate storage layer chosen for the data type
|
||||
- cross-references added where relevant
|
||||
Reference in New Issue
Block a user