본문으로 건너뛰기
cccskills
무료GitHub에 공개

upstream-first

Load this skill before implementing a fix for a barrier that may originate in a shared component, design system, renderer, or external dependency rather than this project's own code. Decide whether the responsible fix is local, an existing installed capability, or an upstream contribution before writing a workaround. Absolutely always record any temporary local divergence with an owner and removal condition. Under no circumstances open, comment on, or submit anything in an external project without explicit human approval.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

설치 방법 보기

포함된 파일(1)

  • SKILL.md6.4 KB

SKILL.md(원문)

설치하기 전에 에이전트에게 전달되는 지시 내용을 확인할 수 있습니다.

Upstream First Skill

This skill is a pointer to mgifford/upstream-first, a separate, standalone set of agent skills for deciding where an accessibility (or any other) fix belongs and preparing it for the receiving project. It does not restate that project's decision hierarchy, classification steps, or contribution workflow — those stay owned there so this skill does not drift out of sync with a project that is still a pre-release review draft.

When to Use This

Before implementing a fix for an accessibility barrier, check whether the affected code is actually owned by this project:

  • a shared component or design system used across multiple projects;
  • a renderer, framework, or platform dependency;
  • an npm/PyPI/Packagist/Composer package rather than first-party code;
  • a pattern that would benefit other consumers of the same dependency, not only this project.

If the barrier may originate outside this project's own code, load upstream-first to decide whether the responsible fix is:

  1. an existing installed capability;
  2. an existing public API or extension point;
  3. a suitable maintained open-source package;
  4. a focused contribution to an existing project;
  5. a new reusable open-source package with credible ownership; or
  6. a local implementation, with a written justification for why every higher option is unsuitable.

Do not default to a local patch without going through this decision. A local fix for a shared-component barrier repeats the same maintenance burden for every other consumer of that component, and this project's users are not the only people affected by the barrier.

Preparing a Contribution

If the decision favors an upstream contribution, use maintainer-ready-contribution to prepare an issue, proposal, patch, or pull request the receiving project's maintainers can actually review and accept.

If the issue may be a security vulnerability, do not open a public issue, reproduction, branch, fork, or pull request. Use responsible-security-disclosure instead.

If AI materially assisted a known contribution, run ai-contribution-review before submission, when the receiving project's policy permits that use.

Human Approval Is Required

Never open, comment on, assign, label, fork, branch, or submit anything in an external project without a human explicitly approving that specific action. Deciding that a change belongs upstream is not the same as being authorized to act on that decision in someone else's project.

Tracking Temporary Local Divergence

An urgent local patch, override, fork, pin, or workaround may be necessary while an upstream correction is pending — accessibility barriers should not wait on a release the project does not control. When this happens, do not treat it as resolved. Record it as debt with:

  • a downstream owner;
  • an upstream reference or a documented exception if none exists;
  • a risk-based review date;
  • the supported versions the patch applies to;
  • a removal condition (a supported upstream release adopted and verified); and
  • a rollback plan.

If this project uses the ACCESSIBILITY.md template, use the downstream divergence record. Otherwise use the upstream-debt record shape directly.

A merged or closed upstream tracker item is not resolution. Closure requires the supported release to be adopted downstream and the original user-facing behavior to be retested — see Accessibility Finding Tracking, "Local and upstream trackers" if this project tracks findings with that schema.

Relationship to Other Skills

  • ACCESSIBILITY-general governs when and how all skills in this repository are loaded; this skill is one of the things it points to when a fix's ownership is unclear.
  • bug-reporting records scope, likely source, and (when applicable) local and upstream tracker relationships for a filed finding — this skill decides what to do about that source before a fix is written, not after.
  • Per-topic skills (forms, keyboard, color-contrast, and so on) define how to fix a barrier once ownership is decided. This skill decides where the fix belongs.

References

리뷰

아직 리뷰가 없습니다. 사용해 본 소감을 남겨 주세요.

댓글

로그인 없이 쓸 수 있습니다. 사용 후기, 질문, 작동하지 않은 환경 등을 편하게 남겨 주세요.

아직 댓글이 없습니다. 첫 댓글을 남겨 보세요.

보내면 바로 공개됩니다. 이메일 주소나 전화번호 같은 개인 정보는 쓰지 마세요. URL은 2개까지입니다.

0 / 1,000자

이 양식은 reCAPTCHA로 보호되며 Google 개인정보처리방침 및 서비스 약관이 적용됩니다.

같은 저장소의 스킬

Load this skill immediately whenever a project contains an ACCESSIBILITY.md file, or whenever you are contributing to the mgifford/ACCESSIBILITY.md repository. Absolutely always read ACCESSIBILITY.md before proposing or writing any changes. Under no circumstances skip this skill when an ACCESSIBILITY.md file is present. This skill governs when and how all other accessibility topic skills must be loaded.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

LazyCats-dev/ao3-podfic-posting-helper112026년 10월 5일 업데이트

Load this skill whenever the project contains in-page anchor links, skip links, fragment identifiers, or heading links. Under no circumstances omit accessible anchor-link requirements when such links exist. Ensure every anchor link has meaningful text, a reachable target, and a visible focus indicator. Apply these rules when creating or reviewing any in-page navigation.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

LazyCats-dev/ao3-podfic-posting-helper112026년 10월 5일 업데이트

Audit and fix common accessibility issues in Angular templates and Angular Material components. Use when the user mentions Lighthouse, axe, screen readers, keyboard navigation, ARIA, asks to fix a11y issues in Angular HTML templates, or after any feature, bug fix, or refactor that changed Angular templates.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

LazyCats-dev/ao3-podfic-posting-helper112026년 10월 5일 업데이트

Generates Angular code and provides architectural guidance. Trigger when creating projects, components, or services, or for best practices on reactivity (signals, linkedSignal, resource), forms, dependency injection, routing, SSR, accessibility (ARIA), animations, styling (component styles, Tailwind CSS), testing, or CLI tooling.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

LazyCats-dev/ao3-podfic-posting-helper112026년 10월 5일 업데이트

Generates Angular code and provides architectural guidance. Trigger when creating projects, components, services, or HTTP communication, or for best practices on reactivity (signals, linkedSignal, resource, httpResource), forms, dependency injection, routing, SSR, accessibility (ARIA), animations, styling (component styles, Tailwind CSS), testing, naming conventions, or CLI tooling.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

LazyCats-dev/ao3-podfic-posting-helper112026년 10월 5일 업데이트

Creates a new Angular app using the Angular CLI. This skill should be used whenever a user wants to create a new Angular application and contains important guidelines for how to effectively create a modern Angular application.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

LazyCats-dev/ao3-podfic-posting-helper112026년 10월 5일 업데이트

LazyCats-dev의 스킬 모두 보기

이 스킬의 문제 신고