Skip to content

[INFRA] update skills for pnpm and React compatibility policy #255

@egdev6

Description

@egdev6

Infrastructure Task

Area

Other tooling

Team

Squad 1

Milestone

Core

Motivation

PR #253 changed the repository's operational contract:

  • The repo now pins packageManager to pnpm@10.34.1.
  • CI workflows should use the same exact pnpm version, not only 10.
  • verify:package now verifies real package consumption against React 18 and React 19 consumers.
  • React 19 dependency updates are not safe to evaluate with tests/Storybook only; package build and consumer compatibility evidence are required.
  • The PR also exposed declaration packaging constraints: generated declarations must not leak internal aliases or CSS side-effect imports.

Project skills should reflect this so future agents do not regress the policy.

Proposed change

Files/config affected:

  • .atl/AGENTS.md
  • .atl/skills/npm-architect/SKILL.md
  • .atl/skills/pr-reviewer/SKILL.md
  • Possibly .atl/skills/release-changeset/SKILL.md only if release/package verification wording needs alignment.

Expected behavior:

  • Skills mention pnpm@10.34.1 as the repo package manager contract.
  • PR/dependency/package review skills require pnpm run verify:package when React, package output, declarations, exports, or peer compatibility change.
  • React major upgrades must include evidence for React 18 and React 19 consumers while peer deps remain react >=18.0.0 and react-dom >=18.0.0.
  • Skills warn that generated declarations must not contain internal path aliases or CSS side-effect imports.

Secrets or environment assumptions:

  • None.

Rollback plan:

  • Revert skill/doc wording only. No runtime code should be required for this issue.

Validation plan

Local commands:

Workflow run URL or draft PR check:

  • Not required unless the implementation changes scripts or CI.

Failure/rollback check:

  • Ensure skills still route component implementation to component-specific skills and do not turn every component PR into a package architecture review.

Workflow gates

  • START WORK must run only after issue label status:approved; it assigns the issue, moves Project status to In progress, and records branch/worktree before implementation.
  • PR must link this issue and include validation evidence.
  • END WORK moves the Project item to Done only after merge or explicit maintainer approval.

Additional notes

This issue follows from PR #253. Keep it as a separate docs/skills follow-up so the dependency PR stays focused on React/Vitest/pnpm/package verification changes.

Related resources

Metadata

Metadata

Assignees

Type

No type
No fields configured for issues without a type.

Projects

Status
Done

Relationships

None yet

Development

No branches or pull requests

Issue actions