skill-pack publish pipeline is broken end-to-end: two critical blockers

[JoeCardoso13]

Summary

Publishing a skill to Mpak following the documented workflow at https://mpak.dev/publish/skills and https://docs.mpak.dev/skills/github-action/ failed after several attempts. Two distinct blockers prevent publishing from working at all.

---

Blocker 1: GITHUB_TOKEN-created releases don't trigger the release: published workflow event

The documented approach is a two-workflow setup:

1. One workflow creates a GitHub release
2. A second workflow triggers on release: [published] and runs skill-pack

This doesn't work. GitHub intentionally prevents workflows triggered by GITHUB_TOKEN from firing other workflow events, to avoid infinite loops. So the release: published event never fires when the release is created programmatically.

What we tried: We merged both workflows into a single job (auto-release → skill-pack in sequence), bypassing the cross-workflow trigger entirely. This leads to Blocker 2.

---

Blocker 2: skill-pack@v1 pack step fails silently on push events

When running skill-pack directly in a push-triggered workflow (after creating the release in the same job), the pack step fails with exit code 1 and zero output after printing Packing: <skill-name>.

Relevant log:

Packing: devflow
##[error]Process completed with exit code 1.

No zip error, no version error, nothing. The failure is completely silent.

What we tried:

• Overriding GITHUB_REF via env: GITHUB_REF: refs/tags/<computed-tag> to simulate a release event context — no change
• Installing zip explicitly via apt-get before the step — no change
• Confirmed skill validates successfully (✓ Valid: devflow) before the pack step fails

Runs for reference: JoeCardoso13/devflow — runs 24566028970, 24566570805, 24566729124, 24567028379

---

Impact

Publishing a skill to Mpak is currently impossible following the documented workflow. The two blockers together mean there's no working path from "I have a SKILL.md" to "skill is on mpak.dev" without undocumented workarounds.

The docs need to either:

• Document a working single-workflow approach that doesn't rely on cross-workflow event triggers
• Fix skill-pack to handle non-release event contexts gracefully (or surface actionable errors instead of silent exit 1)

Happy to test fixes.

[JoeCardoso13]

For reference, here's the full SKILL.md I were trying to publish:

---
name: devflow
description: Development workflow. Use when building a feature, creating an MVP, refactoring code, fixing a bug, or any task that involves writing or changing implementation code.
argument-hint: "[design|test|implement|debug]"
---

Work happens in exactly 4 modes. Operate in one mode at a time.
Do not finish working on a mode without the consent of the user.

---

### How to identify your current mode

If `$ARGUMENTS` is provided, jump directly to that mode:

| `$ARGUMENTS` | Action |
|---|---|
| `design` | Enter Mode 1 — Design |
| `test` | Enter Mode 2 — Test (Red) |
| `implement` | Enter Mode 3 — Implement (Green) |
| `debug` | Enter Mode 4 — Observe & Debug |
| empty | Read HANDOFF.md if present; otherwise ask the user which mode to start in |

Fallback: infer from codebase state

| Mode | You're here when... |
|------|-------------------|
| 1 - Design | No implementation plan exists yet, OR the user asks to plan/architect |
| 2 - Test (Red) | Design is complete; no tests exist yet (or tests need to be written) |
| 3 - Implement (Green) | Failing tests exist; task is to make them pass |
| 4 - Observe & Debug | Tests pass; task is coverage, logging, or a bug was reported |

---

### Mode 1 — Design

**Goal:** Establish the *why*, *what*, and *how* before any code is written.
**Activities:** Ideation, architecture, stack/tooling choices, infrastructure scoping.
**Forbidden:** Writing or editing any code in the codebase.
**Output (contract to Mode 2):** A concrete, agreed spec of what will be built — specific enough that tests can be written against it.

---

### Mode 2 — Test (Red) ⚠️ Most critical mode

**Goal:** Prove the spec is testable before implementation begins.
**Input:** The design contract from Mode 1.
**Activities:**
- Write tests that will pass *only if* the correct behavior is implemented
- Cover happy paths, edge cases, failure modes, and interface boundaries
- Install dependencies / set up boilerplate so tests fail at *assertions*, not imports

**The one rule:** A test that cannot fail for the right reasons is worse than no test.
**Forbidden:** Writing implementation code (test scaffolding/boilerplate is the only exception).
**Output (contract to Mode 3):** Full test suite — all red, all failing at assertions.

---

### Mode 3 — Implement (Green)

**Goal:** Make the red tests pass.
**Input:** The failing test suite from Mode 2.
**Activities:** Write implementation code guided by what the tests express.
**Forbidden:** Editing tests. If a test seems wrong, stop and ask the user — do not modify it.
**Output (contract to Mode 4):** All tests passing. No test was changed.

---

### Mode 4 — Observe & Debug

**Goal:** Verify the system works end-to-end and regressions are caught.
**Activities:**
- Run coverage; flag untested lines to the user
- Write e2e tests that exercise the system from the outside — real inputs, real outputs, no mocks
- If a bug is found: understand it, fix it, add a **regression test** before touching the code

**Forbidden:** Fixing a bug before writing a regression test that reproduces it.
**Output:** Coverage report, e2e tests passing, zero known regressions.

---

**Context note:** Each mode may run in a separate agent/context window.
Treat the mode's input contract as the only shared state you can rely on.

### Mode Handoff

At the end of each mode, (over)write a handoff to `HANDOFF.md` at the repository root.

`HANDOFF.md` is the canonical cross-mode handoff artifact. It should contain the latest authoritative handoff, replacing any previous handoff content unless the user explicitly asks for a historical log.

**Mode:** <DESIGN | TEST_RED | IMPLEMENT_GREEN | OBSERVE_DEBUG>
**Goal:** <what this mode was trying to accomplish>
**Inputs used:** <user request, files read, tests examined, errors seen>
**Changes made:** <specific files edited or created — paths and a one-line summary each>
**Outputs produced:** <design doc, list of failing tests with names, passing test run output, debug findings>
**Open issues:** <blockers, risks, unknowns — be specific, not vague>
**Next recommended mode:** <next mode + one sentence on why>