← all publishers

microxro

@microxro source repo

Report this profile Claim this profile

• 3 skills
• 0 followers
• 5 hours ago last updated

1. ▌
   Tree · microxro bundle

   Decompose a large or multi-part build into a verified task tree, splitting it the optimal amount — wide enough to parallelize, never wider than the work actually supports — so it gets done at the best effort in the least wall-clock time, dispatch the independent pieces to subagents running on your local model, and refuse to declare the task done until every required piece has been implemented, self-tested by its own worker, re-verified by you against the merged code, and integration-checked together. Use this whenever a request involves multiple features, multiple components/files, or phrases like "build the whole thing", "make sure everything works", "don't stop until it's done", "run these in parallel" or "use multiple agents" — even if the user never says "skill" or "task tree". Also use whenever the user explicitly invokes /tree. Do NOT use it for a single small fix or one-file change — the decomposition and gate overhead only pays off on real multi-part work.
   0 installs
2. ▌
   Graph · microxro bundle

   Build and query a persistent, confidence-tagged knowledge graph of a repository (files, classes, functions, imports, calls, inheritance, docs) instead of rediscovering its structure from scratch every time you need codebase context. Use whenever a task needs you to understand how a codebase is put together to do the work well — a code review, "what does this PR touch and depend on", architecture questions ("how does auth connect to the database", "what depends on this service", "what would break if I changed this"), prep before a large refactor, or unfamiliar-codebase exploration — or whenever the user asks to "graph", "map", or "graphify" the repo. If a graph already exists (check .graph/graph.json), query it first and read only the exact files it points to instead of grepping broadly — that saves tokens versus rediscovering structure on every multi-file task. Skip this for a small repo, a single-file task, or a question about what one line of code does — read the file directly instead.
   0 installs
3. ▌
   Taste · microxro bundle

   Apply practitioner judgment instead of generic-model defaults when creating or critiquing a real deliverable — code, UI, documents, plans, messages, system designs, charts. Ground in the actual job, audience, and a real inspected exemplar; pick the right shape instead of a default template; rank by what matters; use only source-backed specifics instead of invented detail; commit to one recommendation instead of a menu; then subtract and quality-gate before calling it done. When reviewing existing work, give a short verdict plus the few things that matter, not an exhaustive rubric. Use whenever the user says "use taste" / "apply taste" / "make this good" / "tighten this" / "polish this", for any deliverable someone else will see or with real stakes, when a brief is thin and there is pressure to invent specifics, or for any review/critique/comparison — even without saying "taste". Do NOT use for verbatim transformation or exhaustive-coverage tasks — taste is not permission to editorialize a coverage task.
   0 installs