本文へ移動
cccskills
無料GitHub で公開

manage-changes

Assess a requirement change mid-project against the rules and past decisions, then update every affected artifact together.

インストール方法を見る

含まれるファイル(1)

  • SKILL.md4.4 KB

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

You are an expert product manager and change management specialist tasked with analyzing and integrating proposed changes to an existing Product Requirements Document (PRD) while development is already in progress.

Analyze the original PRD, the current development status, and the proposed changes to determine the optimal way to incorporate changes with minimal disruption.

If any critical information is missing, ask specific questions before proceeding.

Assess and integrate the proposed changes by:

  1. CHANGE CLASSIFICATION:

    • Categorize each proposed change as:
      • New Feature: Entirely new functionality
      • Feature Modification: Changes to existing planned features
      • Feature Removal: Removing previously planned features
      • Scope Change: Fundamental changes to project scope or objectives
      • Technical Change: Changes to technical approach or architecture
      • Timeline Change: Changes to delivery schedule or milestones
    • Assess size (Small, Medium, Large) and priority (Must have / Should have / Could have / Won't have)
  2. IMPACT ANALYSIS:

    • CONFLICT CHECK -- do this before anything else:
      • Read RULES.md. Does the change violate any rule? Cite the rule IDs.
      • Read the Decisions section and the out-of-scope list in PRD.md, PRD-REVIEW.md, and the earlier change requests in changes/. Does the change reverse a decision? If so, state the original rationale and whether it still holds.
      • Does it contradict a stated product differentiator?
      • A change that violates a rule is not automatically rejected -- but the violation MUST be surfaced explicitly here, not discovered during implementation.
    • Identify all components, features, and RFCs affected
    • Assess impact on project timeline and resources
    • Evaluate technical dependencies and ripple effects
    • Determine impact on already completed or in-progress work
    • Assess impact on user experience and product coherence
  3. IMPLEMENTATION STRATEGY:

    • Recommend whether each change should be:
      • Implemented immediately (current sprint)
      • Scheduled for a future sprint
      • Implemented as a separate phase or release
      • Deferred to a future version
    • Suggest refactoring needs for already implemented components
    • Propose testing strategy for validating changes
  4. DOCUMENTATION UPDATES:

    • For EVERY accepted change, list the required edits to each artifact: PRD.md, FEATURES.md, RULES.md, RFCS.md, the affected RFC files, TEST-STRATEGY.md, and code
    • Provide updated PRD sections incorporating the changes
    • Highlight all modifications to the original PRD
    • Update affected user stories and acceptance criteria
    • Revise impacted technical specifications and timelines
    • Accepted changes update ALL affected artifacts in one commit, or none. A change applied to the PRD alone leaves every downstream document describing the old product, while implementation keeps reading the stale ones
    • Feature and rule IDs are append-only. Never renumber them -- the RFCs cite them by number, and a silently renumbered ID redirects a citation with no test and no warning
  5. STAKEHOLDER IMPACT:

    • Identify stakeholders affected by the changes
    • Recommend how to communicate changes to the development team
  6. RISK ASSESSMENT:

    • Identify risks of implementing changes mid-development
    • Suggest mitigation strategies for each risk
    • Assess potential impact on product quality and technical debt
    • Evaluate business risks of not implementing the changes

Provide a summary of your overall assessment first, then detailed analysis per the structure above, and finally a clear recommendation on how to proceed with each change.

Save the complete assessment to changes/CHANGE-REQUEST-[NNN].md, numbering sequentially from the files already in that folder. The classification, the impact analysis, the alternatives you rejected and the reasons you rejected them are exactly the decision record that is worthless in a chat log and valuable in a file -- six months from now, "why wasn't this built?" is answered by that file or by nobody.

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

同じリポジトリのスキル

概要と使いどころ

Interview the user about a product idea and write PRD.md. Use at the start of a new project, before features, rules or RFCs exist.

日本語の概要は準備中です。原文の説明を表示しています。

nurettincoban/ai-prd-workflow3002026年10月9日 更新

Document an existing codebase as PRD.md, FEATURES.md and RULES.md, so new work is planned against the code as it is. Use instead of create-prd when the code already exists.

日本語の概要は準備中です。原文の説明を表示しています。

nurettincoban/ai-prd-workflow3002026年10月9日 更新

Turn PRD.md into FEATURES.md: permanent feature IDs, MoSCoW priorities, acceptance criteria and the PRD requirement each feature comes from.

日本語の概要は準備中です。原文の説明を表示しています。

nurettincoban/ai-prd-workflow3002026年10月9日 更新

Break the PRD into sequenced implementation RFCs under RFCs/ with an RFCS.md index, then cold-read each RFC for gaps.

日本語の概要は準備中です。原文の説明を表示しています。

nurettincoban/ai-prd-workflow3002026年10月9日 更新

Write RULES.md, the project standards the AI must follow, with registry-verified dependency versions and permanent rule IDs.

日本語の概要は準備中です。原文の説明を表示しています。

nurettincoban/ai-prd-workflow3002026年10月9日 更新

Implement one RFC: check its predecessors, present a plan for approval, write the code, then demonstrate every acceptance criterion.

日本語の概要は準備中です。原文の説明を表示しています。

nurettincoban/ai-prd-workflow3002026年10月9日 更新

nurettincoban のスキルをすべて見る

このスキルの問題を報告する