Maintainability-focused code review - correctness, hidden coupling, testability, and regression risk. Use proactively after multi-file changes, before merging, or when asked to review a diff or PR. Reports findings ordered by severity. Read-only.
Technical judgment lens - architecture, implementation strategy, tradeoffs, and maintainability direction. Use before significant implementation choices, when a design feels over- or under-engineered, or to sanity-check technical direction against the project stage. Advisory and read-only.
Measurement lens - success metrics, lightweight instrumentation, privacy boundaries, and review cadence. Use when defining what success looks like for a feature, adding analytics, or judging whether a claim about usage is actually measurable. Read-only.
Execution lens - converts plans and council output into milestones, sequencing, dependencies, decisions, and next actions. Use at the end of planning work, when a project feels stuck, or when many open threads need turning into an ordered, owned plan. Read-only.
Experience and UI judgment lens - clarity, UX risks, visual coherence, accessibility, and user-facing polish. Use when reviewing screens, flows, copy, or any user-facing change, or when a feature works but does not feel right. Advisory and read-only.
Launch and positioning lens - messaging, launch assets, distribution fit, credible claims, and feedback loops. Use when preparing a release announcement, README, landing page, or launch plan, or when checking that public claims match what the product actually does. Read-only.
Product judgment lens - user value, scope, priorities, and product fit. Use when deciding what to build, cutting or challenging scope, weighing features against each other, or reviewing whether finished work actually serves the primary user. Advisory and read-only.
Deployment and operations lens - CI/CD, environment hygiene, observability, rollback, and production readiness. Use before a deploy, when wiring CI, or when reviewing anything that touches infrastructure, environments, or release mechanics. Read-only.
Acceptance testing and ship-readiness lens. Use proactively after a feature is implemented, before a release, or when asked for a QA pass, acceptance criteria, edge-case coverage, or "is this ready to ship?". Reports findings with severity and a fix list. Read-only.
Research lens - validates assumptions, compares options, checks source quality and currentness, and surfaces unknowns. Use before adopting a library, pattern, or claim from outside the repo, or when a decision rests on facts nobody has verified. Has web access; read-only in the repo.
Defensive security review - secrets exposure, injection risk, unsafe automation, privacy, dependency risk, and local-system exposure. Use when changes touch auth, user data, external input, new dependencies, CI, or anything that runs automatically. Read-only.
Instructions for SarutobiSasuke8/agentops-template, covering github copilot instructions, alignment markers, copilot behavior and tests and verification.