User Story

As the framework maintainer (me2resh) or any adopter who wants to test pre-release framework changes on a separate machine before the release tag is cut, I want a hidden --from-dev flag on /update that pulls from upstream/dev instead of the latest tagged release, prints a "PRE-RELEASE — expect breakage; revert with X" banner, and otherwise reuses the existing /update conflict-resolution flow.

Acceptance Criteria

Skill

• .claude/skills/update/SKILL.md accepts a new --from-dev flag
• When --from-dev is passed:
  • Fetches upstream/dev (not the latest tag)
  • Previews the commit delta between fork's HEAD and upstream/dev
  • Creates the same sync branch (chore/sync-upstream-dev or similar; existing convention)
  • Merges (or rebases per --rebase) using the existing conflict-resolution flow
  • Prints a banner at the top of the operation:

    ⚠ PRE-RELEASE SYNC — pulling from upstream/dev
       This is unreleased work; expect breakage.
       Revert with: git reset --hard origin/main
       For supported updates, use /update (no flag) to pull tagged releases.
    

• When --from-dev is NOT passed: behaviour identical to today (pull tagged release from upstream/main)

"Hidden" semantics

• The flag is NOT mentioned in the skill's description frontmatter (so /help doesn't surface it)
• The flag IS documented in the skill's ## Options / ## Usage section near the bottom, so operators who read the spec find it
• No /setup prompt offers the flag; adopters opt in by knowing the flag exists from the spec

Safety

• --from-dev does NOT bypass any existing safety in /update: still creates a sync branch (no direct push to main), still walks conflict resolution, still leaves the merge for the operator to push
• The banner is printed BEFORE the fetch + merge starts, so the operator sees the warning before any state mutation

Tests

• Existing /update tests (if any) still pass
• New smoke test: run /update --from-dev --dry-run on a synthetic fork; assert: banner printed, commits previewed against upstream/dev (not upstream/main), no state changes

Docs

• docs/multi-project.md or docs/getting-started.md § Upgrades gains a brief note: "Pre-release testing: use /update --from-dev to pull unreleased changes from upstream dev for testing before a release tag is cut. Not a supported general-adopter path."

Design Notes

Why "hidden". The framework's adopter contract is "tagged releases from upstream/main", per the release-cut model (AgDR-0007). Adopters who pull from dev are signing up for breakage between releases — that's an opt-in behaviour, not a default. Making the flag discoverable via /help would invite adopters to use it casually, defeating the release-cut model's stability promise.

Why not a separate skill (/update-dev). Same conflict-resolution code path, same sync-branch convention, same merge gates. A separate skill duplicates 95% of /update's logic for a one-line flag-check difference. The flag-on-existing-skill shape is cheaper to maintain.

Why the banner is load-bearing. Without it, an operator who runs --from-dev once may forget the next time and assume they're on a stable release. The banner restates the deal every invocation.

Use cases that motivated this:

1. me2resh testing v1.3 work on a separate machine before cutting the v1.3 release tag (exactly the trigger that filed this ticket)
2. Adopters who want to validate that an upcoming framework change is safe for their stack before the wider rollout
3. CI workflows that pin to dev for integration testing (rare, but legitimate)

Out of Scope

• Pulling from a specific tag that isn't the latest (could be a separate --tag=<tag> flag if anyone asks)
• Pulling from a fork other than the configured upstream (out of scope; configured upstream only)
• Auto-rollback if the merged dev commits cause test failures (operator's job to verify post-merge; the framework's /update doesn't try-and-roll-back)
• Bringing --from-dev parity to /release (release work always pulls tagged + cuts new tags; dev isn't a release source)

Effort Estimate

TBD — likely 0.5 day. Mostly a flag-check + a banner + adjusting the fetch target.