umbel: Skill for Claude Code

Change Request: Update + Cascade

Handle changes to what a feature does, requires, or connects to. Updates the affected feature and cascades impact assessments - to step traces, to dependent features, and to audit results that may now be stale.

What this skill assumes

• The change has been identified — the user has either described it or this skill is invoked from a context where the change is implicit (e.g., a brainstorm or audit run surfacing the need).
• The project state on disk is consistent (no half-applied edits from a previous interrupted change).
• For spine-level changes (renaming a persona, reordering jobs[], editing opportunity.personas), the user provides an explicit reindex/rename map when this skill asks for one. The skill refuses silent corruption.
• Audit cascade is the user's responsibility post-change. This skill identifies what needs re-verification; the user runs /tend audit to close the loop.

Why this matters

When checks change, every step that traces to them and every audit verdict against them becomes potentially invalid. The MCP write's auto-side-effects handle the easy cases (audit auto-invalidates on spec-of-truth field changes), but human-judgment cascades to dependent features are this skill's job. Without explicit handling, you end up with steps tracing to deleted checks, dependents that silently assume edges that no longer exist, and audits whose verdicts contradict the checks they reference.

Rules

• Always show a before/after diff for every changed field before writing. Confirm with the user before applying.
• Ask confirmation before making any changes to dependent features - the user decides cascade scope.
• Ask the user for clarification when a change is ambiguous - do not guess intent.
• Do not auto-rewrite checks on dependent features - flag them as needing review, never silently change them.
• If a change removes a dependency edge, check whether any dependent feature assumed that edge was satisfied - flag it.
• After all updates, run tend_validate and surface any schema errors (especially orphan checks after a step trace is removed).
• If the change would create a dependency cycle, refuse and explain why.
• Audit auto-invalidation is handled by the MCP write. Any material change to a check (description material change, validates, validates_job, method, integration_level, verification_recipe), any change to a step's description / traces_to, or any change to smoke.cmd causes the MCP write to clear audit and drop status from verified to in-progress in the same call. The skill does not call invalidation explicitly - the side-effect is what makes the cascade durable.
• The skill does the human-judgment cascade. MCP handles "this feature's audit is stale". The skill handles "feature X is in feature Y's dependencies, and X just changed its surface area - does Y need to revisit its checks?"