arozumenko
- 69 skills
- 0 followers
- 3 hours ago last updated
- ▌ Test Case Analysis · arozumenko bundleUse when a TMS test case needs manual execution, selector discovery, or defect investigation before automation — "analyse SCRUM-T101", "run this case and emit an AFS", any pre-automation case exploration. Produces an Automation-Friendly Spec (AFS); does not write test code.
- ▌ Root Cause Analysis · arozumenko bundleUse when a bug has been reproduced or confirmed and needs its exact cause traced before a fix is proposed, or when the user says 'investigate issue'. Traces a bug to its exact cause in the codebase. Investigation only — reports the cause on the ticket; does not edit code.
- ▌ Security Test Planning · arozumenko bundleUse when turning a threat model's candidate cases or your own drafts into passive security test cases in manual-qa format, admitting them by lint against the allowed-operation grammar, and handing off a verified suite; provides cases.mjs.
- ▌ Stakeholder Interview · arozumenko bundleUse when a stakeholder conversation, customer meeting, or user session is being planned or has just happened — even if the user only says 'I'm meeting them Thursday' or pastes raw notes. Runs two modes — PREPARE aggregates every open question, untested critical assumption, and unresolved escalation across the workspace into a themed, value-of-information-ordered guide filtered to what THIS interviewee can answer; SYNTHESIZE turns raw notes or a transcript into a durable evidence file and propagates the answers into the hypotheses they touch (evidence links, assumption verdicts, resolved questions). Trigger phrases — 'prep the interview', 'what should I ask', 'here are my notes', 'synthesize this interview', 'we talked to the customer'. NOT for triaging raw feature asks (intake-triage), NOT for team-internal meeting minutes, and NOT for fact-checking a document (deep-research factcheck mode).
- ▌ Test Automation Workflow · arozumenko bundleUse when ready-made test cases (TMS or tasks/<suite>/TC-*.md) need to become automated tests — a single case or a batch — or when technical suite work (tech-debt, migrations, improvements, suite health) needs planning and batching. Batch pipeline: units run one at a time on a batch trunk — routed by execution evidence (manual-qa-verified / needs-execution / combined), built, statically reviewed against the coverage contract, merged back — then one N×-green hardening gate per batch and one TMS/tracker mirror sweep. Pluggable TMS (Zephyr/TestRail/Xray/Azure/markdown).
- ▌ Session Retrospective 2 · arozumenko bundleUse when asked to run a retrospective, mine past sessions, or improve the team from what already happened — turning prior Claude Code conversations and sub-agent sessions into proposed memory and workflow updates. Used by scout.
- ▌ Journeys To Hypotheses · arozumenko bundleUse when journeys and the backlog need reconciling — 'turn my journeys into hypotheses', 'map the journeys to the backlog', 'what do my journeys cover', 'convergence pass', 'where are the gaps in the backlog' — or proactively whenever new journey files exist that no hypothesis or epic references. Runs a convergence pass over every user journey (maps, list, BDD), every existing hypothesis, and (where one is configured) the project's issue tracker, classifying each journey COVERED / GAP / OUT-OF-SCOPE, regenerating the journey-coverage board, and on confirmation authoring the missing problem statements and hypothesis stubs with house frontmatter and collision-free IDs. NOT for authoring journeys themselves, NOT for promoting hypotheses, and NOT for breaking epics into stories.
- ▌ Seeding Automation Project · arozumenko bundleUse when the user asks to 'seed the project', 'onboard this repo', 'generate project config', 'create AGENTS.md', or after the scout has explored the codebase. Generates AGENTS.md and .agents/ configuration files for a new project.
- ▌ Test Automation Workflow 2 · arozumenko bundleUse when a TMS test case needs to become an automated test, or when automating a regression batch — "automate TC-NNN", "convert this case to Playwright", any flow from a manual case to green framework tests. Pluggable TMS (Zephyr/TestRail/Xray/Azure/markdown).
- ▌ Test Automation Implementation · arozumenko bundleUse when a test case needs to become a green, framework-resident test — the build slot of the test-automation pipeline, from case to green test. Six-phase loop (Absorb → Investigate → Automate → Execute → Debug → Handoff), the 12 Hard Rules, the coverage declaration, the Run Report. Orchestration: test-automation-workflow.
- ▌ Security Engagement · arozumenko bundleUse when running a security engagement end to end as the lead — init, review, register, model, cases, hand-off, report, fix, acceptances, sign-off; points at the other security-testing skills rather than duplicating their commands.
- ▌ Implement Feature · arozumenko bundleUse when the user says "implement", "build feature", "work on task", or once a plan or story is approved and you're about to start building. The end-to-end feature-implementation workflow; delegates the final handoff to completing-a-task.
- ▌ Seeding A Project · arozumenko bundleUse when the user asks to 'seed the project', 'onboard this repo', 'generate project config', 'create AGENTS.md', or after the scout has explored the codebase. Generates AGENTS.md and .agents/ configuration files for a new project.
- ▌ Session Retrospective · arozumenko bundleUse when asked to run a retrospective, mine past sessions, or improve the team from what already happened — turning prior Claude Code conversations and sub-agent sessions into proposed memory and workflow updates. Used by scout.
- ▌ Playwright Testing 2 · arozumenko bundleUse when a manual-QA agent does live browser testing through the Playwright MCP server — exploring/profiling a web app or executing a web test case against a running app, with no test code generated. Web/PWA/hybrid targets; used by app-profiler and test-runner. Mobile native → use mobile-testing instead.
- ▌ Reproducing Issues 2 · arozumenko bundleUse when a bug is unclear or unconfirmed and needs reproduction before RCA or any fix. Turns a vague bug report into precise, repeatable steps with evidence and a CONFIRMED / CANNOT-REPRODUCE / PARTIAL verdict. Reproduction and documentation only — does not fix code.
- ▌ Tokenomics · arozumenko bundleOptional always-on usage telemetry for agent teams — hooks capture every session's tokens, cost, time, activity and named case ids into a git-committed ledger (.agents/telemetry/automation/), covering Claude Code, Copilot CLI AND the VS Code Copilot sidebar, so the data survives transcript expiry and accumulates across the whole team; a report joins it with the pipeline's own report.json receipts to answer how much automating each batch of cases cost. Use when the user wants continuous/team-wide usage tracking, "enable telemetry", cost-per-case over time, a team usage report, a local OTel sink/doctor, or hyperfactory dataset work — "are we ready to submit tokenomics", build/refresh the submission, the §7 checklist, anonymize the dataset; for a one-off deep audit of live transcripts use efficiency-audit instead.
- ▌ Content SEO Audit · arozumenkoContent quality, copywriting, and SEO metadata analysis. Checks copy quality visually and page metadata (title, description, structured data) where observable.
- ▌ Performance Audit · arozumenko bundlePerformance, networking, console, and JavaScript analysis. Checks network issues, console errors, and JS problems; approximates load/resource health where full Core Web Vitals aren't available.
- ▌ Code Review · arozumenko bundleUse when the user asks to 'review this code', 'check my changes', 'review PR', 'audit' — and proactively after a non-trivial change or before opening, approving, or merging a PR, even unprompted. Reviews code for correctness, security, performance, and maintainability.
- ▌ Playwright Testing · arozumenko bundleUse when a manual-QA agent does live browser testing through the Playwright MCP server — exploring/profiling a web app or executing a web test case against a running app, with no test code generated. Web/PWA/hybrid targets; used by app-profiler and test-runner. Mobile native → use mobile-testing instead.
- ▌ Git Workflow · arozumenko bundleUse when the user asks to "commit", "create PR", "branch", "merge", "rebase", "cherry-pick", "tag", or otherwise manage git history. Guides disciplined git operations — branching, commits, PRs, and recovery.
- ▌ Define Outcomes · arozumenko bundleUse when a hypothesis names no ratified outcome and so cannot be promoted, a quarterly bet is being set, or someone asks what number a bet is actually trying to move. Drafts, stress-tests, and records ratification of outcome anchors in docs/discovery/outcomes.md — measurable customer-behavior metrics with a dated baseline, a target, and a quarterly timeframe — running each candidate through a definition-quality checklist, where only the product owner's explicit in-chat act ratifies one and never without a dated baseline. Trigger phrases — 'define the outcomes', 'our hypotheses have no ratified outcome', 'what metric is this bet moving', 'set the quarterly targets', 'ratify the anchor'. NOT for business or traction metrics as anchors (revenue, signups, ARR — those may appear only as lagging confirmation), NOT for team OKRs or engineering SLOs, and NOT a metrics-dashboard builder.
- ▌ Define Personas · arozumenko bundleUse when personas come up — 'define the personas', 'who are our users', 'make a persona card for X', 'which persona owns this journey' — or proactively whenever a journey, BDD scenario, or hypothesis names an actor that has no card yet or spells one inconsistently. Creates and maintains the canonical persona cards under docs/discovery/personas/ (one file per persona with its surface, goals, pains, jobs-to-be-done, and evidence links) so downstream artifacts reference stable persona slugs instead of drifting ad-hoc actor names. NOT for org-chart or stakeholder-power mapping, and NOT for market-segmentation research (deep-research).
- ▌ Prioritize Bets · arozumenko bundleUse when deciding what to build next, when validated hypotheses outnumber the team's appetite, when a ranking feels stale, or when someone asks which bet comes first. Ranks the incubating and promotion-ready bets against the active prioritization framework — RICE by default, with WSJF and ICE as config options — deriving the confidence factor from each hypothesis's evidence-banded confidence block (never free-guessed), persisting scores into hypothesis frontmatter so the ranking survives the session, warning (never blocking) when a bet is ranked on gut-band evidence, and rewriting the derived priority board at docs/discovery/priority.md. Trigger phrases — 'what should we build next', 'rank the backlog', 'prioritize the hypotheses', 'which bet comes first', 'the backlog is stale'. NOT for promotion-gate scoring, NOT for triaging raw incoming asks (intake-triage), and NOT for attacking the assumptions inside one hypothesis.
- ▌ Automation Scoping · arozumenko bundleUse when a scope of test cases (or a described backlog, before any cases even exist as files) needs sizing or a cost/time estimate BEFORE automation work starts — presales scoping, a proposal, "how long/much to automate these N cases", "size these cases S/M/L/XL", estimating the framework/CI/foundation work an engagement needs on top of its cases, sizing a new engagement, or recalibrating an estimate against a project's own delivery history. Produces a scoping report with a range and a stated confidence level, never a bare point number.
- ▌ Reproducing Issues · arozumenko bundleUse when a bug is unclear or unconfirmed and needs reproduction before RCA or any fix. Turns a vague bug report into precise, repeatable steps with evidence and a CONFIRMED / CANNOT-REPRODUCE / PARTIAL verdict. Reproduction and documentation only — does not fix code.
- ▌
- ▌ Capture Learning · arozumenko bundleUse when a hypothesis closes, an experiment concludes with a metric movement or a killed assumption, a vendor / data source / external service behaves differently than its docs implied, or a non-obvious product decision needs its rationale preserved — even if the user never says the word 'learning'. Captures a problem → outcome → lesson from product experiments and hypothesis outcomes (won or lost) into docs/discovery/evidence/learnings/ so the next similar discovery moves faster. Trigger phrases — 'capture learning', 'save what worked', 'document this lesson', 'what did we learn from X', 'we should remember that'. NOT for meeting minutes or transcripts, NOT for a durable forward-looking rule (record a decision via grill-decision), NOT for a retrospective, and NOT for a bare todo or a one-off observation.
- ▌ Discovery Status · arozumenkoUse when starting a work session, when the PO is unsure what to do next, or when promotion, gates, blockers, what's-stuck, where-am-I, or am-I-ready-for-review come up — even without the word 'status'. Reports the whole discovery pipeline as one navigable dashboard — where every hypothesis stands against the promotion gate, what is blocked and on whom, the tracker board versus what docs/discovery/ says, and the exact next action (naming the exact skill) for each item; read-only, reading the docs/discovery/ tree and the product-owner's role memory directly and re-deriving gate state from the promotion checklist in prose (no vault, no validator script). NOT for code or CI status, PR-review state, deployment health, or git status — those are different tools.
- ▌ Opportunity Tree · arozumenko bundleUse when mapping opportunities under an outcome, asking where a hypothesis hangs, spotting solution-shaped 'problems', or when a new Problem or Hypothesis has no parent. Maintains the opportunity–solution tree over existing Discovery artifacts by adding only node_type / parent frontmatter to existing files and regenerating the derived docs/discovery/outcome-tree.md board (no new file silo); applies the disguise test (an opportunity that cannot spawn 3+ different solutions may be a solution in disguise) and annotates opportunities with Olsen scores for prioritize-bets. Trigger phrases — 'map the opportunity tree', 'where does this hypothesis hang', 'is this an opportunity or a solution', 'regenerate the outcome tree'. NOT for authoring outcome anchors (define-outcomes), NOT for ranking bets (prioritize-bets), and NOT for reconciling journeys against the backlog (journeys-to-hypotheses).
- ▌ Secure Code Review · arozumenko bundleUse when reviewing code for security defects with citations anyone can re-check, giving a second opinion on one finding, or verifying a fix at a commit; provides cite.mjs and verify.mjs.
- ▌ Plan Feature · arozumenko bundleUse when the user says "plan a feature", "design this", "how should we build", or before writing code for any non-trivial feature. Produces an approved task breakdown before implementation begins — plan first, build second.
- ▌ Accessibility Audit · arozumenko bundleAccessibility and WCAG compliance analysis, from the accessibility snapshot and visual review — flags issues automated axe-style scans miss.
- ▌ Risk Register · arozumenko bundleUse when recording, accepting, expiring, closing, superseding or ticketing residual security risks in the append-only register, or reading its exposure and approval counts; provides register.mjs.
- ▌ Browser Verify · arozumenko bundleUse when you need to run arbitrary JS in a page, inspect cookies/localStorage, check computed styles, emulate devices, or drive real mouse/keyboard events. Chrome DevTools Protocol browser automation with zero external dependencies.
- ▌ Issue Tracking · arozumenko bundleUse when the user asks to 'create an issue', 'file a bug', 'check issues', 'update a ticket', 'create an epic', or anything about issue or ticket management. Creates, manages, and tracks issues in GitHub, Linear, or GitLab.
- ▌ Code Review 2 · arozumenko bundleUse when the user asks to 'review this code', 'check my changes', 'review PR', 'audit' — and proactively after a non-trivial change or before opening, approving, or merging a PR, even unprompted. Reviews code for correctness, security, performance, and maintainability.
- ▌ Plan Feature 2 · arozumenko bundleUse when the user says "plan a feature", "design this", "how should we build", or before writing code for any non-trivial feature. Produces an approved task breakdown before implementation begins — plan first, build second.
- ▌ Screen Specs · arozumenko bundleUse when screens need designing or documenting as reference a developer or agent can build from — "design the screens", "screen specs", "what should this screen look like", "turn the flows into designs", "document the UI", or when a flow map's nodes need to become actual screens. Produces standalone HTML pages showing each screen as a device-framed mock beside its spec — regions with Material component and token names, every state the criteria demand, the MD3-vs-platform calls, accessibility notes, and traceability back to a flow node and acceptance criterion. Mock and spec are generated from one source so they cannot drift. NOT for flow/journey diagrams (use user-flow-maps), NOT a design tool replacement, and NOT for writing the screens' production code.
- ▌ Tosca Automation · arozumenko bundleUse when the user asks to create a TOSCA test case, run a playlist, organize cases, or perform any TOSCA Cloud REST/CLI operation. Tricentis TOSCA Cloud automation via the bundled tosca_cli.py — create/update/run TestCases, Modules, Reusable Blocks, Playlists, folders, and TSU import/export.
- ▌ Gathering Context · arozumenko bundleUse when the user says 'what do we know about X', 'find prior discussions with Y', or before drafting any reply where prior history matters. Gathers cross-channel context (local KB, email, Teams, optional web) about a person or topic before responding.
- ▌ Knowledge Curation · arozumenko bundleUse when promoting a hard-won fact from per-role memory into the shared, committed `.agents/knowledge/` layer, auditing that layer for stale or unindexed notes, or retiring a fact that stopped being true. Also use at the end of a substantial session or mission to sweep memory for anything cross-role worth committing. Not for per-role notes or daily logs (that is the `memory` skill), and not for mission state (that belongs on the work board).
- ▌ Verifying Outcomes · arozumenko bundleUse when the user asks to 'verify', 'did this actually work', 'is X really done' — or before you claim a task is complete and before closing an issue or merging a PR. Goal-backward verification — checks whether the desired outcome was achieved, not whether tasks were marked done.
- ▌ UX Audit · arozumenko bundleUI/UX, forms, and page-type analysis. Checks general UI patterns, form usability, and domain-specific UX for 20+ page types.
- ▌ XLSX Reader · arozumenko bundleUse when the user provides an Excel file of test cases or requirements, or asks to import a spreadsheet. Reads .xlsx/.xls spreadsheets (test cases, checklists, requirement matrices) into Markdown tables so an agent can ingest them.
- ▌ Privacy Audit · arozumenko bundlePrivacy, cookie consent, and GDPR analysis. Audits cookies, trackers, consent banners, and GDPR compliance from network traffic and the page.
- ▌ Quality Evals · arozumenko bundleUse when a team wants to validate test-runner's bug-detection accuracy or test-author's authoring fidelity against their OWN app before trusting the manual-qa bundle on real work — "how good is this agent, really", "benchmark test-author/test-runner", "build a gold suite", "self-eval the manual QA team". Ports a held-out-answer-key eval methodology (deterministic Tier A scoring + a judged Tier B rubric) that keeps a self-authored eval honest, generalized to any app.
- ▌ Mobile Testing · arozumenko bundleUse when profiling a mobile app, authoring or sizing mobile TCs, orchestrating a mobile suite run, executing a mobile TC, generating a manual guide, or producing a mobile run report. Mobile-app testing for all manual-qa agents — native iOS/Android via Appium MCP and the Mobitru device farm, and PWA/hybrid via Playwright mobile viewport.
- ▌ Security Audit · arozumenko bundleSecurity and OWASP analysis. Reviews for XSS, CSRF, injection risks, missing security headers, and exposed data.
- ▌ Responsive Audit · arozumenkoResponsive-layout analysis on a real browser — viewport configuration, touch-target sizing, and mobile-layout issues via a resized Playwright viewport.
- ▌ Intake Triage · arozumenko bundleUse when a raw ask arrives — a feature request, stakeholder ask, support theme, or 'someone wants X' — before anything becomes a Problem or Hypothesis. Verdicts every item Act Now / Plan Next / Collect More Signal / Decline-or-Defer, writes one batch record, and mints accepted in-scope items as Problems carrying discovered_from provenance; out-of-scope asks are declined against the scope line, and raw material naming a person stays in the confidential inbox with records referring by role. Trigger phrases — 'triage these requests', 'here are the asks from the sales call', 'someone wants X, what do we do with it', 'sort these into the pipeline'. NOT for interview synthesis (stakeholder-interview), NOT for bug or support-ticket triage, and NOT for meeting minutes.
- ▌ Threat Modeling · arozumenko bundleUse when deriving a data-flow diagram and STRIDE threats from code, with a citation per element and mitigations recorded as claims a fresh reviewer can confirm or refute; provides the threat-model.json shape cite.mjs check validates.
- ▌ Efficiency Audit · arozumenko bundleUse when the user asks 'what did this cost', cost per session/role/test case, which role or sub-agent burned the most, tool-call/skill/time breakdowns, 'before vs after' cost comparisons, or wants to audit AI spend over time. Measures the token/cost/time efficiency of AI coding-agent work — per session, per role, per day, and per individual sub-agent — with every dollar metered by ccusage.
- ▌ Grill Decision · arozumenko bundleUse when you're trying to make a hard call, sharpen fuzzy language, interrogate a fresh Hypothesis before promotion, or pressure-test a plan or new initiative — even if you don't say 'grill'. A Socratic, one-question-at-a-time interview that walks the decision tree branch by branch, taking a position on each question instead of asking open-ended ones and reading (never asking for) what is already written down; it challenges every idea against the project's guardrails, open pending decisions, and established terminology, and captures outcomes inline the moment they crystallize — a sharpened term edited into the artifact that used it, a real decision written as a DEC entry in decisions.md, a hypothesis edited in place. NOT for adversarial claim verification against external sources, NOT for feasibility sign-off, and NOT for code / PR review or CI status.
- ▌ User Flow Maps · arozumenko bundleUse when a user flow, journey, or screen-to-screen behaviour needs to become a visual flow map — "draw the flow", "make a flow map", "user flow diagram", "map the screens", "turn these journeys into diagrams", or when acceptance criteria need a picture reviewers can sign off on. Renders a spec of screens, decisions and transitions into standalone HTML posters — numbered screen wireframes, decision diamonds, Start/End markers naming where a flow hands off, orthogonal connectors routed from the data, and an authoritative edge table. Layout, routing and label collision are handled by the bundled flowmap.js; you supply data, never coordinates. NOT for architecture or sequence diagrams, NOT for visual/UI design of the screens themselves (that is a design role's job), and NOT a mermaid replacement — the source diagram stays canonical.
- ▌ Atlassian Content · arozumenko bundleUse when the user says 'file a bug', 'comment on JIRA-123', 'write up a decision page', or authors any Atlassian content. Creates well-formatted Jira issues/comments and Confluence pages on both Cloud and Server/Data Center, with mandatory post-creation re-fetch plus repair.
- ▌ Completing A Task · arozumenko bundleUse when a routed task has been implemented and the working code needs to be committed, pushed, PR'd, commented on the issue, and handed to a reviewer. The canonical task-handoff protocol; runs standalone or as the final phase of implement-feature.
- ▌ Browser Verify 2 · arozumenko bundleUse when you need to run arbitrary JS in a page, inspect cookies/localStorage, check computed styles, emulate devices, or drive real mouse/keyboard events. Chrome DevTools Protocol browser automation with zero external dependencies.
- ▌ Issue Tracking 2 · arozumenko bundleUse when the user asks to 'create an issue', 'file a bug', 'check issues', 'update a ticket', 'create an epic', or anything about issue or ticket management. Creates, manages, and tracks issues in GitHub, Linear, or GitLab.
- ▌ User Flow Maps 2 · arozumenko bundleUse when a user flow, journey, or screen-to-screen behaviour needs to become a visual flow map — "draw the flow", "make a flow map", "user flow diagram", "map the screens", "turn these journeys into diagrams", or when acceptance criteria need a picture reviewers can sign off on. Renders a spec of screens, decisions and transitions into standalone HTML posters — numbered screen wireframes, decision diamonds, Start/End markers naming where a flow hands off, orthogonal connectors routed from the data, and an authoritative edge table. Layout, routing and label collision are handled by the bundled flowmap.js; you supply data, never coordinates. NOT for architecture or sequence diagrams, NOT for visual/UI design of the screens themselves (that is a design role's job), and NOT a mermaid replacement — the source diagram stays canonical.
- ▌ Memory · arozumenko bundleUse when the user says 'remember this' or 'log this', asks 'what did you learn yesterday', or whenever you discover something worth keeping across sessions. Per-role persistent memory — durable facts, preferences, decisions, and a daily log, as plain markdown.
- ▌ Vividus · arozumenko bundleUse when the user mentions Vividus, .story files, vividus-bom/-starter, backtick-parameter BDD, or ./gradlew runStories. Bootstrap, configure, and author tests for the Vividus BDD framework — JBehave-based, config-first .story files spanning web/REST/mobile/DB via 47+ plugins.
- ▌ Xray Testing · arozumenko bundleUse when the user says 'pull test PROJ-T42', 'create Xray test from this AFS', 'upload JUnit to test plan', or performs any Xray CRUD. CRUD plus results import on Xray entities (Test, Precondition, Test Set/Plan/Execution/Run) across Cloud (GraphQL) and Server/DC (REST).
- ▌ Deep Research · arozumenko bundleUse when the user asks to 'research trends', 'analyze a topic', 'fact-check this', 'verify claims', 'what's the state of X', or hands you a document to vet. A disk-first, checkpointed research workflow with three modes — trend research, topic analysis, and fact-checking.
- ▌ Microsoft 365 · arozumenko bundleUse when the user asks to 'check my email/Teams/calendar', 'what meetings do I have', 'any messages about X', or whenever a task needs live Microsoft 365 data rather than memory. Microsoft 365 (Graph) access to email, Teams, calendar, and SharePoint — scriptable scans plus an interactive query.py.
- ▌ Obsidian Vault · arozumenko bundleUse when the user says 'save to vault', 'log this note', 'find my notes about X', 'what's in my inbox', 'open loops', or when filing an incoming signal (email/chat/memo) or updating people/project/meeting notes. Headless, file-system Obsidian vault operations, no Obsidian app needed.
- ▌ Visual Testing · arozumenko bundleUse when rendered UI needs visual regression checking — "did the UI change", "visual test", "screenshot diff", "compare against the baseline", "catch layout regressions", or a visual assertion in a test run. Works on any HTML you can render — a generated static page (design mock, report, flow-map poster) opened from disk, or a running app driven by your existing browser/device automation. Screenshots each screen, diffs it against a committed baseline with reg-cli (MIT, no cloud), and reports what changed as an HTML report plus a pass/fail summary. Capture rides on whatever browser or device tool you already have — no separate headless engine is installed. NOT a functional or correctness check (a diff proves pixels moved, not that anything is right), and a red diff is a prompt to look, not an automatic verdict.
- ▌ Delivery Monitor · arozumenko bundleDelivery monitor for harness work items — the cycle-time and cadence sibling of tokenomics. Registers a plan (campaign → mission → task) with ranged, human-accepted estimates, records dispatch/merge/cancel transitions into a git-committed event ledger (.agents/telemetry/delivery/), backfills history from git, and reports cycle time, weekly throughput/velocity and estimate-vs-actual delta per level. Use when the user asks "how fast are we delivering", "register the plan / estimates", "record that TASK-023 merged", "delivery report / status", "enable delivery tracking", or "how good were our estimates". For cost per case use tokenomics; for sizing new work use automation-scoping.