update-app

name	update-app
description	Use when the user wants to change, extend, or add a feature to an existing Rayfin (Microsoft Fabric Data App). Trigger phrases — "update this Rayfin app", "add a screen to", "change the write-back for", "add a feature to the [app name] app". Amends the existing requirements.md in place and adds a new numbered user story; never creates a duplicate spec for an app that already has one.

Update an existing Rayfin app

Turn "change this Rayfin app" into an amended spec and a new, next-numbered user story — without losing or duplicating the app's existing spec history.

Boundaries

• Amends requirements.md in place. Never creates a second requirements file for an app that already has one.
• Adds a new user story for the change. Never renumbers, rewrites, or deletes a past story — even one that's now partially obsolete; if a past story is contradicted by this change, say so in the new story's Notes rather than editing history.
• Delegates the actual content of changed sections to plan-frontend / plan-data-source where the change touches screens/visuals or data contracts; this skill's own job is locating the app, reading its current state, and sequencing the story — not authoring those sections itself.
• Does not run CLI commands or deploy — that's build, once the amended spec reaches Ready to Build again.

Workflow

1. Resolve the target app via ../common/spec-location.md steps 1–4. This skill expects an existing match — if zero folders match at all, say so and suggest new-app instead of guessing that the user meant to create one.
2. Read current state: requirements.md (note its Status) and specs/user-stories/README.md's status table. Summarize back to the user in 2-3 sentences what this app currently does and its current Status, so they can correct you before you change anything.
3. Ask what's changing. Get enough detail to know which section(s) of requirements.md are affected: a new/changed screen → Screens/visuals (delegate to plan-frontend); a new/changed data source or write-back field → Data contracts (delegate to plan-data-source); anything else (auth, non-goals, personas) → amend directly here.
4. If Status: Built, reopen it. State plainly that you're moving it back to In Review because new work is being specced, and get a one-line confirmation before writing it — never silently reopen a shipped spec.
5. Amend the affected section(s) in place, either directly or via the delegated skill.
6. Add the next-numbered story in specs/user-stories/ (check the existing highest number, never reuse or renumber). Match the app's own established story shape first: read one or two of its existing story files — if they use a richer or different section layout than new-app's generic references/user-story-template.md (e.g. a ## Description / ## Acceptance Criteria / ## Impacted Files / ## Execution shape), follow that shape instead, so the story set stays consistent within the app. Fall back to the generic template only when no existing story gives a shape to match. Link the new story from requirements.md's User stories list and add its row to specs/user-stories/README.md's status table.
7. Confirm the diff back to the user: which sections changed, which story was added, and the new Status if it moved.