carecard-workspace-standards

Enforce shared engineering, testing, security, and workflow standards across CareCard repositories.

Updated Dec 11, 2025
One-click install
npx skills add https://github.com/CareCard-ca/pkg-auth-util --skill carecard-workspace-standards
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: carecard-workspace-standards
Source: https://github.com/CareCard-ca/pkg-auth-util/tree/main/.agents/skills/carecard-workspace-standards
Command: npx skills add https://github.com/CareCard-ca/pkg-auth-util --skill carecard-workspace-standards

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

It prevents inconsistent, risky, or incompatible modifications across the CareCard workspace by enforcing shared coding, testing, validation, dependency, and security expectations before and during repository work.

Core Features & Use Cases

  • Workspace-wide change governance: Apply consistent rules when modifying any api-* service, pkg-* package, app-* frontend, or cross-repository contract.
  • Quality and compatibility protection: Preserve public APIs, module/style conventions, TypeScript constraints (including avoiding any), and update compatibility/type surfaces together when exports change.
  • Safety-first engineering: Avoid secret/token exposure, do not bypass failing checks, never suppress errors or lint/type/security failures, and run required validations and Husky scripts.

Quick Start

Use the carecard-workspace-standards skill before starting any api-*, pkg-*, or app-* change to confirm the required workflow, safety constraints, and validation commands for the specific area you are touching.

Frequently Asked Questions about carecard-workspace-standards

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I enforce shared TypeScript constraints and testing standards across multiple repositories?

You can enforce shared TypeScript constraints and workspace standards by applying non-negotiable rules for dependency restraint, safe error handling, and test coverage across api-*, pkg-*, and app-* components before modifying cross-repository contracts.

What's the best way to prevent risky API contract changes in a multi-package workspace?

The best way to prevent risky API contract changes is to preserve public APIs and update compatibility and type surfaces together whenever exports change, ensuring no incompatible modifications slip through across the workspace.

Do I need Husky scripts to validate local repository workflow changes?

Yes, you need Husky scripts for mandatory local validation of repository workflow changes. You must run these required validations without remote Git operations and never suppress errors or bypass failing lint, type, or security checks.

When should I apply workspace standards for security and auth boundary modifications?

You should apply workspace standards whenever modifying api-*, pkg-*, or app-* components, especially for auth, security, API contracts, boundaries, and validation, to prevent secret or token exposure and ensure safety-first engineering.

Why does my TypeScript workspace change fail validation when using `any` types?

Your TypeScript workspace change fails validation because workspace standards require avoiding `any` types and never suppressing lint, type, or security failures to maintain strict compatibility and safety across all repository boundaries.