markus-global/markus

Why We have no repeatable way to answer "did this change make agents slower?" Until now, performance and stability work has relied on ad-hoc measurement (reading logs, watching a single run). Several P0 issues we fixed recently — heartbeat storms, lock granularity, tool timeouts, stream handling — were all things a throughput/latency harness would have surfaced earlier, or at least would now guard against regressing. Scope A benchmark harness, runnable from the repo, that measures agent throughput and latency on a fixed synthetic workload. Requirements Fixed workload — a small set of scripted task scenarios (e.g. N agents each running a multi-step task with a mix of tool calls), stored as fixtures. Same input every run. Deterministic where it can be, honest where it can't — LLM latency is not deterministic, so the harness must record the provider/model, and separate platform overhead (scheduling, routing, persistence, streaming) from provider latency as far as the instrumentat

Goal Markus ships 25 role templates (templates/roles/): researcher, developer, reviewer, ops, finance, HR, SRE... Add a role we don't yet have, following the same structure. Candidate roles (pick one or propose your own with a clear job description) security-auditor (review code/arch for vulnerabilities) data-analyst (SQL/reporting agent) seo-specialist (web visibility) sales-engineer (demo + technical sales) localization-manager (i18n coordination) How Study templates/roles/sre/ROLE.md and templates/roles/secretary/ROLE.md — note the structure: Identity & Expertise, Core Responsibilities, Workflow, Guardrails, metrics Create templates/roles/NEW-ROLE/ROLE.md with: Identity section (who the agent is, core expertise) Core Responsibilities (tables of duties, triggers, outputs) Workflow steps Guardrails / escalation rules Concrete success metrics Add the role to the README package table if roles are listed there Validate: the role directory is discoverable by the agent system (see

Goal Windows users currently must install via npm or the Electron desktop package. Add a PowerShell installer (iwr -UseBasicParsing ... | iex) that mirrors scripts/install.sh: detect architecture, download the right binary bundle, verify checksum, and print next steps. Reference files scripts/install.sh (existing bash installer — mirror its logic) scripts/build-binary.sh (what artifacts exist for Windows) markus.global/install.sh endpoint (where the script is served) Acceptance criteria install.ps1 works on PowerShell 5.1+ and 7+ (x64 + arm64) Downloads and verifies checksum, installs to %LOCALAPPDATA%\Markus (or similar), adds to PATH Documented in README Quick Start (Windows line) No secrets; respects standard security (RemoteSigned / execution policy guidance) Size: M · Skill needed: PowerShell, release engineering · Comment before starting to coordinate with release automation.

Where we actually are (v0.11.0) Since this issue was filed, the skill codec has grown a real multi-format front end: packages/core/src/skills/codec/ (detect.ts, parse.ts, render.ts, import-export.ts, frontmatter.ts). Formats the detector already handles (priority order in detectSkillPackageFormat): markus → mcp-server → soul → openclaw → claude (bare SKILL.md) → skillhub → agentscope. Registries wired up: our own Hub, SkillHub, and skills.sh (/api/skills/registry, /skillhub, /skillssh). So "support additional import formats beyond current adapters" is largely done — what's left is narrower and better specified. This issue is being rewritten to match. Gap No adapter for: A2A agent definitions — agent card / capability manifest → canonical skill. Cursor Rules (.cursor/rules/*.mdc) — closest field mapping to what we already model. n8n workflow nodes — widest reach, but needs the node graph modelled; heavier. Optional, lower priority: Claude Code subagent definition

Goal Add a Discord messaging adapter to packages/comms so teams can drive Markus from Discord. This also enables the planned Discord community channel. How Follow the existing adapter pattern — each adapter lives in packages/comms/src/NAME/ with adapter.ts + client.ts and is wired in packages/comms/src/router.ts: Study packages/comms/src/telegram/ (which is similar in shape) and packages/comms/src/slack/ Implement a minimal Discord client (discord.js or raw REST) supporting: receive messages, send messages, connect/disconnect Register the adapter in packages/comms/src/index.ts + router.ts Add unit tests mirroring packages/comms/test/telegram-adapter.test.ts Reference files packages/comms/src/telegram/, slack/, router.ts, index.ts packages/comms/test/telegram-adapter.test.ts Acceptance criteria discord.js (or equivalent) is a peerDependency, not bundled into core Adapter connects, receives, and sends with graceful error handling (token invalid, network down) Unit tests pass; pnpm