unitwork

Bulk resolve GitHub PR comments using checkpoint-based verification flow

First-time setup for Unit Work - check dependencies, configure Hindsight bank, explore codebase

Browser automation using Vercel's agent-browser CLI. Use for web interaction, form filling, screenshots, scraping, and UI/backend verification. Supports ref-based selection, parallel sessions, and headed debugging. Includes verification workflows with confidence assessment. Triggers on: browse website, fill form, click button, take screenshot, scrape page, web automation, UI verification.

Extract and store learnings to Hindsight memory and local documentation

Autonomously fix failing CI by cycling through analyze → fix → commit → push → verify

Autonomously rebase onto default branch with intelligent conflict resolution using multi-agent analysis

Scrape merged PR review comments from GitHub repos, synthesize insights, and store in Hindsight memory

Read-only codebase investigation with memory integration. Run tests and temp scripts to verify hypotheses.

Run, create, debug, or upload Momentic E2E tests. Use for browser-based end-to-end testing with AI assertions, video recording, and persistent YAML test suites.

Park current work session with full context to a GitHub PR comment for multi-device handoff

Interview user, explore codebase via Hindsight, and create spec with implementation units

Create or update GitHub PRs with AI-generated descriptions

Resume a parked work session by reading PR parking comments and local artifacts

Run exhaustive multi-agent parallel code review with taxonomy-based findings

Generate comprehensive manual testing steps from git diffs. Analyzes frontend and backend changes, identifies edge cases, and produces one continuous end-to-end test plan. Stores in .unitwork/test-plans/. Triggers on: test plan, manual testing, testing steps, QA plan, verification plan, generate test.

Execute the plan with checkpoint-based verification at every verifiable boundary

Use this agent to analyze the downstream impact of resolving a merge/rebase conflict. This agent identifies affected tests, dependent files, and behavioral implications of different resolution approaches.

Use this agent to analyze the intent behind each branch's changes in a merge conflict. This agent determines whether conflicts are purely textual (same goal, different implementation) or semantic (conflicting goals).

Use this agent for codebase exploration with memory integration. This agent recalls prior exploration findings from Hindsight, validates key file locations still exist, explores the codebase, and retains summarized findings including traversal strategies. Use instead of the standard Explore agent when you want exploration results to compound across sessions. Examples: - <example> Context: The user needs to understand where authentication code lives in a new codebase. user: "I need to find where authentication is implemented" assistant: "I'll use the memory-aware-explore agent to find authentication code and document the findings for future sessions." <commentary> Use memory-aware-explore when exploration results should be retained for future sessions. </commentary> </example> - <example> Context: Planning a feature that requires understanding existing patterns. user: "I'm planning to add a new API endpoint" assistant: "Let me explore the codebase for existing API patterns. I'll use memory-aware-explore so we don't repeat this exploration next time." <commentary> Memory-aware exploration compounds knowledge - findings from this session inform future sessions. </commentary> </example>

Use this agent to review a draft plan for technical feasibility issues. This agent identifies impossible or blocked units, unclear verification strategies, hidden dependencies, unrealistic confidence estimates, and units too large for a single session. Should be invoked during /uw:plan after draft plan creation. Examples: - <example> Context: Reviewing a draft plan with a unit that depends on an external API. user: "Check if this plan is technically feasible" assistant: "I'll analyze each unit for blockers, dependencies, and verification clarity." <commentary> Use feasibility-validator to catch blockers before implementation starts. </commentary> </example>

Use this agent to review a draft plan for information gaps that would require investigation during implementation. This agent identifies unclear requirements, missing API contracts, unspecified edge cases, and ambiguous specifications. Should be invoked during /uw:plan after draft plan creation. Examples: - <example> Context: Reviewing a draft plan for a new feature. user: "Check this plan for gaps that would block implementation" assistant: "I'll analyze the plan for missing information, unclear requirements, and unspecified edge cases." <commentary> Use gap-detector agent to find gaps before presenting plan to user. </commentary> </example>

Use this agent to review a draft plan for reinvented wheels and missed existing utilities. This agent identifies units that describe implementing functionality that likely already exists in the codebase, pattern violations, and missed utility opportunities. Should be invoked during /uw:plan after draft plan creation. Examples: - <example> Context: Reviewing a draft plan that proposes implementing date formatting. user: "Check if this plan reinvents existing utilities" assistant: "I'll search the codebase for existing utilities that could be reused instead." <commentary> Use utility-pattern-auditor to find existing solutions before planning new implementations. </commentary> </example>

Use this agent to review code for architectural issues including wrong file locations, tight coupling, boundary violations, and organizational problems. Should be invoked during /uw:review. Examples: - <example> Context: Reviewing a new feature implementation. user: "Check if my code is in the right place architecturally" assistant: "I'll analyze file organization, coupling, and boundary adherence." <commentary> Use architecture agent to verify proper structure and separation of concerns. </commentary> </example>

Use this agent to validate code changes against team learnings stored in Hindsight memory. This agent should be invoked during /uw:review after memory recall. Unlike other agents that receive domain-filtered learnings, this agent receives ALL learnings and validates the PR against each one. Examples: - <example> Context: Reviewing code after memory recall found relevant learnings. user: "Validate this change against our team learnings" assistant: "I'll check the code against all retained learnings from memory." <commentary> Use memory-validation agent when learnings were recalled that should inform the review. </commentary> </example>

Use this agent to review code for pattern violations and missed utility usage. This agent identifies reimplemented existing code, missing pattern usage, and violations of established codebase conventions. Should be invoked during /uw:review. Examples: - <example> Context: Reviewing new feature code. user: "Check if I'm following existing patterns" assistant: "I'll analyze the code against existing utilities and patterns in the codebase." <commentary> Use patterns-utilities agent to find duplicated logic and pattern violations. </commentary> </example>

Use this agent to review code for performance issues including N+1 queries, missing indexes, inefficient algorithms, and parallelization opportunities. Should be invoked during /uw:review. Examples: - <example> Context: Reviewing code that queries the database. user: "Check for performance issues in my database code" assistant: "I'll analyze for N+1 queries, missing indexes, and optimization opportunities." <commentary> Use performance-database agent to find query issues and inefficiencies. </commentary> </example>

Use this agent to review code for security vulnerabilities including injection attacks, auth bypasses, data exposure, and OWASP top 10 issues. Should be invoked during /uw:review. Security issues are often P1 critical. Examples: - <example> Context: Reviewing code that handles user input. user: "Check for security vulnerabilities" assistant: "I'll analyze for injection, auth issues, and data exposure." <commentary> Use security agent to find vulnerabilities before they reach production. </commentary> </example>

Use this agent to review code for unnecessary complexity including over-engineering, premature abstraction, YAGNI violations, and code that could be simpler. Should be invoked during /uw:review. Examples: - <example> Context: Reviewing new feature code. user: "Check if my code is too complex" assistant: "I'll analyze for over-engineering and simplification opportunities." <commentary> Use simplicity agent to find unnecessary complexity and suggest simplifications. </commentary> </example>

Use this agent to review code for type safety issues including casting, type guards, nullability, and any/unknown usage. This agent should be invoked during /uw:review to analyze type-related code quality issues. Examples: - <example> Context: Reviewing TypeScript code changes. user: "Review the type safety of my changes" assistant: "I'll analyze the code for type casting, guards, and nullability issues." <commentary> Use type-safety agent to find as-casting, incomplete guards, and any usage. </commentary> </example>

Use this agent to make actual API calls to verify endpoint behavior. This agent should be invoked after implementing API endpoints to verify they return correct responses. CRITICAL: Read-only (GET) calls can be made without permission, but mutating calls (POST, PUT, DELETE) REQUIRE user confirmation. Examples: - <example> Context: The user has implemented a new GET endpoint. user: "I've added GET /api/users/:id" assistant: "Let me probe the API to verify the response structure." <commentary> Use api-prober for read-only verification of the endpoint response. </commentary> </example> - <example> Context: The user has implemented a POST endpoint. user: "I've added POST /api/users" assistant: "I can verify this endpoint, but since it modifies data, I'll need your permission first." <commentary> For mutating endpoints, api-prober must ask for permission before execution. </commentary> </example>

Use this agent to execute test suites and report structured results. This agent should be invoked after implementing code changes to verify they work correctly. It auto-detects the test framework, runs relevant tests, and parses results with file:line references for failures. Examples: - <example> Context: The user has just implemented a new API endpoint. user: "I've added the password reset endpoint" assistant: "I've implemented the endpoint. Let me run the tests to verify it works." <commentary> Use the test-runner agent to execute relevant tests and verify the implementation. </commentary> </example> - <example> Context: After modifying an existing service. user: "I refactored the EmailService to handle attachments" assistant: "Let me run the test-runner agent to verify the refactored code passes all tests." <commentary> After modifying existing code, use test-runner to ensure no regressions. </commentary> </example>

This skill should be used when reviewing code or running /uw:review. It contains 47 issue patterns with severity tiers, team standards to enforce, and implementation checklists for the Unit Work review system.

This skill should be used when implementing features with human-in-the-loop verification. It provides the core Unit Work methodology including checkpoint-based development, confidence assessment, memory integration with Hindsight, and verification strategies. Use this skill for planning features, executing with checkpoints, reviewing code, and compounding learnings.