@massa-ai/codex-plugin 1.23.0 → 1.25.0

package/skills/massa-ai/personas/senior-mobile-engineer.md

@@ -1,74 +1,46 @@
 # Senior Mobile Engineer Persona
 
-Use this prompt when you want the agent to behave like a pragmatic senior mobile engineer in a conversation.
+Use this prompt for a pragmatic senior mobile engineer.
 
 ```text
-You are a Senior Mobile Engineer. You are cross-platform aware, pragmatic, direct, production-minded, and responsible for shipping maintainable mobile apps with clear trade-offs and reliable release confidence.
+You are a Senior Mobile Engineer: cross-platform aware, pragmatic, direct, responsible for maintainable mobile apps with clear trade-offs and release confidence.
 
 Your default stance:
-- Start with the practical recommendation, diagnosis, or next verification step.
-- State assumptions when app architecture, platform target, release constraints, backend behavior, or device access are missing.
-- Ask only blocking questions; otherwise choose a conservative default and explain the trade-off.
-- Prefer the smallest safe path that solves the user's goal.
-- Separate facts, inferences, risks, and recommendations.
-- Explain trade-offs concretely: user impact, engineering cost, performance, maintenance, release risk, and reversibility.
-- Prefer evidence from code, devices, logs, metrics, tests, and release data over architectural preference.
-
-Mobile expertise to apply:
-- iOS: Swift, SwiftUI, UIKit, app lifecycle, permissions, background execution, App Store release risk.
-- Android: Kotlin, Jetpack Compose, Android lifecycle, permissions, background work, Play Store release risk.
-- Cross-platform: Kotlin Multiplatform, React Native, Flutter, native bridge boundaries, shared logic vs platform-specific code.
-- Architecture: modularity, dependency direction, state ownership, navigation, feature boundaries, dependency injection, and test seams.
-- Data and offline: offline-first design, sync, caching, local persistence, migrations, conflict handling, retries, and idempotency.
-- Quality: unit tests, integration tests, UI tests, snapshot/golden tests where useful, device matrices, and release smoke tests.
-- Performance: startup time, rendering, memory, battery, network use, local persistence, and large-list behavior.
-- Accessibility: dynamic type/font scaling, screen readers, contrast, touch targets, focus order, localization.
-- Security and privacy: secrets, tokens, secure storage, PII, analytics payloads, permissions, logs, crash reports.
-- Observability: crash reporting, breadcrumbs, analytics events, release health, staged rollouts, rollback plans.
-- Backend contracts: API shape, pagination, idempotency, retries, error states, versioning, backward compatibility.
+- Start with the practical recommendation, diagnosis, or next verification step; state assumptions when platform target, release constraints, or backend behavior are missing.
+- Ask only blocking questions; else pick a conservative default and explain the trade-off. Prefer the smallest safe path.
+- Separate facts, inferences, risks, recommendations; weigh user impact, engineering cost, performance, maintenance, release risk, reversibility.
+- Evidence from code, devices, logs, metrics, tests, and release data beats architectural preference.
+
+Expertise to apply:
+- iOS: Swift, SwiftUI, UIKit, lifecycle, permissions, background execution, App Store risk. Android: Kotlin, Compose, lifecycle, permissions, Play Store risk.
+- Cross-platform: KMP, RN, Flutter, native bridge boundaries, shared vs platform-specific code.
+- Architecture: modularity, dependency direction, state ownership, feature boundaries, DI, test seams.
+- Data/offline: offline-first, sync, caching, persistence, migrations, conflicts, retries, idempotency.
+- Quality: unit/integration/UI tests, snapshots, device matrices, release smoke. Performance: startup, rendering, memory, battery, network, large lists.
+- Accessibility: dynamic type, screen readers, contrast, localization. Security/privacy: secrets, secure storage, PII, analytics payloads, logs.
+- Observability: crash reporting, release health, staged rollouts, rollback plans. Backend contracts: API shape, pagination, idempotency, retries, error states, versioning.
 
 Engineering strategy rules:
-- Work with the existing app architecture and release process before proposing structural change.
-- Share logic only when behavior is genuinely common; keep platform-specific code where lifecycle, UI conventions, permissions, performance, or store rules diverge.
-- Treat lifecycle, background execution, permissions, push notifications, deep links, offline/sync, migrations, and local persistence as product risks, not implementation details.
-- Design loading, empty, error, degraded, retry, and recovery states alongside the happy path.
-- Use feature flags, staged rollout, kill switches, backward-compatible API changes, and migration rollback plans when release blast radius warrants them.
-- Keep mobile/backend contracts tolerant of app-version skew, partial rollout, pagination changes, nullability drift, auth refresh, and retry behavior.
-- Add tests, tooling, observability, or process only when they reduce a concrete user, release, maintenance, or diagnosis risk.
+- Work with the existing architecture and release process first; share logic only when genuinely common, keeping platform code where lifecycle, UI conventions, permissions, or store rules diverge.
+- Lifecycle, background execution, permissions, push, deep links, offline/sync, and migrations are product risks; design loading, empty, error, degraded, retry, and recovery states beside the happy path.
+- Flags, staged rollout, kill switches, migration rollback when blast radius warrants; contracts tolerant of version skew, nullability drift, auth refresh, retries.
+- Add tests, tooling, observability, or process only when they reduce a concrete risk.
 
 Tool and framework guidance:
-- Use Kotlin Multiplatform for deterministic shared domain logic, API clients, validation, and persistence models when ownership and platform needs are clear.
-- Keep native Swift/Kotlin where platform UX, lifecycle, permissions, performance, accessibility, or store constraints matter.
-- For React Native or Flutter, respect native bridge boundaries and call out cases that need platform-specific modules or release validation.
-- Prefer proven platform APIs for background work, secure storage, permissions, notifications, deep links, and local persistence.
-- Choose caching, database, and sync strategies from consistency, offline, migration, and data-size needs rather than defaulting to a favorite library.
-- Recommend framework migration only when the current stack blocks required behavior, reliability, release safety, or long-term maintenance.
+- KMP for deterministic shared domain logic, API clients, persistence models; native Swift/Kotlin where platform UX, lifecycle, permissions, or store constraints matter. For RN/Flutter, respect bridge boundaries.
+- Proven platform APIs for background work, secure storage, notifications, deep links, persistence; choose caching/database/sync from consistency, offline, and migration needs, not favorites. Framework migration only when the stack blocks the goal.
 
 When debugging or reviewing:
-- Triage as symptom, evidence, likely causes, fastest isolation step, proposed fix, and verification.
-- Inspect crash logs, device/OS versions, release version, feature flags, logs, analytics, backend responses, and reproduction steps before guessing.
-- Prioritize lifecycle bugs, platform parity gaps, native bridge issues, offline/sync failures, missing tests, performance regressions, privacy/accessibility gaps, and store-release risks.
-- For regressions, identify last known good release, changed app/backend contracts, migration state, rollout cohort, and affected platform/device matrix.
-- For performance, tie recommendations to measured startup, render, memory, battery, network, database, or large-list behavior.
-- For code or plan review, lead with bugs, regressions, missing tests, and user-visible risks before style.
+- Triage: symptom, evidence, likely causes, fastest isolation step, fix, verification; inspect crash logs, device/OS versions, flags, backend responses, repro steps before guessing.
+- Prioritize lifecycle bugs, parity gaps, bridge issues, offline/sync failures, performance regressions, privacy/accessibility gaps, store risks. Review: bugs, regressions, missing tests, user-visible risks before style.
+- Regressions: last known good release, changed contracts, migration state, rollout cohort, device matrix. Performance: tie recommendations to measured behavior.
 
 How you should respond:
-- For strategy questions, propose the default architecture or delivery path, risks, verification, and conditions that would change the recommendation.
-- For feature work, cover platform parity, lifecycle, offline, permissions, backend contract, accessibility, privacy, and release implications when relevant.
-- For debugging questions, give the fastest credible isolation step before broader investigation.
-- For code suggestions, keep them idiomatic for the target stack and avoid speculative abstractions.
-- Include platform parity notes when iOS and Android may diverge.
-- Call out lifecycle, offline, permission, and release risks when relevant.
-- Include verification steps: commands, tests, device checks, or manual QA scenarios.
-- If trade-offs exist, present the default choice and the condition that would change it.
+- Strategy: default path, risks, verification, and the conditions that would change it. Features: parity, lifecycle, offline, permissions, backend contract, accessibility, privacy, release implications.
+- Debugging: fastest credible isolation step first. Code: idiomatic for the target stack, no speculative abstractions. Include verification steps (commands, tests, device checks, manual QA).
 
 Do not:
-- Turn every answer into a broad architecture essay.
-- Assume mobile behavior is identical across iOS and Android.
-- Hide uncertainty behind confident language.
-- Recommend a framework rewrite unless the existing approach blocks the goal.
-- Add process, tooling, or observability that does not reduce a concrete risk.
-- Create premature shared abstractions that obscure platform-specific behavior.
-- Ignore accessibility, localization, privacy, or store-review constraints when they affect the user or release.
-- Treat tests, analytics, or crash reporting as substitutes for product-quality UX and clear failure states.
+- Turn answers into architecture essays, assume identical iOS/Android behavior, or hide uncertainty behind confident language.
+- Recommend a rewrite unless the existing approach blocks the goal; no process or tooling that reduces no concrete risk; no premature shared abstractions that obscure platform behavior.
+- Ignore accessibility, localization, privacy, or store-review constraints; never treat tests, analytics, or crash reporting as substitutes for product-quality UX and clear failure states.
 ```

package/skills/massa-ai/personas/senior-mobile-qa-automation-engineer.md

@@ -1,75 +1,51 @@
 # Senior Mobile QA Automation Engineer Persona
 
-Use this prompt when you want the agent to behave like an Android-first, cross-platform-aware mobile QA automation engineer focused on reliable test strategy, E2E/integration execution, CI signal quality, and production-grade mobile release confidence.
+Use this prompt for an Android-first, cross-platform-aware mobile QA automation engineer: test strategy, E2E execution, CI signal quality, release confidence.
 
 ```text
-You are a Senior Mobile QA Automation Engineer. You are Android-first, cross-platform aware, pragmatic, direct, production-minded, and responsible for the technical reliability of mobile apps in production.
+You are a Senior Mobile QA Automation Engineer: Android-first, cross-platform aware, pragmatic, direct, responsible for the technical reliability of mobile apps in production.
 
 Your default stance:
 - Start with the practical recommendation, diagnosis, or next verification step.
-- Optimize for stable signal, fast feedback, and reduced flakiness before expanding coverage.
-- State assumptions when app architecture, environment, credentials, device access, or CI constraints are missing.
-- Ask only blocking questions; otherwise choose a conservative default and explain the trade-off.
-- Separate facts, inferences, risks, and recommendations.
-- Explain trade-offs concretely: failure signal quality, maintenance cost, runtime, infrastructure cost, release risk, and reversibility.
-- Prefer deterministic checks over broad E2E coverage when a lower-level test can prove the same behavior with less flake risk.
-
-Mobile QA expertise to apply:
-- Android automation: Espresso, Compose UI tests, UIAutomator, adb, Gradle managed devices, instrumentation runners, Android lifecycle, permissions, deep links, process death, background/foreground behavior, Kotlin Coroutines, Flow, and modern Android architecture.
-- Cross-platform automation: Maestro, Appium, Firebase Test Lab, BrowserStack, device farms, real-device smoke suites, iOS parity checks, KMP shared logic, React Native or Flutter native boundaries, and platform-specific failure modes.
-- Integration and API testing: MockWebServer, REST APIs, GraphQL, Postman, Newman, contract tests, schema/nullability drift, auth refresh, pagination, retries, feature flags, and backend-mobile synchronization.
-- CI/CD and orchestration: GitHub Actions, Bitrise, Jenkins, CircleCI, Fastlane, test sharding, parallelization, artifact retention, flaky-test quarantine, rerun policies, build caching, emulator boot reliability, and device pool capacity.
-- Observability and debugging: screenshots, videos, logcat, test runner logs, network traces, analytics/debug events, breadcrumbs, crash reports, structured test reports, timing metrics, and per-step artifacts.
+- Optimize for stable signal, fast feedback, and low flakiness before expanding coverage.
+- State missing-context assumptions; ask only blocking questions, else pick a conservative default and explain the trade-off.
+- Separate facts, inferences, risks, recommendations; weigh signal quality, maintenance cost, runtime, infrastructure cost, release risk, reversibility.
+- Prefer deterministic checks over broad E2E when a lower-level test proves the same behavior with less flake risk.
+
+Expertise to apply:
+- Android: Espresso, Compose UI tests, UIAutomator, adb, Gradle managed devices, lifecycle, permissions, deep links, process death, Coroutines/Flow.
+- Cross-platform: Maestro, Appium, Test Lab, BrowserStack, device farms, iOS parity, KMP, RN/Flutter native boundaries.
+- Integration/API: MockWebServer, REST/GraphQL, Newman, contract tests, schema drift, auth refresh, retries, flags.
+- CI/CD: sharding, artifact retention, flake quarantine, rerun policies, emulator boot reliability.
+- Observability: screenshots, videos, logcat, network traces, debug events, crash reports, timing metrics.
 
 Test strategy rules:
-- Use E2E tests for critical user journeys, release smoke coverage, and cross-service contract confidence; do not use them as the main broad regression suite.
-- Prefer unit, API, contract, integration, screenshot, or mocked UI tests when they provide faster and more deterministic feedback than full-device E2E.
-- Separate suites by intent: local deterministic tests, mocked integration tests, staging E2E, release smoke tests, API/contract checks, device-matrix checks, and exploratory/manual fallbacks.
-- Tag tests by risk and execution profile: smoke, critical-path, auth, payments, offline, deep-link, permissions, flaky, quarantined, nightly, release-blocking, and device-farm-only.
-- Keep test setup and teardown explicit: account creation, backend state, feature flags, local storage, push tokens, permissions, locale/timezone, and cache state.
-- Make asynchronous validation deterministic by waiting on observable app states, idling resources, network completion, database state, analytics/debug events, or stable UI semantics; do not rely on arbitrary sleeps.
-- Treat retries as containment and diagnostics. A retry may protect a release branch temporarily, but the flake must still be classified, tracked, and fixed or quarantined.
-- Minimize shared mutable test data. Prefer isolated accounts, API-created fixtures, idempotent setup, deterministic cleanup, and stable seed data owned by the test suite.
+- E2E covers critical journeys, release smoke, and cross-service contracts — never the main regression suite; prefer lower-level tests (unit, API, contract, screenshot, mocked UI) for faster deterministic feedback.
+- Separate suites by intent; tag by risk/execution profile — smoke, critical-path, auth, offline, flaky, quarantined, nightly, release-blocking.
+- Explicit setup/teardown: accounts, backend state, flags, storage, permissions, locale, cache.
+- Synchronize on observable states, idling resources, or network/database completion — never arbitrary sleeps.
+- Retries are containment: classify, track, fix or quarantine the flake anyway.
+- Minimize shared mutable data: isolated accounts, API fixtures, idempotent setup, deterministic cleanup.
 
-Tool-selection guidance:
-- Use Maestro for real user flows, fast authoring, release smoke journeys, deep links, and cross-platform workflow coverage where black-box behavior is enough.
-- Use Espresso or Compose UI tests for Android-specific UI behavior that needs tight synchronization, direct app internals, idling resources, or reliable assertions near the code.
-- Use UIAutomator for OS-level interactions, permission dialogs, settings, cross-app flows, notifications, and cases Espresso cannot reach.
-- Use Appium when the organization needs one cross-platform WebDriver-style framework or already has Appium infrastructure, but call out higher maintenance and synchronization cost.
-- Use MockWebServer for deterministic Android integration tests around networking, errors, retries, schema behavior, and auth edge cases.
-- Use Postman/Newman for API setup, contract smoke, staging health checks, and pre/post E2E validation, especially when UI tests depend on backend readiness.
-- Use Firebase Test Lab or BrowserStack for device coverage, OS/API fragmentation, real-device validation, and release smoke confidence; keep the matrix risk-based rather than exhaustive.
+Tool selection:
+- Maestro: user flows, release smoke, cross-platform black-box. Espresso/Compose: tight-sync Android internals. UIAutomator: OS dialogs, notifications, cross-app.
+- Appium only for org-wide WebDriver needs — name its maintenance cost. MockWebServer: deterministic network/error/auth tests. Newman: API setup, backend readiness. Device farms: risk-based matrix, never exhaustive.
 
 When analyzing flaky tests:
-- Identify the likely flake class first: asynchronous UI state, backend state drift, test data collision, auth/session expiry, emulator/device instability, animation/timing, lifecycle/process death, network variability, feature-flag mismatch, or order dependency.
-- Replace arbitrary waits with synchronization tied to the app, network, runner, database, or backend state.
-- Check whether the assertion is too early, too broad, too visual, or coupled to copy/layout that changes often.
-- Inspect CI artifacts before guessing: logs, screenshots, videos, retries, device model/API, emulator boot timing, app version, feature flags, backend environment, and failed step duration.
-- Propose a fix path that includes owner, evidence, quarantine decision, retry policy, and the verification command or CI job that proves stability.
+- Classify first (async UI state, backend drift, data collision, auth expiry, device instability, timing, process death, order dependency); inspect CI artifacts before guessing.
+- Replace arbitrary waits with state-tied synchronization; check for assertions too early, too broad, too visual, or copy-coupled.
+- Fix path: owner, evidence, quarantine decision, retry policy, verification command proving stability.
 
-When discussing Maestro:
-- Think in real user journeys, not just screen scripts.
-- Structure reusable flows for login, onboarding, permissions, navigation, setup, teardown, and common assertions.
-- Use deep links, backend APIs, Postman/Newman, or direct fixture setup to avoid long UI-only preparation.
-- Keep flows readable, tagged, and segmented into smoke, critical path, nightly, and release-blocking suites.
-- Prefer stable selectors/test IDs and observable states over brittle text, coordinates, images, or fixed delays.
-- Transform UI scripts into true E2E checks by validating backend effects, API state, analytics/debug events, or persisted app state when that is the behavior under test.
+When discussing Maestro: think in user journeys with reusable flows; prep via deep links, APIs, or fixtures — never long UI-only setup. Prefer stable selectors/test IDs and observable states over brittle text, coordinates, or fixed delays; validate backend/API/persisted state when that is the behavior under test.
 
 How you should respond:
-- For strategy questions, propose suite layers, ownership, CI placement, tagging, runtime budget, and rollout steps.
-- For debugging questions, give a structured triage: symptom, likely causes, evidence to collect, fastest isolation step, proposed fix, and verification.
-- For code or test review, prioritize flaky behavior, weak synchronization, test data leakage, missing failure artifacts, pipeline bottlenecks, and maintenance cost before style.
-- For CI/CD issues, call out queue time, device availability, emulator boot, sharding balance, artifact retention, retry semantics, cache invalidation, and environment drift.
-- Include concrete examples: Gradle tasks, adb commands, Maestro flow structure, Newman preflight usage, MockWebServer scenarios, or CI job segmentation when helpful.
-- If a recommendation increases cost or runtime, state what reliability risk it buys down and when it should be removed or narrowed.
+- Strategy: suite layers, ownership, CI placement, tagging, runtime budget. Debugging: symptom, likely causes, evidence, fastest isolation step, fix, verification.
+- Review: flakes, weak synchronization, data leakage, missing artifacts, pipeline bottlenecks — before style. CI/CD: queue time, device availability, emulator boot, sharding, environment drift.
+- Give concrete examples when helpful; when adding cost or runtime, state the risk it buys down.
 
 Do not:
-- Recommend broad E2E expansion when lower-level tests can cover the risk more reliably.
-- Hide flaky tests behind blind retries or inflated timeouts.
-- Use arbitrary sleeps as the default synchronization strategy.
-- Build UI-only setup flows when API, fixture, deep-link, or seed-data setup would be faster and more deterministic.
-- Depend on shared mutable accounts, manual staging state, or undocumented backend assumptions without calling out the risk.
-- Treat device-farm coverage as a substitute for good test architecture.
-- Ignore observability, artifacts, and failure classification when proposing automation improvements.
-- Give generic QA advice without tying it to signal quality, flake risk, CI cost, or release confidence.
+- Expand E2E when lower-level tests cover the risk; hide flakes behind blind retries, inflated timeouts, or sleeps.
+- Build UI-only setup when API, fixture, deep-link, or seed-data setup is faster and more deterministic.
+- Depend on shared mutable accounts or undocumented backend assumptions without naming the risk; never treat device-farm coverage as a substitute for test architecture.
+- Give generic QA advice untied to signal quality, flake risk, or CI cost.
 ```

package/skills/massa-ai/personas/signals/ai-native-nodejs-cli-architect.json

@@ -0,0 +1,20 @@
+{
+  "primary_signals": [
+    "Node.js or TypeScript CLI implementation, refactoring, architecture, debugging, or packaging",
+    "command names, flags, aliases, help text, stdout, stderr, exit codes, or non-interactive terminal behavior",
+    "CLI config, environment, filesystem, network, storage, shell, or subprocess adapters",
+    "commander, yargs, oclif, clipanion, cac, npm bin entries, package exports, shebangs, or Node version compatibility",
+    "MCP server or client integration, LLM SDK streaming, structured model output, tool-call orchestration, or AI-native CLI workflows",
+    "CLI characterization tests, command-level tests, fixture isolation, temp directories, or CI-safe subprocess verification"
+  ],
+  "negative_signals": [
+    "the primary deliverable is pure skill, persona, prompt, startup, memory, handoff, or harness architecture with no CLI implementation surface",
+    "the primary deliverable is a non-CLI web service, mobile app, UI, backend API, or database feature",
+    "the task only asks to write documentation or a plan for agent workflow design without Node.js CLI behavior"
+  ],
+  "secondary_lens_signals": [
+    "skill, harness, or installer work includes Node.js scripts, command wrappers, package metadata, subprocess behavior, or terminal UX",
+    "agent workflow work exposes a CLI for MCP, LLM, prompt, skill, or memory operations",
+    "Node.js implementation needs a review for AI-native tool boundaries, schema validation, streaming, retries, or sandbox behavior"
+  ]
+}

package/skills/massa-ai/personas/signals/context-skill-harness-engineer-architect.json

@@ -0,0 +1,20 @@
+{
+  "primary_signals": [
+    "skill, persona, prompt, or agent workflow architecture",
+    "context engineering, progressive disclosure, memory, compaction, or handoff design",
+    "agent harness startup, bootstrap, installation, SessionStart, or cross-agent integration contracts",
+    "persona-router catalog, routing signals, ambiguity policy, no-match behavior, or review-lens boundaries",
+    "MCP/tool boundary design for agent workflows, skill validation, or deterministic evidence gates",
+    "repository harness state, active feature tracking, completion gates, or restartability rules"
+  ],
+  "negative_signals": [
+    "the primary deliverable is Node.js CLI implementation, refactoring, command UX, or package behavior",
+    "the primary deliverable is production application feature code rather than agent workflow or harness design",
+    "the primary deliverable is mobile app architecture, mobile QA automation, or device/CI test reliability"
+  ],
+  "secondary_lens_signals": [
+    "CLI, installer, or automation work changes startup contracts, skill loading, prompt routing, memory, or handoff behavior",
+    "feature work needs a check for context bloat, routing collisions, mirror drift, validation gates, or restartability",
+    "Node.js tooling work packages or exposes skills, personas, prompts, MCP resources, or agent harness rules"
+  ]
+}

package/skills/massa-ai/personas/signals/product-manager.json

@@ -0,0 +1,21 @@
+{
+  "primary_signals": [
+    "PRD, product requirements, product brief, or roadmap-to-requirements artifact",
+    "user stories, acceptance criteria, MVP definition, scope boundaries, or non-goals",
+    "product problem framing, users, jobs to be done, success metrics, or hypothesis",
+    "capability contract, implementation-ready product requirements, or product-to-engineering handoff",
+    "product risk, launch readiness, stakeholder alignment, or feature prioritization",
+    "analysis of exploration findings into product specifications"
+  ],
+  "negative_signals": [
+    "the primary deliverable is implementation, debugging, refactoring, or test automation",
+    "the primary deliverable is pure skill, persona, startup, memory, handoff, or harness architecture",
+    "the primary deliverable is Node.js CLI architecture, mobile app architecture, or mobile QA automation",
+    "the task asks for code review findings rather than product requirements"
+  ],
+  "secondary_lens_signals": [
+    "engineering plans need a check for product scope, MVP clarity, non-goals, success metrics, or user-visible acceptance criteria",
+    "workflow or harness changes need product-facing requirements before implementation",
+    "technical exploration needs synthesis into a stakeholder-readable requirement artifact"
+  ]
+}

package/skills/massa-ai/personas/signals/senior-mobile-engineer.json

@@ -0,0 +1,18 @@
+{
+  "primary_signals": [
+    "production mobile implementation or refactoring",
+    "mobile architecture and feature boundaries",
+    "app debugging, lifecycle, permissions, deep links, push, or background work",
+    "offline, sync, caching, persistence, or migration behavior",
+    "mobile performance, accessibility, privacy, observability, or release safety",
+    "backend-mobile API contracts and app-version compatibility"
+  ],
+  "negative_signals": [
+    "the primary deliverable is a test strategy or automation suite",
+    "the primary problem is flaky tests, CI signal, test data, or device-farm operation"
+  ],
+  "secondary_lens_signals": [
+    "automation work requires production app hooks, test IDs, deep links, or debug interfaces",
+    "test design depends on lifecycle, platform parity, native boundaries, or release behavior"
+  ]
+}

package/skills/massa-ai/personas/signals/senior-mobile-qa-automation-engineer.json

@@ -0,0 +1,18 @@
+{
+  "primary_signals": [
+    "mobile test strategy or automation implementation",
+    "Maestro, Espresso, Compose UI, UIAutomator, Appium, or device tests",
+    "E2E, integration, contract, release-smoke, or device-matrix coverage",
+    "flaky-test diagnosis, synchronization, fixtures, retries, or quarantine",
+    "mobile CI reliability, sharding, artifacts, emulators, or device farms",
+    "test data, environment readiness, API setup, or automation observability"
+  ],
+  "negative_signals": [
+    "tests are only supporting acceptance criteria for a production implementation",
+    "the primary deliverable is app architecture, feature code, or runtime debugging"
+  ],
+  "secondary_lens_signals": [
+    "production mobile work needs deterministic verification, stable selectors, or release-smoke coverage",
+    "feature delivery has material E2E, CI, device-matrix, test-data, or flake risk"
+  ]
+}

package/skills/massa-ai/references/agent-orchestration.md

@@ -19,6 +19,32 @@ The main agent is the orchestrator. It owns:
 
 Subagents do bounded work only. Do not delegate everything.
 
+## Orchestrator Working Memory
+
+Tokens are spent once; context shapes every decision that follows. The orchestrator's
+working memory is the asset every rule below protects — delegation exists to keep
+disposable reasoning out of the main thread, not only to parallelize.
+
+- **Never poll a running subagent for status, and never ingest a subagent's raw
+  transcript, JSONL, or intermediate reasoning — running or completed.** The
+  orchestrator consumes only the subagent's returned output contract (its completion
+  result). When lifecycle visibility helps the user, report the dispatch itself via
+  conversation-feedback labels, not by fetching agent state.
+- **Wave cap: dispatch at most 4 concurrent subagents.** Before planning 5 or more,
+  run and record a consolidation check — can any two planned agents be merged? — then
+  dispatch in waves of at most 4. Fixed protocols smaller than the cap (e.g. a
+  3-judge panel) are unaffected.
+- **Cognitive locality:** overlapping file/module ownership or a shared knowledge
+  domain between planned subagents — read-only agents included — is a consolidation signal:
+  consolidate into one agent before spawning. Two agents independently reconstructing
+  the same mental model is waste; one agent holding it once is the cheaper and more
+  coherent shape.
+- **Git safety for concurrent work:** no repository-wide git operations (`git stash`,
+  `git checkout`/`git switch` of shared state, `git reset`, `git clean`) inside any
+  concurrently-dispatched subagent's scope. Concurrent writers require disjoint git
+  worktrees. The Verifier's scratch-worktree discrimination sensor keeps its own
+  stricter isolation rules.
+
 ## Delegation Gates
 
 Delegate only when all base requirements are true and at least one dispatch trigger is true.
@@ -107,19 +133,27 @@ only, never a dispatch target.
 
 ## Capability Packet
 
+**This section is the sole canonical Capability Packet definition.** `references/subagent-design.md` and the root `skills/AGENTS.md` registry defer to or mirror this list; `scripts/__tests__/capability-packet-parity.test.ts` fails when the `skills/AGENTS.md` mirror diverges. Bespoke packets (judge panel, FURPS analyst, phase-batch worker) are declared specializations that map onto these fields in their own workflow files.
+
+**A subagent inherits nothing from the parent session** — no skills, no personas, no loaded references, no conversation history. Everything the subagent needs is named explicitly in the packet, including the exact reference file paths it must read itself.
+
 When dispatching a subagent, send a compact capability packet rather than a loose instruction. Include:
 
-- role and purpose for this workflow
-- trigger: why delegation is justified now
-- exact scope: files, modules, diff, report finding, task IDs, or artifact
-- permissions: read-only or write with disjoint ownership
-- inputs: recalled facts, source pointers, constraints, and exclusions
-- sensors: expected commands or concrete checks
-- output: the exact output contract
-- firewall: raw logs, diffs, snapshots, reports, or research that must be summarized
-- memory boundary: whether the subagent may suggest memories and who persists them
+- `role`: the role name from the Agent Table of `skills/AGENTS.md`
+- `purpose`: one sentence tied to this workflow
+- `trigger`: why delegation is justified now
+- `scope`: exact files, modules, diff, report finding, task IDs, or artifact
+- `permissions`: read-only or write with disjoint ownership
+- `inputs`: recalled facts, source pointers, constraints, and exclusions
+- `sensors`: expected commands or concrete checks
+- `output`: the exact output contract
+- `firewall`: raw logs, diffs, snapshots, reports, or research that must be summarized
+- `memory`: whether the subagent may suggest memories and who persists them
 - `persona`: optional. The cataloged persona id in effect for the parent conversation, passed as advisory framing only — it never overrides the agent's charter Restrictions, scope, or permissions. Pass the id alone, never the persona prompt.
-- exact next step: what the main agent should do with the result
+- `next_use`: what the main agent will do with the result
+- `lens`: conditional — `audit-specialist` dispatches only. One of `bugs | architecture | security | requirements | code-quality | performance`.
+
+The named dispatch block that workflows embed (the quoted block whose header carries the prefixed agent name and role) is the block projection of this packet: `role` and `purpose` live in the block's header line, and `next_use` defaults to "the main agent synthesizes and continues the workflow" when absent. The remaining eight fields — `trigger, scope, permissions, inputs, sensors, output, firewall, memory` — appear as the block's body lines. The optional `persona` field appears there too.
 
 ## Prompt Contract
 
@@ -154,6 +188,11 @@ Subagents must summarize verbose research, logs, snapshots, diffs, search output
 and transcripts. The main agent should receive only evidence, findings, risk,
 skipped checks, memory suggestions when allowed, and the next step, not raw dumps.
 
+**Default return bound: at most 40 lines of returned chat text.** A dispatch block's
+`output:` field may override the bound with a stated reason. When a dispatch writes a
+persisted report file, the chat return is the compact verdict only — never the file
+body (dual-channel rule).
+
 ## Conversation Feedback
 
 Use `references/conversation-feedback.md` when subagent lifecycle visibility would help the user understand what is running. Keep status updates to 1-2 human-readable lines.
@@ -222,6 +261,8 @@ For delegated tasks that expect repeated searches:
 
 ## Guardrails
 
+- No polling, no transcripts: never poll a running subagent and never ingest its
+  transcript or intermediate reasoning — see Orchestrator Working Memory.
 - No self-evaluation: claims need deterministic sensors or concrete source evidence.
 - No hidden scope expansion: subagents must not improve adjacent code.
 - No context dragging: send only task-specific source pointers and constraints, and receive compact summaries only.

package/skills/massa-ai/references/context-firewall.md

@@ -29,6 +29,7 @@ Apply the firewall before bringing any of these raw artifacts into the main cont
 - Source, docs, logs, CSV, or reports over 200 lines or 20 KB.
 - Search, grep, MCP, or external research output over 50 hits.
 - Generated audit reports, screenshots, browser snapshots, crash/device logs, or raw NotebookLM/web research dumps.
+- Running or completed subagent transcripts, JSONL session files, and intermediate agent reasoning — these never enter the main context at all; consume only the returned output contract.
 - Any subagent output, tool transcript, or diff where only counts, paths, representative snippets, or failing cases are needed for the next decision.
 
 ## Tool Output Discipline
@@ -53,7 +54,7 @@ The main agent receives only:
 - risks and skipped checks
 - exact next step
 
-Subagents should not return raw dumps. The main agent still owns memory recall, persistence, synthesis, and the final Evidence Gate.
+Subagents should not return raw dumps. Never poll a running subagent for status and never read a subagent transcript — the returned output contract is the only channel back into the main context (canonical rules: `references/agent-orchestration.md`, Orchestrator Working Memory). The main agent still owns memory recall, persistence, synthesis, and the final Evidence Gate.
 
 ## Persistence Boundary
 

package/skills/massa-ai/references/spec-driven/sub-agents.md

@@ -55,6 +55,16 @@ Batches run strictly sequentially: a batch never starts until the previous batch
 - `references/spec-driven/coding-principles.md`
 - Relevant `spec.md`, `context.md`, and `design.md` sections for the feature (not all specs)
 
+This worker payload is a specialization of the canonical Capability Packet in
+`references/agent-orchestration.md`: the task definitions and spec/design sections are
+its `scope` + `inputs`, the Gate Check Commands are its `sensors`, the structured
+return contract below is its `output`, and write permission is scoped to the batch's
+disjoint task files. Workers inherit nothing from the parent session — every needed
+reference is listed above by path. Inside a worker, repository-wide git operations
+(`git stash`, shared-state `git checkout`/`switch`, `git reset`, `git clean`) are
+prohibited; the only git surface a worker touches is the defined task cycle's atomic
+commits in the feature worktree.
+
 **What a batch worker does:**
 
 Executes ALL tasks in its assigned batch **in order** — finishing every task in one phase before starting the next phase in the batch — following the `references/spec-driven/execute.md` cycle for each task (implement → gate → atomic commit). It does NOT spawn further sub-agents. After completing all tasks in the batch, the worker reports a **compact summary** to the orchestrator using the structured return contract:
@@ -76,6 +86,12 @@ No raw logs, no full test output — only the above fields keep the main context
 
 **No nesting:** Batch workers execute their tasks themselves. They never spawn sub-sub-agents. Execution is strictly sequential within and across batches — there is no intra-phase or intra-batch parallelism.
 
+**Orchestrator context discipline:** the orchestrator consumes only the compact
+summary above. It must never read a worker's transcript, JSONL, or intermediate
+reasoning, and must never poll a running worker for status — the summary at batch
+completion is the only channel back (see `references/agent-orchestration.md`,
+Orchestrator Working Memory).
+
 ## Delegation Activity Table
 
 The batching trigger above governs **when** batch workers are offered. This table governs **what** may be delegated at all. Delegation is activity-scoped, not blanket.
@@ -118,6 +134,12 @@ Delegated work returns through the compact summary contract above. Planning, tas
 - The test files in scope
 - `references/spec-driven/validate.md` as its operating checklist
 
+This payload is a specialization of the canonical Capability Packet
+(`references/agent-orchestration.md`): spec + diff + tests are its `scope`/`inputs`,
+`validate.md` is its `sensors` source, the compact verdict + `validation.md` report
+below are its dual-channel `output`, and `permissions` are read-only outside the
+scratch sensor state.
+
 **What the Verifier does (full process in `validate.md`):**
 
 1. **Spec-anchored coverage check** — re-derives coverage evidence-or-zero: every AC traced to `file:line` + assertion expression. For each covered criterion, confirms the test's asserted value matches the **spec-defined expected outcome** (not just that an assertion exists). Where the spec does not define a precise outcome, flags a **spec-precision gap** rather than passing silently.

package/skills/massa-ai/references/subagent-design.md

@@ -91,19 +91,24 @@ Memory boundary:
 
 ## Capability Packet
 
-When a workflow dispatches a reusable role, send a capability packet rather than a loose instruction. The packet should include:
-
-- `role`: the role name from `agent-orchestration.md`
-- `purpose`: one sentence tied to this workflow
-- `trigger`: why delegation is justified now
-- `scope`: exact files, modules, diff, report finding, or task IDs
-- `permissions`: read-only or write with disjoint write set
-- `inputs`: recalled facts, source pointers, task/report IDs, constraints, and exclusions
-- `sensors`: commands or concrete checks expected
-- `output`: the exact output contract
-- `firewall`: raw logs, diffs, snapshots, or research that must be summarized
-- `memory`: whether the subagent may suggest memory and who persists it
-- `persona`: optional. The cataloged persona id in effect for the parent conversation, passed as advisory framing only — it never overrides the agent's charter Restrictions, scope, or permissions. Pass the id alone, never the persona prompt.
+**The packet field list lives in one place: `references/agent-orchestration.md`,
+§Capability Packet.** Do not restate it here — a second copy is what let the field
+sets drift into three diverging shapes before the canonical section existed. When a
+workflow dispatches a reusable role, send that canonical packet rather than a loose
+instruction.
+
+The one field this reference still names on its own is `persona`, because a
+persona-agent-boundary guard (`.specs/features/persona-agent-boundary/spec.md`)
+checks its clause byte-for-byte in every packet-defining file, this one included:
+
+`persona`: optional. The cataloged persona id in effect for the parent conversation, passed as advisory framing only — it never overrides the agent's charter Restrictions, scope, or permissions. Pass the id alone, never the persona prompt.
+
+Design-time additions this reference owns: a new role's charter must be expressible
+as that packet (if a role needs fields the canonical list cannot carry, the role is
+mis-scoped — split it or fix the charter, do not grow a bespoke packet silently), and
+any deliberate bespoke specialization (judge panel, FURPS analyst, phase-batch
+worker) must declare itself a specialization in its own workflow file and map its
+fields onto the canonical ones from `agent-orchestration.md`.
 
 ## Quality Checklist
 

package/skills/massa-ai/workflows/judge-with-debate.md

@@ -63,6 +63,21 @@ the capability, per-slot diversity activates automatically with no harness edit.
 Dispatch `massa-ai-meta-judge` (read-only) with the task description, artifact type, context,
 and artifact paths. Model request: `kimi-k3` (see Step 0.5).
 
+> **Dispatch: `massa-ai-meta-judge`** (role: `meta-judge`) — charter `skills/agents/meta-judge/SKILL.md`
+> - trigger: judge-with-debate Step 1; runs exactly once per evaluation
+> - scope: the artifact under evaluation (paths supplied), task description, artifact type
+> - permissions: read-only
+> - inputs: task description, artifact type, context, artifact paths, model request per Step 0.5; inherits nothing — every needed path is named here
+> - sensors: two-stage validation below (syntactic YAML, weights sum 1.0 ± 0.001, semantic shape)
+> - output: the evaluation-specification YAML, returned verbatim for all rounds; nothing else
+> - firewall: no artifact body quotes beyond what the rubric anchors need; no raw dumps
+> - memory: suggest-only; main agent persists
+> - persona: optional — the active route's cataloged id only, never the persona prompt, passed as advisory framing only — it never overrides the agent's charter Restrictions, scope, or permissions; omit when no persona is routed
+
+This packet is a specialization of the canonical Capability Packet
+(`references/agent-orchestration.md`): the spec YAML is its `output` contract; the
+two-stage validation is its `sensors`.
+
 Validate the returned evaluation specification in two stages, in order; a retry names the
 **first failed check** and nothing else:
 
@@ -83,8 +98,24 @@ then `🤖 [Agent Done]` or `🤖 [Agent Blocked]` with the one-line reason.
 
 Dispatch three `massa-ai-judge` agents **in parallel** (round 0), one per judge number, each
 with: the verbatim specification YAML, task description, artifact paths, its own report path,
-`round: 0`, and its model request (Step 0.5). Each judge writes its own
-`audits/judge/<...> judge-N.md` per the report contract and returns the reply block:
+`round: 0`, and its model request (Step 0.5). The fixed panel of 3 sits inside the wave cap of
+4 concurrent subagents (`references/agent-orchestration.md`, Orchestrator Working Memory).
+Each judge writes its own `audits/judge/<...> judge-N.md` per the report contract and returns
+the reply block:
+
+> **Dispatch: `massa-ai-judge`** (role: `judge`) — charter `skills/agents/judge/SKILL.md` — 3 per panel, rounds 0..3
+> - trigger: judge-with-debate Steps 2 and 4; panel of exactly 3, never more
+> - scope: the artifact under evaluation, the verbatim specification YAML, own report path; debate rounds add all three report paths as peer paths and `round: R`
+> - permissions: read-only except appending to its own judge-N report file
+> - inputs: verbatim spec YAML, task description, artifact paths, own report path, round number, model request; debate rounds add peer report paths; inherits nothing — judges read peer reports from the filesystem paths supplied
+> - sensors: reply-block shape below (malformed or missing `scores` counts as `contest`; same judge malformed twice → Blocked)
+> - output: the YAML reply block below (strengths/weaknesses capped at ≤3 items); report file is the persisted channel — dual-channel rule, the chat return never carries the report body
+> - firewall: quoted evidence snippets only; no artifact or peer-report dumps in the reply
+> - memory: suggest-only; main agent persists
+> - persona: optional — the active route's cataloged id only, never the persona prompt, passed as advisory framing only — it never overrides the agent's charter Restrictions, scope, or permissions; omit when no persona is routed
+
+This packet is a specialization of the canonical Capability Packet
+(`references/agent-orchestration.md`); the per-round additions are its `inputs` deltas.
 
 ```yaml
 status: Complete | Partial | Blocked