revise

Treat follow-up requests as spec amendments requiring explicit approval before implementation.

Updated May 21, 2026
One-click install
npx skills add https://github.com/mica-agent/mica-solar-system --skill revise-mica-agent
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: revise
Source: https://github.com/mica-agent/mica-solar-system/tree/main/.qwen/skills/revise
Command: npx skills add https://github.com/mica-agent/mica-solar-system --skill revise-mica-agent

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

It prevents wasting turns by treating “follow-up” requests as code patches when they actually require contract (spec) changes, ensuring the next implementation matches the updated expectations.

Core Features & Use Cases

  • Contract-change routing: Handles requests like “now it should also…”, “change the way X works”, and “include/add/remove” as spec amendments rather than cosmetic edits.
  • Approval-gated spec amendments: Reads the existing spec, proposes exact verbatim changes, and waits for explicit user approval before touching implementation.
  • Derived-surface discipline: Ensures the prompt/system instructions, parsers, and render surfaces are updated consistently with the amended output contract.

Quick Start

Reading this as a spec change, propose the exact replacement text for the affected section and ask for confirmation before any code changes are applied.

Frequently Asked Questions about revise

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I handle follow-up requests that require specification changes instead of code patches?

Specification changes for follow-up requests require routing the request as a contract amendment, proposing exact verbatim spec replacements, and waiting for explicit user approval before touching implementation.

What is the best way to manage contract changes when altering output shape or expanding scope?

Managing contract changes involves treating altered output shape or expanded scope as spec amendments, proposing exact replacement text for affected sections, and gating implementation behind explicit user approval.

When do I need to update the specification before changing behavior?

You need to update the specification before changing behavior when the user requests altered output shape, expanded scope, or when “still says X” recurrence indicates the existing spec is stale.

How do I ensure prompt instructions and parsers stay consistent with amended output contracts?

To ensure consistency with amended output contracts, apply derived-surface discipline to update prompt instructions, parsers, and render surfaces alongside the amended specification.

Does this spec-first workflow require explicit approval before applying code changes?

Yes, this spec-first workflow requires an approval gate where exact verbatim spec changes are proposed and confirmed by the user before any implementation or code changes are applied.

Why does my implementation still output the old behavior after a follow-up request?

Your implementation still outputs old behavior because follow-up requests were treated as cosmetic edits rather than contract changes, leaving the specification stale and the implementation unmatched.