₿ag Hodlr@agHodlryk
/goal Stabilize my local AI-agent system and get it back to a clean, reliable foundation.
Do not assume you know how my system is set up. First discover it. Then map it. Then read the current upstream docs/repos/release notes/issues for every relevant component. Then ask me concise clarification questions for anything ambiguous. Then apply safe incremental fixes with evidence.
The goal is a stable runtime, predictable agent behavior, preserved data/integrations, correct wiring, and a final report I can trust.
Hard rules:
1. Treat the live machine as the source of truth.
2. Do not expose secrets, tokens, API keys, OAuth files, cookies, bot tokens, or raw credentials.
3. Backup before changing configs, prompts, workspaces, databases, env files, launch jobs, or integration settings.
4. Do not delete, migrate, overwrite, or simplify anything unless you can prove it is unused, broken, duplicated, or superseded.
5. Preserve existing data, memory, history, agents, integrations, credentials, custom workflows, and user-specific behavior unless I explicitly approve a change.
6. Prefer upstream-supported/native config over custom hacks, wrappers, patches, daemons, or sidecars.
7. Do not blindly upgrade everything. Check installed versions, current upstream docs, recent issues, release notes, and rollback paths first.
8. If my intent is unclear, reverse-prompt me with short numbered questions and a recommended default.
9. Do not mark this complete if major items are only planned. Complete means fixed, verified, or explicitly blocked with next action.
Phase 1 — Discover and map the system:
- Identify all runtimes, CLIs, package managers, repos, config directories, workspaces, agents, prompts, skills, plugins, tools, MCP servers, gateways, memory systems, databases, scheduled jobs, env files, auth profiles, launch services, and integrations.
- Find all relevant logs, task/session records, gateway records, memory/compaction summaries, error traces, and recent handoff/audit files.
- Produce SYSTEM_MAP.md showing:
- what is installed
- what is active
- what talks to what
- what models/providers are used
- where memory/data lives
- how incoming requests flow to responses
- what integrations are wired
- what background jobs exist
- what is custom vs upstream-native
Phase 2 — Read evidence before changing:
- Read recent logs and state files deeply enough to understand how the system has actually been behaving.
- Identify stuck jobs, silent completions, broken agents, failed tool calls, auth failures, model-routing mistakes, plugin/skill conflicts, gateway delivery failures, memory/compaction issues, slowdowns, and stale config.
- Read current upstream docs/repos/release notes/issues for every relevant component before editing it.
- Compare my current setup against upstream intent and best practices.
- Produce CURRENT_STATE_AUDIT.md with issues ranked P0/P1/P2.
Phase 3 — Reverse-prompt me where needed:
If you cannot safely infer intent, ask me concise questions before changing anything important.
For each question include:
- what you found
- why it matters
- the safest default
- what you need from me
Do not ask vague questions. Ask only questions that unblock real decisions.
Phase 4 — Diagnose root causes:
For each issue, record:
- symptom
- evidence
- likely root cause
- affected component
- upstream-intended behavior
- current local behavior
- safest fix
- rollback path
Focus especially on:
- agents not answering or not returning results
- background tasks finishing silently
- broken or slow runtime behavior
- model/provider misrouting
- gateway/Discord/Telegram/chat delivery problems
- memory or compaction losing context
- stale or conflicting prompt files
- broken tools/plugins/skills/MCP servers
- auth/env/config drift
- duplicate or shadowed components
- custom code replacing native behavior
- regressions from recent upgrades
Phase 5 — Fix incrementally:
- Apply the smallest safe fix for each issue.
- Verify each fix before moving on.
- Prefer config/doc/prompt alignment over new code.
- Preserve custom behavior that is intentional and working.
- Do not create a new orchestration layer unless the native runtime truly lacks the needed feature.
- Anything questionable should go into TRIM_CANDIDATES.md, not be deleted.
Phase 6 — Make agent behavior reliable:
Ensure user-originated work always returns one of:
- a useful result
- an artifact/link/path
- a clear blocker
- the exact next input needed from me
If one agent delegates to another, the original/main agent still owns final delivery back to the user.
Use a compact result contract when helpful:
status: success | blocked | failed
answer: concise useful result
artifact: optional path/link
proof: optional evidence
needs_user: optional exact question
Do not add heavy ledgers, dashboards, or tracking systems unless the native runtime has no usable status mechanism.
Phase 7 — Validate with smoke tests:
Run practical tests that match my actual use.
At minimum test:
- simple direct request
- delegated/subagent request if applicable
- long-running/background task if applicable
- gateway/chat round trip if applicable
- tool/plugin/MCP call if applicable
- memory retrieval if applicable
- model routing
- restart/resume behavior
- one real-world workflow I care about
For every test, record:
- input
- expected result
- actual result
- whether the user got the final answer/artifact/blocker
- evidence
- remaining issue if any
Phase 8 — Align with upstream without destroying my setup:
For each important component, record:
- installed version
- latest stable version
- relevant upstream docs/issues
- whether to update, pin, rollback, or leave unchanged
- why
- rollback path
Do not migrate me from one runtime/framework to another unless I explicitly approve it after seeing a written migration decision.
If migration seems attractive, write MIGRATION_DECISION.md comparing:
- what is broken now
- whether it can be fixed natively
- what migration would preserve or lose
- integration/data risk
- exact rollback path
Phase 9 — Trim only proven deadweight:
Classify components as:
- active verified
- probably active
- dormant but useful
- duplicate
- stale/shadowed
- broken
- unknown
- verified dead
Only remove verified dead items after backup.
Leave unknown/questionable items in TRIM_CANDIDATES.md for my review.
Phase 10 — Final report:
Produce FINAL_REPORT.md with:
- system map summary
- what was broken
- root causes
- what changed
- what was preserved
- what was not changed
- unresolved blockers
- trim candidates
- version/update recommendations
- smoke-test results
- rollback notes
- exact next steps
Completion criteria:
- SYSTEM_MAP.md exists.
- CURRENT_STATE_AUDIT.md exists.
- FIX_LOG.md exists.
- TRIM_CANDIDATES.md exists.
- FINAL_REPORT.md exists.
- Every P0/P1 issue is fixed or explicitly blocked.
- Runtime behavior is stable enough for normal use.
- Agents return useful results/artifacts/blockers without silent disappearance.
- Important integrations are preserved and verified.
- No raw secrets appear in reports.
- Final status is one of COMPLETE, PARTIAL, or BLOCKED. Do not call it COMPLETE if major work is only planned.