prepare-feedback-proposals
Skill117 starsChanged 10 days agoMITView on GitHub
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.
We split this skill into the rules it gives an agent
2 rules. About 0 are common, 2 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈2
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 16
Keep the review's timestamps, uncertainties, exclusions and single-reviewer limits visible.
- Distinctive: line 47
Only after explicit approval of the displayed changes, read apply approved guidance.
≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
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:
| Outcome | Required explanation |
| Guidance change proposed | The supported gap or contradiction, why the wording would help, its applicability and exceptions, and the existing canonical owner |
| Already covered | The matching guidance and relevant loading/applicability evidence; no duplicate rule |
| Needs clarification | The missing evidence, unresolved authority or user decision; no speculative solution |
| Environment investigation suggested | The 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.
In this repository34 other files it gives its agents.
- AGENTS.mdAGENTS.md
- hub/AGENTS.mdAGENTS.md
- starters/coreai/AGENTS.mdAGENTS.md
- starters/minimal/AGENTS.mdAGENTS.md
- replica-pick-and-polishSkill
- replica-publish-prototypeSkill
- review-hub-feedbackSkill
- code-reviewSkill
- write-testsSkill
- coreai-ds-fluentui-reactSkill
- css-stylingSkill
- features-variantsSkill
- iconsSkill
- interpreting-htmlSkill
- lintSkill
- new-variantSkill
- react-componentsSkill
- routingSkill
- start-appSkill
- state-managementSkill
- context-templatesSkill
- accessibility-auditSkill
- add-seed-dataSkill
- agent-browserSkill
- browser-canvas-validationSkill
- component-design-system-reviewSkill
- create-prototypeSkill
- developer-handoffSkill
- product-designSkill
- prototype-controlsSkill
- responsive-auditSkill
- review-hub-feedbackSkill
- setup-skillsSkill
- visual-design-reviewSkill
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
Reviews can't be read right now.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

