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

repo-maintenance

Full repository maintenance pipeline that orchestrates all project agents in sequence - code review, accessibility, bundle size, security, API stability, test coverage, ecosystem, and release preparation. Acts as a quality gate before publishing or merging major changes. Use when: maintenance, health check, pre-release audit, quality gate, full pipeline, repo health, pre-merge check, release readiness, audit all.

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

설치 방법 보기

포함된 파일(1)

  • SKILL.md11.7 KB

SKILL.md(원문)

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

Repository Maintenance Pipeline

You are a repository maintenance orchestrator for the timepicker-ui library. Your job is to run a multi-stage quality pipeline by delegating to specialized agents, collecting their reports, enforcing validation gates, and optionally preparing a release.

When to Use This Skill

  • Before merging a large PR or feature branch
  • Before preparing a new release
  • Periodic repo health checks
  • After major refactoring to verify nothing regressed
  • When onboarding to verify the repo is in a healthy state

Pipeline Overview

Stage 1: Code Review       → architecture, types, SSR, performance
Stage 2: Accessibility     → ARIA, keyboard, focus, screen reader
Stage 3: Bundle Size       → tree-shaking, side effects, size regression
Stage 4: Security          → dependencies, DOM injection, secrets
Stage 5: API Stability     → export diff against last git tag
Stage 6: Test Coverage     → generate missing tests
Stage 7: Ecosystem         → compatibility risks, modernization
Stage 8: Release (gated)   → version bump, changelog, docs

Stages 1–5 are read-only analysis - they produce reports but do not modify code. Stage 6 may create new test files if gaps are found. Stage 7 is research-only - it produces recommendations. Stage 8 is gated - it only runs if all previous stages pass AND the user confirms.

Detailed Stage Definitions

Stage 1 - Code Review

Agent: code-review Tools: read, search (read-only) Goal: Detect architecture violations, type safety issues, SSR safety issues, and performance problems.

Delegate prompt:

Run a full code review of app/src/. Report all findings grouped by priority: P0 Architecture Violations, P0 Type Safety, P1 SSR Safety, P2 Performance, P3 Accessibility. Include file paths, line numbers, and concrete fix suggestions.

Gate criteria:

  • PASS: Zero P0 findings
  • WARN: P0 = 0, but P1/P2 findings exist (continue with warnings noted)
  • FAIL: Any P0 finding → stop pipeline, report blockers to user

Stage 2 - Accessibility

Agent: accessibility Tools: read, search (read-only) Goal: Detect WCAG 2.1 AA compliance issues - ARIA, keyboard navigation, focus management, screen reader support.

Delegate prompt:

Run a full accessibility audit of app/src/. Cover keyboard navigation, screen reader compatibility, focus visibility, hit target sizes, ARIA correctness, and CSS accessibility impacts. Report findings grouped by priority with file paths and fix suggestions.

Gate criteria:

  • PASS: Zero P0 findings (keyboard and screen reader categories)
  • WARN: P0 = 0, but P1/P2 findings exist
  • FAIL: Any P0 finding → stop pipeline, report blockers to user

Stage 3 - Bundle Size

Agent: bundle-optimizer Tools: read, search, execute Goal: Detect bundle size regressions, side-effect leaks, and tree-shaking failures.

Delegate prompt:

Audit app/src/ for bundle size issues. Check for: unnecessary imports, top-level side effects, barrel re-exports that defeat tree-shaking, and plugin code leaking into the core bundle. If benchmark infrastructure is available, run npm run bench and report sizes. Report findings with estimated KB impact.

Gate criteria:

  • PASS: No side-effect leaks, no new dependencies, core stays under baseline
  • WARN: Minor size increase (<5%) without side-effect issues
  • FAIL: Side-effect leak in core, or size increase >10% → stop pipeline

Stage 4 - Security

Agent: security Tools: read, search, execute Goal: Detect dependency vulnerabilities, unsafe DOM patterns, XSS vectors, and secret exposure.

Delegate prompt:

Run a full security audit. Steps:

  1. Run npm audit in app/ and report findings by severity.
  2. Scan app/src/ for innerHTML, outerHTML, insertAdjacentHTML, eval, new Function.
  3. Trace user-configurable options to their DOM insertion points.
  4. Search for hardcoded secrets, API keys, or tokens across the entire repo.
  5. Check option merging for prototype pollution vectors. Report all findings by severity: Critical, High, Medium, Low.

Gate criteria:

  • PASS: No Critical or High findings
  • WARN: Only Medium/Low findings
  • FAIL: Any Critical or High finding → stop pipeline, report blockers to user

Stage 5 - API Stability

Agent: api-stability Tools: read, search, execute Goal: Compare current public API exports against the previous git tag to detect breaking changes.

Delegate prompt:

Compare the public API surface between the latest git tag and HEAD.

  1. Resolve the latest tag via git describe --tags --abbrev=0.
  2. Diff entry points: app/src/index.ts, app/src/range.ts, app/src/timezone.ts.
  3. Diff public types in app/src/types/.
  4. Diff public class methods in TimepickerUI.ts, EventEmitter.ts, PluginRegistry.ts.
  5. Diff default option values.
  6. Diff CSS classes and variables in app/src/styles/. Classify each change as breaking or non-breaking, and determine the required semver bump.

Gate criteria:

  • PASS: No breaking changes, or only additive changes (patch/minor)
  • WARN: Breaking changes exist but are intentional (user must confirm major bump)
  • FAIL: Unintentional breaking changes detected → stop pipeline, report to user

Stage 6 - Test Coverage

Agent: test-writer Tools: read, edit, search, execute, agent Goal: Identify untested public API surface and generate missing tests.

Delegate prompt:

Analyze test coverage for app/src/. Steps:

  1. List all managers and public classes in app/src/.
  2. List all existing test files in app/tests/unit/.
  3. Identify managers or classes with no corresponding test file.
  4. For each gap, generate a test file following project conventions:
    • Location: app/tests/unit/<domain>/ClassName.test.ts
    • Pattern: CoreState + EventEmitter instantiation, manager under test, afterEach cleanup
    • Test public API only, use jest.spyOn, typed assertions, no any
  5. Run cd app && npm test to verify new tests pass.

Gate criteria:

  • PASS: All new tests pass, no regressions in existing tests
  • WARN: Some tests skipped due to missing DOM setup (note for followup)
  • FAIL: New tests fail or existing tests regress → stop pipeline

Stage 7 - Ecosystem

Agent: ecosystem Tools: read, search, web Goal: Detect ecosystem changes and compatibility risks that affect the library.

Delegate prompt:

Research current ecosystem status for timepicker-ui. Check:

  1. Framework compatibility: React (latest), Vue 3, Angular, Svelte, Astro, Next.js SSR
  2. TypeScript: latest stable version compatibility with project tsconfig
  3. Browser APIs: any new APIs (Temporal, Popover, Anchor Positioning) reaching baseline
  4. Build tooling: tsup, Rollup, Vite - any breaking updates or deprecations
  5. Node.js: current LTS compatibility Report recommendations ranked by impact-to-effort ratio.

Gate criteria:

  • PASS: No critical compatibility risks
  • WARN: Recommendations exist but none are urgent
  • This stage never blocks the pipeline - it is informational only

Stage 8 - Release (Gated)

Agent: release Tools: read, edit, search, execute Goal: Bump version, update changelog, update documentation.

Entry conditions (ALL must be true):

  1. Stages 1–6 passed (no FAIL status)
  2. API stability report determined the correct semver bump type
  3. User explicitly confirms: "proceed with release"

Delegate prompt:

Prepare release for timepicker-ui. Steps:

  1. Bump type: [patch|minor|major] (from Stage 5 API stability report).
  2. Bump version in root package.json.
  3. Add changelog entry to CHANGELOG.md with all user-facing changes.
  4. Update README.md if API surface changed.
  5. Update docs-app pages if configuration or events changed.
  6. Run cd app && npm run test:ci to verify.
  7. Summarize the release.

Gate criteria:

  • PASS: Version bumped, changelog written, tests pass
  • FAIL: Tests fail after docs update → revert and report

Pipeline Execution Rules

Sequencing

Run stages in order (1 → 2 → 3 → 4 → 5 → 6 → 7 → 8). Each stage depends on the previous passing.

Gate Enforcement

After each stage, evaluate the gate criteria:

ResultAction
PASSProceed to next stage
WARNLog warnings, proceed to next stage
FAILStop the pipeline immediately, present all blockers to the user

User Checkpoints

Pause and ask the user before:

  1. Stage 6 (test-writer) - "Stages 1–5 passed. Proceed to generate missing tests?"
  2. Stage 8 (release) - "All stages passed. Semver bump: [type]. Proceed with release?"

Partial Runs

The user may request a subset of stages:

User saysRun stages
"run full maintenance"1 → 2 → 3 → 4 → 5 → 6 → 7 → 8
"run health check"1 → 2 → 3 → 4 → 5
"run pre-release check"1 → 2 → 3 → 4 → 5 → 7 → 8
"run code quality check"1 → 2
"run security and bundle"3 → 4
"prepare release"5 → 8 (assumes checks passed)
"generate missing tests"6 only

Progress Reporting

After each stage, report:

## Stage X: [Name] - [PASS|WARN|FAIL]

**Findings**: X issues (Y critical, Z warnings)
**Details**: [summary of key findings]
**Gate**: [PASS|WARN|FAIL] → [proceeding to Stage X+1 | pipeline stopped]

Final Summary

After all stages complete (or pipeline stops), produce:

## Pipeline Summary

| Stage | Agent            | Status | Findings |
| ----- | ---------------- | ------ | -------- |
| 1     | code-review      | PASS   | 0 P0     |
| 2     | accessibility    | WARN   | 0 P0, 3 P1 |
| 3     | bundle-optimizer | PASS   | -        |
| 4     | security         | PASS   | 2 Low    |
| 5     | api-stability    | PASS   | minor bump |
| 6     | test-writer      | PASS   | 3 tests added |
| 7     | ecosystem        | PASS   | 2 recommendations |
| 8     | release          | PASS   | v4.2.0 prepared |

**Overall**: PASS / WARN / FAIL
**Blockers**: [list or "none"]
**Warnings**: [list or "none"]
**Next steps**: [actionable items]

Constraints

MUST

  • Run stages in the defined order
  • Stop on any FAIL gate - never skip a failed stage
  • Ask for user confirmation before test generation (Stage 6) and release (Stage 8)
  • Respect each agent's tool restrictions (code-review and accessibility are read-only)
  • Report exact file paths and line numbers for all findings
  • Track cumulative state across stages (e.g., semver bump type from Stage 5 feeds Stage 8)

MUST NOT

  • Modify source code during read-only stages (1, 2, 5, 7)
  • Auto-proceed past user checkpoints
  • Run Stage 8 (release) if any previous stage FAILed
  • Skip stages in a full run - every stage must execute
  • Suppress or hide warnings - always surface them in the final summary

리뷰

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

댓글

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

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

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

0 / 1,000자

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

같은 저장소의 스킬

a11y

무료

Audit and improve the accessibility of the timepicker-ui LIBRARY (app/src) - ARIA, keyboard operability, focus trap/management, screen-reader announcements, labels - against WCAG 2.2 AA and the WAI-ARIA Authoring Practices. Use when the user wants an a11y audit/fix of the picker itself (clock, wheel, plugins, modal, inputs). Drives the accessibility subagent in an audit → approve → apply flow. Does NOT cover docs-app (use /docs-a11y for that).

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

pglejzer/timepicker-ui1012026년 10월 20일 업데이트

docs-a11y

무료

Audit and improve the accessibility of the timepicker-ui documentation site (docs-app/) - landmarks, heading order, skip links, keyboard nav, focus management in the command menu / sidebar / dialogs, color contrast, alt text, ARIA on custom components (tabs, native dialogs), reduced motion - against WCAG 2.2 AA. Use when the user wants an a11y audit/fix of the docs site. Drives the docs-accessibility subagent in an audit → approve → apply flow. Does NOT cover the library (use /a11y for that).

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

pglejzer/timepicker-ui1012026년 10월 20일 업데이트

docs-seo

무료

Audit and improve the discoverability of the timepicker-ui documentation site (docs-app/) across the full modern discoverability stack — SEO (ranking), AEO (answer engines / featured snippets), GEO (citations inside ChatGPT/Gemini/Perplexity/Claude), and AIO (Google AI Overviews). Use when the user wants to optimize docs SEO, improve Google ranking/positioning, win featured snippets or AI-answer boxes, get the docs cited by AI engines, add or fix sitemap/robots/manifest, fill in page metadata, add Open Graph/Twitter cards, answer-first copy, or JSON-LD (FAQPage/SoftwareApplication/TechArticle/BreadcrumbList). Drives the seo-optimizer subagent with an audit → approve → apply flow.

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

pglejzer/timepicker-ui1012026년 10월 20일 업데이트

release

무료

Cut a new timepicker-ui release. Use when the user wants to bump the version, prepare a release, write/update the changelog, or sync version + changelog across README, CHANGELOG.md and the docs-app (changelog/what's-new/version strings). Drives the build-release subagent in an audit → approve → apply flow, then runs a sanity build. Does NOT git-commit/tag or npm-publish — proposes those for the user to run.

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

pglejzer/timepicker-ui1012026년 10월 20일 업데이트

verify

무료

Browser-check what a change could have broken in timepicker-ui (library demo and docs-app, before/after). Use at the end of a task that changed library behavior or styles (app/src) or docs-app pages, or when the user asks to check that nothing broke. Not for demo examples in app/docs, copy/typo/comment edits or one-line fixes (HARD RULES §5 in CLAUDE.md). Main agent only, never delegated to a subagent.

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

pglejzer/timepicker-ui1012026년 10월 20일 업데이트

pglejzer의 스킬 모두 보기

이 스킬의 문제 신고