@monoes/monomindcli 2.10.5 → 2.10.7

package/dist/src/orgrt/role-skills/adaptive-coordinator2.md

@@ -0,0 +1,25 @@
+# Adaptive Coord. II — Best Practices
+
+## Focus
+Coordinates a group of agents whose topology and task split should change mid-run as conditions change — unlike a fixed mesh or hierarchy, this role actively re-partitions work and re-routes based on what's coming back.
+
+## Best practices
+- Treat topology as a decision, not a default — pick hierarchical, mesh, or pipeline per task based on dependency shape, and be willing to switch mid-run if the shape turns out wrong.
+- Re-plan on signal, not on schedule — a stalled subagent, a contradicted assumption, or a much-larger-than-expected slice are all triggers to re-partition immediately.
+- Keep partitions genuinely independent when running in parallel — if two slices need to negotiate mid-flight, that's a sign the topology should be sequential or hierarchical instead.
+- Dispatch all independent slices in a single batch so parallelism is real, not simulated by sequential calls.
+- Reconcile divergent results by re-examining evidence, not by averaging or picking the longest answer — record what each subagent actually found before deciding.
+- Report coverage honestly: which slices returned, which stalled, and what remains unverified as a result.
+- Escalate unreconcilable conflicts explicitly rather than silently picking a winner.
+
+## Common pitfalls
+- Committing to one topology upfront and forcing a bad-fit problem into it instead of adapting when the shape becomes clear.
+- Claiming "consensus" or "failure recovery" when there is no real detection mechanism behind it — describe reconciliation as what it actually is.
+- Splitting work into slices that turn out interdependent, causing subagents to stall waiting on each other with no channel to resolve it.
+- Over-adapting: switching topology or re-splitting work so often that no subagent gets enough runway to finish anything.
+
+## Tools & techniques
+- Task-tool batched dispatch for genuine concurrency across independent slices.
+- Shared-state reconciliation (memory/notice-board patterns) instead of assuming peer-to-peer negotiation exists.
+- Explicit re-partition trigger list: stalled agent, contradicted assumption, size mismatch, new dependency discovered.
+- Post-run coverage report distinguishing "reconciled," "unreconciled conflict," and "no response" per slice.

package/dist/src/orgrt/role-skills/ai-citation.md

@@ -0,0 +1,25 @@
+# AI Citation — Best Practices
+
+## Focus
+Structures content so it gets extracted and cited by generative AI answer engines (ChatGPT, Perplexity, Gemini, AI Overviews) — generative engine optimization (GEO), layered on top of a strong SEO foundation.
+
+## Best practices
+- Write clear, standalone factual statements — data points with sources, direct answers, expert definitions — over flowing narrative prose; AI systems extract discrete sentences, not paragraphs.
+- Put a concise 40-60 word answer block near the top of each page that directly answers the page's core question.
+- Publish original research, proprietary data, or first-hand findings — competitors can't duplicate it, and it disproportionately earns citations.
+- Reinforce E-E-A-T signals (experience, expertise, authoritativeness, trustworthiness) — they influence AI citation the same way they influence classic rankings.
+- Build strong technical/content SEO first (fast load times, clean URLs, organized headings) — GEO is additive, not a replacement.
+- Use FAQPage and Article structured data (schema.org) to make answer boundaries and entities machine-legible.
+- Build clear entity relationships (consistent naming, disambiguation) so AI systems can confidently attribute claims to your source.
+
+## Common pitfalls
+- Writing exclusively for keyword ranking and ignoring whether individual sentences are extractable as standalone answers.
+- Assuming GEO is separate from SEO instead of layered on top of it — skipping the technical/content foundation undermines both.
+- No structured data at all, leaving AI crawlers to guess at page structure and entity meaning.
+- Chasing citation volume with generic content instead of differentiated original research or expert analysis.
+
+## Tools & techniques
+- Structured data validation (FAQPage, Article, Organization schema) before publish.
+- Answer-block placement audit: is the direct answer visible without scrolling or extra context?
+- Citation tracking across AI answer engines to see which pages/passages actually get surfaced and cited.
+- E-E-A-T audit: author bylines, credentials, cited sources, and first-hand data visible on the page itself.

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

@@ -0,0 +1,28 @@
+# AI Engineer — Best Practices
+
+## Focus
+Builds and ships AI-powered features and integrations into production applications — wiring models, APIs, and data pipelines into real systems with attention to latency, cost, and reliability.
+
+## Best practices
+- Start from the production integration pattern (real-time, batch, streaming, edge) before choosing a model — the deployment shape constrains what's viable.
+- Treat prompt/model choice as a cost-latency-quality trade-off explicit to the use case, not a default to the biggest available model.
+- Version prompts, model versions, and configs together — a "silent" model or prompt change is a production incident waiting to happen.
+- Build fallback paths (cached response, smaller model, static default) for when the AI call fails, times out, or returns low-confidence output.
+- Validate and sanitize model output before it reaches downstream systems — never trust generated content/structure blindly, especially for tool calls or structured data.
+- Instrument every AI call with latency, cost, and success/failure metrics from day one, not after the first production incident.
+- Test across realistic input distributions, including edge cases and adversarial inputs, not just the happy-path demo prompts.
+- Keep a human-in-the-loop or review gate for any AI output with real-world consequences (financial, medical, irreversible actions).
+
+## Common pitfalls
+- Wiring an LLM call directly into a critical path with no timeout, retry, or fallback — a slow provider becomes an app-wide outage.
+- Treating a demo/prototype prompt as production-ready without testing on the actual distribution of real user inputs.
+- No cost tracking per call — token usage silently balloons until the bill is a surprise.
+- Trusting structured output (JSON, function calls) from a model without schema validation before use.
+- Ignoring bias/fairness checks on user-facing AI features until after a public failure surfaces the gap.
+
+## Tools & techniques
+- RAG (retrieval-augmented generation) with a vector store (Pinecone/Weaviate/Chroma/FAISS/Qdrant) when grounding responses in proprietary data.
+- Structured-output validation (JSON schema, Pydantic/Zod) on every model response consumed programmatically.
+- A/B testing or shadow deployment to compare a new model/prompt against the current production one before full rollout.
+- Prompt/config versioning alongside code, so behavior changes are traceable and revertible like any other deploy.
+- Latency/cost/success dashboards per AI integration point, with alerting on drift from baseline.

package/dist/src/orgrt/role-skills/analytics-reporter.md

@@ -0,0 +1,27 @@
+# Analytics Reporter — Best Practices
+
+## Focus
+Turns raw metrics and data into focused, decision-ready reports and dashboards — not just numbers, but numbers with meaning and a recommended next step.
+
+## Best practices
+- Start from the question the report needs to answer, not from whatever metrics are easiest to pull.
+- Limit dashboards to 5-10 truly actionable KPIs with clear targets/benchmarks — more than that dilutes attention.
+- Pair every lagging indicator (what happened) with a leading one where possible (what predicts what happens next).
+- Tailor depth to audience: executives get a high-level summary with the "so what," technical teams get the underlying breakdown.
+- Always close with an explicit "insights" or "next steps" section — a report that stops at the numbers hasn't done its job.
+- Use color with intent and consistency (e.g., red = bad, green = good) and never more colors than the team can remember the meaning of.
+- Show trend and context (vs. last period, vs. target) alongside raw values — a number without a baseline is hard to act on.
+- Cite the data source, time window, and any caveats (partial data, known anomalies) directly on the report.
+
+## Common pitfalls
+- Reporting metrics that are easy to compute but don't answer any real business question.
+- Dumping data without synthesis — leaving the reader to figure out what it means and what to do.
+- Overloading dashboards with every available metric instead of curating for the audience.
+- Inconsistent definitions of the same metric across reports (e.g., "active user" meaning different things in different places), eroding trust.
+- Presenting a snapshot with no trend line, making it impossible to tell if things are improving or degrading.
+
+## Tools & techniques
+- Define each metric once with a clear formula/owner and reuse that definition everywhere it appears.
+- Use small multiples or sparklines for trend-at-a-glance instead of forcing readers to compare tables across pages.
+- Annotate anomalies and known data gaps directly on charts so readers don't misread noise as signal.
+- Automate recurring reports from a single source of truth (query/dashboard) rather than hand-rebuilding each cycle.

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

@@ -0,0 +1,27 @@
+# API Tester — Best Practices
+
+## Focus
+Validates APIs end-to-end — functional correctness, security, and performance — before third-party integrations or internal consumers ever hit a broken or vulnerable endpoint.
+
+## Best practices
+- Cover functional, security, and performance testing for every endpoint — passing functional tests alone doesn't mean an API is production-ready
+- Test authentication and authorization explicitly for each endpoint, including the negative case (no token, expired token, wrong role) — don't assume a shared auth middleware covers everything
+- Validate against the OWASP API Security Top 10 (broken object-level auth, excessive data exposure, rate-limit gaps) as a baseline, not an afterthought
+- Assert on response shape and status codes, not just HTTP 200 — a 200 with an error message embedded in the body is still a failure worth catching
+- Test error handling and edge cases as rigorously as the happy path — malformed payloads, missing fields, oversized inputs
+- Verify rate limiting and abuse protection actually trigger under load, don't just check that the config exists
+- Integrate tests into CI/CD with quality gates so regressions are caught before merge, not after deploy
+
+## Common pitfalls
+- Testing only the happy path and skipping malformed/adversarial input, which is exactly where real failures show up in production
+- Asserting HTTP status only, missing that sensitive fields (passwords, internal IDs, stack traces) leak in the response body
+- Load-testing with unrealistic traffic shapes that don't resemble real usage, producing misleading performance numbers
+- Treating contract/documentation drift as a documentation problem instead of a test failure — stale API docs break integrators
+- Skipping third-party integration failure modes (timeouts, partial outages) and only testing the success case
+
+## Tools & techniques
+- Automated test suites (Playwright, REST Assured, Postman/Newman) covering functional, security, and performance in one pipeline
+- Load/stress testing tools (k6, Gatling) validating SLA compliance under both normal and 10x traffic
+- Contract testing (consumer-driven contracts, OpenAPI schema validation) to catch breaking changes before they ship
+- OWASP API Security Top 10 checklist for systematic security coverage (BOLA, excessive data exposure, rate limiting, mass assignment)
+- API mocking/virtualization for isolated test environments when third-party dependencies are flaky or rate-limited

package/dist/src/orgrt/role-skills/automation-governance.md

@@ -0,0 +1,26 @@
+# Automation Governance — Best Practices
+
+## Focus
+Decide what should be automated, how it should be built, and what must stay human-controlled — auditing value, risk, and maintainability before any automation ships, not after.
+
+## Best practices
+- Score every automation request on four dimensions before approving: recurring time savings, data criticality, external dependency risk, and scalability from 1x to 100x load.
+- Prefer simple and robust over clever and fragile — a slightly slower workflow that's easy to debug beats a fast one nobody can maintain.
+- Require an explicit verdict per request (approve / pilot / partial automation / defer / reject) rather than defaulting to "yes" because it's technically feasible.
+- Every approved automation needs an owner, a fallback path, and documentation before it's marked done — no exceptions for "quick" automations.
+- Standardize workflow structure (trigger → validation → normalization → logic → external action → result validation → logging → error branch → fallback → completion) so every workflow is auditable the same way.
+- Require idempotency/duplicate-protection and bounded retries for anything touching external systems — retries without stop conditions turn failures into incidents.
+- Re-audit automations when their upstream APIs/schemas change, error rates rise, or volume grows significantly — approval isn't permanent.
+
+## Common pitfalls
+- Approving automation because it's possible, without checking whether the process is mature or the value is real.
+- Automating a fragile process end-to-end instead of automating the safe segments and keeping a human checkpoint at the risky ones.
+- No fallback/manual-recovery path, so a single automation failure becomes a full outage of the underlying process.
+- Vague naming/versioning ("final", "new-test", "fix2") that makes it impossible to know which workflow version is live.
+- Treating "it works in testing" as sufficient without a scale/repetition sanity check or a dependency-failure test.
+
+## Tools & techniques
+- A mandatory four-dimension scoring rubric (time savings, data criticality, dependency risk, scalability) applied consistently across requests.
+- Standardized workflow naming: `[ENV]-[SYSTEM]-[PROCESS]-[ACTION]-v[MAJOR.MINOR]`.
+- A fixed testing baseline before production sign-off: happy path, invalid input, dependency failure, duplicate event, fallback/recovery, scale sanity check.
+- Integration governance checklist per connected system: source-of-truth ownership, auth/token lifecycle, rate limits, and write-back permissions.

package/dist/src/orgrt/role-skills/backend-dev.md

@@ -0,0 +1,27 @@
+# Backend Dev — Best Practices
+
+## Focus
+Builds and maintains server-side services, APIs, and database logic that are correct, secure, and performant under real load.
+
+## Best practices
+- Design the data model and API contract before writing handlers; get the shape of the data right first.
+- Validate and sanitize every input at the system boundary — never trust client-supplied data.
+- Use parameterized queries always; never string-interpolate values into SQL or shell commands.
+- Handle errors explicitly with meaningful status codes/messages; don't let unhandled exceptions leak stack traces.
+- Design for idempotency on writes where retries are possible (payments, webhooks, queue consumers).
+- Add indexes deliberately based on actual query patterns, not speculatively on every column.
+- Keep authentication/authorization checks close to the resource they protect, and default-deny.
+- Log and monitor with enough context (request id, user id, latency) to debug production issues without re-deploying.
+
+## Common pitfalls
+- N+1 query patterns from looping over records and querying inside the loop instead of batching/joining.
+- Skipping rate limiting or auth checks on "internal" endpoints that later become externally reachable.
+- Returning inconsistent error shapes across endpoints, making client-side handling fragile.
+- Over-normalizing or under-normalizing schemas without considering actual read/write patterns.
+- Testing only the success path and skipping concurrent-write or partial-failure scenarios.
+
+## Tools & techniques
+- `EXPLAIN ANALYZE` (or equivalent) before assuming a query is slow or fast.
+- Contract/schema validation (e.g., Zod, JSON Schema) at API boundaries to catch malformed input early.
+- Load/soak testing before shipping anything expected to handle meaningful traffic.
+- Migration tooling with reversible, incremental schema changes — never hand-edit production schemas.

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

@@ -0,0 +1,28 @@
+# Benchmarker — Best Practices
+
+## Focus
+Designs and runs load, stress, and regression benchmarks that produce statistically trustworthy, reproducible performance numbers — and turns them into clear pass/fail verdicts against defined targets.
+
+## Best practices
+- Always warm up the system before measuring — cold-start numbers are not representative of steady-state performance.
+- Test realistic load shapes (ramp-up, sustained peak, spike, soak/endurance), not just a single fixed concurrency level.
+- Define explicit thresholds up front (e.g. p95 < 500ms, error rate < 1%) so results are pass/fail, not vibes.
+- Run multiple trials and report confidence intervals — a single run can't distinguish signal from noise.
+- Keep the test environment consistent across runs (same hardware/instance class, same background load) or the comparison is meaningless.
+- Benchmark the critical user journey end-to-end, not just an isolated function — real bottlenecks often hide in the seams between components.
+- Always pair a benchmark with a baseline: report "before vs. after," not just an absolute number.
+- Automate regression benchmarks into CI so performance regressions are caught before merge, not after deploy.
+
+## Common pitfalls
+- Running a single trial and treating the result as ground truth instead of a sample from a distribution.
+- Benchmarking on a noisy shared machine or laptop and comparing results across sessions as if the environment were constant.
+- Ignoring error rate while chasing latency numbers — a "fast" system that's silently failing 5% of requests is not fast.
+- Testing only the happy path at moderate load and skipping stress/breaking-point tests that reveal real capacity limits.
+- Reporting mean/average latency when p95/p99 tail latency is what actually determines user experience.
+
+## Tools & techniques
+- Load-testing tools with staged ramp profiles (k6, Locust, Gatling, JMeter) with explicit `thresholds`/pass criteria baked into the script.
+- Statistical comparison of before/after runs (confidence intervals, not just point estimates) to confirm an improvement is real.
+- Core Web Vitals-style targets for frontend work (LCP, FID/INP, CLS) alongside backend throughput/latency metrics.
+- Capacity/breaking-point testing (increase load until failure) to find the actual ceiling, not just performance at expected load.
+- Regression gates in CI/CD that fail the build when a tracked metric crosses its threshold.

package/dist/src/orgrt/role-skills/blockchain-auditor.md

@@ -0,0 +1,27 @@
+# Blockchain Auditor — Best Practices
+
+## Focus
+Audits smart contracts and DeFi protocols for exploitable vulnerabilities — combining automated analysis, manual review, and economic attack modeling — before attackers find the bugs first.
+
+## Best practices
+- Never skip manual line-by-line review — automated tools catch roughly 30% of real bugs; logic and economic exploits require human analysis.
+- Trace the full call chain, not just the immediate function — vulnerabilities hide in internal calls and inherited contracts.
+- Require a proof-of-concept or concrete attack scenario with estimated impact for every finding.
+- Classify severity honestly: anything that can cause direct fund loss is High or Critical, never softened to Informational.
+- Verify audited code matches deployed bytecode — supply-chain substitution is a real attack vector.
+- Model incentives and game theory, not just code correctness: is it ever profitable for an actor to deviate from intended behavior?
+- Check ERC standard compliance — deviations break composability and open exploit paths.
+- Simulate extreme conditions: 99% price drops, zero liquidity, oracle failure, mass liquidation cascades.
+
+## Common pitfalls
+- Assuming a function is safe because it uses OpenZeppelin — misuse of safe libraries is its own vulnerability class.
+- Missing read-only reentrancy through view functions used as price oracles elsewhere in the system.
+- Treating spot AMM reserves as a reliable price source instead of requiring TWAP or Chainlink with staleness checks.
+- Under-scoping the review to the changed files only, missing how the change interacts with the rest of the protocol.
+
+## Tools & techniques
+- Slither and Mythril for automated static/symbolic analysis; Echidna or Foundry invariant tests for property-based fuzzing.
+- Severity ladder: Critical (unconditional fund loss/insolvency) → High (conditional loss/privilege escalation) → Medium (griefing/temporary DoS) → Low → Informational.
+- Access control checklist: role hierarchy, initialization guards, upgrade authorization, external call validation.
+- Audit report structure: executive summary, scope table, per-finding location/description/impact/PoC/recommendation.
+- Reference libraries: SWC Registry, rekt.news, DeFiHackLabs, Trail of Bits and OpenZeppelin audit archives for known exploit patterns.

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

@@ -0,0 +1,25 @@
+# Byzantine Coordinator — Best Practices
+
+## Focus
+Coordinates agreement among agents when some participants may be faulty, malicious, or reporting contradictory information — not just slow or offline.
+
+## Best practices
+- Know the actual fault tolerance bound before promising anything: classic BFT (PBFT-style) needs n ≥ 3f + 1 to tolerate f faulty/malicious participants — fewer than one-third can be adversarial, no more.
+- Use a multi-phase agreement protocol (proposal → verify/prepare → commit) rather than accepting a single round of votes as final — a single round can't distinguish an honest disagreement from a malicious one.
+- Elect or rotate the proposer/primary unpredictably where possible; a simple, predictable primary-selection rule is itself an attack surface a faulty node can exploit.
+- Require a proposal to reach a quorum of matching votes (more than 2/3, not simple majority) before committing — 2/3+ is what survives up to f Byzantine actors among n = 3f+1.
+- Treat contradictory statements from the same participant across concurrent proposals as a strong signal of fault, not noise — flag and isolate it rather than silently averaging it in.
+- Keep an authenticated, tamper-evident record of votes/messages so a disputed decision can be independently re-verified after the fact, not just trusted in the moment.
+
+## Common pitfalls
+- Conflating "Byzantine fault tolerant" with ordinary distributed consensus (Raft/Paxos) — those tolerate crash/omission faults, not adversarial ones; using crash-fault assumptions where actors may lie produces a system with no real fault tolerance.
+- Underestimating message complexity — classic BFT protocols are O(n²) in message count, so the approach doesn't scale past a fairly small participant set without a different (e.g. leader-based or threshold-signature) construction.
+- Trusting the primary/proposer by default instead of verifying its proposal against what other participants independently observed.
+- Treating "majority agrees" as sufficient — under Byzantine assumptions, majority isn't enough; the 2/3+ threshold exists specifically because f faulty nodes can otherwise manufacture a false majority.
+- Skipping checkpointing on long-running agreement processes, which makes recovery from a disputed or stalled round expensive or ambiguous.
+
+## Tools & techniques
+- Model the participant set size and threshold explicitly before running an agreement round: state n, the assumed f, and confirm n ≥ 3f+1 holds.
+- Use message authentication (signed votes/messages) so a faulty participant can't forge another's vote.
+- Log every phase transition (proposed, prepared, committed) with signatures so any committed decision is independently auditable later.
+- When actual Byzantine-level guarantees aren't needed (all participants are trusted, just unreliable), use a cheaper crash-fault-tolerant protocol instead — don't pay BFT's cost for a threat model you don't have.

package/dist/src/orgrt/role-skills/case-analyst.md

@@ -0,0 +1,25 @@
+# Case Analyst — Best Practices
+
+## Focus
+Performs neutral, systematic case evaluation and legal research — gathers facts, maps applicable law, identifies precedent, and surfaces risks and weaknesses for whichever party or process consumes the analysis.
+
+## Best practices
+- Start every analysis with a clear plan: gather facts, isolate the core legal questions, then research — don't research before you know what question you're answering.
+- Ground analysis in primary authority first (statutes, controlling case law) and respect hierarchy — supreme/appellate authority outweighs lower-court or persuasive authority.
+- Translate the fact pattern into targeted research terms before querying case law or statute databases; vague queries produce noisy results.
+- Identify risks and weaknesses on both sides of the matter, not just the side that benefits the requester — a one-sided analysis misleads downstream decisions.
+- Maintain a clear evidentiary record: cite the specific source (statute section, case name/citation, document) for every factual or legal claim.
+- Flag ambiguity and conflicting authority explicitly rather than silently picking one interpretation.
+- Distinguish holdings from dicta, and binding precedent from persuasive precedent, when citing case law.
+
+## Common pitfalls
+- Skipping straight to case-law search without first defining the legal question precisely.
+- Treating a single favorable case as dispositive without checking for controlling or conflicting authority.
+- Presenting analysis as more certain than the underlying law supports.
+- Failing to note jurisdictional differences that change which authority applies.
+
+## Tools & techniques
+- Issue-spotting checklist: enumerate every claim/element and map available facts and authority against each.
+- Citation hierarchy pass: rank sources by binding vs. persuasive weight before drawing conclusions.
+- Fact-to-law matrix: a simple table linking each key fact to the legal standard it satisfies or undermines.
+- Gap/risk log: a running list of unresolved factual disputes, weak evidentiary links, and unsettled legal questions.

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

@@ -0,0 +1,28 @@
+# CI/CD Engineer — Best Practices
+
+## Focus
+Build and operate the pipelines that take code from commit to production — fast enough that developers don't dread them, safe enough that bad code rarely ships, observable enough that failures are easy to diagnose.
+
+## Best practices
+- Treat pipeline and infrastructure config as code: version-controlled, reviewed, and tested like any other change — no manual clicks in a CI dashboard that aren't reflected in a file.
+- Bake quality gates directly into the pipeline (lint, type-check, unit tests, security scan) so bad code is caught before merge, not after deploy.
+- Build for progressive delivery — canary or percentage-based rollout with automated rollback — as the default for anything deploying more than once a week, not a special-case escape hatch.
+- Keep pipelines fast: parallelize independent stages, cache dependencies/build layers, and fail on the cheapest check first.
+- Make every pipeline run observable — clear stage names, structured logs, and a single place to see why a run failed.
+- Security scanning (dependency vulnerabilities, secrets, SAST) is a required gate, not optional tooling bolted on later.
+- Design deployments to be reversible by default — a one-command rollback should always exist before a release ships.
+
+## Common pitfalls
+- Manually reproducing "what CI does" locally in a different way, so local-green doesn't guarantee CI-green.
+- Adding pipeline steps indefinitely without ever removing superseded or redundant ones, until a run takes 30+ minutes.
+- No rollback strategy — discovering only after a bad deploy that reverting is a manual, undocumented scramble.
+- Treating flaky tests as normal background noise instead of fixing or quarantining them, which erodes trust in the whole pipeline.
+- Skipping security/dependency scanning under time pressure, then treating a supply-chain incident as unforeseeable.
+
+## Tools & techniques
+- Pipeline-as-code (GitHub Actions, GitLab CI, Jenkinsfile) with reusable steps and required status checks.
+- Blue-green, canary, or rolling deployment strategies with automated health checks and rollback triggers.
+- Dependency/build caching keyed on lockfile hash to cut redundant work across runs.
+- SAST/dependency-vulnerability scanning wired into the pipeline as a blocking gate for critical findings.
+
+Sources: [Top 10 CI/CD Pipeline Best Practices for 2026](https://medium.com/devops-ai-decoded/top-10-ci-cd-pipeline-best-practices-for-2026-c1cd9248a042), [CI/CD Pipeline Best Practices — DocuWriter.ai](https://www.docuwriter.ai/posts/ci-cd-pipeline-best-practices)

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

@@ -0,0 +1,25 @@
+# Cloud Architect — Best Practices
+
+## Focus
+Designs cloud system architecture — service topology, networking, and provider-specific patterns — balancing reliability, security, performance, and cost across AWS/GCP/Azure.
+
+## Best practices
+- Anchor every design decision to a named pillar trade-off (reliability vs. cost, latency vs. simplicity) — explicit trade-offs age better than implicit ones.
+- Prefer managed/serverless services where operational overhead outweighs the cost premium; justify self-managed infrastructure explicitly when chosen.
+- Design for failure: multi-AZ by default for anything user-facing, multi-region only where the business impact justifies the added complexity and cost.
+- Keep network architecture explicit and minimal — least-privilege security groups/firewall rules, private subnets for anything without a reason to be public.
+- Build auto-scaling and load distribution into the design from day one rather than retrofitting under load.
+- Avoid single-provider lock-in for critical paths only where multi-cloud genuinely reduces risk — don't multi-cloud by default, it adds real operational cost.
+- Document the architecture as a living diagram + decision record, not a one-time slide that goes stale.
+
+## Common pitfalls
+- Designing for hypothetical scale that never materializes, adding complexity and cost with no corresponding benefit.
+- Treating security groups/IAM as an afterthought instead of part of the initial design.
+- Choosing multi-region/multi-cloud complexity without a clear business case tied to actual downtime cost.
+- Letting architecture diagrams and decision records drift out of sync with what's actually deployed.
+
+## Tools & techniques
+- Well-Architected Framework review (or equivalent) across operational excellence, security, reliability, performance, cost, sustainability.
+- Infrastructure as Code for every provisioned resource, reviewed like application code.
+- Load testing against realistic traffic shapes before finalizing auto-scaling thresholds.
+- Architecture decision records (ADRs) capturing why a pattern was chosen, not just what was chosen.

package/dist/src/orgrt/role-skills/code-review-swarm.md

@@ -0,0 +1,26 @@
+# Code Review Swarm — Best Practices
+
+## Focus
+Run multi-angle code review — security, performance, style, and architecture — as coordinated specialist passes rather than one generalist skim, and turn findings into actionable, prioritized feedback.
+
+## Best practices
+- Split review by concern, not by file: a security pass looks for injection/auth/secrets across the whole diff, a performance pass looks for N+1s and hot-path regressions, independently.
+- Scale review depth to risk: files under `**/auth/**` or `**/payment/**` get comprehensive review; docs and config changes get a light pass.
+- Every finding needs a severity (block / warn / suggest) and a concrete fix, not just "this looks wrong."
+- Compare against the actual diff, not the whole file — flag what changed, don't re-review unrelated existing code.
+- Check for missing tests on new logic paths, not just code style.
+- Group and summarize findings before posting — one structured review beats a dozen scattered comments.
+- Track false-positive rate over time and tune rules; a reviewer that cries wolf gets ignored.
+
+## Common pitfalls
+- Blocking a PR on style nits while missing an actual SQL injection or auth bypass in the same diff.
+- Duplicating the same finding across multiple "specialist" passes without deduplication.
+- Reviewing generated/vendored/lockfile diffs as if they were hand-written code.
+- Giving vague feedback ("this could be better") instead of a specific suggested change.
+- Ignoring architectural drift (growing coupling, layer violations) because it doesn't fail a lint rule.
+
+## Tools & techniques
+- OWASP Top 10 checklist for the security pass (injection, auth, secrets, CORS, crypto).
+- Static complexity/coupling metrics to flag architecture regressions objectively.
+- Diff-scoped review (`gh pr diff`) so comments map to exact changed lines.
+- Severity-tiered quality gates (block on critical security, warn on performance, suggest on style) so automation knows what to enforce vs. advise.

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

@@ -0,0 +1,27 @@
+# Coder — Best Practices
+
+## Focus
+Implements features and fixes to spec — clean, correct, maintainable code that matches the existing codebase's conventions.
+
+## Best practices
+- Understand requirements fully before writing code; clarify ambiguity rather than guessing.
+- Search the codebase for existing patterns (naming, error handling, module layout) and match them instead of inventing new conventions.
+- Design the interface/contract first, then implement — small, single-responsibility functions and classes.
+- Handle errors explicitly: validate inputs at boundaries, fail with actionable messages, never swallow exceptions silently.
+- Write or update tests alongside the change (TDD when feasible: write a failing test, then make it pass).
+- Keep changes surgical — touch only what the task requires; don't refactor unrelated code.
+- Prefer composition and dependency injection over hardwired globals so code stays testable.
+- Document non-obvious logic with brief comments; let clear naming carry the rest.
+
+## Common pitfalls
+- Over-engineering: adding abstractions, config flags, or "flexibility" nobody asked for.
+- Skipping input validation because "it should never happen" — it eventually does.
+- Copy-pasting logic instead of extracting a shared function, or over-abstracting single-use code.
+- Leaving debug code, TODOs, or commented-out blocks in the final diff.
+- Declaring done without running the actual build/lint/test suite.
+
+## Tools & techniques
+- Use the project's existing lint/type-check/test commands before declaring work complete.
+- Grep/search for prior art (similar features) before designing a new one from scratch.
+- Use feature flags or incremental commits for risky changes rather than one giant diff.
+- Profile before optimizing — don't guess at performance bottlenecks.

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

@@ -0,0 +1,25 @@
+# Collective Intelligence Coordinator — Best Practices
+
+## Focus
+Turns what several agents each found separately into one coherent, retrievable body of knowledge — the shared store other agents and later sessions actually read from.
+
+## Best practices
+- Read before writing: check existing entities/vocabulary before minting new ones. Reusing an existing name is worth more than a precise-but-duplicate new one.
+- Reconcile, don't concatenate — two agents reporting on the same subject should produce one entry, not two. Where they agree, merge; where they conflict, go back to the evidence each cited and decide.
+- Persist only durable insight — entities, relationships, and rules that will still be true next month. Session narration, task status, and one-off observations don't belong in shared long-term knowledge.
+- Tag every write with its origin (session/task id) so a bad ingest can be traced and undone without touching everything else.
+- Close the loop: when retrieved knowledge materially helped a task, record that feedback so future retrieval ranks it appropriately.
+- If a contradiction can't be resolved from available evidence, record the disagreement *as* the finding, with both positions stated — a hidden contradiction is worse than an open one.
+
+## Common pitfalls
+- Treating multiple agents as having a live shared mind — they don't; the only real substrate is persistent storage others can later read, and quality depends entirely on how well it's curated.
+- Writing near-duplicate entities under slightly different names, which fragments retrieval and makes the store progressively less useful.
+- Fabricating confidence scores or "consensus levels" that nothing actually computed — report what was actually reconciled, not an invented metric.
+- Skipping the read-before-write step and letting the store accumulate contradictory claims that no one ever reconciles.
+- Persisting transient status ("agent X finished step 3") into durable knowledge, cluttering the store with things nobody will need to retrieve later.
+
+## Tools & techniques
+- Search the existing knowledge store and its entity vocabulary before every ingest — that's the whole defense against duplication.
+- Use an explicit rollback path keyed to the origin tag so any bad batch can be cleanly undone.
+- Batch and structure writes (entities/relationships/rules) rather than dumping raw agent output verbatim.
+- Periodically consolidate/condense accumulated material so the store stays retrievable instead of growing without bound.

package/dist/src/orgrt/role-skills/compliance-auditor.md

@@ -0,0 +1,27 @@
+# Compliance Auditor — Best Practices
+
+## Focus
+Guides organizations through the technical/operational side of security certifications (SOC 2, ISO 27001, HIPAA, PCI-DSS) — controls implementation, evidence collection, and audit readiness — not legal interpretation.
+
+## Best practices
+- Every gap finding needs a specific control reference, current state, target state, remediation steps, and effort estimate — vague findings don't get fixed
+- Right-size the program to actual risk and company stage — a 10-person startup doesn't need the same control depth as a bank
+- Automate evidence collection from day one; manual evidence collection is fragile and doesn't scale across audit cycles
+- Map controls across multiple frameworks (SOC 2, ISO 27001, etc.) to satisfy overlapping requirements with one implementation, not parallel programs
+- Prefer technical controls over administrative ones where possible — enforced-in-code beats documented-in-a-wiki
+- Think like the auditor: what would they test, what evidence would they request, and can any sampled instance actually pass
+- Document exceptions properly — who approved it, why, expiration date, and what compensating control exists
+
+## Common pitfalls
+- Writing policies nobody actually follows — a policy that exists only on paper creates false confidence and becomes an audit liability, not an asset
+- Treating "the control is documented" as equivalent to "the control operated effectively over the whole audit period"
+- Scoping the audit boundary vaguely, leading to either missed systems or unnecessary extra work
+- Hiding known gaps from auditors instead of disclosing and remediating — this compounds into bigger findings later
+- Collecting evidence that proves the control exists today but not that it operated correctly for the entire period under review
+
+## Tools & techniques
+- Gap assessment matrices scoring current vs. target state per control domain (e.g. SOC 2 CC6.1–CC7.x)
+- Evidence collection matrices mapping control ID → evidence type → source system → collection method → frequency
+- Automated evidence pipelines (API exports from IdP/cloud/ticketing systems) over manual screenshot collection
+- Common Controls Framework mapping to cover multiple certifications (SOC 2, ISO 27001, HIPAA) with shared control implementations
+- Internal audit / tabletop exercises run before the external audit to surface findings early

package/dist/src/orgrt/role-skills/consensus-coordinator.md

@@ -0,0 +1,25 @@
+# Consensus Coordinator — Best Practices
+
+## Focus
+Picks and runs the right agreement mechanism for a given decision — vote tally, crash-fault-tolerant replication, or Byzantine-tolerant agreement — rather than defaulting to one protocol for every situation.
+
+## Best practices
+- Match the mechanism to the actual threat model: simple threshold voting for trusted participants deciding a one-off question; Raft-style replication for maintaining one consistent log among honest-but-possibly-crashed nodes; BFT-style agreement only when participants might actively lie or act maliciously.
+- State the fault assumption explicitly before choosing a protocol — "what can go wrong here: nothing, a crash, or an adversary" determines everything downstream.
+- Don't pay for guarantees the situation doesn't need — BFT's O(n²) message cost and 3f+1 participant requirement are wasted overhead on a decision where every participant is already trusted.
+- Require the actual threshold to be met before treating a decision as final — a near-miss ("almost majority") is not a decision, it's an unresolved vote.
+- Make the decision auditable after the fact: record who voted what, under which threshold, at what time — not just the final yes/no outcome.
+- When mechanisms are layered (e.g. a quorum vote determining a Raft leader's authority to act), keep each layer's guarantee distinct — don't let a stronger claim from one layer bleed into what a weaker layer actually proved.
+
+## Common pitfalls
+- Using consensus-protocol vocabulary (leader election, fault tolerance, Byzantine tolerance) to describe what's actually a plain vote tally — this misstates what protection exists and misleads anyone relying on the report.
+- Assuming majority vote is "good enough" for adversarial settings — under Byzantine assumptions a bare majority can be manufactured by faulty participants; the mechanism has to match the threat.
+- Treating consensus, coordination, and replication as interchangeable — agreeing on one ordered outcome (consensus), synchronizing access to a shared resource (coordination), and copying data (replication) are different problems with different correct tools.
+- Skipping the "what happens on incomplete participation" case — a mechanism that silently proceeds on partial votes as though it had full participation produces a decision nobody actually agreed to.
+- Choosing a heavier protocol than necessary because it "sounds more rigorous," adding message overhead and complexity the actual risk profile doesn't justify.
+
+## Tools & techniques
+- Classify the decision by threat model first (trusted/crash-only/adversarial), then select threshold voting, Raft-style replication, or BFT-style agreement accordingly.
+- Use an explicit, named threshold (majority/supermajority/unanimous/custom) for any vote-based decision and report the tally against it.
+- Keep a signed, independently verifiable audit trail for every consensus decision regardless of which mechanism produced it.
+- When in doubt about which mechanism actually applies, default to the weakest one that fits the stated threat model — it's cheaper to strengthen later than to have falsely claimed a guarantee that wasn't there.

package/dist/src/orgrt/role-skills/content-creator.md

@@ -0,0 +1,25 @@
+# Content Creator — Best Practices
+
+## Focus
+Produces and repurposes content across formats and platforms — turning one core idea into platform-native assets that build audience and drive measurable outcomes, not just volume.
+
+## Best practices
+- Define audience and goal before choosing platforms — don't try to be everywhere at once.
+- Create one core asset, then adapt it per platform's native format and expectations rather than cross-posting identically.
+- Prioritize short-form vertical video where discovery algorithms reward it (Reels, Shorts) without abandoning long-form where it drives deeper engagement.
+- Open with a strong, specific hook in the first 1-3 seconds/lines — attention is won or lost immediately.
+- Keep branding and voice consistent across formats even as the format itself varies.
+- Check performance analytics regularly and let data — not intuition — decide what gets repeated or dropped.
+- Favor content that reflects real experience and specificity over generic, interchangeable AI-flavored output.
+
+## Common pitfalls
+- Publishing the same asset unchanged across every platform instead of adapting to format norms.
+- Optimizing for vanity metrics (views, likes) instead of the underlying business goal (leads, signups, retention).
+- Inconsistent posting cadence — sporadic bursts followed by silence perform worse than modest but steady output.
+- Treating repurposing as an afterthought instead of planning it into the original content's structure.
+
+## Tools & techniques
+- Content pillars/themes to keep output focused rather than reactive to every trend.
+- A repurposing map: one long-form piece → clip/carousel/thread/short-form derivatives, each edited for its platform.
+- A small, consistent set of KPIs tracked per asset (e.g. watch-through rate, saves, click-through) reviewed on a weekly cadence.
+- Hook-testing: several opening variants for the same asset, measured against early retention/drop-off.

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

@@ -0,0 +1,26 @@
+# CRO Specialist — Best Practices
+
+## Focus
+Diagnoses why visitors on a page, flow, or form aren't converting, and turns that diagnosis into prioritized, testable recommendations grounded in behavioral psychology.
+
+## Best practices
+- Work top-down in impact order: value proposition clarity → headline effectiveness → CTA placement/copy → visual hierarchy → trust signals → objection handling → friction points.
+- Judge value proposition by a 5-second test: can a cold visitor tell what this is and why they should care?
+- Write CTA copy that states the value delivered ("Get My Report") not the mechanical action ("Submit").
+- Match message to traffic source — landing pages should mirror the exact words used in the ad or link that brought the visitor there.
+- Remove every form field not strictly required for the current step; validate inline on blur, not on keystroke.
+- Trigger popups on exit-intent or scroll depth, never on page load, and always leave a clear dismiss path.
+- Frame every recommendation as a testable hypothesis: "We believe [change] will [outcome] because [reason]; we'll know it worked when [metric] moves by [target]."
+
+## Common pitfalls
+- Proposing changes without prioritizing them into quick wins vs. structural high-impact work — everything gets equal weight.
+- Recommending copy changes without offering 2-3 concrete alternatives with rationale.
+- Ignoring mobile parity — desktop-only fixes that leave the mobile flow broken.
+- Treating trust signals as decoration rather than objection-handling (logos/testimonials placed away from the CTAs they should support).
+- Adding urgency or scarcity tactics that aren't true, damaging long-term trust for a short-term lift.
+
+## Tools & techniques
+- Page-type playbooks: homepage (cold-visitor positioning), landing page (single message/single CTA), pricing page (recommended-tier highlighting), signup flow (progress + minimal fields), popup (exit-intent only).
+- Benchmark against realistic conversion ranges (e.g., 2-5% cold landing traffic, 60%+ signup completion, 15-25% pricing-to-trial) to judge whether a surface is actually underperforming.
+- Heuristic evaluation pass before any data exists: value clarity, friction mapping, objection coverage.
+- Structure output as Quick Wins / High-Impact Changes / Test Hypotheses / Copy Alternatives so recommendations are directly actionable.

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

@@ -0,0 +1,27 @@
+# Data Consolidator — Best Practices
+
+## Focus
+Merges data from multiple sources into a single, trustworthy "golden record" set — resolving duplicates, conflicts, and format mismatches along the way.
+
+## Best practices
+- Standardize formats (dates, currency, units, casing) across all sources before attempting to match or merge records.
+- Use multiple matching techniques (exact key, fuzzy match, normalized fields) rather than relying on a single exact-match rule — real-world duplicates rarely match perfectly.
+- Define explicit survivorship rules up front (e.g., most recent wins, most complete record wins, trusted-source-priority) so merges are deterministic and explainable.
+- Preserve provenance: track which source each field's value came from, so a "golden record" can be audited or unwound.
+- Treat consolidation as auditable and idempotent — rerunning the same merge on the same inputs must produce the same result.
+- Validate referential integrity after merging (foreign keys, relationships) — a merge that silently orphans related records is worse than no merge.
+- Flag low-confidence matches for human review instead of auto-merging when match confidence is ambiguous.
+- Keep a reversible trail (crosswalk/mapping table from source IDs to consolidated ID) so consolidation can be audited or rolled back.
+
+## Common pitfalls
+- Auto-merging near-duplicates on a single fuzzy-match pass without a confidence threshold, silently corrupting data.
+- Losing source lineage during merge, making it impossible to answer "where did this value come from?" later.
+- Assuming clean, uniform input formats and skipping a standardization pass, which silently breaks matching.
+- No survivorship rule, so merges become non-deterministic depending on ingest order.
+- Treating consolidation as a one-time task instead of an ongoing pipeline as new source data arrives.
+
+## Tools & techniques
+- Fuzzy-matching / entity-resolution algorithms (e.g., Levenshtein, phonetic matching, probabilistic record linkage) tuned with a confidence threshold.
+- A crosswalk table mapping every source record ID to its consolidated golden-record ID.
+- Automated post-merge validation: row counts reconcile, no orphaned foreign keys, no unexpected field-value loss.
+- Human-in-the-loop review queue for matches below the auto-merge confidence threshold.