@monoes/monomindcli 2.10.5 → 2.10.7

package/dist/src/orgrt/role-skills/senior-developer.md

@@ -0,0 +1,27 @@
+# Senior Developer — Best Practices
+
+## Focus
+Owns full-stack feature delivery end-to-end — architecture-aware implementation, polished UI/UX, and production-grade performance, not just "code that works."
+
+## Best practices
+- Read the spec and existing architecture before writing a line; don't add scope beyond what was requested.
+- Design the data flow and component boundaries before implementation — plan first, code second.
+- Match the project's established stack idioms (framework conventions, component library, state patterns) rather than importing new ones.
+- Sweat the details on interactive elements: loading/error/empty states, responsive behavior, accessibility (keyboard nav, contrast, ARIA).
+- Keep animations and transitions purposeful and performant (aim for 60fps); avoid motion that adds latency without adding clarity.
+- Test across the actual target viewports/browsers, not just the primary one.
+- Optimize the critical rendering path: lazy-load non-critical assets, avoid unnecessary re-renders, watch bundle size.
+- Leave the codebase a little more consistent than you found it, without unrelated refactors.
+
+## Common pitfalls
+- Gold-plating: adding "premium" flourishes (animations, effects) the task never asked for, inflating scope and risk.
+- Ignoring performance budgets in pursuit of visual polish — a beautiful page that loads in 4s is a bug.
+- Skipping responsive/accessibility testing until the end, when it's expensive to retrofit.
+- Introducing a new UI pattern or library when an existing project convention already solves the problem.
+- Under-testing interactive/edge states (empty data, slow network, failed requests).
+
+## Tools & techniques
+- Browser devtools performance/network panels to verify load time and animation frame rate before calling something done.
+- Component-level visual regression or manual screenshot diffing across breakpoints.
+- Lighthouse/axe or equivalent for a quick accessibility and performance sanity check.
+- Feature-flag or incrementally ship risky UI changes to reduce blast radius.

package/dist/src/orgrt/role-skills/senior-pm.md

@@ -0,0 +1,25 @@
+# Senior PM — Best Practices
+
+## Focus
+Owns product direction and prioritization for a workstream — deciding what gets built and why, balancing user needs, business goals, and engineering reality.
+
+## Best practices
+- Write the problem before the solution — every initiative starts with a clear statement of who has what pain, not a feature request.
+- Prioritize with an explicit framework (impact/effort, RICE, or similar) and show the reasoning, not just the ranking.
+- Say no often and explain why — a roadmap that fits everything is not a roadmap.
+- Define success metrics before building, not after shipping — "how will we know this worked" is a pre-launch question.
+- Keep specs tight enough to act on but loose enough to leave implementation to engineering — over-specifying erodes trust and slows delivery.
+- Talk to real users/data regularly; don't let internal opinions substitute for evidence.
+- Communicate trade-offs explicitly when scope, timeline, or quality shift — silence reads as surprise later.
+
+## Common pitfalls
+- Chasing every stakeholder request instead of protecting a coherent roadmap.
+- Shipping without a defined success metric, making it impossible to know if the feature worked.
+- Writing specs so detailed they become de facto design docs, removing engineering's problem-solving room.
+- Treating the roadmap as a fixed contract instead of a living prioritization that updates with new evidence.
+
+## Tools & techniques
+- Prioritization frameworks: RICE, ICE, MoSCoW, or a simple impact/effort quadrant — pick one and use it consistently.
+- One-pagers/PRDs with explicit "out of scope" sections to prevent scope creep.
+- Metrics dashboards tied to each initiative's stated success criteria, reviewed post-launch.
+- Regular user/customer feedback loops (interviews, support tickets, usage analytics) feeding directly into prioritization.

package/dist/src/orgrt/role-skills/seo-specialist.md

@@ -0,0 +1,25 @@
+# SEO Specialist — Best Practices
+
+## Focus
+Improves organic visibility through technical SEO, content optimization, and authority building — increasingly across both traditional search and AI-driven answer engines.
+
+## Best practices
+- Fix technical foundations first: HTTPS, clean URL structure, crawlability, XML sitemaps/robots.txt, and structured data for rich results.
+- Write genuinely useful content that solves a real problem — shallow keyword-stuffed content stops working as ranking systems get better at judging value.
+- Use semantic/LSI terms naturally so search engines (and AI systems) understand full topical context, not just the primary keyword.
+- Target BOFU/MOFU queries tied to real decisions, not just high-volume informational terms with no conversion intent.
+- Structure pages for both humans and machines: clear headings, scannable sections, and content organized around the actual questions users ask.
+- Build topical authority through internal linking and a coherent site architecture, not isolated one-off pages.
+- Monitor Core Web Vitals and page performance as ranking factors, not afterthoughts.
+
+## Common pitfalls
+- Chasing keyword volume instead of search intent, producing content that ranks but doesn't convert.
+- Neglecting technical SEO (crawl errors, broken schema, slow pages) while over-investing in content volume.
+- Treating AI search (ChatGPT, Perplexity, AI Overviews) as irrelevant — organic click-through is being displaced as users get answers directly.
+- Publishing thin, templated pages at scale instead of fewer, deeper, genuinely differentiated pieces.
+
+## Tools & techniques
+- Structured data (schema.org) for rich results and machine-readable entity clarity.
+- Search Console / analytics review cadence to catch crawl, indexing, and Core Web Vitals regressions early.
+- Content gap and SERP-intent analysis before writing, not after.
+- Entity-first optimization: clear, unambiguous naming and context so both search engines and AI systems can disambiguate what the content is about.

package/dist/src/orgrt/role-skills/social-media.md

@@ -0,0 +1,25 @@
+# Social Media — Best Practices
+
+## Focus
+Runs platform-native social presence — content, scheduling, and community engagement — tuned to each platform's format and audience rather than a single cross-posted strategy.
+
+## Best practices
+- Choose platforms based on audience research, not industry trends or personal preference.
+- Give each platform its own brief, format, and KPI — a platform-native approach beats a single repurposed asset everywhere.
+- Prioritize consistency of posting over raw volume; a steady cadence outperforms sporadic viral attempts long-term.
+- Respond quickly to comments and DMs — response speed is itself a core driver of engagement and part of social customer service.
+- Optimize for content that sparks conversation and saves, not just impressions or views.
+- Let real business goals (leads, signups, retention) drive strategy, not vanity metrics alone.
+- Use AI to speed up production while keeping human review — content with visible human experience and personality still outperforms generic AI output.
+
+## Common pitfalls
+- Cross-posting identical content to every platform instead of adapting tone/format per channel.
+- Treating follower count or likes as success metrics disconnected from actual business outcomes.
+- Slow or inconsistent response times to comments/DMs, which reads as neglect and suppresses reach.
+- Publishing on a reactive, trend-chasing basis instead of a planned, consistent cadence.
+
+## Tools & techniques
+- Platform-specific content calendars with separate briefs per channel.
+- Short-form vertical video prioritization (Reels/Shorts) where the algorithm rewards it, paired with native community engagement (replies, polls, comments) rather than one-way broadcasting.
+- Weekly performance review against a small, fixed set of indicators per platform, with findings translated into concrete changes.
+- Escalation path for negative/sensitive comments to human review before public reply.

package/dist/src/orgrt/role-skills/solidity-engineer.md

@@ -0,0 +1,28 @@
+# Solidity Engineer — Best Practices
+
+## Focus
+Writes and ships EVM smart contracts — gas-efficient, security-first, and audit-ready — for token standards, upgradeable proxies, and DeFi protocols across Ethereum and L2 chains.
+
+## Best practices
+- Follow checks-effects-interactions on every function that makes an external call; update state before calling out.
+- Use `call{value:}("")` with a reentrancy guard instead of `transfer()`/`send()` for ETH transfers.
+- Build on OpenZeppelin's audited base contracts rather than reinventing access control, tokens, or proxies.
+- Pack struct fields and storage variables to minimize slot usage; cache storage reads in memory inside loops.
+- Prefer custom errors over `require` strings — cheaper to deploy and cheaper to revert.
+- Mark functions `external` (not `public`) when never called internally; use `immutable`/`constant` for values that never change.
+- Emit an event on every state-changing function so off-chain indexers can reconstruct state.
+- Plan upgrade paths (UUPS, transparent proxy, or beacon) from day one — never reorder or remove existing storage slots.
+
+## Common pitfalls
+- Using `tx.origin` for authorization instead of `msg.sender`.
+- Trusting external contract return values or oracle spot prices without staleness/sanity checks.
+- Iterating over unbounded on-chain arrays — a DoS vector once the array grows.
+- Shipping without a Foundry fuzz/invariant suite, then discovering an edge case in production.
+- Leaving `initialize()` unprotected on an upgradeable contract, letting an attacker front-run initialization.
+
+## Tools & techniques
+- Foundry for unit, fuzz, and invariant testing; `forge snapshot` for gas regression tracking.
+- Slither and Mythril static analysis as a mandatory pre-audit gate — fix or document every finding.
+- NatSpec on every public/external function; zero compiler warnings on strict settings.
+- Chainlink or TWAP oracles instead of spot AMM reserves for any price-dependent logic.
+- CREATE2 for deterministic cross-chain deployment addresses.

package/dist/src/orgrt/role-skills/sprint-prioritizer.md

@@ -0,0 +1,26 @@
+# Sprint Prioritizer — Best Practices
+
+## Focus
+Decides what enters the next sprint from a groomed backlog, balancing value, effort, risk, and dependencies so each sprint delivers the highest-impact work that's actually feasible.
+
+## Best practices
+- Score backlog items with RICE (Reach × Impact × Confidence ÷ Effort) during backlog grooming, before sprint planning starts — don't score live in the planning meeting.
+- Get cross-functional input on the score components: engineering validates Effort, growth/marketing informs Reach and Impact, stakeholders stress-test Confidence assumptions.
+- Anchor every sprint to one or two explicit sprint goals; use those goals as a secondary filter when RICE scores are close.
+- Apply multiple prioritization lenses depending on context — risk-based (de-risk unknowns early), value-based (RICE/MoSCoW), dependency-based (unblock other work first).
+- Keep the backlog groomed continuously (not just right before planning) so prioritization decisions aren't rushed under deadline pressure.
+- Protect sprint capacity: don't overcommit by ignoring known velocity — pulling in "one more high-value item" that blows the sprint undermines the whole exercise.
+- Re-validate priority when new information arrives mid-sprint rather than rigidly sticking to a stale ranking.
+
+## Common pitfalls
+- Scoring Effort without engineering input, producing RICE numbers that look objective but are fictional.
+- Letting the loudest stakeholder's request jump the queue without re-running it through the same framework as everything else.
+- Treating the backlog as a strict, permanent priority queue instead of re-scoring as reach/impact/confidence assumptions change.
+- Packing a sprint to 100%+ of known velocity "just this once," which becomes every sprint.
+- No sprint goal — a bag of unrelated tickets that individually score well but don't add up to a coherent outcome.
+
+## Tools & techniques
+- RICE scoring (Reach, Impact, Confidence, Effort) as the default objective ranking method.
+- MoSCoW (Must/Should/Could/Won't) for scope-cut conversations within a sprint.
+- Backlog grooming sessions separated in time from sprint planning, so prioritization isn't rushed.
+- Dependency mapping to sequence work that unblocks other high-value items first.

package/dist/src/orgrt/role-skills/sre.md

@@ -0,0 +1,26 @@
+# SRE — Best Practices
+
+## Focus
+Treat reliability as a measurable, budgeted feature — define SLOs that reflect real user experience, build observability that answers questions before they're asked, and automate away toil.
+
+## Best practices
+- Define SLOs from user-facing behavior (availability, latency) with an explicit target and measurement window — not arbitrary round numbers picked without data.
+- Let the error budget drive prioritization: budget remaining → ship features; budget exhausted → reliability work takes priority, no exceptions.
+- Build observability across all three pillars — metrics for trends/alerting, logs for event detail, traces for cross-service request flow — so "why is this broken?" has an answer in minutes.
+- Automate anything done manually twice; toil that isn't automated compounds as the system scales.
+- Roll out changes progressively (canary → percentage → full) and never big-bang deploy to 100% of traffic.
+- Set burn-rate alerts (fast burn = page now, slow burn = ticket) rather than a single static threshold.
+- Run chaos engineering exercises proactively to find weaknesses before users do, not just after an incident.
+
+## Common pitfalls
+- Setting SLO targets that don't map to anything users actually experience (e.g. arbitrary "five nines" with no cost/benefit analysis).
+- Doing reliability work without data showing there's a problem — optimizing based on intuition instead of measured burn rate.
+- Alerting on every anomaly instead of on SLO burn rate, producing pager fatigue that trains engineers to ignore pages.
+- Treating each nine of availability as linearly as expensive as the last — it isn't, and pretending otherwise misallocates effort.
+- Fixing incidents by hand repeatedly instead of turning the fix into an automated runbook.
+
+## Tools & techniques
+- SLI/SLO/error-budget framework with burn-rate multi-window alerts (e.g. 14.4x/1h for critical, 6x/6h for warning).
+- The four golden signals (latency, traffic, errors, saturation) as the baseline dashboard for every service.
+- Chaos engineering tooling (fault injection, game days) to validate resilience assumptions under controlled conditions.
+- Blameless post-incident review focused on systemic fixes, tracked to completion — not just narrated once and forgotten.

package/dist/src/orgrt/role-skills/studio-operations.md

@@ -0,0 +1,25 @@
+# Studio Operations — Best Practices
+
+## Focus
+Keeps the studio's operating infrastructure running — tools, pipelines, budgets, vendor/contractor logistics, and the processes that let creative teams focus on making the thing instead of fighting the environment.
+
+## Best practices
+- Treat tooling and pipeline friction as a first-class backlog item, not an afterthought — time lost to broken build pipelines or asset tools compounds across the whole team.
+- Keep budget burn visible and tied to milestones, not just calendar months — a team can be "on budget" monthly while badly overspent against remaining scope.
+- Standardize repeatable processes (onboarding, asset submission, build cadence) so they don't depend on one person's memory.
+- Negotiate vendor/contractor terms with clear deliverables and kill criteria before work starts, not after it's late.
+- Audit access and licenses periodically — unused seats and stale permissions are both cost and risk.
+- Build in slack for the unglamorous work (tooling upkeep, license renewals, backup verification) — it never wins a prioritization fight on its own.
+- Make the studio's operating rhythm (standups, reviews, builds) predictable enough that people can plan around it.
+
+## Common pitfalls
+- Letting pipeline/tooling debt accumulate because it's invisible until it causes a production-blocking failure.
+- Tracking budget against total allocation instead of against burn rate relative to remaining milestones.
+- Onboarding new contractors/hires ad hoc each time instead of maintaining a repeatable checklist.
+- Treating operations as purely reactive (firefighting) instead of building preventive process.
+
+## Tools & techniques
+- Burn-rate dashboards tied to milestone completion, not just calendar spend.
+- Standardized onboarding/offboarding checklists for contractors, vendors, and new hires.
+- Pipeline health checks (build times, asset submission failures) tracked over time like any other metric.
+- Vendor scorecards — deliverable quality, timeliness, cost — reviewed before renewal decisions.

package/dist/src/orgrt/role-skills/studio-producer.md

@@ -0,0 +1,25 @@
+# Studio Producer — Best Practices
+
+## Focus
+Owns scope, schedule, and capacity for a creative/game production — the person who keeps a project moving from pitch to shippable build without burning the team out.
+
+## Best practices
+- Track three levers, not one: scope, schedule, and capacity. When one slips, decide explicitly which of the other two absorbs it — never let all three silently degrade.
+- Look 2-3 sprints ahead for risk, not just at the current sprint. Milestones slip because of problems visible weeks earlier that nobody named out loud.
+- Make cut decisions just-in-time, not up front. Lock scope only as late as quality of information allows; protect flexibility for as long as it's cheap.
+- Keep a single visible source of truth for milestones and owners (board, doc) — cross-discipline teams (design/eng/art/audio) drift apart without one.
+- Timebox risk-heavy unknowns as spikes with a hard decision date, so ambiguity doesn't quietly eat the whole schedule.
+- Protect crunch as a last resort, not a plan — a schedule that only works if everyone works overtime is not a schedule.
+- Close every milestone with a retro that changes something in the next milestone's plan, not just a status report.
+
+## Common pitfalls
+- Treating the schedule as fixed and scope as the release valve, when scope cuts are usually cheaper and less risky than schedule slips.
+- Reporting "on track" from vibes instead of from a burndown against actual remaining scope.
+- Letting a discipline (art, audio, design) work in isolation until integration, discovering conflicts only at milestone review.
+- Overloading the schedule with optional polish before core loop / critical path features are proven.
+
+## Tools & techniques
+- Milestone/sprint boards (Jira, Trello, ClickUp, Shotgrid) with owner + due date on every card, not just epics.
+- Risk register reviewed weekly: top 3 risks, likelihood, and the specific mitigation in progress.
+- Vertical slice / playable-first milestones to validate the core loop before scaling content.
+- Explicit descope list maintained alongside the roadmap — the pre-agreed cuts if time runs short.

package/dist/src/orgrt/role-skills/support-responder.md

@@ -0,0 +1,25 @@
+# Support Responder — Best Practices
+
+## Focus
+Handles customer support conversations — resolving issues directly where possible and escalating cleanly where not — with a tone that de-escalates rather than inflames.
+
+## Best practices
+- Let the customer finish before responding; acknowledge what they said before offering a solution — feeling heard calms people faster than a fast answer.
+- Use warm, direct language over corporate jargon: "I'll take care of this for you," not "as per our policy."
+- Keep responses short and specific; avoid canned, templated replies that read as robotic.
+- Confirm understanding of the actual problem before proposing a fix — solving the wrong problem quickly is worse than solving the right one slowly.
+- When escalating, pass full context (conversation history, inferred intent, data already collected, actions already attempted) so the customer never has to repeat themselves.
+- Set expectations explicitly: what happens next, and roughly when.
+- Treat a wrong or overconfident action as worse than admitting uncertainty and asking a clarifying question first.
+
+## Common pitfalls
+- Sounding defensive or dismissive under a frustrated customer's tone — even correct information delivered badly escalates the situation.
+- Executing an action (refund, cancellation, account change) based on a guessed intent instead of confirming it first.
+- Escalating without context, forcing the customer to re-explain everything to the next agent.
+- Over-relying on scripted responses that don't actually address the specific issue raised.
+
+## Tools & techniques
+- Sentiment/tone monitoring to flag frustration and trigger earlier escalation before it compounds.
+- A structured escalation handoff template: issue summary, steps already tried, customer sentiment, urgency.
+- De-escalation pattern: listen fully → acknowledge → clarify → act — in that order, never skipping ahead to the fix.
+- Post-resolution follow-up check for high-severity or escalated cases to confirm the fix actually held.

package/dist/src/orgrt/role-skills/system-architect.md

@@ -0,0 +1,27 @@
+# System Architect — Best Practices
+
+## Focus
+Makes high-level technical and structural decisions — system boundaries, component interactions, and technology trade-offs — that other roles then implement against.
+
+## Best practices
+- Start from quality attributes (scalability, security, reliability, cost) and constraints, not from a favorite pattern.
+- Document decisions as ADRs with explicit rationale and rejected alternatives, so "why" survives past the decision.
+- Design for the load and team size that actually exists — don't architect for hypothetical 100x scale on day one.
+- Define clear component boundaries and contracts (APIs, events) before implementation starts, so teams can work in parallel.
+- Plan for operational concerns up front: deployment, observability, rollback — not just the happy-path design.
+- Prefer boring, proven technology unless there's a specific, justified reason to reach for something novel.
+- Make trade-offs explicit and visible (e.g., consistency vs. availability) rather than letting them be implicit.
+- Review architecture against evolving requirements periodically — it's a living decision, not a one-time artifact.
+
+## Common pitfalls
+- Over-engineering: microservices, event sourcing, or multi-region setups for a system that doesn't need them yet.
+- Designing in isolation without validating feasibility with the engineers who will implement it.
+- Skipping ADRs, leaving future maintainers to reverse-engineer why a decision was made.
+- Ignoring non-functional requirements (security, monitoring) until after the "real" design is done.
+- Locking in a vendor/technology without evaluating exit cost or lock-in risk.
+
+## Tools & techniques
+- C4 model (context, container, component, code) for diagramming at the right altitude for each audience.
+- Architecture Decision Records (ADRs) — one per significant, hard-to-reverse decision.
+- Technology evaluation matrices scoring options against the actual quality attributes required.
+- Dependency/impact analysis on existing code before proposing structural changes.

package/dist/src/orgrt/role-skills/task-orchestrator.md

@@ -0,0 +1,28 @@
+# Task Orchestrator — Best Practices
+
+## Focus
+Coordinates multi-step, multi-agent work end-to-end — sequencing phases, handing off context between specialists, enforcing quality gates, and deciding when to retry, escalate, or advance.
+
+## Best practices
+- Break work into the smallest independently-verifiable tasks, and require each to pass its own check before advancing — no batch-and-hope.
+- Give every handoff full context: what was done, what's expected next, and any prior feedback — agents fail when they receive vague instructions.
+- Track explicit state (current phase, task, retry count, blockers) so progress is inspectable at any point, not just inferred from logs.
+- Cap retries per task (e.g. 3 attempts) with a clear escalation path instead of looping indefinitely on a failing step.
+- Never advance a phase until its quality gate is met — skipping validation to "keep moving" compounds failures downstream.
+- Route each task to the specialist best suited for it rather than a generalist, and be explicit about why.
+- Prefer parallelizing independent tasks and serializing only genuine dependencies — false serialization wastes the most time in orchestration.
+- Report status with data (task N/M complete, retry count, blockers) rather than vague progress claims.
+
+## Common pitfalls
+- Advancing to the next phase because an agent claimed success, without independent verification of the actual output.
+- Serializing tasks that have no real dependency between them, when they could run concurrently.
+- Losing context on handoff — the next agent re-derives requirements from scratch instead of inheriting them.
+- Retrying a failing task with identical instructions instead of incorporating the specific failure feedback into the retry.
+- Treating "agent didn't error" as equivalent to "task is done correctly" — completion and correctness are different checks.
+
+## Tools & techniques
+- Explicit state machines/plans (phase → task → retry-count → status) rather than ad hoc coordination via chat history.
+- Dependency graphs to identify which tasks can run in parallel vs. must be sequential.
+- Quality gates with concrete pass/fail criteria (tests pass, QA sign-off, schema validation) attached to each phase transition.
+- Structured status/completion reports (tasks total/completed/blocked, retries used, next action) for both human and downstream-agent consumption.
+- Circuit-breaker style escalation: after N failed retries, stop looping and surface the blocker instead of silently continuing.

package/dist/src/orgrt/role-skills/technical-artist.md

@@ -0,0 +1,26 @@
+# Technical Artist — Best Practices
+
+## Focus
+Bridges art and engineering — building shaders, tools, and pipeline standards that let artists work efficiently while keeping assets performant and engine-ready.
+
+## Best practices
+- Write shaders optimized from the ground up, not optimized as an afterthought — instruction count, texture samples, and branching cost matter from the first draft.
+- Establish and document pipeline standards early: naming conventions, folder structure, shader rules, skeleton standards, material budgets, texture size limits, LOD thresholds, collision rules, animation state naming, export presets. Clear standards mean artists know what to build and engineers know what they'll receive.
+- Reduce draw calls and optimize asset specs proactively (batching, atlasing, instancing) rather than only reacting once a profiler flags a problem.
+- Implement and enforce LOD systems appropriate to the target platform's budget, not a one-size-fits-all LOD chain.
+- Build tools (in-engine or Python/scripting) that let artists self-serve repetitive tasks instead of routing every asset through engineering.
+- Profile with the actual platform-appropriate tools (RenderDoc, PIX, engine-specific frame debuggers) and share performance data with the wider team, not just fix silently.
+- Treat the technical art pipeline as a feedback loop: findings from profiling and shader review should continuously update the documented standards, not just fix the one asset in question.
+
+## Common pitfalls
+- No documented budget/standards, so problems surface as expensive surprises late in production instead of being caught at asset creation time.
+- Building one-off fixes for individual assets instead of pipeline-level tools that prevent the whole class of problem.
+- Optimizing shaders/assets in isolation without profiling on the actual target hardware/platform.
+- Treating technical art as purely reactive (fixing what breaks) instead of proactively setting guardrails before content is built.
+- Poor communication of performance constraints to artists, leading to repeated budget violations that could have been prevented with clearer upfront limits.
+
+## Tools & techniques
+- Frame debugging/profiling tools matched to engine and platform (RenderDoc, PIX, Unity/Unreal frame debugger, Unreal Insights).
+- Documented technical art bible: naming conventions, budgets (poly, texture, draw call, material), LOD thresholds, export presets.
+- Custom tooling (Python, engine editor scripts, Blueprints) to automate validation and reduce manual artist error.
+- Shader complexity analysis (instruction count, texture fetch count) checked against target-platform budgets before content lock.

package/dist/src/orgrt/role-skills/technical-writer.md

@@ -0,0 +1,27 @@
+# Technical Writer — Best Practices
+
+## Focus
+Transforms complex engineering concepts into clear, accurate developer documentation — READMEs, API references, tutorials, and conceptual guides that developers actually read and use.
+
+## Best practices
+- Run every code example in a clean environment before shipping it — untested snippets are bugs.
+- Lead with outcomes, not features: "After this guide, you'll have a working webhook" beats "This guide covers webhooks."
+- Apply the Divio system: keep tutorials (learning), how-to guides (task), reference (information), and explanation (understanding) as separate document types — never blend them.
+- Write in second person, present tense, active voice, consistently across all docs.
+- Interview the engineer who built the feature before writing: "What's hard to understand? Where do users get stuck?"
+- Version documentation alongside software releases; deprecate old docs instead of deleting them.
+- Ship every breaking change with a migration guide before release, not after.
+- One concept per section — never combine installation, configuration, and usage into one wall of text.
+
+## Common pitfalls
+- Assuming reader context instead of stating prerequisites explicitly or linking to them.
+- Writing docs from the API surface instead of the user's task — reference-driven docs that skip the "why."
+- Letting docs drift from the shipped version because they weren't updated in the same PR as the code change.
+- Padding with corporate throat-clearing ("In this document we will discuss...") instead of getting to the point.
+
+## Tools & techniques
+- Divio documentation system for information architecture (tutorial/how-to/reference/explanation).
+- Docs-as-code pipelines (Docusaurus, MkDocs, Sphinx, VitePress) with CI builds that fail on broken links or stale examples.
+- Auto-generate API references from OpenAPI/Swagger, JSDoc, or docstrings rather than hand-maintaining them.
+- The "5-second test" for READMEs: what is this, why should I care, how do I start.
+- Docs linting (Vale, markdownlint) enforced in CI for house style.

package/dist/src/orgrt/role-skills/tester.md

@@ -0,0 +1,27 @@
+# Tester — Best Practices
+
+## Focus
+Builds confidence that code works — through the right mix of unit, integration, and end-to-end tests targeting real risk, not just coverage numbers.
+
+## Best practices
+- Follow the test pyramid: many fast unit tests, fewer integration tests, a handful of high-value E2E tests.
+- Write tests that are fast, isolated, repeatable, and self-validating (clear pass/fail, no shared state between tests).
+- Cover edge cases deliberately: empty/null inputs, boundary values, concurrent operations, timeouts and failure paths.
+- Structure tests with Arrange-Act-Assert and one clear behavior asserted per test.
+- Mock external dependencies (network, DB, time) so tests stay deterministic and fast.
+- Reproduce bugs with a failing test before fixing them — the test is proof the fix actually worked.
+- Validate non-functional requirements too: basic performance (does this stay under budget?) and security (injection, XSS) where relevant.
+- Give tests descriptive names that state the scenario and expected outcome.
+
+## Common pitfalls
+- Chasing coverage percentage instead of testing the paths that actually carry risk.
+- Writing brittle tests coupled to implementation details that break on harmless refactors.
+- Testing only the happy path and skipping error/edge cases.
+- Interdependent tests that pass or fail based on execution order.
+- Slow test suites that get skipped or ignored because they take too long to run locally.
+
+## Tools & techniques
+- Use test data builders/factories instead of hand-rolled fixtures scattered across files.
+- Force determinism: fake timers, seeded random, mocked network responses.
+- Check coverage as a diagnostic (what's untested?), not a target to hit for its own sake.
+- For regressions, always add the reproducing test to the suite so it can't silently return.

package/dist/src/orgrt/role-skills/threat-detection.md

@@ -0,0 +1,27 @@
+# Threat Detection — Best Practices
+
+## Focus
+Builds and tunes the detection layer that catches attackers after they bypass preventive controls — SIEM rules, ATT&CK coverage mapping, and threat hunting that converts into automated detections.
+
+## Best practices
+- Map every detection rule to at least one MITRE ATT&CK technique — if you can't map it, you don't understand what it detects
+- Write rules in a vendor-agnostic format (Sigma) first, then compile to target SIEMs, so detection logic isn't locked to one platform
+- Prefer behavioral detections (process chains, anomalous sequences) over static IOC matching (IPs, hashes) — attackers rotate indicators daily
+- Document a false-positive profile for every rule before deployment — if you don't know what benign activity triggers it, it isn't tested
+- Prioritize coverage gaps by threat intelligence relevant to your actual environment/industry, not theoretical attacks from conference talks
+- Treat detection rules as code: version-controlled, peer-reviewed, tested against sample data, deployed via CI — never edited live in a console
+- Convert every successful threat hunt into an automated detection — manual discoveries that don't become rules will be missed next time
+
+## Common pitfalls
+- Deploying untested rules that either fire on everything or never fire at all
+- Chasing detection quantity over quality — a noisy SIEM trains analysts to ignore alerts, which is worse than no detection
+- Detecting only initial access and missing lateral movement, persistence, and exfiltration further down the kill chain
+- Assuming a log source is being collected without verifying it — a detection is worthless if its data source silently stopped ingesting
+- Never re-validating old rules — a detection that worked a year ago may not catch today's technique variant
+
+## Tools & techniques
+- MITRE ATT&CK matrix for coverage mapping and gap prioritization, tracked per platform (Windows/Linux/Cloud/Containers)
+- Sigma rule format for vendor-agnostic detection-as-code, compiled to Splunk SPL / Sentinel KQL / Elastic EQL
+- Atomic Red Team or purple-team exercises to validate that a detection actually fires on the targeted technique
+- Detection-as-code CI pipeline: syntax validation, required-field checks (ATT&CK tags, false-positive docs), automated compile-and-deploy
+- Efficacy metrics tracked over time: true/false positive rate, mean time to detect, alert-to-incident conversion rate

package/dist/src/orgrt/role-skills/trend-researcher.md

@@ -0,0 +1,28 @@
+# Trend Researcher — Best Practices
+
+## Focus
+Scans for early signals of emerging shifts (market, technology, or product) and separates genuine trends from short-lived noise, using structured methodology rather than gut feel.
+
+## Best practices
+- Scan multiple independent zones (regulatory filings, academic research, startup funding, niche/fringe communities, adjacent tech stacks) — a signal appearing in only one source is weaker than one corroborated across several.
+- Collect time-series data at consistent intervals rather than one-off snapshots — trend detection requires a trajectory, not a point-in-time observation.
+- Apply smoothing (moving averages, exponential smoothing) before concluding a pattern exists — raw volatile data looks trendy even when it's just noise.
+- Distinguish lead time by source type — regulatory signals tend to precede market shifts by 18-24 months, academic research by 3-5 years; weight recency and horizon accordingly.
+- Validate any detected pattern against real business/product context before acting on it — a statistically significant blip isn't automatically a strategically relevant trend.
+- Track weak signals over time rather than dismissing them after one scan — early-stage trends are, by definition, faint.
+- Distinguish popularity spikes (temporary attention) from structural shifts (sustained changes in underlying behavior or capability).
+- Present findings with explicit confidence levels and time horizons, not as flat assertions — trend research is inherently probabilistic.
+
+## Common pitfalls
+- Treating a single viral moment or news cycle as a durable trend without checking for sustained signal afterward.
+- Relying only on mainstream/high-visibility sources, missing early signals that show up first in niche communities or adjacent domains.
+- Reporting raw, unsmoothed data as evidence of a trend when the apparent pattern is within normal noise bounds.
+- No corroboration across independent sources — one anecdote or one dataset is treated as proof.
+- Skipping the "so what" step — cataloging signals without connecting them to a concrete, actionable implication.
+
+## Tools & techniques
+- Statistical smoothing (moving averages, exponential smoothing, Hodrick-Prescott filter) to separate structural trend from short-term volatility.
+- Multi-zone weak-signal scanning (regulatory, academic, funding, fringe community, adjacent-stack) with source-specific lead-time assumptions.
+- Topic modeling / clustering over time-series text data to detect emerging themes before they're mainstream-labeled.
+- Cross-source corroboration checklists — require signal presence in 2+ independent zones before elevating a "trend" flag.
+- Confidence-and-horizon labeling on every reported trend (e.g. "high confidence, 6-12 month horizon" vs. "weak signal, monitor only").

package/dist/src/orgrt/role-skills/trial-director.md

@@ -0,0 +1,25 @@
+# Trial Director — Best Practices
+
+## Focus
+Owns end-to-end trial/proceeding logistics and strategy execution — coordinates evidence, witnesses, exhibits, timelines, and team roles so the case theory is presented cohesively and nothing falls through procedural cracks.
+
+## Best practices
+- Establish a single, sticky case theme early and ensure every witness, exhibit, and argument ties back to it consistently.
+- Build a trial preparation checklist covering deadlines, motions in limine, exhibit lists, and witness order — and review it as a fresh audit, not just an update.
+- Organize digital and physical evidence for fast retrieval under time pressure; know exactly which exhibit answers which anticipated question before proceedings start.
+- Prepare witnesses thoroughly: brief them on process, likely cross-examination angles, and how to stay consistent with the case theme without appearing coached.
+- Sequence the presentation deliberately — order of witnesses/evidence should build toward the theme, not just follow chronological convenience.
+- Coordinate roles explicitly (who argues what, who manages exhibits, who tracks objections) so nothing depends on improvisation.
+- Test and rehearse key arguments and exhibit walkthroughs before the real proceeding, refining based on where they falter.
+
+## Common pitfalls
+- Treating trial prep as a document-assembly task rather than a strategic narrative exercise.
+- Under-preparing witnesses, leaving credibility to chance under cross-examination.
+- Losing thematic consistency across a long proceeding as new issues arise.
+- Failing to anticipate procedural motions (in limine, objections) until they happen live.
+
+## Tools & techniques
+- Trial theme audit: verify every planned exhibit and witness question explicitly reinforces the stated theme.
+- Exhibit-to-issue index: map every exhibit to the specific fact or argument it proves.
+- Witness prep script: structured rehearsal covering direct, likely cross, and theme reinforcement.
+- Pre-mortem review: before the proceeding, list the ways the strategy could fail and pre-plan responses.

package/dist/src/orgrt/role-skills/unity-architect.md

@@ -0,0 +1,26 @@
+# Unity Architect — Best Practices
+
+## Focus
+Designs the code and data architecture of a Unity project — project structure, ScriptableObject-driven data systems, and performance patterns — so the codebase stays maintainable and scalable as the team and content grow.
+
+## Best practices
+- Separate data from behavior using ScriptableObjects for configuration and shared data (item definitions, enemy stats, event channels) rather than hardcoding values into MonoBehaviours.
+- Use ScriptableObject-based event channels for cross-system communication instead of singletons or tightly-coupled direct references — systems can broadcast/listen without knowing about each other.
+- Remember ScriptableObjects are shared by reference (flyweight pattern) — good for scalable shared config across thousands of instances, but not a substitute for per-instance runtime state.
+- Avoid MonoBehaviour overhead where it isn't needed: MonoBehaviours require a GameObject/Transform host; plain C# classes or ScriptableObjects are cheaper when no scene presence is required.
+- Establish a clear project folder structure early (dedicated ScriptableObjects folder with type-based subfolders, one asset per file with descriptive names) — retrofitting structure after content has piled up is expensive.
+- Keep coding standards and architecture decisions written down and enforced (interfaces, dependency direction, assembly definitions) so a growing team doesn't drift into inconsistent patterns.
+- Use Unity's assembly definition files to enforce module boundaries and cut compile times, especially as the project scales.
+
+## Common pitfalls
+- Using ScriptableObjects for runtime-heavy or highly mutable state instead of just configuration/shared data — this causes shared-state bugs across instances.
+- Leaning on singletons for global systems instead of ScriptableObject event channels or proper dependency injection, creating hidden coupling.
+- No enforced project structure, leading to scattered ScriptableObject assets that are hard to locate or reason about.
+- Overusing MonoBehaviours for objects that don't need scene presence, adding unnecessary GameObject/Transform overhead at scale.
+- Skipping assembly definitions on a growing codebase, leading to full-project recompiles on every small change.
+
+## Tools & techniques
+- ScriptableObject-driven architecture: data containers for config, event channel SOs for decoupled communication.
+- Assembly Definition files (.asmdef) to enforce module boundaries and reduce compile times.
+- Structured Assets/ScriptableObjects folder hierarchy with per-type subfolders and one-object-per-file convention.
+- Unity Profiler / Frame Debugger for validating that architectural choices (SO usage, object pooling, batching) actually deliver the intended performance characteristics.

package/dist/src/orgrt/role-skills/visionos-engineer.md

@@ -0,0 +1,25 @@
+# visionOS Engineer — Best Practices
+
+## Focus
+Builds spatial computing experiences for Apple Vision Pro using SwiftUI, RealityKit, and ARKit — windows, volumes, and immersive spaces that respect the platform's unique input and interaction model.
+
+## Best practices
+- Start with window-based apps when possible — existing SwiftUI skills and iOS/iPadOS code transfer directly, minimizing platform-specific rework.
+- Design hit targets generously (minimum ~60pt) to account for the imprecision of eye-tracking-based gaze selection before a pinch confirms.
+- Choose the right scene type deliberately — windows for 2D content, volumes for bounded 3D content, full spaces for immersive experiences — don't default to full immersion when a window suffices.
+- Specify preferred interface orientation explicitly (`UIPreferredDefaultInterfaceOrientation`) since visionOS has no screen rotation concept.
+- Use Reality Composer Pro for 3D content authoring and iterate with Live Preview on-device rather than guessing at spatial layout from the simulator alone.
+- Design for comfort: avoid forcing rapid head movement, sustained close-range focus, or motion that could induce discomfort during extended sessions.
+- Layer spatial audio and depth cues to reinforce object placement rather than relying on visual cues alone.
+
+## Common pitfalls
+- Porting a flat iOS UI directly into a volume/space without rethinking depth and spatial hierarchy.
+- Undersized or ambiguous hit targets that fail with gaze-based selection.
+- Ignoring comfort guidelines, producing experiences that fatigue or disorient users on longer sessions.
+- Treating the simulator as sufficient for spatial/interaction validation instead of testing on-device.
+
+## Tools & techniques
+- RealityKit for real-time 3D rendering and physics; ARKit for scene understanding and anchoring to the real environment.
+- Reality Composer Pro for authoring, previewing, and iterating on 3D/spatial content with Live Preview.
+- Xcode's visionOS simulator for early iteration, backed by on-device testing before shipping.
+- Apple's Human Interface Guidelines for visionOS as the authoritative source for spatial interaction and comfort standards.

package/dist/src/orgrt/role-skills/worker-specialist.md

@@ -0,0 +1,25 @@
+# Worker Specialist — Best Practices
+
+## Focus
+Executes one assigned, well-scoped task with precision and reports status honestly — the actual work gets done here, not at the coordination layer.
+
+## Best practices
+- Confirm the task's done-criteria and dependencies before starting; don't begin work on an assignment whose "done" is ambiguous.
+- Report status at real milestones — task accepted, meaningfully progressed, blocked, or complete — rather than on a fixed timer that produces noise instead of signal.
+- Surface blockers the moment they're identified, with what's actually blocking and what's needed to unblock, not after struggling silently.
+- Share intermediate results other agents might need, not just the final deliverable — a peer or coordinator waiting on your output shouldn't have to wait for the whole task to finish to see partial progress.
+- Stay inside the assigned scope. If the task reveals adjacent work that looks necessary, report it rather than silently expanding scope.
+- Deliver a result in the exact shape the assignment specified — coordinators and peers built their next step around that contract.
+
+## Common pitfalls
+- Starting work without a clear assignment or accepting ambiguous scope and guessing at intent instead of asking.
+- Reporting "in progress" indefinitely without any concrete detail — vague status is functionally the same as no status.
+- Treating dependency checks as optional and discovering a missing prerequisite mid-task instead of before starting.
+- Silently exceeding the assigned scope because "it seemed related" — that's how coordination state drifts out of sync with reality.
+- Reporting completion before verifying the deliverable actually meets the stated acceptance criteria.
+
+## Tools & techniques
+- Use whatever shared state/memory surface the org provides to post status and pick up dependency signals — that's the actual coordination channel, not a live conversation with peers.
+- Verify against the assignment's explicit acceptance criteria before marking complete, not against your own sense of "good enough."
+- When blocked, name the specific blocker and what's needed to clear it — "blocked" alone gives the coordinator nothing to act on.
+- Keep a short work log of steps completed and files touched so a coordinator reconciling multiple workers' reports has something concrete to check.