chore(skills): update cutting-releases for fullsend-ai @main switch

skills/cutting-releases/post-flight.md

@@ -4,7 +4,7 @@ Part of the [cutting-releases](SKILL.md) skill.
 
 Run after the version tag is pushed, the `v0` tag is moved, and the
 CI workflows complete. Focus on the areas identified during pre-flight
-step E.
+step F.
 
 ## A. Wait for CI workflows
 
@@ -29,59 +29,65 @@ gh release view <tag>
 Check that the title, changelog, and binary assets look correct.
 Verify the release is not marked as a draft.
 
-## C. Check fullsend-ai repos
+## C. Skip fullsend-ai repos
 
-The skill user is a fullsend repo admin, so fullsend-ai org repos
-are always accessible. Check recent workflow runs in the org's repos
-that consume `@v0` reusable workflows:
+The `fullsend-ai/.fullsend` repo references reusable workflows via
+`@main`, not `@v0`. Its runs do **not** exercise the `v0` tag and
+cannot confirm that the tag move worked. (Those runs are checked
+during pre-flight instead, as a signal that `main` is healthy.)
+
+Skip fullsend-ai for post-flight `v0` verification. Focus on other
+downstream consumers in step D.
+
+## D. Check additional downstream repos (optional)
+
+Use `AskUserQuestion` to ask if the user has access to additional
+downstream orgs:
+
+> Do you have access to any other downstream orgs/repos to verify?
+> (e.g. "konflux-ci, redhat-developer/rhdh-agentic")
+> Leave blank to skip.
+
+For each repo provided, check recent workflow runs that started
+**after** the `v0` tag move:
 
 ```
-gh run list --repo fullsend-ai/fullsend --limit=3
-gh run list --repo fullsend-ai/.fullsend --limit=3
+gh run list --repo <org/repo> --limit=5
 ```
 
-Look for runs that started **after** the `v0` tag move. Confirm they
-completed without workflow-resolution errors (e.g. "could not find
-reusable workflow"). If no runs occurred naturally, check for any
-recent failed or cancelled runs that can be retriggered:
+Confirm they completed without workflow-resolution errors (e.g.
+"could not find reusable workflow"). If no runs occurred naturally,
+check for recent failed runs that can be retriggered:
 
 ```
-gh run list --repo fullsend-ai/.fullsend --status=failure --limit=3
+gh run list --repo <org/repo> --status=failure --limit=3
 ```
 
 Present any candidate to the user for confirmation before retriggering:
 
-> I found run `<run-id>` (failed) in `fullsend-ai/.fullsend`.
+> I found run `<run-id>` (failed) in `<org/repo>`.
 > Retrigger it to verify `@v0` resolves?
 
 Once confirmed:
 
 ```
-gh run rerun <run-id> --failed --repo fullsend-ai/.fullsend
+gh run rerun <run-id> --failed --repo <org/repo>
 ```
 
-## D. Check additional downstream repos (optional)
-
-Use `AskUserQuestion` to ask if the user has access to additional
-downstream orgs:
-
-> Do you have access to any other downstream orgs/repos to verify?
-> (e.g. "konflux-ci, redhat-developer/rhdh-agentic")
-> Leave blank to skip.
-
-If the user provides repos, repeat the same checks from step C for
-each one. If blank, skip this step — not all admins have access to
-every enrolled org.
+If blank, skip this step — not all admins have access to every
+enrolled org.
 
 ## E. Present post-flight summary
 
 Summarize results to the user:
 
 | Org/Repo | `@v0` Refs | Status |
 |----------|-----------|--------|
-| fullsend-ai/.fullsend | Confirmed | Passing |
 | ... | ... | ... |
 
+Note: `fullsend-ai` repos are excluded from this table — they use
+`@main` and were checked during pre-flight.
+
 Distinguish between:
 - **Release-related failures** — workflow resolution errors, missing
   secrets, or permission failures caused by the tag move.

skills/cutting-releases/pre-flight.md

@@ -102,21 +102,43 @@ gh run list --branch=main --limit=5
 All recent runs should be passing. If E2E tests are failing, investigate
 before releasing.
 
-## E. Identify post-flight check areas
+## E. Check fullsend-ai runs as a main-branch signal
+
+The `fullsend-ai/.fullsend` repo references reusable workflows via
+`@main` (not `@v0`). This means its recent runs already exercise the
+exact commit we are about to tag. Use this as a pre-flight signal:
+
+```
+gh run list --repo fullsend-ai/.fullsend --limit=5
+gh run list --repo fullsend-ai/fullsend --limit=5
+```
+
+If recent runs are passing, that is evidence the reusable workflows on
+`main` work correctly and moving `v0` to this commit is low-risk.
+
+If recent runs are failing, investigate whether the failures are related
+to reusable workflow changes. Workflow-resolution errors or permission
+failures are blockers. Unrelated agent runtime errors are not.
+
+## F. Identify post-flight check areas
 
 Based on the changes found in steps A–C, determine what needs
 post-flight verification after the `v0` tag moves:
 
-- **Reusable workflow changes** → verify workflow runs in fullsend-ai
-  repos resolve `@v0` correctly and pass.
+- **Reusable workflow changes** → verify workflow runs in downstream
+  `@v0` consumers (outside fullsend-ai) resolve correctly and pass.
 - **New secrets or permissions** → verify affected workflows don't
   fail on missing secrets.
 - **CLI default changes** → note migration steps for existing
   installs in the release summary.
 - **No reusable workflow changes** → post-flight can be limited to
   confirming the release artifacts built correctly.
 
-## F. Present summary
+Note: `fullsend-ai/.fullsend` uses `@main`, not `@v0`, so its runs
+are not useful for post-flight `v0` verification. Post-flight checks
+should focus on other downstream consumers that reference `@v0`.
+
+## G. Present summary
 
 Summarize findings to the user in a table:
 
@@ -126,6 +148,6 @@ Summarize findings to the user in a table:
 | Scaffold templates | ... | No/Yes |
 | CLI / internal | ... | No/Yes |
 
-List the post-flight check areas identified in step E.
+List the post-flight check areas identified in step F.
 
 Give a **GO / NO-GO** verdict. Do not proceed until the user confirms.