@monoes/monomindcli 2.10.5 → 2.10.7

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

@@ -0,0 +1,27 @@
+# Data Engineer — Best Practices
+
+## Focus
+Builds reliable, observable data pipelines and platform infrastructure that turn raw, messy data into trusted, analytics-ready assets.
+
+## Best practices
+- Make every pipeline idempotent — rerunning it must never duplicate or corrupt data.
+- Enforce explicit schema contracts between producers and consumers; schema drift should alert loudly, never silently corrupt downstream data.
+- Follow a layered model (raw/bronze → cleansed/silver → business-ready/gold): never let consumers read directly from raw layers.
+- Handle nulls and malformed records deliberately (impute, flag, or reject) — never let them propagate implicitly into business-facing tables.
+- Prefer incremental/CDC processing over full-table refreshes to control cost and latency.
+- Attach audit columns (`created_at`, `updated_at`, `deleted_at`, `source_system`) and prefer soft deletes for traceability.
+- Set and monitor freshness/completeness SLAs per pipeline, with alerting on breach — not just on hard failure.
+- Document data lineage so any row's provenance can be traced back to its source system.
+
+## Common pitfalls
+- Silent data quality failures that only surface once a downstream report or model looks wrong.
+- Full-table scans/refreshes that work fine in dev and become a cost or latency disaster at scale.
+- Transforming data in place at the raw layer, destroying the ability to reprocess from source.
+- Treating schema changes as someone else's problem instead of validating and gating them explicitly.
+- Under-documenting pipeline ownership, so failures have no clear owner or runbook.
+
+## Tools & techniques
+- Data contract tooling (e.g., dbt contracts, Great Expectations) enforced in CI, not just checked manually.
+- Window-function based deduplication keyed on primary key + event timestamp for the silver layer.
+- Partitioning/clustering (date partitions, Z-ordering) tuned to actual downstream query patterns.
+- Pipeline observability with freshness, row-count, and schema-drift alerts wired to an on-call channel.

package/dist/src/orgrt/role-skills/database-optimizer.md

@@ -0,0 +1,25 @@
+# Database Optimizer — Best Practices
+
+## Focus
+Optimizes schema design, queries, and indexing for relational databases (PostgreSQL, MySQL, Supabase, PlanetScale) so systems perform under load and don't page anyone at 3am.
+
+## Best practices
+- Run EXPLAIN ANALYZE before deploying any non-trivial query — check actual time vs. planned time and rows vs. estimated rows, not just "it returned results."
+- Index every foreign key used in joins — unindexed joins are the single most common cause of unexpected sequential scans.
+- Avoid `SELECT *` — fetch only the columns a query actually needs to reduce I/O and network payload.
+- Prevent N+1 queries by using JOINs or batched loading instead of looping queries per row in application code.
+- Use connection pooling (PgBouncer, transaction-mode poolers) — never open a raw connection per request, especially in serverless contexts.
+- Write migrations that are reversible and non-locking — use `CREATE INDEX CONCURRENTLY`, add columns with defaults that don't rewrite the table.
+- Choose normalization vs. denormalization deliberately per access pattern, not dogmatically — document the trade-off made.
+
+## Common pitfalls
+- Adding indexes reactively after a production slowdown instead of reviewing query plans during development.
+- Locking tables in production migrations by using blocking `CREATE INDEX` or full-table rewrites.
+- Trusting an ORM's default query generation without checking for hidden N+1 patterns.
+- Over-normalizing a schema for theoretical purity when the actual access pattern demands a denormalized read path.
+
+## Tools & techniques
+- `EXPLAIN ANALYZE` read as standard practice: look for Seq Scan (red flag), Index Scan / Bitmap Heap Scan (expected).
+- `pg_stat_statements` or platform-equivalent slow-query logs monitored continuously, not just during incidents.
+- Partial and composite indexes for common filter+sort patterns rather than one broad index per column.
+- Connection pooler configuration (pool size, mode) tuned against actual concurrent connection counts.

package/dist/src/orgrt/role-skills/deal-strategist.md

@@ -0,0 +1,26 @@
+# Deal Strategist — Best Practices
+
+## Focus
+Structures, prices, and shepherds complex, high-value deals through internal approval and negotiation — acting as the cross-functional point of contact between sales, legal, finance, and operations.
+
+## Best practices
+- Build working knowledge of how sales, finance, legal, and operations each affect deal structure — a deal desk that only understands sales terms will misprice risk.
+- Maintain a documented playbook of deal-structuring guidelines (discount bands, payment terms, contract length tradeoffs) aligned to company strategic goals, not ad hoc precedent.
+- Get involved early on high-value or non-standard deals — retrofitting structure after terms are already promised to the customer is far costlier.
+- Know product value and competitive positioning cold; pricing decisions should reflect what the deal is actually worth to the customer, not just list-price anchoring.
+- Keep discounting and approvals consistent across similar deals — inconsistency erodes both margin and sales credibility.
+- Model the full economics of a deal (multi-year value, services cost, churn risk) before approving concessions, not just the headline ACV.
+- Pre-negotiate fallback positions (what you'll trade for what) before the customer call, so concessions aren't improvised live.
+- Close the loop after signature or loss — log what terms moved, why, and whether the deal structure held up post-close.
+
+## Common pitfalls
+- Approving one-off exceptions without documenting them, which quietly resets the baseline for the next negotiation.
+- Optimizing for closing the deal fast at the expense of terms that create downstream delivery, renewal, or margin problems.
+- Treating legal/finance as a rubber stamp instead of looping them in early enough to shape the deal, causing late-stage renegotiation.
+- Losing sight of the total contract value (services, expansion potential, renewal risk) by fixating on the headline discount.
+
+## Tools & techniques
+- Deal desk playbook with pre-approved discount/term matrices tied to deal size and strategic priority.
+- Approval routing with clear thresholds and escalation paths so deals don't stall waiting on ambiguous sign-off.
+- Win/loss and margin-impact review on every closed deal above a size threshold.
+- Standard fallback/concession matrix ("if they ask for X, offer Y") prepared before negotiation calls.

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

@@ -0,0 +1,25 @@
+# Defender — Best Practices
+
+## Focus
+Provides zealous advocacy for the opposing party within ethical bounds — the defender's job is to test the prosecution's case rigorously and ensure every weakness, gap, and alternative explanation is surfaced, not to assume the accusation is true.
+
+## Best practices
+- Never accept the opposing narrative at face value — independently reconstruct the facts and look for what doesn't fit.
+- Attack the case at its weakest evidentiary links: chain of custody, witness credibility, procedural errors, and gaps between evidence and required elements.
+- Develop alternative explanations for the evidence, not just objections to it — juries and judges respond to competing stories, not just doubt.
+- Hold the other side strictly to its actual burden — do not let unproven assumptions get treated as established fact.
+- Prepare witnesses and evidence meticulously; credibility under cross-examination is often decisive.
+- Stay within ethical bounds: zealous advocacy never extends to presenting evidence known to be false or misleading the tribunal.
+- Build a coherent trial theme early and repeat it consistently — juries retain themes, not isolated objections.
+
+## Common pitfalls
+- Being reflexively obstructive rather than substantively rigorous — objecting without building a case.
+- Overlooking procedural defenses (standing, admissibility, timeliness) in favor of only merits-based arguments.
+- Failing to prepare an affirmative narrative and relying solely on poking holes in the opposing case.
+- Conflating "zealous" with "aggressive" — losing credibility with the decision-maker through overreach.
+
+## Tools & techniques
+- Evidence gap analysis: mirror the prosecution's element-by-element case and mark every element with weak, missing, or contested support.
+- Alternative-theory drafting: generate at least one plausible innocent/non-liable explanation for each major piece of evidence.
+- Procedural checklist: verify chain of custody, disclosure timeliness, and admissibility before accepting evidence as usable.
+- Theme consistency check: ensure every argument and cross-examination point ties back to a single core defense theory.

package/dist/src/orgrt/role-skills/devops-automator.md

@@ -0,0 +1,25 @@
+# DevOps Automator — Best Practices
+
+## Focus
+Eliminate manual infrastructure and deployment work through automation — Infrastructure as Code, CI/CD pipelines, container orchestration, and monitoring that catches problems before users do.
+
+## Best practices
+- Manage all infrastructure through code (Terraform/CloudFormation/CDK) with version control and review — no manual console changes that drift from the source of truth.
+- Design deployments to be zero-downtime by default (blue-green, canary, or rolling) with automated health checks gating traffic shift.
+- Build monitoring and alerting alongside the infrastructure, not after an incident reveals it was missing — cover the golden signals (latency, traffic, errors, saturation).
+- Automate secrets management and rotation; never let a credential live only in a human's memory or a Slack message.
+- Right-size resources with data (actual utilization) rather than guesswork, and revisit sizing as load patterns change.
+- Bake security scanning (dependency, container, static analysis) into the pipeline as a blocking gate for critical findings.
+- Automate disaster recovery and backups, and actually test restoring from them — an untested backup is not a backup.
+
+## Common pitfalls
+- Infrastructure changes made by hand "just this once" that never get reflected back into the IaC source, causing drift.
+- Deploying without a rollback mechanism ready, discovered only during an incident.
+- Alerting on everything, which trains engineers to ignore pages — tune to actionable signals only.
+- Optimizing for automation coverage over actual reliability outcomes (uptime, MTTR) — automation is a means, not the goal.
+
+## Tools & techniques
+- Terraform/CloudFormation/CDK for infrastructure as code with plan/apply review gates.
+- Kubernetes/ECS with health checks, autoscaling, and rolling/blue-green deploy strategies.
+- Prometheus/Grafana or equivalent for metrics, with alert rules tied to the golden signals, not raw resource thresholds alone.
+- Automated vulnerability scanning integrated into the build (containers and dependencies) as a merge/deploy gate.

package/dist/src/orgrt/role-skills/discovery-coach.md

@@ -0,0 +1,26 @@
+# Discovery Coach — Best Practices
+
+## Focus
+Sharpens how reps run discovery calls — the questions they ask, the depth they go to, and the qualification rigor — since discovery quality predicts win rate more than almost any other sales skill.
+
+## Best practices
+- Push reps toward the proven question arc: Situation → Problem → Implication → Vision/Need-payoff (SPIN), rather than jumping straight to pitching a solution.
+- Target roughly an 80/20 open-to-closed question ratio, and coach toward 11-14 substantive questions per call rather than a rushed five-minute checklist.
+- Emphasize implication questions specifically — top performers ask far more of these than average reps, and they correlate strongly with win rate and deal size.
+- Require real pre-call preparation; asking questions whose answers are obvious from public info signals no homework and erodes buyer trust immediately.
+- Coach toward listening, not talking — buyers consistently rank "listen to my needs" as their top ask, and talk-ratio is one of the most fixable, highest-leverage metrics.
+- Anchor every discovery call to a qualification framework (MEDDIC or BANT) so reps leave with Metrics, Economic Buyer, Decision Criteria/Process — not just vague interest.
+- Review calls with structured scorecards mapped to the chosen methodology, not gut-feel impressions.
+- Reinforce that the goal of discovery is diagnosis, not qualification theater — the rep should be able to state the customer's problem back better than the customer can.
+
+## Common pitfalls
+- Reps pitching too early, before the customer's actual pain, priority, and buying process are understood.
+- Surface-level situation questions without ever pushing into implication/impact — leaves the business case fuzzy for the customer.
+- Skipping economic-buyer and decision-process questions, leading to deals that stall in "no decision" because the real buyer was never engaged.
+- Treating discovery as a one-time call instead of an ongoing thread refined throughout the deal cycle.
+
+## Tools & techniques
+- SPIN and MEDDIC/BANT as the two core qualification lenses — pick one as primary and coach consistently against it.
+- Discovery call scorecards scoring question mix (situation/problem/implication/vision), talk ratio, and qualification field completeness.
+- Call recording + transcript review for implication-question frequency, a strong leading indicator of win rate.
+- Standard discovery question bank, refreshed from what's actually working in recent won deals.

package/dist/src/orgrt/role-skills/email-marketing.md

@@ -0,0 +1,27 @@
+# Email Marketing — Best Practices
+
+## Focus
+Designs and writes email sequences — welcome series, nurture, onboarding, re-engagement, and B2B cold outreach — that read as human and drive action without feeling like a sales machine.
+
+## Best practices
+- One email, one job: a single primary CTA per send, no competing asks.
+- Earn the right to sell — lead every sequence with value before the ask.
+- Write "you/your" more than "I/we"; open with the reader's world, not your announcement.
+- Keep subject lines clear over clever, 40-60 characters, no "I hope this finds you well."
+- Match sequence length to intent: welcome (5-7 emails/12-14 days), nurture (5-10), onboarding (5-10 emails to first value), re-engagement (3-5 with a sunset).
+- For cold outreach, anchor on a real trigger or signal (hiring, funding, product change) before making the ask.
+- A/B test subject lines, send times, and CTA variants — don't guess at what resonates.
+- Read every draft aloud; if it sounds like copy, rewrite it.
+
+## Common pitfalls
+- Cramming multiple CTAs into one email, diluting the intended action.
+- Writing generic, un-personalized cold email that reads as mass-blasted.
+- Letting nurture sequences drift into pure promotion with no education or trust-building.
+- Ignoring deliverability hygiene — unsubscribe rate above 0.5% or spam-trigger language — until sender reputation is already damaged.
+- Skipping the sunset step in re-engagement sequences, continuing to email unresponsive contacts indefinitely.
+
+## Tools & techniques
+- Sequence frameworks: Observation→Problem→Proof→Ask and Trigger→Relevance→Value→Ask for cold email.
+- Segmentation by behavioral trigger, not just static list membership.
+- Success benchmarks: 35%+ open rate (warm), 15-25% (cold), 5-10% reply rate (cold), <0.5% unsubscribe per send.
+- Preview text as a second subject line — always write it deliberately, never leave it to auto-pull body text.

package/dist/src/orgrt/role-skills/embedded-firmware.md

@@ -0,0 +1,25 @@
+# Embedded Firmware — Best Practices
+
+## Focus
+Writes production-grade firmware for resource-constrained embedded systems (ESP32/ESP-IDF, STM32 HAL/LL, Nordic nRF/Zephyr, FreeRTOS) where hardware constraints and undefined behavior carry real consequences.
+
+## Best practices
+- Avoid dynamic allocation in RTOS tasks after init — use static allocation or memory pools; heap fragmentation on constrained devices causes unpredictable failures.
+- Always check return values from HAL/SDK calls (`esp_err_t`, HAL status codes) — a silently ignored error is a silent field failure.
+- Calculate stack sizes, don't guess — verify with `uxTaskGetStackHighWaterMark()` or equivalent under real load, not just at boot.
+- Keep ISRs minimal — defer work to tasks via queues/semaphores; never call blocking APIs from interrupt context.
+- Use `FromISR` API variants inside interrupt handlers, and never poll from an ISR on timing-critical platforms.
+- Pin toolchain and library versions in build config (`platformio.ini`, `west.yml`) — never track `@latest` in anything shipping to production.
+- Test every error path with fault injection, not just the happy path — the failures that matter are the ones nobody exercises in normal testing.
+
+## Common pitfalls
+- Using `malloc`/`new` freely in long-running tasks, causing heap fragmentation that only manifests after hours or days of uptime.
+- Guessing stack sizes instead of measuring high-water marks, leading to intermittent stack overflow crashes.
+- Doing real work inside an ISR (I2C/SPI transactions, logging, heavy computation) instead of deferring to a task.
+- Hardcoding peripheral addresses or pin assignments instead of using devicetree/Kconfig or board-specific config layers.
+
+## Tools & techniques
+- JTAG/SWD debugging and crash-dump analysis (`idf.py coredump-info`, STM32 SWV/ITM trace) for post-mortem root cause.
+- FreeRTOS runtime stats / task trace (SystemView) to catch priority inversion and starvation before they hit production.
+- Logic analyzer / oscilloscope captures to verify timing-critical peripheral transactions against datasheet specs.
+- OTA update paths with rollback (`esp_ota_ops.h`, MCUboot) designed and tested before first field deployment, not after.

package/dist/src/orgrt/role-skills/evidence-collector.md

@@ -0,0 +1,27 @@
+# Evidence Collector — Best Practices
+
+## Focus
+Gathers and verifies visual/factual proof that a claimed implementation actually works — the antidote to "it should work" reports that were never actually checked.
+
+## Best practices
+- Require concrete evidence (screenshots, command output, logs) for every claim of "done" or "working" — a claim without evidence is unverified
+- Default to expecting issues on a first pass — a fresh implementation reporting "zero issues found" is a signal to look harder, not a sign of quality
+- Compare evidence directly against the original specification, quoting exact spec text next to what was actually observed
+- Test interactive/stateful behavior explicitly (does the button actually submit, does the toggle actually persist), not just that the element renders
+- Document what you actually observed, not what you'd expect to see if the implementation were correct — evidence trumps inference
+- Capture evidence across the relevant matrix of conditions (viewport sizes, themes, auth states) rather than a single happy-path snapshot
+- Rate quality honestly on a realistic scale — reserve top marks for evidence that genuinely supports them
+
+## Common pitfalls
+- Accepting a verbal/textual claim of correctness in place of actual evidence because gathering evidence takes more effort
+- Letting "looks reasonable" substitute for "matches the spec" — specification compliance and general polish are different checks
+- Collecting evidence but not actually comparing it against requirements before signing off
+- Being satisfied with a single screenshot when the claim spans multiple states (before/after an interaction, multiple breakpoints)
+- Softening findings to avoid conflict — a diplomatic "mostly working" report that hides a broken feature does more harm than a blunt one
+
+## Tools & techniques
+- Automated screenshot capture across breakpoints and themes (Playwright, browser automation) rather than manual spot-checks
+- Before/after comparison captures for any interactive element (accordions, forms, toggles) to prove state actually changed
+- Side-by-side spec-vs-evidence tables: quoted requirement, observed result, pass/fail
+- Structured test-results artifacts (JSON/log output) retained alongside screenshots so claims are traceable to raw data
+- A minimum-findings heuristic (assume several issues exist on a first pass) to counter the tendency to under-report

package/dist/src/orgrt/role-skills/experiment-tracker.md

@@ -0,0 +1,28 @@
+# Experiment Tracker — Best Practices
+
+## Focus
+Records and organizes every experiment (ML training run, A/B test, feature trial) — parameters, code version, data, environment, and results — so outcomes are reproducible, comparable, and auditable.
+
+## Best practices
+- Log parameters, code version, data version, environment, and metrics together for every run — a metric without its full context is not reproducible.
+- Give every experiment a clear hypothesis and success criterion before it starts, not a post-hoc interpretation of whatever the numbers show.
+- Compare against a control/baseline explicitly — an isolated "the metric went up" claim means nothing without what it's relative to.
+- Pin environment and dependency versions per run so a "reproduce this result" request is actually answerable months later.
+- Track statistical significance and sample size for A/B-style experiments, not just the raw metric delta.
+- Tag and organize runs by project/hypothesis so related experiments can be compared as a group, not just individually.
+- Record negative/failed results with the same rigor as successful ones — knowing what didn't work is as valuable as knowing what did.
+- Close the loop: record the decision made from each experiment (shipped / rejected / needs more data), not just the raw numbers.
+
+## Common pitfalls
+- Logging metrics without the parameters/code/data version that produced them — the run becomes unreproducible the moment code changes.
+- Declaring a winner from an A/B test before reaching statistical significance or minimum sample size.
+- No control group — measuring a change against "how things felt before" instead of a concurrent baseline.
+- Losing track of which experiment config is actually running in production versus which was just an exploratory trial.
+- Discarding failed experiments instead of recording them, causing the same dead end to be re-explored later.
+
+## Tools & techniques
+- Tracking platforms (MLflow, Weights & Biases, or equivalent) that auto-capture params, metrics, code version, and artifacts per run.
+- Model/experiment registries to distinguish "promoted to production" from "exploratory" runs.
+- A/B test statistical frameworks (power analysis for sample size, significance testing before calling a winner) for product experiments.
+- Environment manifests (lockfiles, container images, YAML env specs) versioned alongside each run for reproducibility.
+- Comparison dashboards that plot multiple runs against shared baselines to make relative performance legible at a glance.

package/dist/src/orgrt/role-skills/feedback-synthesizer.md

@@ -0,0 +1,26 @@
+# Feedback Synthesizer — Best Practices
+
+## Focus
+Turns raw, scattered user feedback (interviews, surveys, support tickets, reviews) into actionable themes and recommendations — the bridge between "we collected data" and "here's what to do about it."
+
+## Best practices
+- Separate analysis from synthesis explicitly: analysis breaks data into parts and finds patterns; synthesis combines those patterns into insights and recommendations. Don't skip straight to conclusions.
+- Use thematic analysis for textual/qualitative data: read everything first, code short labels on similar fragments, then group codes into larger themes.
+- For each theme, document what's happening, who it affects, where in the experience it shows up, and attach 1-3 concrete verbatim examples as evidence — themes without evidence aren't trustworthy.
+- Triangulate across sources (interviews + support tickets + survey text + reviews) before treating a theme as real — a pattern that only shows up in one channel is weaker signal.
+- Choose the analysis method and framework before sessions/collection begins, and align the team on it, so synthesis doesn't turn into ad hoc opinion.
+- Quantify theme frequency and severity where possible ("18 of 40 interviews," "top support category") so prioritization discussions have a number to argue with.
+- Deliver synthesis as recommendations tied to themes, not just a list of quotes — the output should answer "so what do we do."
+
+## Common pitfalls
+- Cherry-picking a few vivid quotes that confirm an existing hypothesis instead of coding the full dataset.
+- Conflating loud feedback (frequent complainers) with representative feedback (what most users actually experience).
+- Presenting raw notes or transcripts as "synthesis" — no grouping, no themes, no recommendation.
+- Ignoring the difference between what users say they want and the underlying problem revealed by their behavior/complaint.
+- Losing traceability — a theme with no linked source evidence that can't be re-verified later.
+
+## Tools & techniques
+- Thematic coding: label → group into codes → group codes into themes → attach evidence.
+- Data triangulation across qualitative sources to increase confidence in a theme before acting on it.
+- Frequency/severity tagging per theme to feed directly into prioritization frameworks (e.g., RICE Reach/Impact inputs).
+- Structured synthesis output: theme, affected segment, evidence, recommended action.

package/dist/src/orgrt/role-skills/finance-tracker.md

@@ -0,0 +1,26 @@
+# Finance Tracker — Best Practices
+
+## Focus
+Keeps ongoing visibility into money in and out — expenses, budgets, and core financial KPIs — so decisions are made on current, accurate data rather than stale or informal impressions.
+
+## Best practices
+- Record transactions and expenses in real time (or as close to it as possible) rather than batching reconciliation — delayed entry is the single biggest source of inaccurate financial pictures.
+- Separate expense categories clearly (fixed vs. variable, department, project) so spend trends are analyzable, not just a lump total.
+- Track a small set of core KPIs consistently rather than a sprawling dashboard: profitability (margin, burn), liquidity (cash runway, current ratio), and efficiency (cost per unit of output) at minimum.
+- Reconcile budget-to-actual on a fixed cadence (weekly/monthly) and flag variances early rather than discovering drift at quarter-end.
+- Keep an audit trail on every entry — source document, approver, category — so figures can be traced and trusted, not just totals.
+- Flag anomalies (unexpected spend spikes, missing categorization, duplicate entries) proactively rather than waiting for a periodic review to surface them.
+- Present financial status in terms decision-makers act on — runway remaining, budget variance, trend direction — not raw ledger dumps.
+- Keep personal/unrelated spend and business finances strictly separated to avoid muddying every downstream metric.
+
+## Common pitfalls
+- Batching data entry infrequently, which produces a financial picture that's always weeks stale by the time anyone looks at it.
+- Tracking too many KPIs at once, diluting attention from the few that actually predict trouble (cash runway, margin trend).
+- Reporting totals without variance context — a number alone doesn't tell anyone whether it's good, bad, or expected.
+- Letting miscategorized or duplicate entries accumulate uncorrected, silently corrupting trend analysis over time.
+
+## Tools & techniques
+- Budget-vs-actual variance reports on a fixed cadence, with variance thresholds that trigger explicit flags.
+- Core KPI set: gross/net margin, cash runway, burn rate, cost per unit — tracked as a trend line, not a single snapshot.
+- Categorized expense tracking (fixed/variable, by department/project) to support cohort-style analysis of where spend is concentrated.
+- Anomaly checks (spend spikes, duplicate/missing entries) run automatically before data is reported as final.

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

@@ -0,0 +1,25 @@
+# Frontend Developer — Best Practices
+
+## Focus
+Builds responsive, accessible, and performant web UIs with modern frameworks (React/Vue/Angular/Svelte) — turning designs into production-quality, maintainable interfaces.
+
+## Best practices
+- Build mobile-first, responsive layouts and verify behavior across breakpoints, not just desktop.
+- Bake accessibility in from the start: semantic HTML, ARIA only where semantics fall short, full keyboard navigation, and screen-reader testing — not a post-hoc audit.
+- Optimize for Core Web Vitals (LCP, INP/FID, CLS) as a first-class requirement, not an afterthought — use code splitting, lazy loading, and asset optimization.
+- Keep component architecture composable and typed (TypeScript); avoid prop-drilling and oversized components by extracting reusable pieces early.
+- Manage state deliberately — pick the simplest mechanism that fits (local state, context, or a dedicated store) rather than reaching for global state by default.
+- Write unit/integration tests for components with real user interactions, and cover critical flows end-to-end.
+- Handle loading, empty, and error states explicitly for every data-driven view — don't design only the happy path.
+
+## Common pitfalls
+- Shipping desktop-only layouts and retrofitting responsiveness later.
+- Adding ARIA attributes without verifying actual screen-reader/keyboard behavior.
+- Letting bundle size grow unchecked from unnecessary dependencies or missing code-splitting.
+- Skipping accessibility and cross-browser testing until just before release.
+
+## Tools & techniques
+- Lighthouse / Core Web Vitals audits as part of the review checklist.
+- Virtualization (windowing) for long lists/tables to keep render times low.
+- Automated accessibility testing (axe, etc.) integrated into CI, backed by manual screen-reader spot checks.
+- Component-driven development (isolated component review) to catch visual/interaction regressions before integration.

package/dist/src/orgrt/role-skills/game-audio-engineer.md

@@ -0,0 +1,26 @@
+# Game Audio Engineer — Best Practices
+
+## Focus
+Implements adaptive sound and music systems in-engine — building mixer architecture, middleware projects (Wwise/FMOD), and gameplay-driven audio parameters — not just producing sound assets.
+
+## Best practices
+- Build a tree-structured mixer bus architecture: individual sounds route to category buses, category buses to sub-mixes, sub-mixes to master — this enables hierarchical volume control, consistent effects processing, and efficient CPU usage.
+- Drive adaptive audio from gameplay parameters (intensity, wetness, occlusion, combat state) set by game systems via the middleware's parameter API — keep audio logic inside the middleware, not scattered across gameplay scripts.
+- Design music systems that transition smoothly across tension states (exploration → combat → victory) using vertical layering or horizontal re-sequencing rather than hard cuts.
+- Structure the Wwise/FMOD project (Actor-Mixer hierarchy / event structure, Work Units, naming conventions) so it scales with content growth without becoming unmaintainable — decide this early, not after hundreds of events exist.
+- Choose middleware deliberately: Wwise for AAA-scale data-driven complexity with a steeper learning curve; FMOD for a more approachable timeline-based workflow — match the choice to team size and project scope.
+- Keep sound designers empowered to build interactive behaviors (adaptive mixing, transitions) without needing engineering support for every change, via well-designed parameter-driven systems.
+- Profile audio performance (voice count, CPU/memory budget, streaming) the same rigor as any other real-time system — audio bugs (voice stealing, clipping, missing occlusion) are performance bugs too.
+
+## Common pitfalls
+- Hardcoding audio triggers/logic in gameplay code instead of exposing clean parameters for middleware-side authoring — this couples audio changes to engineering time forever.
+- Letting the middleware project grow unstructured (no naming convention, no Work Unit organization) until sound designers can't find or safely edit events.
+- Hard-cutting music between states instead of designing proper adaptive transitions, breaking immersion at exactly the moments that matter most.
+- No mixer bus hierarchy — flat routing that makes global volume/ducking/sidechain adjustments painful or impossible.
+- Ignoring voice budget/CPU cost until late, causing last-minute audio cuts under performance pressure.
+
+## Tools & techniques
+- Wwise (Actor-Mixer hierarchy, Work Units, RTPCs/parameters) or FMOD Studio (timeline events, parameters, snapshots) as the implementation layer between sound design and gameplay code.
+- Tree-structured mixer bus routing for hierarchical control and consistent DSP application.
+- Parameter-driven adaptive mixing (setParameterByName / RTPC) so game systems push state, not explicit sound triggers.
+- Vertical layering and horizontal re-sequencing techniques for state-based adaptive music.

package/dist/src/orgrt/role-skills/game-designer.md

@@ -0,0 +1,26 @@
+# Game Designer — Best Practices
+
+## Focus
+Designs the core gameplay loop, mechanics, and balancing that make a game engaging — the systemic "why is this fun" layer that everything else (levels, narrative, art) builds on.
+
+## Best practices
+- Nail the core loop before anything else — the repeatable cycle of goal → action → reward → risk. If it isn't solid, no amount of content polish will fix it.
+- Design for the "flow channel": balance challenge against player skill continuously — too easy bores, too hard frustrates. Difficulty should ramp with demonstrated player competence, not a fixed curve.
+- Apply the five pillars of player-centric design: Clarity (players know how to interact), Motivation (players know where to go/why), Response (challenges react meaningfully to player action), Satisfaction (effort is rewarded), Viscerality (moment-to-moment feel).
+- Introduce iterative variation on the core loop (new enemy types, shifting hazards, time pressure) to keep a familiar mechanic engaging rather than repetitive.
+- Treat "game feel" as a first-class design concern — responsive controls, feedback timing, screen shake, and impactful audio are part of the mechanic, not polish added later.
+- Playtest early and often with the core loop in isolation before building content on top of it; use observed player behavior, not just verbal feedback, to judge whether a mechanic works.
+- Design systems, not one-off content — a mechanic should generate many interesting situations, not just support one scripted moment.
+
+## Common pitfalls
+- Building content (levels, story) on top of a core loop that hasn't been validated through playtesting first.
+- Confusing complexity with depth — adding more systems instead of making existing systems interact more meaningfully.
+- Tuning difficulty from designer intuition alone instead of observed playtester skill curves.
+- Ignoring game feel until late in production, when it's expensive to retrofit responsiveness into controls and feedback.
+- Over-indexing on what players say they want in feedback sessions versus what their actual play behavior reveals.
+
+## Tools & techniques
+- Core loop diagramming (goal/action/reward/risk cycle) as the first design artifact for any game or feature.
+- Flow-channel difficulty curves mapped against observed player skill progression from playtests.
+- Rapid paper/greybox prototyping to validate a mechanic before committing art or content budget.
+- Structured playtesting with behavioral observation (where players struggle, quit, or repeat) as primary signal, verbal feedback as secondary.

package/dist/src/orgrt/role-skills/hierarchical-coord.md

@@ -0,0 +1,26 @@
+# Hierarchical Coordinator — Best Practices
+
+## Focus
+Runs a manager/worker tree: owns authoritative state, decomposes objectives into subtasks with a single accountable owner each, and reconciles reports flowing back up the chain.
+
+## Best practices
+- Decompose before delegating — each subtask needs a named owner, explicit acceptance criteria, and a clear handoff target, not "someone will do it."
+- Route by capability, not convenience: match subtask type to the specialist's declared expertise; prefer the narrowest qualified specialist over overloading one agent.
+- Treat subordinate reports as inputs, not truth — reconcile conflicting status into one authoritative view instead of relaying whichever came in last.
+- Checkpoint every cycle: compare current state against the goal, not just against the last report.
+- Intervene early on drift — a specialist quietly diverging from scope costs more the longer it runs; re-scope immediately with a narrower, corrected task.
+- Keep the tree shallow. Escalate to a real hierarchy only once the flat/parallel option genuinely can't cover the worker count (rule of thumb: 5-8+ concurrent workers).
+- Never let two subordinates silently own overlapping work — ambiguity in ownership is where hierarchical coordination fails first.
+
+## Common pitfalls
+- Static hierarchy under growing load: every new sub-agent still reports through the same chain, so the root becomes the bottleneck as task count or depth grows.
+- Specification ambiguity — subordinates misinterpret their scope or skip verification because the brief assumed shared context they didn't have.
+- Rubber-stamping upward reports instead of reconciling them, which lets a wrong subordinate claim propagate as fact.
+- Adding coordination machinery (extra approval layers, extra reporting) faster than the actual task complexity justifies — each new layer adds dependencies and conflict-resolution overhead of its own.
+- Treating "hierarchical" as inherently safer than flat/mesh — it improves control and efficiency but trades away the resilience a peer topology gets from having no single point of failure.
+
+## Tools & techniques
+- Represent the subtask tree and dependency edges explicitly (a DAG, not prose) so ownership and the critical path are checkable at a glance.
+- Dispatch independent subtasks in one batch so they run concurrently; only serialize what genuinely depends on prior output.
+- Use an explicit approval/acceptance gate before a deliverable is marked done — don't let "reported complete" and "verified complete" collapse into the same event.
+- When a subordinate stalls or diverges, re-scope with a narrower brief rather than escalating vaguely — specificity is the actual fix, not more oversight.

package/dist/src/orgrt/role-skills/incident-commander.md

@@ -0,0 +1,26 @@
+# Incident Commander — Best Practices
+
+## Focus
+Turn production chaos into structured, time-boxed resolution — classify severity, assign clear roles, drive communication cadence, and convert every incident into a systemic fix via blameless post-mortem.
+
+## Best practices
+- Classify severity immediately using a fixed framework (SEV1–SEV4) — severity determines escalation, response time, and communication cadence, so never skip it.
+- Assign explicit roles before troubleshooting starts: Incident Commander, Communications Lead, Technical Lead, Scribe — chaos multiplies without clear ownership of decisions.
+- Communicate on a fixed cadence even when there's no new information ("still investigating") — silence is worse than a boring update.
+- Timebox each investigation hypothesis (e.g. 15 minutes); if unconfirmed, pivot or escalate rather than tunneling on one theory.
+- Fix the bleeding first, root-cause later — rollback/restart/scale/failover to restore service, then investigate why it broke.
+- Verify recovery through metrics, not visual impression — confirm SLIs are back inside SLO and hold for a monitoring window before declaring resolved.
+- Run every SEV1/SEV2 through a blameless post-mortem within 48 hours, with owned action items tracked to completion — a post-mortem without follow-through is just a meeting.
+
+## Common pitfalls
+- Diving into fixes before assigning roles or classifying severity, producing uncoordinated, duplicated effort.
+- Framing post-mortem findings around what a person did wrong instead of what the system allowed — this erodes the psychological safety needed for people to escalate early next time.
+- Letting action items from previous post-mortems go undone, so the same incident recurs.
+- Declaring "resolved" based on things looking fine rather than confirmed metric recovery.
+- Undocumented tribal-knowledge fixes that only the one engineer who did it last time remembers.
+
+## Tools & techniques
+- A written severity matrix with explicit escalation triggers (impact doubling, time-without-root-cause) that auto-upgrade severity.
+- Tested runbooks per known failure mode, verified quarterly — an untested runbook is a false sense of security.
+- SLO/error-budget policy that gates feature work vs. reliability work based on budget consumption.
+- On-call rotation design with burnout guardrails (max consecutive weeks, page-volume ceilings, mandatory handoff during business hours).

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

@@ -0,0 +1,25 @@
+# Infrastructure — Best Practices
+
+## Focus
+Designs and operates the underlying systems (compute, networking, storage, CI/CD) that everything else runs on — reliability and reproducibility over feature velocity.
+
+## Best practices
+- Define infrastructure as code — every resource should be reproducible from a config file, not created by hand through a console.
+- Design for the six well-architected pillars: operational excellence, security, reliability, performance efficiency, cost optimization, sustainability — trade-offs should be explicit, not accidental.
+- Build in redundancy proportional to actual criticality — multi-AZ/multi-region for what truly needs it, not everything by default (cost matters).
+- Automate scaling and load distribution (auto-scaling groups, load balancers) rather than manually provisioning for peak.
+- Version and review infra changes like application code — plan/diff before apply, peer review before merge.
+- Instrument before you need it — monitoring, logging, and alerting must exist before an incident, not get added after one.
+- Keep environments (dev/staging/prod) as close to identical as practical to catch environment-specific failures early.
+
+## Common pitfalls
+- Manual, undocumented changes made directly against production that drift from the IaC source of truth.
+- Over-provisioning "just in case" instead of right-sizing against actual load data.
+- Treating monitoring/alerting as optional polish added after the first incident instead of a prerequisite.
+- Ignoring cost pillar until the bill is a surprise — cost optimization is a design-time concern, not a later cleanup.
+
+## Tools & techniques
+- Infrastructure as Code (Terraform, Pulumi, CloudFormation) with plan/apply review gates.
+- Well-Architected style review across reliability, security, cost, performance, and operations before major changes ship.
+- Auto-scaling + load balancing configured against real traffic patterns, not guessed capacity.
+- Centralized logging/monitoring (e.g., Cloud Monitoring/Logging equivalents) wired to actionable alerts, not noise.

package/dist/src/orgrt/role-skills/input-validator.md

@@ -0,0 +1,27 @@
+# Input Validator — Best Practices
+
+## Focus
+Enforces that every value crossing a trust boundary — user input, API payload, file upload, env var — is checked against an explicit allowlist before it reaches business logic.
+
+## Best practices
+- Use allowlist (positive) validation, not blocklist: define exactly what's acceptable (character set, format, length, range) and reject everything else
+- Validate at every trust boundary, not just the outermost one — a value that passed validation at the API layer can still be dangerous three functions deeper if it's re-used in a different context
+- Separate validation from sanitization — validation rejects bad input, sanitization neutralizes it; know which one a given field needs, and don't silently "fix" input that should be rejected
+- Validate structure and semantics, not just syntax — an email that matches a regex but points to a banned domain is still invalid for the use case
+- Fail closed: on ambiguous or malformed input, reject rather than guess at intent
+- Use the same validation logic on both client and server — client-side validation is UX, server-side validation is the actual security boundary
+- Escape/encode output for its destination context (HTML, SQL, shell, URL) — validation at input time does not substitute for contextual output encoding
+
+## Common pitfalls
+- Relying on blocklists ("reject `<script>`") that attackers trivially bypass with encoding or case variation
+- Validating once at the edge and assuming the value stays "clean" as it flows through the system, including into logs or templates
+- Conflating validation with sanitization, e.g. stripping characters from a username instead of rejecting invalid ones — silently mutating input hides bugs
+- Using overly permissive regexes (`.*`, unescaped metacharacters) that pass almost anything through
+- Trusting client-supplied metadata (Content-Type, file extension, declared length) without independently verifying it
+
+## Tools & techniques
+- OWASP Input Validation Cheat Sheet as the canonical reference for allowlist patterns and pitfalls
+- Schema-based validation libraries (Pydantic, Zod, JSON Schema) so validation is declarative and testable, not ad hoc regex scattered through handlers
+- Parameterized queries / prepared statements for anything that reaches a database — validation reduces risk but does not replace this
+- Contextual output encoding libraries matched to the sink (HTML entity encoding, SQL parameter binding, shell arg escaping)
+- Fuzz testing and boundary-value test cases (empty, max-length, unicode, null bytes) to catch validation gaps automated review misses

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

@@ -0,0 +1,25 @@
+# iOS Developer — Best Practices
+
+## Focus
+Builds native iOS applications with Swift and SwiftUI — modern, safe, performant apps that follow Apple's current platform conventions and data-safety guarantees.
+
+## Best practices
+- Default to SwiftUI for new UI work; it now covers the vast majority of active devices (iOS 15+) and is no longer optional greenfield tech.
+- Use `@Observable` (iOS 17+) for state management in new code — don't mix it with the legacy `ObservableObject`/`@Published` pattern in the same feature.
+- Embrace Swift's strict concurrency model: use actors to guard mutable state and resolve data-race warnings rather than suppressing them.
+- Use SwiftData for new local persistence needs unless there's a specific reason to stay with Core Data (e.g., deep existing investment).
+- Follow MVVM (or a comparably clear separation) so views stay declarative and business logic stays testable outside the view layer.
+- Apply Apple's secure coding and data-handling guidance for anything touching user data — keychain for secrets, no sensitive data in plain UserDefaults or logs.
+- Build accessibility in from the start: Dynamic Type, VoiceOver labels, and sufficient color contrast, verified with the Accessibility Inspector.
+
+## Common pitfalls
+- Mixing old and new observation/state patterns within the same view hierarchy, causing confusing update behavior.
+- Ignoring Swift 6 data-race warnings instead of fixing the underlying shared-state design.
+- Storing sensitive data insecurely (plain UserDefaults, hardcoded secrets) instead of using Keychain.
+- Treating accessibility as a final QA pass rather than validating it alongside each new screen.
+
+## Tools & techniques
+- Xcode's strict concurrency checking and Instruments (Time Profiler, Allocations) for correctness and performance validation.
+- SwiftData/Core Data migrations tested against real data before shipping schema changes.
+- Accessibility Inspector and VoiceOver walkthroughs for every new screen.
+- TestFlight staged rollouts combined with crash reporting (e.g., Xcode Organizer / Crashlytics) to catch regressions before full release.

package/dist/src/orgrt/role-skills/issue-tracker.md

@@ -0,0 +1,26 @@
+# Issue Tracker — Best Practices
+
+## Focus
+Keep issues accurate, well-triaged, and actionable — the single source of truth for what work exists, its state, and who owns it.
+
+## Best practices
+- Write issues with a clear problem statement, reproduction steps (for bugs) or acceptance criteria (for features) — not just a title.
+- Label consistently: type (bug/feature/docs), priority, and area, using a fixed taxonomy rather than inventing new labels per issue.
+- Link issues to the PRs that close them so history stays traceable.
+- Keep issue state current — close stale/duplicate issues rather than letting the backlog rot; a tracker nobody trusts stops being used.
+- Post progress updates on long-running issues at natural milestones, not on a timer for its own sake.
+- Break large issues into sub-tasks with explicit dependencies rather than one sprawling checklist.
+- Triage new issues promptly: confirm it's real, assign priority/labels, and either schedule or explicitly defer it.
+
+## Common pitfalls
+- Creating near-duplicate issues instead of searching first and commenting on the existing one.
+- Letting an issue sit "in progress" indefinitely with no update, blocking anyone from knowing its real status.
+- Over-labeling (ten labels on one issue) which makes filtering useless.
+- Writing bug reports without reproduction steps, forcing the assignee to re-discover the bug from scratch.
+- Closing issues without stating why (fixed, wontfix, duplicate) or linking the resolving change.
+
+## Tools & techniques
+- `gh issue create/list/view/edit/comment` for the full CLI workflow; `gh search issues` before filing anything new.
+- Milestones/projects for grouping issues toward a release rather than tracking dates in the issue body.
+- A fixed bug-report and feature-request template so triage doesn't need to ask clarifying questions every time.
+- Cross-repo search when working in a monorepo, so duplicate reports across packages get caught.