원클릭으로 Manus에서 모든 스킬 실행

056-design-avoid-breaking-changes

스타416

포크83

업데이트2026년 7월 11일 17:34

Use when you need to review a plan, OpenSpec change, specification, or implementation proposal for breaking-change risk across commands, skills, generated outputs, XML sources, README/docs, tests, CI, APIs, schemas, configuration, data, migration, and release guidance. This should trigger for requests such as Review breaking changes in this spec; Check compatibility risks; Avoid breaking changes in this OpenSpec change; Review migration impact before release; Assess command and skill compatibility. Part of Plinth Toolkit

설치

Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.

Manus에서 실행

출처

jabrena

jabrena/plinth

GitHub 저장소 열기 Creator 저장소 보기

다운로드

Manus에서 실행

관련 직업SOC

SOC 직업 분류 기준

소프트웨어 개발자컴퓨터 및 수학직·SOC 15-1252

파일 탐색기

2 개 파일

SKILL.md

readonly

이 저장소의 다른 Skills

같은 저장소

041-planning-plan-mode

jabrena/plinth

Use when creating or refining a structured Java implementation plan from trusted issue summaries, approved designs, ADRs, OpenSpec changes, existing plans, or a valid combination. The plan records its source artifacts and derivation direction and can remain the execution artifact without requiring OpenSpec. This should trigger for requests such as Create a plan from an issue; Create a plan from OpenSpec; Design an implementation plan; Refine an existing plan. Part of Plinth Toolkit

2026-07-11416

042-planning-openspec

jabrena/plinth

Use when creating or updating OpenSpec change artifacts from an issue, implementation plan, approved design, ADRs, existing OpenSpec artifacts, or a valid combination. The workflow assesses whether the scope is one change or multiple changes, records sources and derivation direction, and prevents silent synchronization. This should trigger for requests such as Create an OpenSpec change from an issue; Convert a plan into OpenSpec; Update an existing OpenSpec change; Split broad requirements into reviewable OpenSpec changes. Part of Plinth Toolkit

2026-07-11416

044-planning-jira

jabrena/plinth

Use when you need Jira CLI (`jira`) installation/authentication guidance and a maintainer-authored Jira issue inventory workflow. The agent does not ingest raw Jira issue or JQL output directly; it asks the Jira project maintainer/operator to author sanitized issue summaries before analysis or @014-agile-user-story handoff. This should trigger for requests such as jira issue list; List Jira issues; Jira JQL issue query; Jira CLI issue workflow. Part of Plinth Toolkit

2026-07-11416

057-design-feature-toggles

jabrena/plinth

Use when designing, implementing, reviewing, testing, or cleaning up feature toggles, feature flags, kill switches, runtime configuration gates, canary controls, staged rollouts, experiments, or temporary compatibility switches in Java enterprise systems. This should trigger for requests such as Design a feature toggle strategy; Review this feature flag; Add a kill switch safely; Test toggle on and off paths; Clean up an expired feature toggle; Plan controlled rollout and rollback behavior. Part of Plinth Toolkit

2026-07-11416

123-java-design-patterns

jabrena/plinth

Use when you need to select, review, or implement Java design and integration patterns — including classic Java design patterns, REST API patterns, Kafka and event-driven patterns, database and persistence patterns, and cross-cutting integration patterns. This should trigger for requests such as Apply Java design patterns; Review REST API patterns; Design Kafka event-driven patterns; Improve database persistence patterns; Add resilient integration patterns. Part of Plinth Toolkit

2026-07-11416

128-java-generics

jabrena/plinth

Use when you need to review, improve, or refactor Java code for generics quality — including avoiding raw types, applying the PECS (Producer Extends Consumer Super) principle for wildcards, using bounded type parameters, designing effective generic methods, leveraging the diamond operator, understanding type erasure implications, handling generic inheritance correctly, preventing heap pollution with @SafeVarargs, and integrating generics with modern Java features like Records, sealed types, and pattern matching. This should trigger for requests such as Improve the code with Generics; Apply Generics; Refactor the code with Generics; Improve generic type safety in Java APIs; Fix raw types and unchecked casts in Java code. Part of Plinth Toolkit

2026-07-11416

name	056-design-avoid-breaking-changes
description	Use when you need to review a plan, OpenSpec change, specification, or implementation proposal for breaking-change risk across commands, skills, generated outputs, XML sources, README/docs, tests, CI, APIs, schemas, configuration, data, migration, and release guidance. This should trigger for requests such as Review breaking changes in this spec; Check compatibility risks; Avoid breaking changes in this OpenSpec change; Review migration impact before release; Assess command and skill compatibility. Part of Plinth Toolkit
license	Apache-2.0
metadata	{"author":"Juan Antonio Breña Moral","version":"0.17.0"}

Avoid Breaking Changes

Review planned repository changes for breaking-change and compatibility risk before implementation or release promotion. This is an interactive SKILL.

What is covered in this Skill?

Command contract compatibility: names, inputs, owning agents, outputs, safeguards, installer registration, and command inventories
Skill routing compatibility: identifiers, metadata, descriptions, triggers, references, generated local output, and acceptance coverage
Generated-output ownership: XML/source files versus .agents/skills, public skills/, .cursor/commands, .cursor/rules, and docs/
Source and generator contracts: XML, XInclude, XSLT, Maven modules, schema expectations, and module validation
README, localized README, changelog, migration, and deprecation guidance
External and runtime contracts: APIs, schemas, data formats, configuration keys, persistence, CLI behavior, and CI expectations
Structured compatibility reports with severity-ranked findings and validation guidance

Constraints

Keep the review evidence-based, read-only, and scoped to compatibility risk unless the user explicitly asks for implementation.

MUST read references/056-design-avoid-breaking-changes.md before producing compatibility guidance
MUST identify the source artifacts reviewed and the compatibility surfaces considered
MUST distinguish confirmed breaking changes, potential risks, non-breaking changes, and unknowns that need maintainer decision
MUST include migration, deprecation, validation, or release-note guidance for intentional breaking changes
MUST respect repository source ownership: edit XML and source docs, regenerate generated output through documented workflows, and avoid direct generated-output edits unless the repository explicitly owns that file
MUST NOT modify plans, specs, source files, generated outputs, or issue descriptions during review unless the user explicitly requests implementation

When to use this skill

Review breaking changes in this spec
Check compatibility risks
Avoid breaking changes in this OpenSpec change
Review migration impact before release
Assess command and skill compatibility
Find generated output compatibility risks
Review API schema configuration or data contract changes

Workflow

Read the compatibility reference

Read references/056-design-avoid-breaking-changes.md, then identify the source artifacts to review, their authority, and whether the request is read-only review or approved implementation.

Inventory compatibility surfaces

Check commands, skills, generated outputs, XML/source ownership, README/docs, tests, CI/build gates, external contracts, runtime behavior, data/configuration contracts, and release or migration guidance relevant to the proposed change.

Classify findings

Classify each finding as BREAKING, POTENTIALLY BREAKING, NON-BREAKING, or UNKNOWN. Include the affected users, artifacts, contracts, and validation evidence or missing evidence.

Recommend migration and validation

For each confirmed or potential risk, recommend deprecation, compatibility windows, migration notes, release-note updates, generator checks, focused tests, or owner decisions.

Report the review outcome

Produce a concise compatibility report with reviewed sources, risk summary by surface, severity-ranked findings, recommended validation, and a clear no-risk statement when no breaking-change risks are found.

Reference

For detailed guidance, examples, and constraints, see references/056-design-avoid-breaking-changes.md.