skills/release/SKILL.md
Force-release a stuck roadmap-level feature claim (admin command)
npx skillsauth add pdlc-os/pdlc releaseInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
You are force-releasing a roadmap-level feature claim. Use this when a claim is stuck — dev left the team, laptop unavailable, session died without cleanup — and another dev needs to pick up or reassign the feature.
If $ARGUMENTS is empty, list every currently-held roadmap claim and ask which to release:
bd list --label roadmap --status in-progress --json
Present the list as:
"Active roadmap claims:
- F-005 (
user-auth) — held by[email protected]since2026-04-10- F-008 (
webhooks) — held by[email protected]since2026-04-18Which do you want to release? Type
F-NNNorcancel."
Store the target feature ID as [feature-id] and feature slug as [feature-name].
Check if [feature-id] is claimed by the current user:
bd list --claimed-by me --label roadmap --label [feature-id] --json
If the result is non-empty, refuse:
"
[feature-id]is your own active claim. Use/abandonif you want to stop work on this feature — that preserves artifacts and records an ADR./releaseis for unsticking someone else's orphaned claims."
Stop here.
Show what's being released and require explicit confirmation:
bd show [bd-task-id]
Print:
"Force-releasing
[feature-id]: [feature-name]
- Currently claimed by:
[claimer email]- Claimed at:
[timestamp]- Status will go from
in-progress→planned- Feature becomes available for the next
/brainstormThis is a high-friction action — it interferes with another developer's in-flight work. Confirm with their team first if possible.
Reason for force-release? (required — goes into DECISIONS.md)"
Wait for a reason. Empty / skip / cancel aborts.
bd unclaim [bd-task-id]
bd update [bd-task-id] --status planned
If bd update --status isn't supported, use bd update [bd-task-id] --reopen or the closest equivalent to put the task back into planned so bd ready --label roadmap surfaces it.
Report:
"Claim released.
[feature-id]is now available for the next/brainstorm."
Find the row for [feature-id]. Update:
—In Progress → PlannedAppend a new ADR:
### ADR-[NNN]: Force-release of roadmap claim [feature-id]
**Date:** [today]
**Source:** User (explicit — `/release [feature-id]`)
**Phase:** Administrative
**Agent:** Atlas
**Feature:** [feature-name]
**Previous claimer:** [email]
**Status:** Active
**Decision:** Force-release the claim on `[feature-id]` without consent from the prior claimer.
**Context:** [user's reason]
**Alternatives considered:** Not applicable — administrative action.
If gh is available AND the repo has a pinned Roadmap GitHub issue (from the ship-time mirror), append a comment to that issue:
gh issue comment <roadmap-issue-number> --body "Force-released claim on **[feature-id]** (was held by @[prior-claimer]). Reason: [user's reason]. Released by @[me]."
Skip silently if gh is unavailable or no pinned issue exists.
Tell the user:
"Force-release complete for
[feature-id].
- Beads task unclaimed, status →
planned- ROADMAP.md updated
- ADR-[NNN] recorded in DECISIONS.md [If notified:] - Comment posted to the Roadmap issue
The next
/brainstorm(without args) will pick this feature up as the next priority candidate."
/release never touches artifacts. PRDs, design docs, brainstorm logs, and feature branches created by the prior claimer stay in place. The next dev who claims the feature can choose to reuse or discard them./release never releases your own active claim — use /abandon instead.[feature-id] — check bd list --label roadmap and /diagnose." Do not fall back to editing ROADMAP.md alone; that would create the exact drift this skill is designed to prevent.data-ai
Run a feature autonomously from approved-PRD to shipped, evaluated by a per-turn Sentinel hook. Requires bypass-permissions mode and Agent Teams mode.
development
# Variant Convergence **Topic slug:** `variant-convergence` **Triggers:** - **Inception path — Brainstorm Design Step 10.7:** after Step 10.6 (Design-Laws Audit) completes, before Step 11 (PRD design-doc link updates) and the Step 12 design approval gate. Variants are HTML mockups Muse generates. - **Construction path — Build Review Step 12.5:** after Party Review (Step 12) writes its review file and Muse appends the *As-Built Audit* section to `ux-review.md`, before the Step 13 Review approval
devops
Bypass the deploy-before-Operation guardrails block with a single confirmation
testing
Record an architectural or product decision in the PDLC Decision Registry