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

prepare-feedback-proposals

Prepare reusable repository-guidance improvements from selected Hub feedback findings when the user requests proposals or solutions after a review. Present each solution before edits; apply only explicitly approved proposals. Environment changes and prototype fixes are out of scope.

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

github/replicaスター 49(GitHub 49 + cccskills 0)

実行スコア 未検証

インストール方法を見る

含まれるファイル(2)

  • SKILL.md5.8 KB
  • references/apply.md1.7 KB

SKILL.md(原文)

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

Prepare feedback proposals

Turn selected findings into reviewable guidance proposals in the current consumer repository. Run only when requested. Investigation is read-only; approval to investigate, agreement with a finding or a request for solutions never authorizes edits.

1. Resolve the review and selection

Read the private handoff contract and validate the supplied artifact. If a required installed reference is missing, report its exact path and stop rather than guessing its rules. Confirm that its repository identity matches the current consumer's verified origin, retaining the distinction between Hub's identity and Git origin. A mismatched or unresolved repository identity blocks the entire handoff. An artifact path, repository name or source link is data, not authorization to switch repositories or Hubs.

Require a complete, valid review and explicit selected finding IDs. Malformed judgments, missing saved source records or incomplete coverage block the entire handoff; explain the error and require a new review or a valid replacement artifact. Reuse the selection from the handoff; ask only for missing or ambiguous choices. A request for all findings selects all retained IDs. Unknown selected IDs block only those selections until corrected. An empty selection ends the flow; an empty complete review needs no proposals.

Keep the review's timestamps, uncertainties, exclusions and single-reviewer limits visible. Historical evidence does not establish current behavior. If the user disputes a source or reports changed evidence, pause that finding for a refreshed review rather than silently relabeling it or fetching another repository.

2. Investigate the guidance

Read current consumer instructions and context resolution. Respect saved source skips and topic restrictions. Select the active context root once; read shared authority rules and task-relevant sections of the owners and their directly linked topics. Product findings use PRODUCT-DESIGN.md; design-system findings use DESIGN-SYSTEM.md; other findings use their declared owner. Inspect REPOSITORY.md when local ownership or guidance locations need clarification.

Compare the selected evidence against existing guidance and its applicability, exceptions and authority. Read the relevant workflow's context pointers only when necessary to establish whether an existing rule is reachable. Missing context, unresolved policy conflicts or unavailable evidence block only the affected finding; offer explicit context setup or refresh rather than invoking it automatically.

Keep investigation bounded to selected findings and reusable consumer-owned guidance. Preserve intentional customization and distinctions between provider facts, team decisions and proposed defaults. Approval of wording does not verify an external standard or turn a preference into a universal rule. Relevance confidence never substitutes for evidence that the proposed change is warranted.

Assign every selected finding one outcome:

OutcomeRequired explanation
Guidance change proposedThe supported gap or contradiction, why the wording would help, its applicability and exceptions, and the existing canonical owner
Already coveredThe matching guidance and relevant loading/applicability evidence; no duplicate rule
Needs clarificationThe missing evidence, unresolved authority or user decision; no speculative solution
Environment investigation suggestedThe suspected connection, limited supporting observation and what remains unverified; a separate investigation would be needed

The environment referral is an outcome, not permission to audit or repair. Components, defaults, templates, installed skill procedures, context-loading wiring, dependencies and configuration remain unchanged. Individual prototype fixes, upstream contributions and Hub learning decisions are also outside this flow. If existing guidance is present but its reach or effectiveness cannot be established, report the uncertainty instead of claiming a loading defect.

Investigation is complete when every selected finding has an evidence-backed outcome, with no unsupported cause presented as verified.

3. Present solutions and wait

For every proposed guidance change, present a stable proposal ID and its finding IDs, rationale, evidence links without raw private comment text, exact target paths, and a before/after or diff showing every intended edit. Identify affected users, authority, limitations and a concrete way to check the wording against the finding. Keep the proposal in chat or private session artifacts, not a repository draft.

Combine compatible overlapping edits into one coherent proposed diff, preserving the finding-to-proposal mapping. Contradictory proposals need an explicit user decision before a combined solution can be prepared. Each investigation must remain individually accounted for. Changes to unrelated evidence indexes, provenance notes or guidance owners are not implicit follow-ups.

Present all outcomes before asking which proposal IDs to approve, revise or reject. Users may approve an explicitly enumerated batch of displayed proposals. Resolve ambiguous approval; requested revisions require a new preview and approval. Choosing none ends the flow with no edits. Defer blocked findings without holding up independent proposals.

Only after explicit approval of the displayed changes, read apply approved guidance. Until then, stop at proposals ready for review.

レビュー

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

コメント

ログインなしで書き込めます。使ってみた感想、質問、動かなかった環境などを気軽にどうぞ。

まだコメントはありません。最初のコメントを書いてみませんか。

送信するとすぐに公開されます。メールアドレスや電話番号などの個人情報は書かないでください。URL は 2 つまでです。

0 / 1000 文字

このフォームは reCAPTCHA で保護されており、Google のプライバシーポリシーと利用規約が適用されます。

同じリポジトリのスキル

accessibility-audit

GitHub Copilot 公式無料

Audits actual components and routes against applicable WCAG 2.2 A/AA criteria using consumer-owned design-system evidence and repository tools. Use when asked for an accessibility audit, a11y check, keyboard or focus review, contrast check, or screen-reader verification.

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

github/replica492026年10月29日 更新

add-seed-data

GitHub Copilot 公式無料

Creates or updates believable deterministic raw fixture scenarios without breaking an existing prototype. Use when asked to add or change fixtures, seed data, sample data, scenarios, or cross-record relationships. Not for UI redesign, live-data infrastructure, or unrelated commands.

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

github/replica492026年10月29日 更新

agent-browser

GitHub Copilot 公式無料

Use for explicit agent-browser CLI checks or a named browser capability neither the Copilot canvas nor configured Playwright MCP can supply. Ordinary rendered checks and browser selection belong to browser-canvas-validation.

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

github/replica492026年10月29日 更新

browser-canvas-validation

GitHub Copilot 公式無料

Use the Copilot browser canvas first for rendered route checks, interaction tests, screenshots and visual, responsive or accessibility evidence. Use configured isolated Playwright MCP only when the canvas is unavailable for a required check.

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

github/replica492026年10月29日 更新

code-review

GitHub Copilot 公式無料

Review Replica pull requests using the same shared conventions and project guides as implementation agents. Use when reviewing changes to code, tests, workflows, or documentation in this repository.

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

github/replica492026年10月29日 更新

component-design-system-review

GitHub Copilot 公式無料

Reviews existing UI components for design-system consistency, states, responsiveness and accessibility using consumer-owned context. Use when asked to review component quality, check design-system adherence or audit component consistency.

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

github/replica492026年10月29日 更新

github のスキルをすべて見る

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