Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
git clone --depth 1 https://github.com/nicelight/DevRails-26Wrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/commands/nicelight/devrails-26/mb-sync)<a href="https://agentmods.dev/commands/nicelight/devrails-26/mb-sync"><img src="https://agentmods.dev/badge/commands/nicelight/devrails-26/mb-sync/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/commands/nicelight/devrails-26/mb-sync"><img src="https://agentmods.dev/badge/commands/nicelight/devrails-26/mb-sync.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00018 | $0.01189 |
| Opus 5.5 | $0.00007 | $0.00476 |
| Sonnet 5.5 | $0.00004 | $0.00238 |
| Haiku 4.5 | $0.00002 | $0.00119 |
Grade A, and why
mb-sync scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 1mo ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 115 lines — stays where its author put it; the contents beside it link to each section on GitHub.
/mb-sync - Reconcile durable Memory Bank state
<input_contract>
Read and follow .memory-bank/workflows/mb-sync.md plus only the changed or
referenced Memory Bank/task/evidence surfaces needed for this boundary.
Normal boundary is once at the end of the current wave, after the scheduler or
explicit owner has written every closure/failure/blocking decision, final task
status, and evidence link to indexed .task.json records. Early sync requires
a recorded current-wave dependency on reconciled RTM/index/spec/contract/
changelog state or an explicit owner request; it does not replace the final
wave-boundary sync.
In manual flow, the invocation or its durable context identifies the explicit top-level caller/owner that will own applicable post-sync gates and the next handoff.
Do not require full sync for a local manual T0/T1 closure when only task
status, task verify, and compact .protocols/<TASK>/run.md changed.
</input_contract>
<hard_invariants>
- JSON task records remain authoritative for task status, dependencies, tier, gates, verification targets, and evidence markers.
- Status/closure/promotion ownership comes from
.memory-bank/workflows/tier-policy.md#tier-obligations,.memory-bank/workflows/tier-policy.md#closure-authority, and.memory-bank/workflows/mb-sync.md. /mb-syncnever infers or writes closure/failure/blocking/promotion,planned -> ready, dependent unblock, or dependent block when the explicit owner decision is absent.- In scheduler mode, sync only state already written by
/autopilotor/autonomous. In manual mode, require an already-recorded explicit owner decision or a direct instruction for this sync. spec-index.mdremains a pure registry; no decision bodies, feature status maps, ownership, or reverse usage are added.- Do not create a new task/status/boundary/design lifecycle or guess stale product/design state. </hard_invariants>
<operator_decisions> If authoritative artifacts disagree, or reconciliation exposes a new product, design, canonical-path, contract/state/data/storage/security/compatibility, task-boundary/tier/dependency/verification, closure, or promotion decision, stop with a consistency gap.
Interactive flow asks the operator/explicit owner and requires the answer to be
written to the existing owning artifact before sync resumes. Unattended flow
returns the gap to the scheduler for HALT_CLARIFICATION_REQUIRED,
HALT_BLOCKING_QUESTIONS, or HALT_QUALITY_GATES as applicable. A
recommendation/default is not an owner decision.
</operator_decisions>
<agent_discretion> Within the canonical sync checklist, the agent chooses inspection order, tools, and the minimum changed surfaces needed to prove consistency. It may repair mechanical links/routers and reconcile already-decided state, but may not create missing product/design/lifecycle decisions. </agent_discretion>
<required_outputs> As applicable, reconcile:
- task index/records and evidence links;
- requirements RTM and REQ lifecycle;
- epic/feature lifecycle separately from document status;
- truthful existing spec-backbone, spec-index, feature design links/status, and changed canonical specs without inventing design;
- accepted
boundary-map.mdlinks after path/heading changes; - behavior-spec links as optional examples only;
- Memory Bank/root/subfolder routers;
.memory-bank/changelog.mdfor the current wave/change.
Report consistency gaps and promotion eligibility without applying scheduler-owned promotion or final lifecycle transitions. </required_outputs>
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 1mo ago First seen · 115 lines · 18 tokens per session scan A fabd431afa9d
mb-sync is a command published in the GitHub repository nicelight/DevRails-26 (23 stars, last pushed 1mo ago), licensed MIT. It adds 18 tokens to every session and 1,189 once invoked, about $0.0001 per session on Opus 5.5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other commands, from other repositories
lavra-checkpoint
Save session progress by filing beads, capturing knowledge, and syncing state.
context-age
Envejecimiento semántico del decision-log — comprime y archiva decisiones antiguas.
handoff
Write a session handoff document for continuity.
perf-review-redesign
Replace a broken annual performance ritual with a research-backed continuous + quarterly + annual-comp architecture. Produces redesigned cadence, manager scripts, employee-prep guide, calibration protocol, and a transition plan from old to new. Heavy disclaimer on legal/HRIS implications because changing comp linkage…
talent-burnout-detect
Run a burnout detection protocol on a person or team. Maslach 3-dimensional assessment (emotional exhaustion + cynicism + reduced personal accomplishment) plus root-cause hypothesis plus intervention plan plus reassessment cadence. Cynicism is the diagnostic. Hard clinical-boundary escalation when signals cross into…
talent-psych-safety
Measure psychological safety on a team using Edmondson's 7-question scale (anonymous, longitudinal, team-by-team) plus interpretation rubric and intervention design. Cites Project Aristotle. Refuses "psychological safety training" as primary intervention without leader behavior change. Refuses single-snapshot scoring.…