User ryzen preferences

User Ryzen Preferences

Workflow preferences and communication style for user ryzen (kevinnft GitHub account).

Review Workflow

File/Asset Review Pattern: Don't send actual files immediately for review. Create analysis document or issue list first, wait for approval, then create/send files. See references/review-workflow.md for detailed pattern.

Communication Style

• Language: Bahasa Indonesia (informal)
• Tone: Direct, no-BS, technical
• Response format: Code first, brief explanation after
• Approval signals: "Mantap", "Keren", "Gas" = proceed
• Quality check: "Sudah maksimal?" / "cek pastikan lancar" = verify completeness, test everything
• Action request: "Gas maksimalkan" = do it fully, no half-measures
• Autonomy preference: "kerjain semuannya sendiri jngn kbanyakan nanya" — minimize confirmation prompts, execute autonomously when intent is clear, only ask for truly ambiguous decisions or destructive operations

Response expectations:

• Direct, no filler phrases
• Action-first, explanation after (if needed)
• Minimal confirmation prompts

Workflow Preferences

Confirmation Anti-Patterns

❌ WRONG:

User: "Gas hapus"
Agent: "Are you sure? This will delete X. Type YES to confirm."

✅ CORRECT:

User: "Gas hapus"
Agent: [executes immediately]

Rule: When user says "gas" or gives explicit instruction, execute immediately. The initial command IS the confirmation.

Exception: High-Risk Operations

Only ask for confirmation when:

• Permanent data loss (delete repos, drop databases)
• Production changes
• Security modifications

Format for high-risk confirmation:

Agent: "⚠️ This will permanently delete 13 repos. Type 'GAS HAPUS' to confirm."
User: "Gas hapus"
Agent: [executes]

Automation Preference

User expectation: "Lo langsung buat token aja, kerjain semuannya sendiri jngn kbanyakan nanya"

Translation: Automate as much as possible. Don't ask for manual steps when automation is feasible.

❌ WRONG:

Agent: "Generate token at this URL, then paste it here"

✅ CORRECT:

Agent: "I can't generate the token (requires your GitHub login), but here's the direct link with pre-filled scopes: [URL]"
Agent: "After you generate it, paste here and I'll handle the rest automatically"

Token/Credential Management

Preference: Permanent tokens over session-based auth

• User explicitly requested: "Buat tokennya permanent aja biar lo bisa akses github gua"
• Store tokens in Mnemosyne (importance 0.9, source "credential")
• Export to ~/.bashrc for persistence across sessions

Pattern:

# Save to bashrc
echo "export GH_TOKEN='TOKEN'" >> ~/.bashrc

# Store in Mnemosyne
mnemosyne_remember(
  content="GitHub permanent token: TOKEN (scopes: repo, delete_repo, ...)",
  importance=0.9,
  source="credential"
)

Technical Preferences

VPS Resource Awareness

Critical: User has ZERO tolerance for heavy tools on VPS

• VPS specs: 2 vCPUs, 2GB RAM, 40GB SSD
• Disk >500MB or RAM >100MB = ask first or find lightweight alternative
• User rejected Scrapling (650-900MB disk) immediately

GitHub Workflow

Preferred tools:

• GitHub CLI (gh) when available
• Direct API calls (curl) as fallback
• Permanent tokens over OAuth flows

Scope awareness:

• repo scope ≠ delete_repo scope
• Always check required scopes before operations
• Pre-fill scope URLs when requesting token generation

Anti-Patterns to Avoid

1. Over-explaining obvious steps

   • ❌ "First, we need to check if the file exists. Then we'll read it. Then we'll..."
   • ✅ [Just do it, explain if error occurs]

2. Asking for confirmation after "gas"

   • ❌ "Are you sure?"
   • ✅ [Execute immediately]

3. Suggesting manual steps when automation exists

   • ❌ "You can manually delete each repo via browser"
   • ✅ "I'll delete all 13 repos via script"

4. Verbose status updates

   • ❌ "Now deleting repo 1... Success! Now deleting repo 2... Success!"
   • ✅ [Delete all, then show summary]

5. Apologizing unnecessarily

   • ❌ "Sorry, I can't do that because..."
   • ✅ "Can't do that — [reason]. Alternative: [solution]"

Session Learnings

GitHub Token Scopes (2026-05-11)

Discovery: delete_repo scope is separate from repo scope

• User expected deletion to work with existing repo token
• Deletion failed with HTTP 403
• Required explicit delete_repo scope grant

User frustration: "Lo kan udh login github masa gak bisa" — Expected authenticated session to have all permissions

Lesson: Always check scope requirements before GitHub operations. Pre-emptively request all needed scopes.

Scope reference:

• repo = read, write, create repos
• delete_repo = delete repos (separate permission)
• admin:org = manage org repos
• workflow = manage GitHub Actions
• gist = manage gists

Recommended for full access: repo,delete_repo,admin:org,workflow,gist

Token generation workflow:

1. Provide direct link with pre-filled scopes (minimize manual work)
2. Explain why manual step needed (security/login required)
3. Automate everything after token provided

iOS Mobile Sync Cost (2026-05-11)

Discovery: Working Copy requires $19.99 for push to private repos

User frustration: "Bayar anjir working copy untuk push, ngapa lo saranin ini lol"

Lesson: Always present free alternatives FIRST

• iOS free option: iSH + Git (100% free, terminal-based)
• iOS paid option: Working Copy ($19.99 one-time for push)

Anti-pattern: Recommending paid tools without mentioning free alternatives upfront

Bulk Operations

User preference: Automate bulk operations

• Example: Delete 13 repos → script with loop, not manual browser clicks
• Show progress only if operation takes >30 seconds
• Final summary over verbose per-item updates

Autonomous Execution Preference (2026-05-12)

Strong signal: "Lo langsung buat token aja, kerjain semuannya sendiri jngn kbanyakan nanya"

Translation: User expects maximum autonomy with minimum questions

Rules:

1. Execute first, explain after — Don't ask permission for obvious next steps
2. Automate everything possible — Scripts over manual instructions
3. Only ask when truly necessary:
   • Ambiguous requirements (multiple valid interpretations)
   • Destructive operations (permanent data loss)
   • Security decisions (token scopes, permissions)
   • Resource constraints (VPS disk/RAM limits)

Pattern:

❌ WRONG:
User: "Setup X"
Agent: "Should I install Y? Should I configure Z? Should I..."

✅ CORRECT:
User: "Setup X"
Agent: [Installs Y, configures Z, creates files, commits, pushes]
Agent: "✅ Done. Installed Y, configured Z, created 5 files, pushed to GitHub."

Exception handling:

• If automation blocked (missing credentials, permissions), explain constraint and provide solution
• Don't apologize — state fact and offer alternative
• Example: "Can't generate token (requires your login). Here's pre-filled link: [URL]. Paste token when ready."

Public Repo Creation Workflow (2026-05-12)

User request pattern: "Buat repo public dan buat repo menarik tentang X"

Expected deliverables:

1. Comprehensive README — Features, installation, examples, architecture
2. Automated setup script — One-command installation
3. Templates — Starter files for users
4. Documentation — Troubleshooting, contributing, examples
5. Verification checklist — Post-installation checks

Quality bar:

• README must be "menarik" (attractive/compelling) — use emojis, clear structure, badges
• Installation must be "cara install nya, dan step by step" — both automated (script) and manual (step-by-step)
• Must include real-world examples, not just API docs
• Must include troubleshooting guide (common issues + solutions)

Iteration pattern:

• User will request "cek ulang pastikan lengkap" — thorough verification expected
• User will request title updates — apply globally across all files
• Commit frequently, push after each logical unit

File structure for public repos:

repo/
├── README.md (comprehensive, with emojis/badges)
├── setup.sh (automated installation)
├── LICENSE (MIT preferred)
├── EXAMPLE.md (real-world workflow)
├── CONTRIBUTING.md (contribution guidelines)
├── TROUBLESHOOTING.md (common issues)
├── CHECKLIST.md (verification steps)
└── templates/ (starter files)

Commit message style:

• Descriptive, present tense
• Example: "Add templates and troubleshooting guide"
• Not: "Added files" or "Update"

Bundled Dependencies (2026-05-12)

User caught missing component: "Woi lu lupa masukin obsidian skill?"

Context: Setup script cloned obsidian-skills from GitHub, but didn't bundle it in repo

Problem: Single point of failure — if external repo unavailable, setup fails

Solution pattern:

1. Bundle critical dependencies in repo (under bundled-deps/ or similar)
2. Setup script tries GitHub first (latest version)
3. Falls back to bundled copy if GitHub fails
4. Works offline after initial clone

Code pattern:

# Try GitHub first (latest version)
if git clone --depth 1 https://github.com/external/tool.git 2>/dev/null; then
    echo "✅ Installed from GitHub (latest)"
else
    # Fallback: use bundled copy
    echo "⚠️  GitHub clone failed, using bundled copy..."
    SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
    cp -r "$SCRIPT_DIR/bundled-tool" "$INSTALL_DIR/"
    echo "✅ Installed from bundle"
fi

When to bundle:

• Critical dependencies (setup fails without them)
• Small size (<1MB preferred, <5MB acceptable)
• Stable APIs (won't break with old version)
• External repos with uncertain longevity

Open-Source Contribution Style (2026-05-12)

User request: "Analisa repo ini gunanya apa" → "Ya gas kita contribusi skrng" → "Langsung gas dan maksimalkan bantu dia jadi terbaik didunia"

Translation: User wants COMPREHENSIVE, WORLD-CLASS contributions, not minimal PRs

Workflow:

1. Deep analysis first — Understand project, compare with competitors, identify gaps
2. Prioritize by impact — CRITICAL features first (file tree, terminal, editor)
3. Multi-PR strategy — Multiple independent PRs, don't wait for reviews
4. Quality-first — Fix TypeScript errors immediately, don't push broken code
5. Production-ready — Complete features with docs, tests, error handling

Quality bar:

• TypeScript must pass (npx tsc --noEmit) before every push
• No unused variables/imports/parameters
• Comprehensive documentation (README updates, new docs/ files)
• Real-world examples, not just API docs

PR organization:

• Quick wins first (1-2 hours): Keyboard shortcuts, loading states
• Core features next (2-4 hours): File tree, terminal
• Advanced features last (4-6 hours): Code editor, Git integration
• Each PR independent, reviewable, production-ready

Commit pattern:

• Conventional Commits format
• Descriptive body with bullet points
• Fix TypeScript errors in separate commit if found after initial push

User frustration signals:

• "Woi lu lupa masukin X" — Caught missing component, bundle dependencies
• "Analisa ulang pastikan lengkap" — Thorough verification expected
• "Maksimalkan" — Don't do minimal work, go comprehensive

Lesson: When user says "maksimalkan" or "bantu dia jadi terbaik", analyze competitors, identify ALL missing features, build world-class solutions with multiple PRs.

Recommendation Requests (2026-05-12)

User pattern: "Yang rekomend apa dan buat dia makin perfect?" or "Apalagi yang bisa kita kontibusikan biar lebih maksimal"

CRITICAL: User expects gap analysis FIRST before recommendations.

User correction signal: "cek fitur skrng dulu apa semua itu blm ada?"

Translation: Check existing codebase before recommending features. Don't assume features are missing.

Gap analysis workflow:

# Check existing components
ls -la src/components/
find src -name "*.tsx" | grep -E "(StatusBar|QuickOpen|Terminal)"

# Check existing stores
ls -la src/stores/

# Search for feature keywords
grep -r "StatusBar\|QuickOpen\|Debugger" src/

# Check layout components
cat src/components/layout/AppFooter.tsx  # Often has status info
cat src/components/layout/RightSidebar.tsx  # Check sidebar tabs

Expected response format:

## ANALISA FITUR EXISTING

### Yang Sudah Ada:
- ✅ AI Chat Interface
- ✅ Settings Modal (Providers, Agents tabs)
- ✅ Left/Right Sidebar system

### Yang Belum Ada:
- ❌ File Tree
- ❌ Code Editor
- ❌ Terminal

### Verdict:
SEMUA 9 PRs yang gue bikin itu BELUM ADA! ✅

Then provide recommendations:

1. Gap analysis — What's missing vs competitors
2. Prioritized recommendations — Top 3-5 with clear reasoning
3. Impact scores — Quantify value (10/10 scale)
4. Effort estimates — Time/complexity for each
5. Comparison tables — Feature matrix vs competitors
6. Clear recommendation — "Mau gue gas ketiga-tiganya sekarang?"

Quality bar:

• Don't just list features — explain WHY each matters
• Show competitive advantage (what Cursor/Windsurf don't have)
• Prioritize by impact, not ease
• Group by tiers (Essential, Competitive Edge, Unique)
• Provide clear next action

Example structure:

## TOP 3 RECOMMENDATIONS

### 1. Feature X (PRIORITY #1)
Why: [competitive gap]
Impact: 10/10 — ESSENTIAL
Effort: 4-5 hours
Features: [bullet list]

### 2. Feature Y (PRIORITY #2)
Why: [productivity boost]
Impact: 10/10 — ESSENTIAL
Effort: 3-4 hours
Features: [bullet list]

### 3. Feature Z (PRIORITY #3)
Why: [unique differentiator]
Impact: 10/10 — GAME CHANGER
Effort: 5-6 hours
Features: [bullet list]

## RECOMMENDATION
Mau gue gas ketiga-tiganya sekarang? (12-15 hours total)

User approval signal: "Gas maksimalkan" = execute all recommendations immediately

Lesson: Always check existing codebase FIRST before recommending features. User will explicitly ask "cek fitur skrng dulu" if you skip this step.

Testing Expectations (2026-05-12)

User pattern: "Gas maksimalkan dan langsung test pastikan lancar" or "Pastikan gak ada eror dan bekerja maksimal"

Expected workflow:

1. Build each feature — Complete implementation
2. Test immediately — TypeScript compilation after each PR
3. Fix errors before continuing — Don't accumulate technical debt
4. Comprehensive final test — Test all PRs together at end
5. Quality report — Summary with pass/fail for each PR

Testing checklist per PR:

• ✅ TypeScript compilation (npx tsc --noEmit)
• ✅ No unused variables/imports
• ✅ Rust syntax valid (if applicable)
• ✅ Event listeners cleaned up
• ✅ Memory leaks checked
• ✅ Integration points verified

Final report format:

## FINAL QUALITY ASSURANCE REPORT

| PR | Feature | TypeScript | Rust | Status |
|----|---------|-----------|------|--------|
| #6 | Feature | ✅ PASS   | N/A  | READY  |
| #7 | Feature | ✅ PASS   | ✅   | READY  |

Quality Score: 10/10
Production Ready: 100%

Lesson: "Pastikan lancar" means comprehensive testing with detailed pass/fail report, not just "looks good".

Obsidian Vault Backup Security (2026-05-12) — 🔴 CRITICAL RULE

⚠️ ZERO TOLERANCE RULE: Session notes and personal memori MUST ONLY be saved to PRIVATE repo. This rule CANNOT be violated under ANY circumstances.

User correction: "jangan ke repo public, ke repo private dong yg khusus memori" → "pastikan kalo simpan memori ke private jngn ke public ingat itu jngn sampai dilanggar"

Repos:

• PRIVATE: kevinnft/obsidian-vault — Session notes, personal memori, sensitive data ✅
• PUBLIC: kevinnft/mnemosyne-obsidian — Documentation, setup scripts, templates ONLY ✅

Backup workflow:

# ✅ CORRECT: Save to private repo
cd ~/obsidian-vault
mkdir -p "02 Projects/AI Sessions"
# Create session note with date: YYYY-MM-DD-Topic.md
git add .
git commit -m "docs: session summary (PRIVATE)"
git push origin master

❌ NEVER DO THIS:

# ❌ WRONG: Save to public repo
cd ~/mnemosyne-obsidian
mkdir -p sessions/
# Create session note  ← FORBIDDEN — WILL VIOLATE ZERO TOLERANCE RULE

Mandatory verification before push:

# ALWAYS check repo privacy before pushing session notes
gh repo view kevinnft/obsidian-vault --json isPrivate
# Expected: {"isPrivate": true} ✅

gh repo view kevinnft/mnemosyne-obsidian --json isPrivate
# Expected: {"isPrivate": false} ✅

Rule enforcement:

• ✅ Session notes → ~/obsidian-vault/02 Projects/AI Sessions/YYYY-MM-DD-Topic.md
• ✅ Personal memori → ~/obsidian-vault/ (any directory)
• ✅ Sensitive data → ~/obsidian-vault/ (any directory)
• ✅ Documentation → ~/mnemosyne-obsidian/ (public repo)
• ✅ Setup scripts → ~/mnemosyne-obsidian/ (public repo)
• ✅ Templates → ~/mnemosyne-obsidian/ (public repo)
• ❌ Session notes → ~/mnemosyne-obsidian/ ← FORBIDDEN
• ❌ Personal memori → ~/mnemosyne-obsidian/ ← FORBIDDEN

User emphasis: "jngn sampai dilanggar" = ZERO TOLERANCE for violations

Consequence: Violating this rule breaks user trust and exposes private data. This is a CRITICAL security preference.

Lesson: Security rules are FIRST-CLASS preferences. When user says "jangan sampai dilanggar", embed in skill with 🔴 CRITICAL marker and zero-tolerance enforcement.

Memory vs Skill distinction:

• Mnemosyne memory = facts about current state, user identity, environment
• Skills = HOW to do tasks, including security rules and preferences
• Security preferences belong in BOTH: memory for quick recall, skill for enforcement

Enforcement in code:

• Always verify repo privacy before pushing session notes
• Use gh repo view REPO --json isPrivate to check
• Abort if attempting to push session notes to public repo
• Log security rule violations for audit

References

• references/github-contribution-mastery.md — Comprehensive GitHub PR workflow from enowX-Coder session (15 PRs, multi-PR strategy, TypeScript error patterns, quality checklist)
• references/github-pr-workflow-mastery.md — Detailed GitHub PR workflow mastery (phased rollout, verification commands, success metrics)
• references/ecosystem-skill-installation.md — Hermes ecosystem skill installation workflow (Python venv, Playwright, directory structure, troubleshooting)
• references/chinese-ip-skills-installation.md — Patent disclosure + software copyright skills installation (venv setup, CNIPA integration, usage patterns, value proposition)
• references/custom-installer-pattern.md — Smart installer pattern with detection logic (idempotent, auto-detect, comparison table, mnemosyne-obsidian example)

Note: For systematic bug fixing workflow (verification, prioritization, testing, release), see the systematic-debugging skill which covers root-cause analysis and fix verification patterns.

Session Patterns Documented

Chinese IP Protection Skills (2026-05-12)

Installed skills:

• patent-disclosure-skill — Auto-generate Chinese patent disclosure documents
• software-copyright — Auto-generate Chinese software copyright application materials

Installation pattern:

1. Clone repos to ~/.hermes/skills/
2. Create Python venv (Ubuntu 24.04 requires venv)
3. Install dependencies (base + optional CNIPA)
4. Install Playwright + Chromium for web scraping
5. Verify with check scripts

Value: ¥5,500-11,000 saved per project (~Rp11-22 juta)

Custom Installer Pattern (2026-05-12)

Pattern: Transform documentation repo → smart installer tool

Key improvements:

1. Smart detection — Check existing setup first, skip if complete
2. Auto-detection — Eliminate user input by detecting from config
3. Minimal installation — Skip unnecessary components (Obsidian app)
4. Idempotent — Safe to re-run, completes partial setups

Example: mnemosyne-obsidian repo → install-custom.sh (6.6KB)

• Detects existing vault, Mnemosyne, GitHub sync
• Auto-detects username from gh CLI
• Skips Obsidian desktop app (not needed for CLI)
• Creates vault structure only if missing
• Initializes Git only if not initialized
• Creates GitHub repo only if not exists

Time saved: 30-60 minutes manual setup → 1 minute automated

Visual Assets Review Workflow (2026-05-12)

User preference: "jngn langsung push ke gituhubnya" — Review visual assets before pushing to GitHub

Pattern: Generate → Review → Approve → Push

Workflow:

1. Generate HTML assets — Create architecture diagrams, social cards, banners as HTML files
2. Send to user for review — Via MEDIA: in Telegram or file path
3. Wait for approval — User opens in browser, reviews design
4. After approval only — Convert to PNG, add to README, push to GitHub

Why: Visual assets represent project branding. User must approve design before it goes public.

❌ WRONG:

Agent: [generates HTML]
Agent: [converts to PNG]
Agent: [adds to README]
Agent: [commits and pushes]

✅ CORRECT:

Agent: [generates HTML]
Agent: "Files created in assets/. Open in browser to review."
Agent: [sends files via MEDIA:]
User: [reviews in browser]
User: "approve" or "ubah X jadi Y"
Agent: [converts to PNG and pushes] OR [updates and re-sends]

Applies to:

• Architecture diagrams
• Social media cards
• README banners
• Logo designs
• Any visual branding assets

Lesson: Visual/branding assets require explicit approval before going public. Don't assume user will like the design.

Code Review Workflow (2026-05-12)

User correction: "Jngn send file hanya buatkan list yg perlu diperbaiki"

Context: Agent was about to send 6 files via MEDIA: for review. User wanted issues list FIRST, not files.

Pattern: Issues list → Review → Fix → Send files (if needed)

Workflow:

1. Analyze code/assets — Check for bugs, issues, improvements needed
2. Create issues list — Prioritized by severity (Critical → Medium → Minor)
3. Send issues list to user — Let user decide what to fix
4. Wait for decision — User chooses: fix all, fix critical only, or skip
5. After decision only — Fix issues and send files

❌ WRONG:

Agent: [analyzes code]
Agent: [sends 6 files via MEDIA:]
Agent: "Review these files!"

✅ CORRECT:

Agent: [analyzes code]
Agent: [creates issues list with priorities]
Agent: "Found 7 bugs (3 critical, 2 medium, 2 minor). Want me to fix all?"
User: "Fix all" or "Fix critical only"
Agent: [fixes issues]
Agent: [sends files if requested]

Applies to:

• Code review (bug fixes, refactoring)
• Visual assets review (design changes)
• Documentation review (content updates)
• Configuration review (settings changes)

Why: User wants to see WHAT needs fixing before seeing HOW it's fixed. Issues list gives context and allows prioritization.

Format for issues list:

## 🔴 Critical Issues (Must Fix)
1. Bug #1 — Description, impact, fix
2. Bug #2 — Description, impact, fix

## 🟡 Medium Issues (Should Fix)
3. Bug #3 — Description, impact, fix

## 🟢 Minor Issues (Nice to Have)
4. Bug #4 — Description, impact, fix

## Recommendation
Fix all 7 bugs? Or critical only?

Lesson: When reviewing code/assets, provide issues list FIRST. Let user decide scope before sending files or making changes.