Review Paperclip interface changes using Storybook, a catalog of component examples, alongside production source and existing browser tests. Report rendering, interaction, visual comparison, and production evidence separately, making simulated behavior and untested areas clear.
Review Paperclip stories for a feature or change using the Storybook catalog, production source, and existing browser tests. Report component, mock, interaction, and visual evidence separately.
Run score Not tested
See how to installReviews Paperclip interface changes through Storybook, a catalog of component examples, production source, and existing browser tests. It checks normal actions, failures and retries, permission-dependent displays, and affected mobile layouts or themes. Reports separate rendering, interaction, visual comparison, and production acceptance, marking cases as passed, failed, blocked, or not run.
Use it after feature changes to inspect interface states and clarify what testing with simulated data establishes. For Storybook guide or sidebar changes, it also checks item order, navigation to related examples, and preservation of existing links.
Requires the relevant catalog, production source, and an environment for a Storybook build or development server. Interaction checks require completed play assertions and observed results; screenshots alone do not establish a pass. Visual comparisons require external baseline images and a fixed Linux environment. macOS images serve as observations. Proving actual persistence, authorization, or external service integration requires a production verification skill.
This overview was written by AI (OpenAI Codex) from the public SKILL.md. Check the original below for the exact behavior.
AI checked the SKILL.md for operations that need care and for setup requirements. The score comes only from actually running the skill (hands-on test).
Not counted in the score. Rated by AI (OpenAI Codex) as of Oct 20, 2026. Treat it as a guide and read the original before installing.
Review the instructions the agent will receive before you install.
Read the catalog contract and find the
requested capability in its generated index. Check the relevant feature recipe,
production subject, and story before driving it. Catalog status is prior review
context, not proof of the current revision. This skill consumes the maps/catalog;
corrections belong to maintain-storybook or maintain-verification-skill.
Choose discriminating states for the requested change: the normal action and result, relevant failure/retry, gate/permission presentation, and mobile/theme variants where affected. Record chosen files/exports and omitted scope. For a full source review, account for every file; do not describe sampling as full render or interaction coverage.
When reviewing navigation/index changes, compare the guide and sidebar with the full ordered index generated from feature recipes' navigation metadata. Open a feature without examples and a feature whose related suite lives elsewhere; check capability order, gap messages, classifications, recipe links, and actual suite navigation. Compare built entry IDs before/after so existing links survive. Generated Overview pages do not establish new example coverage.
Use the existing Storybook commands:
pnpm build-storybook, or an owned Storybook dev server on an available local
port. Use the built ui/storybook-static/index.json for actual story IDs and
links. Do not trust an unrelated server on the default port. Keep the process
handle and stop only the server this review started, retaining useful evidence.
Inspect the real rendered subject, including errors and browser console output.
For interactive stories, wait for their play assertions to complete and inspect
the observable result. A screenshot alone does not prove play passed. Verify
fixture isolation by revisiting/resetting relevant stories when they mutate
fetch handlers, storage, query caches, time, or module state. Avoid real provider
actions; explicitly document any live dependency required by a story.
The existing visual suite is
tests/storybook-visual/storybook-visual.spec.ts. It uses external baselines and
a pinned Linux environment. Inspect baseline-manifest.json before claiming
visual regression proof. An unpublished manifest blocks comparisons; a macOS
capture is useful inspection, not the Linux baseline. Do not update/publish
baselines just to make a review pass. Use existing focused browser suites where
they cover the requested scenario, and the production verification skill when
the question requires backend persistence, real authorization, or provider proof.
Report each selected case as passed, failed, blocked, or not run, naming revision, story ID, environment, production versus prototype subject, simulated boundaries, action/assertion and observed result. Separate render, interaction, visual comparison, and production acceptance evidence. Report proven drift with exact source references and a proposed correction; do not lower expectations, remove failing cases, or silently bless historical behavior as current.
No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
Add or extend Paperclip end-to-end evaluations that exercise real browser workflows across the server, database, and runner. Define expected outcomes, check independent evidence, and connect results to the existing reporting pipeline for local or Daytona execution.
Add or extend Paperclip Runner evaluations that test real sessions against a mock control service. Define observable pass conditions, validate cases and run selections, and retain source revisions, evidence, and costs for authorized live runs.
Use a real browser to verify web pages and apps through short, supervised interactions. Capture screenshots, inspect errors and network requests, and document reproducible steps for UI bugs or expected behavior checks.
Read email linked to assigned Paperclip tasks, send new messages or replies through an assigned AgentMail inbox, and check delivery outcomes. Follow task permissions and preserve retry identifiers to avoid duplicate sends.
Inspect proposed changes in GitHub, GitLab, or Perforce for review feedback, failed automated checks, and incomplete descriptions. It separates actionable findings from informational or resolved comments, then helps fix issues and close addressed review threads when requested.
Create an AI agent company or team package from an idea or an existing repository. Define roles, reporting lines, skills, and work handoffs, then generate structured files that follow the Agent Companies specification.