Skip to content

Activate both skill workflows through the shared launcher #904

Description

@tbhb-agent

Problem

Native commands do not complete the migration until both generated harness workflows invoke them. The current entry instructions at packages/agents/source/skills/rebase/SKILL.codex.md:16 and packages/agents/source/skills/resolve-rebase-conflicts/SKILL.codex.md:24 still invoke shell. Activation must use the launcher from #321 and retain the frozen fallback through N-2 without introducing another resolver.

Part of #588 and #326.

Acceptance criteria

  1. AC1: Given a supported installed binary, when either generated skill workflow is followed, then it dispatches to the corresponding Go operation through the shared launcher.
  2. AC2: Given the same supported fixture, when a generated Go workflow runs, then its status, streams and repository effects match the frozen workflow except for recorded migration differences.
  3. AC3: Given a legacy invocation during the N-2 window, when its frozen fallback is selected through the established compatibility contract, then its prior behavior remains available.
  4. AC4: Given the activation diff, when the retained fallback is compared with the baseline, then its executable logic is unchanged.
  5. AC5: Given missing or too-old binaries, when the Go entry is invoked, then the outcome is exactly the shared launcher's documented version contract.
  6. AC6: Given either harness package is generated and deployed, when generated consistency is checked, then source, packages, token metadata and lock records agree.
  7. AC7: Given entry invocation from a repository subdirectory, when either workflow runs, then it resolves the same repository and prints usable follow-up guidance.
  8. AC8: Given the published migration guidance, when it is read, then the first required release and at least two warning releases are identifiable before fallback deletion.
  9. AC9: Non-functional: activation introduces no shell selection logic or second binary resolver.
  10. AC10: Non-functional: native workflow cases execute without skips on macOS, Linux and Windows.

Scope and non-goals

Scope: skill manifests, shared prose, command routing integration and end-to-end compatibility evidence for rebase and conflict resolution.

Non-goal: implementing or modifying the shared launcher (#321), moving or deleting frozen implementations, changing PreToolUse hooks (#328 and #753), or retiring Bats/Python coverage. Existing public entry paths stay available throughout N-2. Python/uv removal applies to native Go commands only; the frozen compatibility path retains its prerequisites.

Approach

Consume #321's launcher and version/fallback contract; identify its exact invocation before editing the skill templates. This child changes generated workflow instructions and integration coverage, not shell algorithms. Keep frozen source in place; any routing or retention work needed by the launcher is a prerequisite delivered by #321, not an uncounted copy or relocation here. Retain current entry conventions in compatibility checks. Generate from canonical templates following tools/generate-skills.sh:30 and verify both harnesses. Keep hook commands at packages/agents/source/skills/rebase/SKILL.claude.md:7 and packages/agents/source/skills/resolve-rebase-conflicts/SKILL.claude.md:7 unchanged. Document intentional loss of Python/uv prerequisites on the Go path and any launcher-selected missing-binary behavior separately from behavioral parity.

Dependencies

Blocked by: #895, #896, #897, #898, #899, #900, #901, #902, #903, #851 (the readiness delivery), #333 (verified binary assets), #544 (consumer installation), #753 (protection).

Prerequisite: #321's single launcher and frozen-fallback contract. Use delivered outcomes rather than requiring whole-area closure. The command release must contain all required operations before deployment. PreToolUse replacement remains with #328 under #753; activation must not weaken the existing guards.

Size

M. Forecast 600 code lines: 450 integration tests/fixtures and 150 Go routing/diagnostic integration. No frozen-source relocation is budgeted or authorized here. Prose allowance: 600 lines including maintained templates and migration guidance.

scc could not run in the isolated checkout. Measured baselines count non-blank lines other than full-line # comments, including Python docstrings and embedded code conservatively. Forecasts include implementation, tests, fixtures and registration; they are estimates, not measured future Go. Generated output is excluded only under packages/agents/claude/.apm/skills/, packages/agents/codex/.apm/skills/, .claude/skills/, .agents/skills/ and tokens.json. The source under packages/agents/source/ and copies anywhere else count. The final diff must be at most 800 code lines and 2,000 prose lines, with no exception; split before implementation if either forecast grows beyond its limit.

Verify plan

  • AC1, AC2, AC7: run both generated workflows against isolated repositories, including a relative invocation from a subdirectory; compare streams, statuses and effects with the frozen implementations.
  • AC3, AC4: record fallback hashes and run supported legacy cases under the Port the shared skill library (lib.sh, agent.sh, signing.sh, gates.py) to Go #321 compatibility contract; compare executable logic byte-for-byte.
  • AC5, AC9: exercise absent, too-old and supported binaries through the one shared launcher; inspect the diff for duplicate resolvers or new shell branches.
  • AC6: regenerate skills, refresh tokens/deployments and lock records, then run generated-consistency and packaging checks.
  • AC8: compare migration documentation with the actual command-bearing release and the warning-release evidence.
  • AC10: inspect native three-platform Go CI; keep shell-required integration evidence explicitly marked by executing platform.
  • Definition of done: D1 each AC is verified at the merged head, with the commands and results cited in the pull request's Verification. D2 an independent review approves the exact merged head, and every finding has a recorded disposition. D3 required checks pass with no gate loosened. D4 the leak scans the repository specifies are clean, and every post made for this work passes the per-post leak review before it is posted. D5 every commit is signed. D6 the documentation matches the change or the Verification says why there is no impact. D7 every commit has an Assisted-by trailer and the pull request has the provenance:agent-assisted label. D8 the pull request stays within the size limits. D9 follow-ups are filed as issues and listed under Related. D10 the merge closes the issue through a closing reference, the board shows Done, and the final Status: comment names the merge commit.

Risks

Activating before binaries or compatibility routing are available strands consumers. A blanket rename could silently exceed the size limit. Undo: revert the workflow activation and regenerate; keep the unchanged fallback and recovery evidence available.

Operator authority

None.

Activity

  1. tbhb-agent commented on Oct 27, 2026

    @tbhb-agent
    ContributorAuthor

    Refinement: READY — Activate both skill workflows through the shared launcher
    Model: gpt-6-astra

    Child 10 Activate both skill workflows through the shared launcher

    Verdict: READY

    Checked: Activation still requires command parity, frozen-fallback preservation and prerequisite delivery. The corrected proof and classification contracts fit its existing integration scope. Forecast remains 600 lines.

    Gaps: None.

    Split: None required.

    Definition of done

    The definition of done for this issue (Feature). Tick each item and give its evidence.

    • D1 The author verified each AC on the merged head, and the Verification section of the pull request cites each AC ID with its evidence: the command and its result, or a link.
    • D2 An independent reviewer approved the exact merged head, and the author resolved each finding or filed it as a follow-up.
    • D3 The required checks pass on that head, and any loosened gate has the owner's approval of that exact head.
    • D4 The leak scans come back clean: gitleaks, devtools' check-leaks.sh with the repository's private-strings list, and the leak review of each post.
    • D5 The author signed each commit, the squash included.
    • D6 The docs match the change (README, docs/, CHANGELOG or help text), or the Verification section says "No doc impact" and why.
    • D7 The commits and the squash have Assisted-by trailers, and the pull request has the provenance:agent-assisted label.
    • D8 The pull request stays within the size limits, or the owner approved its exact head over the hard limit.
    • D9 The author files follow-ups and deferred findings as issues with at least a Problem and numbered AC and lists them under the Related section of the pull request. Any work left in the code links its issue.
    • D10 The merge closes the issue through a closing reference and the board shows Done. The final Status: comment names the merge commit.
    • devtools-1 mise run check is green, and so are the coverage floors mise run cover-go-check and mise run cover-py-check, which check doesn't run.
    • devtools-2 A change to skill sources under packages/agents/source/ commits what mise run generate-skills, then mise run skill-tokens, then apm install rewrite, in that order, and check-generated-skills (part of lint) passes.
    • devtools-3 A consumer-visible change (the vendored payload, a skill, a reusable workflow, a task or a pin) has its consumer steps in docs/agent-skills-migration.md or the adoption docs, or the PR's Verification says "No consumer impact" and why.

    Round: 2 of 3

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    refinement:readyPassed the Definition of Ready; may be picked up

    Fields

    Priority

    None yet

    Work type

    None yet

    Projects

    • Status
      Backlog

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions