Skip to main content
agentsSource-backed

Storybook Repository Contributor Agent for Claude

Source-backed Claude agent prompt for contributing to the official storybookjs/storybook monorepo using its AGENTS.md guidance for the next branch, Node 22.12+, Yarn Berry, NX, yarn task, Storybook Vitest, sandboxes, framework packages, docs, and generated-file safety.

by Storybook · submitted by oktofeesh1·added 2026-06-04·
Review first review before installing

Open the source and read safety notes before installing.

Citation facts

Source-backed facts for citing this resource, derived directly from the registry — also available as plain text for AI assistants.

Source URLs
https://github.com/storybookjs/storybook/blob/next/AGENTS.md, https://github.com/storybookjs/storybook, https://storybook.js.org/
Brand
Storybook
Brand domain
storybook.js.org
Brand asset source
manual
Safety notes
This agent is for contributing to the official Storybook monorepo, not for installing or using the Storybook MCP addon in an application., Repository commands can install dependencies, compile many packages, run lint and type checks, start Storybook UI builds, generate sandboxes outside the repository, run Storybook Vitest tests, run E2E tests, and create build artifacts., Use focused non-production commands first. Add production or sandbox-parity options only when the current task requires those flows., Do not run `yarn task dev` without an explicit sandbox template, and do not run `yarn start`; the official AGENTS.md marks those as wrong defaults for agents., For React component behavior, prefer Storybook stories with `play` functions and Storybook Vitest instead of adding `*.test.tsx` unit tests unless the source guidance says the code is a pure utility, hook, or non-React module., Do not commit accidental overrides to generated files. Check generated-file headers and only include generated output that matches the source change., Avoid raw `console.log`, `console.warn`, and `console.error` in normal code paths when Storybook logger utilities are available., Large compiles, sandbox generation, browser tests, and E2E flows can be expensive or long-running. Prefer targeted commands and report blockers instead of looping indefinitely.
Privacy notes
Storybook repository work can expose component names, props, stories, fixtures, mock data, visual states, accessibility failures, Playwright traces, browser screenshots, console output, build logs, sandbox paths, and generated docs., Do not paste private design-system components, customer data, unreleased UI states, internal routes, screenshots, credentials, proprietary fixtures, or local-only paths into prompts, public PRs, docs, tests, or issue comments., Storybook stories and visual tests often include realistic examples. Review snapshots, traces, screenshots, generated story output, and local Storybook links before sharing them outside the repository context., Telemetry-related environment variables such as `STORYBOOK_DISABLE_TELEMETRY` and `STORYBOOK_TELEMETRY_DEBUG` may affect local runs; state when telemetry controls were used., When summarizing validation failures, redact private hostnames, private package names, environment values, screenshots, and workspace-specific paths.
Author
Storybook
Submitted by
oktofeesh1
Claim status
unclaimed
Last verified
2026-06-04

Decision playbook

Review trust signals before you adopt

Signals are present but mixed. Use the checklist below to confirm the source and operational safety for your environment.

Compare context
Selected

0

Current score

78

Baseline

Delta

No baseline selected

No major trust-signal divergence detected in the current selection.

Source and provenance checks

Complete

Confirm ownership and provenance before trusting install instructions.

  • Source link availableRequired

    Open the canonical repository and verify ownership.

    Done
  • Source provenance statusRequired

    Marked as source-backed.

    Done
  • Metadata reviewed

    Registry metadata indicates a reviewed listing.

    Done

Safety and privacy checks

Complete

Validate risk disclosures before installation or API wiring.

  • Safety notes presentRequired

    Review the listed safety guidance before running commands.

    Done
  • Privacy notes presentRequired

    Review data handling notes before connecting accounts or secrets.

    Done
  • Trust level risk gateRequired

    Trust level does not block evaluation.

    Done

Package and install checks

Needs review

Check package metadata and artifact integrity signals.

  • Install payload available

    Install or copy payload is available for review.

    Done
  • Package verification flag

    No package verification flag provided.

    Pending
  • Checksum metadata

    No checksum provided for downloaded artifact.

    Pending

Compare-driven decision checks

Needs review

Use compare context to validate trade-offs before adoption.

  • Compare tray has multiple entries

    Add at least one more entry to compare trust differences.

    Pending
  • Baseline comparison available

    No baseline peer selected yet.

    Pending
  • Diverging trust signals identified

    No major trust-signal divergence found.

    Pending

Setup at a glance

Copy & paste

Copy-ready — paste the snippet to get started.

10 minutes

Adoption plan

Balanced adoption plan

Current risk score 16/100. Use staged verification before broader rollout.

Risk 16

Pre-adoption checks

Validate source and review signals before any execution.

  • Confirm source provenanceRequired

    Source URL/provenance metadata is present.

    Done
  • Confirm metadata review state

    Listing has review metadata.

    Done
  • Verify install payload

    Install/config payload exists and can be inspected.

    Done

Security checks

Confirm safety, privacy, and package integrity signals.

  • Review safety notesRequired

    Safety notes are present.

    Done
  • Review privacy notesRequired

    Privacy notes are present.

    Done
  • Verify package integrity metadata

    No package verification/checksum metadata.

    Pending

Rollout

Adopt in controlled steps based on the selected plan.

  • Run in isolated sandbox firstRequired

    Use a constrained sandbox and observe behavior across multiple tasks.

    Pending
  • Roll out graduallyRequired

    Roll out to a small cohort before wider usage.

    Pending
  • Set monitoring and fallback

    Define rollback path and monitor errors after adoption.

    Pending

Evidence readiness

Evidence readiness matrix · balanced

Required evidence gates are covered (5/6 signals complete).

Risk 15

Source provenance

Present

Source repository/provenance is listed.

Required in this preset

Metadata review

Present

Review metadata is present.

Required in this preset

Safety notes

Present

Safety notes are present.

Required in this preset

Privacy notes

Present

Privacy notes are present.

Optional in this preset

Package integrity

Missing

Package integrity metadata is missing.

Optional in this preset

Install payload

Present

Install payload is available.

Required in this preset

Required evidence gates are covered for this preset.

Decision timeline

Decision timeline · balanced

5/6 steps complete with no blocking gaps for this preset.

Risk 14

triage

Confirm source provenanceRequired

Source/provenance metadata is available.

Done

triage

Check metadata review statusRequired

Review metadata is available.

Done

verify

Review safety notesRequired

Safety notes are available.

Done

verify

Review privacy notes

Privacy notes are available.

Done

verify

Validate package integrity metadata

Package integrity metadata is missing.

Pending

rollout

Verify install payload and commandsRequired

Install payload is available.

Done

No required blockers for this timeline preset.

Prerequisite readiness

Prerequisite readiness

7 prerequisites to line up before setup. Includes a review or approval gate.

0/7 ready
Install & runtime1Permissions & scopes1Review & approval2General310 minutes

Safety & privacy surface

Safety & privacy surface

8 safety and 5 privacy notes across 4 risk areas. Review closely: credentials & tokens.

4 areas
  • SafetyExecution & processesThis agent is for contributing to the official Storybook monorepo, not for installing or using the Storybook MCP addon in an application.
  • SafetyExecution & processesRepository commands can install dependencies, compile many packages, run lint and type checks, start Storybook UI builds, generate sandboxes outside the repository, run Storybook Vitest tests, run E2E tests, and create build artifacts.
  • SafetyExecution & processesUse focused non-production commands first. Add production or sandbox-parity options only when the current task requires those flows.
  • SafetyExecution & processesDo not run `yarn task dev` without an explicit sandbox template, and do not run `yarn start`; the official AGENTS.md marks those as wrong defaults for agents.
  • SafetyGeneralFor React component behavior, prefer Storybook stories with `play` functions and Storybook Vitest instead of adding `*.test.tsx` unit tests unless the source guidance says the code is a pure utility, hook, or non-React module.
  • SafetyLocal filesDo not commit accidental overrides to generated files. Check generated-file headers and only include generated output that matches the source change.
  • SafetyLocal filesAvoid raw `console.log`, `console.warn`, and `console.error` in normal code paths when Storybook logger utilities are available.
  • SafetyExecution & processesLarge compiles, sandbox generation, browser tests, and E2E flows can be expensive or long-running. Prefer targeted commands and report blockers instead of looping indefinitely.
  • PrivacyLocal filesStorybook repository work can expose component names, props, stories, fixtures, mock data, visual states, accessibility failures, Playwright traces, browser screenshots, console output, build logs, sandbox paths, and generated docs.
  • PrivacyCredentials & tokensDo not paste private design-system components, customer data, unreleased UI states, internal routes, screenshots, credentials, proprietary fixtures, or local-only paths into prompts, public PRs, docs, tests, or issue comments.
  • PrivacyGeneralStorybook stories and visual tests often include realistic examples. Review snapshots, traces, screenshots, generated story output, and local Storybook links before sharing them outside the repository context.
  • PrivacyExecution & processesTelemetry-related environment variables such as `STORYBOOK_DISABLE_TELEMETRY` and `STORYBOOK_TELEMETRY_DEBUG` may affect local runs; state when telemetry controls were used.
  • PrivacyLocal filesWhen summarizing validation failures, redact private hostnames, private package names, environment values, screenshots, and workspace-specific paths.

Safety notes

  • This agent is for contributing to the official Storybook monorepo, not for installing or using the Storybook MCP addon in an application.
  • Repository commands can install dependencies, compile many packages, run lint and type checks, start Storybook UI builds, generate sandboxes outside the repository, run Storybook Vitest tests, run E2E tests, and create build artifacts.
  • Use focused non-production commands first. Add production or sandbox-parity options only when the current task requires those flows.
  • Do not run `yarn task dev` without an explicit sandbox template, and do not run `yarn start`; the official AGENTS.md marks those as wrong defaults for agents.
  • For React component behavior, prefer Storybook stories with `play` functions and Storybook Vitest instead of adding `*.test.tsx` unit tests unless the source guidance says the code is a pure utility, hook, or non-React module.
  • Do not commit accidental overrides to generated files. Check generated-file headers and only include generated output that matches the source change.
  • Avoid raw `console.log`, `console.warn`, and `console.error` in normal code paths when Storybook logger utilities are available.
  • Large compiles, sandbox generation, browser tests, and E2E flows can be expensive or long-running. Prefer targeted commands and report blockers instead of looping indefinitely.

Privacy notes

  • Storybook repository work can expose component names, props, stories, fixtures, mock data, visual states, accessibility failures, Playwright traces, browser screenshots, console output, build logs, sandbox paths, and generated docs.
  • Do not paste private design-system components, customer data, unreleased UI states, internal routes, screenshots, credentials, proprietary fixtures, or local-only paths into prompts, public PRs, docs, tests, or issue comments.
  • Storybook stories and visual tests often include realistic examples. Review snapshots, traces, screenshots, generated story output, and local Storybook links before sharing them outside the repository context.
  • Telemetry-related environment variables such as `STORYBOOK_DISABLE_TELEMETRY` and `STORYBOOK_TELEMETRY_DEBUG` may affect local runs; state when telemetry controls were used.
  • When summarizing validation failures, redact private hostnames, private package names, environment values, screenshots, and workspace-specific paths.

Prerequisites

  • A local checkout or source snapshot of the official `storybookjs/storybook` repository.
  • Review the current official `AGENTS.md` before using this agent, because branch, Node.js, Yarn, NX, task-runner, sandbox, and testing guidance can change.
  • Node.js 22.12 or later, matching the repository `.nvmrc` guidance.
  • Yarn Berry available for repository commands.
  • Permission to run focused `yarn`, `yarn task`, `yarn nx`, lint, compile, Storybook Vitest, sandbox, or E2E validation when the task requires it.
  • A known target area such as `code/core`, addons, builders, renderers, frameworks, docs, test-storybooks, scripts, sandbox templates, or generated Storybook files.
  • Awareness that Storybook PRs target the `next` branch, not `main`, according to the reviewed AGENTS.md.

Schema details

Install type
copy
Troubleshooting
No
Source repository stats
Scope
Source repo
Collection metadata
Estimated setup
10 minutes
Difficulty
advanced
Tool listing metadata
Full copyable content
# Trigger
"Use the Storybook repository contributor agent for this storybookjs/storybook task."

# Required output
1) AGENTS.md, package, NX, yarn task, docs, story, and sandbox context checked
2) Affected core, addon, builder, renderer, framework, docs, or test surface identified
3) Focused Yarn/NX/Storybook Vitest validation commands and results
4) Safety, privacy, generated-file, sandbox, and remaining-risk notes

About this resource

Agent Definition

Create this file as .claude/agents/storybook-repository-contributor.md:

---
name: storybook-repository-contributor
description: Use when the user asks Claude to investigate, patch, test, or review work in the official storybookjs/storybook repository from source-backed repository instructions.
tools:
  - bash
  - read
  - edit
  - grep
  - web_fetch
---

You are the Storybook Repository Contributor Agent. Your job is to help work in
the official `storybookjs/storybook` monorepo while following the current
repository instructions, targeting the correct base branch, respecting package
boundaries, choosing focused Yarn/NX validation, and protecting generated files,
stories, sandboxes, docs, screenshots, traces, and contributor workflow safety.

## Source Order

Use these sources in order:

1. The local `AGENTS.md` in the `storybookjs/storybook` checkout.
2. Local package source, `project.json` files, scripts, tests, stories, docs,
   sandboxes, framework packages, renderer packages, builder packages, addons,
   and nearby conventions.
3. The thin local `CLAUDE.md` only to confirm it points back to `AGENTS.md`.
4. The official Storybook docs at `https://storybook.js.org/docs` for
   user-facing Storybook behavior.
5. `https://github.com/storybookjs/storybook` when a local checkout is
   unavailable or stale.

Do not rely on memory for branch targets, Node.js version, Yarn commands, NX
targets, sandbox paths, component testing expectations, generated-file rules,
or commands to avoid when official sources are available.

## Operating Rules

- Read `AGENTS.md` first and treat it as the canonical instruction source.
- Confirm the target branch is `next` unless current repository guidance says
  otherwise.
- Use Node.js 22.12 or later when local validation is required.
- Use Yarn Berry and repository commands, not npm or pnpm.
- Understand the repository shape before editing: main code under `code/`,
  build tooling under `scripts/`, docs under `docs/`, test repos under
  `test-storybooks/`, and generated sandboxes outside the repo at
  `../storybook-sandboxes/`.
- Identify the affected surface: core package, manager, preview, manager API,
  preview API, channels, csf-tools, common utilities, test support, builders,
  renderers, frameworks, addons, presets, docs, scripts, test-storybooks, or
  sandbox templates.
- Prefer faster non-production commands first. Add `-c production` only when
  sandbox-related NX tasks or CI parity require it.
- Use NX when caching and dependency tracking matter.
- Use `yarn task` when the repository workflow documents it for compile,
  sandbox, E2E, test-runner, smoke-test, or related scenarios.
- Use NX project names from the Nx graph and `project.json`, not package names,
  when running `yarn nx` commands.
- For React components, write or update Storybook stories with `play`
  functions. Do not add `*.test.tsx` unit tests for component behavior unless
  the current repository guidance changes.
- Use unit tests for pure utilities, hooks, and non-React modules where direct
  rendering is not involved.
- Use Storybook loggers instead of raw console calls in normal code paths.
- Check generated files before committing. Do not include accidental generated
  overrides unrelated to the source change.
- Update `AGENTS.md` when architecture, commands, versions, release flows, or
  contributor guidance changes.
- Keep `CLAUDE.md` and other agent entrypoints as thin references to
  `AGENTS.md`.

## Workflow

1. State the target Storybook area, package, docs page, story file, sandbox,
   framework integration, builder, renderer, addon, script, or generated file.
2. Read `AGENTS.md`, nearby source, tests, stories, docs, package targets, and
   relevant `project.json` or task-runner configuration.
3. Decide whether the work affects runtime story rendering, manager UI,
   preview behavior, framework integration, builder integration, docs,
   testing support, CLI/tooling, sandbox generation, or release artifacts.
4. Choose focused validation: compile one project, check one project, lint one
   file, run Storybook Vitest for a story, run a unit test for a utility, build
   the internal UI, generate a matching sandbox, or run an E2E/test-runner
   scenario.
5. Make the smallest source-backed change.
6. Inspect the diff for framework-boundary drift, generated-file churn, story
   coverage gaps, docs gaps, raw console usage, sandbox path mistakes, and
   duplicated instruction files.
7. Run focused validation and broaden only when shared Storybook behavior,
   framework integrations, security-sensitive code, migrations, or release
   outputs require it.
8. Summarize sources checked, affected surface, docs/stories/sandboxes,
   validation, generated-file handling, safety/privacy handling, and remaining
   risk.

## Command Guidance

- Install dependencies with `yarn`.
- Compile with `yarn task compile` or `yarn nx run-many -t compile`.
- Compile one NX project with `yarn nx compile <nx-project-name>`.
- Run broad checks with `yarn task check` or `yarn nx run-many -t check` when
  the affected surface justifies it.
- Fix JavaScript lint for a specific file with
  `yarn --cwd code lint:js:cmd <file-relative-to-code-folder> --fix`.
- Start the internal Storybook UI with `cd code && yarn storybook:ui` when UI
  inspection is required.
- Build the internal Storybook UI with `cd code && yarn storybook:ui:build`.
- Run unit tests with `yarn test` for utilities, hooks, and non-React modules.
- Run Storybook story tests with `yarn storybook:vitest`.
- Run a focused story test with
  `vitest run --config code/vitest.config.storybook.ts <story-file>`.
- Generate a sandbox with
  `yarn task sandbox --template react-vite/default-ts --start-from auto`.
- Run sandbox E2E tests with
  `yarn task e2e-tests-dev --template react-vite/default-ts --start-from auto`
  or the matching template for the changed framework.
- Run sandbox test-runner tests with
  `yarn task test-runner-dev --template react-vite/default-ts --start-from auto`.
- Format with `yarn fmt:write` when formatting is required.
- Use `STORYBOOK_SANDBOX_ROOT=./sandbox` only when you intentionally need local
  sandbox output; the default generated sandbox path is outside the repository.
- Use the repository's documented telemetry environment variables when
  telemetry must be disabled or debugged for local runs.

## Testing Guidance

- Component behavior belongs in Storybook stories with `play` functions using
  `expect`, `userEvent`, and `within` from `storybook/test`.
- Behavior, accessibility, and interaction assertions for React components
  should run through the Storybook Vitest project.
- Unit tests are appropriate for pure utilities, hooks, and non-React modules.
- Use Storybook UI or Chromatic-style visual validation when visual behavior is
  the important contract.
- Use sandbox, E2E, test-runner, and smoke-test flows when framework templates,
  builders, renderers, or integration behavior need parity with real projects.
- Do not add redundant tests for behavior already guaranteed by TypeScript,
  linting, existing play functions, or existing Playwright coverage.
- Test public contracts and observable side effects instead of private
  implementation details.
- For security-sensitive code and migration logic, bias toward broader edge
  case coverage and explicit version scoping.

## Commands To Avoid

- Do not run `yarn task dev` without an explicit sandbox template.
- Do not run `yarn start`.
- Do not run long-running broad servers as the first validation step.
- Do not use npm or pnpm in this repository unless the current AGENTS.md has
  changed to allow it.
- Do not add `-c production` to NX commands by default.
- Do not commit changes in generated files unless they are expected output from
  the source change.

## Safety Boundaries

- Do not treat this as a generic Storybook application setup agent. It is for
  contributing to the official `storybookjs/storybook` repository.
- Do not confuse this with Storybook MCP usage in an application. If the user
  needs app-level component docs through MCP, use the Storybook MCP server
  entry and project-specific instructions instead.
- Do not target `main` for Storybook repository PRs when `AGENTS.md` says PRs
  should target `next`.
- Do not generate sandboxes in unexpected paths or commit generated sandbox
  output.
- Do not paste private component code, screenshots, customer data, unreleased
  UI states, proprietary fixtures, credentials, or local-only paths into public
  output.
- Do not write comments that document the investigation transcript, temporary
  acceptance criteria codes, line-number breadcrumbs, or noisy provenance
  details. Comments should explain durable rationale for maintainers.
- If dependencies, NX graph, Storybook UI, Storybook Vitest, browser tests,
  sandbox generation, or E2E infrastructure are unavailable, report the
  blocker instead of claiming validation passed.

## Output Contract

Use this response shape for Storybook repository work:

```markdown
## Storybook Repo Check

Target area:
- ...

Sources checked:
- ...

Affected package or layer:
- ...

Stories, docs, sandbox, or generated files:
- ...

Plan or change:
- ...

Validation:
- ...

Safety/privacy notes:
- ...

Remaining risk:
- ...

## Source Review

- https://github.com/storybookjs/storybook/blob/next/AGENTS.md
- https://raw.githubusercontent.com/storybookjs/storybook/next/AGENTS.md
- https://github.com/storybookjs/storybook/blob/next/CLAUDE.md
- https://github.com/storybookjs/storybook
- https://storybook.js.org/docs

These sources were reviewed on **2026-06-04**. The official Storybook
repository publishes a root `AGENTS.md` that says it is the canonical
instruction source for coding agents, describes Storybook as a large
TypeScript monorepo, identifies `next` as the PR base branch, requires Node.js
22.12 or later and Yarn Berry, documents NX and `yarn task` workflows, explains
core repository structure, and gives testing expectations for Storybook
stories, play functions, Storybook Vitest, unit tests, sandboxes, E2E flows,
formatting, logging, generated files, telemetry, and commands to avoid.

## Duplicate check

This entry is specifically for contributing to the official
`storybookjs/storybook` repository from its root `AGENTS.md`. It is distinct
from the existing Storybook MCP Server entry, which covers installing
`@storybook/addon-mcp` in a Storybook project so Claude can inspect component
docs, generate stories, preview UI states, and run Storybook tests through a
local MCP endpoint. Before submission, current content and open PRs were
checked for `storybook-repository-contributor-agent`, `Storybook Agent`,
`storybookjs/storybook`, the official Storybook `AGENTS.md` URL, and direct
Storybook repository-agent overlap.

## Disclosure

This is a source-backed listing for an official open-source Storybook
repository instruction file. The submitter is not affiliated with Storybook,
and no sponsorship, affiliate relationship, or paid placement is involved.

Source citations

Add this badge to your README

Show that Storybook Repository Contributor Agent for Claude is listed on HeyClaude. Paste this Markdown into your README — it renders the badge and links back to this page.

Listed on HeyClaude
[![Listed on HeyClaude](https://heyclau.de/badge/agents/storybook-repository-contributor-agent.svg)](https://heyclau.de/entry/agents/storybook-repository-contributor-agent)

How it compares

Storybook Repository Contributor Agent for Claude side by side with 3 alternatives on trust, install, platform support, and disclosed safety notes — all from reviewed registry metadata.

Field

Source-backed Claude agent prompt for contributing to the official storybookjs/storybook monorepo using its AGENTS.md guidance for the next branch, Node 22.12+, Yarn Berry, NX, yarn task, Storybook Vitest, sandboxes, framework packages, docs, and generated-file safety.

Open dossier

Source-backed Claude agent prompt for contributing to the official angular/angular repository using its AGENTS.md guidance for pnpm, Bazel test targets, coding standards, commit guidelines, zoneless tests, async stability, and PR handling.

Open dossier

Source-backed Claude agent prompt for contributing to the official ansible/ansible repository using its AGENTS.md guidance for licensing, ansible-test workflows, Docker container selection, changelog fragments, CI triage, module documentation, and devel-branch PRs.

Open dossier

Source-backed Claude agent prompt for contributing to the official Astro monorepo using its AGENTS.md guidance, pnpm workspace commands, package-local testing, bgproc dev server management, agent-browser UI checks, and Astro docs sources.

Open dossier
Next steps
Trust
Review statusReviewedMaintainer reviewedReviewedMaintainer reviewedReviewedMaintainer reviewedReviewedMaintainer reviewed
Package trustPackage not verifiedPackage not verifiedPackage not verifiedPackage not verified
Source provenanceSource-backedSource-backedSource-backedSource-backed
Submitteroktofeesh1oktofeesh1oktofeesh1oktofeesh1
Install riskReview firstReview firstReview firstReview first
Notes Safety ✓ Privacy ✓ Safety ✓ Privacy ✓ Safety ✓ Privacy ✓ Safety ✓ Privacy ✓
BrandStorybook
Categoryagentsagentsagentsagents
SourceSource-backedSource-backedSource-backedSource-backed
AuthorStorybookAngularAnsibleAstro
Added2026-06-042026-06-042026-06-042026-06-04
Platforms
Harness
Source repo
Safety notesThis agent is for contributing to the official Storybook monorepo, not for installing or using the Storybook MCP addon in an application. Repository commands can install dependencies, compile many packages, run lint and type checks, start Storybook UI builds, generate sandboxes outside the repository, run Storybook Vitest tests, run E2E tests, and create build artifacts. Use focused non-production commands first. Add production or sandbox-parity options only when the current task requires those flows. Do not run `yarn task dev` without an explicit sandbox template, and do not run `yarn start`; the official AGENTS.md marks those as wrong defaults for agents. For React component behavior, prefer Storybook stories with `play` functions and Storybook Vitest instead of adding `*.test.tsx` unit tests unless the source guidance says the code is a pure utility, hook, or non-React module. Do not commit accidental overrides to generated files. Check generated-file headers and only include generated output that matches the source change. Avoid raw `console.log`, `console.warn`, and `console.error` in normal code paths when Storybook logger utilities are available. Large compiles, sandbox generation, browser tests, and E2E flows can be expensive or long-running. Prefer targeted commands and report blockers instead of looping indefinitely.This agent is for contributing to the official Angular framework repository, not for generating generic Angular application code or replacing Angular documentation. Repository commands can install dependencies, run Bazel test targets, run package builds, apply formatting, execute TypeScript checks, and invoke tooling that may be expensive on a large monorepo. Use focused `pnpm bazel test //target` validation when possible instead of broad test runs. Angular's reviewed AGENTS.md says tests should assume a zoneless environment where state changes schedule updates asynchronously. Do not use `fixture.detectChanges()` as a manual update trigger in new or modified tests when the repository guidance calls for the Act, Wait, Assert pattern. Use `await fixture.whenStable()` after actions that schedule framework updates, and use `useAutoTick()` or the repository timeout helper where the official guidance applies. Do not change Angular coding-standard, commit-message, build, or testing conventions based on generic TypeScript habits when repository docs provide the rule. Use the GitHub CLI for PR work only after the branch is ready and local validation has been summarized.This agent is for contributing to the official ansible-core repository, not for writing generic playbooks, roles, private automation, or Ansible Tower/AWX operational runbooks. Licensing is a hard gate: ansible-core code must be GPLv3 compatible, and `lib/ansible/module_utils` defaults to BSD-2-Clause according to the reviewed AGENTS.md. Do not suggest, add, or approve new external dependencies unless their licenses and repository context are compatible with Ansible's current rules. Repository commands can run `ansible-test` sanity, unit, integration, coverage, Docker/Podman containers, Azure Pipelines log downloads, GitHub PR checkout, and large test suites. Use the right container type: the reviewed guidance says `default` is for sanity/unit tests, while integration tests require distro-specific containers such as Ubuntu images. Security issues should be reported privately through the official Ansible security route, not disclosed in public issues, tests, examples, or PR text. New plugins generally belong in collections, not ansible-core, unless current maintainers and repository guidance say otherwise. Do not claim validation passed if `ansible-test`, container setup, Azure log access, or required changelog/documentation checks were unavailable.This agent is for the official Astro repository and should not be treated as a generic Astro application generator. The Astro monorepo has broad format, lint, build, and test commands. Prefer package-local or focused commands before expensive full-repo checks. `pnpm format` and code generators can modify many files. Inspect the diff before committing and avoid formatting unrelated files unless the repo workflow requires it. Use the repo's `pnpm -C <dir> <command>` pattern for package-local work so commands run in the intended package, example, or triage directory. Do not start detached dev or preview servers manually when the repo's `bgproc` workflow is appropriate. Clean up long-running servers after verification. Do not use unrelated static web servers to test Astro HMR or preview behavior. Use Astro's documented dev and preview paths. When UI interaction, HMR behavior, or browser automation is required, use the repo-approved browser automation path or explicitly report if the tool is unavailable. Read relevant local README and deep-dive reference files before changing subsystem code such as unit testing helpers or Vite dependency optimization.
Privacy notesStorybook repository work can expose component names, props, stories, fixtures, mock data, visual states, accessibility failures, Playwright traces, browser screenshots, console output, build logs, sandbox paths, and generated docs. Do not paste private design-system components, customer data, unreleased UI states, internal routes, screenshots, credentials, proprietary fixtures, or local-only paths into prompts, public PRs, docs, tests, or issue comments. Storybook stories and visual tests often include realistic examples. Review snapshots, traces, screenshots, generated story output, and local Storybook links before sharing them outside the repository context. Telemetry-related environment variables such as `STORYBOOK_DISABLE_TELEMETRY` and `STORYBOOK_TELEMETRY_DEBUG` may affect local runs; state when telemetry controls were used. When summarizing validation failures, redact private hostnames, private package names, environment values, screenshots, and workspace-specific paths.Angular repository work can expose local file paths, package names, Bazel labels, test fixtures, build logs, stack traces, browser output, generated docs, and environment-specific setup details. Do not paste private application code, customer component names, internal design-system examples, proprietary test fixtures, credentials, tokens, private URLs, or local-only paths into prompts, public PRs, docs, or examples. Bazel and test output can include workspace paths, temporary paths, browser logs, and environment details. Summarize and redact sensitive values before sharing. When using Angular examples, prefer synthetic component, directive, service, or fixture names unless the upstream source already contains the public example.Ansible repository work can expose inventories, hostnames, playbook snippets, module arguments, CI logs, Azure Pipelines URLs, ansibot comments, test fixtures, remote paths, stack traces, and environment-specific setup details. Do not paste private inventories, credentials, vault secrets, customer playbooks, internal hostnames, SSH details, cloud account IDs, private CI logs, or security reproductions into prompts, docs, issues, tests, or PRs. Integration tests and CI triage can include host, container, distro, Python, environment, and network details. Redact sensitive values before sharing summaries. When creating examples for modules or plugins, prefer synthetic hosts and parameters unless the upstream source already contains the public example.Astro repo work can expose local file paths, stack traces, package names, test fixtures, browser snapshots, dev server logs, issue repro data, and unpublished source changes. Avoid pasting private local paths, user-specific environment details, credentials, tokens, private issue data, or unreleased customer examples into prompts, public PRs, or issue comments. Browser screenshots, dev server logs, and test output can include route names, fixture content, environment variables, and local hostnames. Use synthetic repros and public fixtures when sharing investigation results outside the local checkout.
Prerequisites
  • A local checkout or source snapshot of the official `storybookjs/storybook` repository.
  • Review the current official `AGENTS.md` before using this agent, because branch, Node.js, Yarn, NX, task-runner, sandbox, and testing guidance can change.
  • Node.js 22.12 or later, matching the repository `.nvmrc` guidance.
  • Yarn Berry available for repository commands.
  • A local checkout or source snapshot of the official `angular/angular` repository.
  • Review the current official `AGENTS.md` before using this agent, because package, test, coding-standard, and PR guidance can change.
  • pnpm installed and used for repository package management.
  • Repository build dependencies available for the focused Bazel target, test target, package, or documentation area being changed.
  • A local checkout or source snapshot of the official `ansible/ansible` repository.
  • Review the current official `AGENTS.md` before using this agent, because licensing, testing, CI, documentation, and PR guidance can change.
  • A POSIX development environment. The reviewed AGENTS.md notes that ansible-core and its CLIs, including `ansible-test`, require POSIX; Windows users should use WSL.
  • Python tooling prepared for ansible-core development, typically including an editable install with `pip install -e .` when local execution is needed.
  • A local checkout or source snapshot of the official `withastro/astro` repository.
  • Review the current official `AGENTS.md` before using this agent, because repo instructions can change.
  • pnpm workspace setup for the Astro monorepo and enough local dependencies to run the relevant package commands.
  • Known target package, example, docs page, integration, or subsystem before editing.
Install
Config
Citations
ClaimUnclaimedUnclaimedUnclaimedUnclaimed
Open 4 picks in the interactive comparison tool

Related guides

Signals

Loading live community signals…

More like this, weekly

A short, calm digest of reviewed Claude resources. Unsubscribe any time.