egdev6egdev6/discord-project-manager/skills/release-roadmap-hygiene/SKILL.md

release-roadmap-hygiene

Skill4 starsChanged 5 months agoMITView on GitHub

Trigger: release hygiene, post-release issues, Kanban status, project column, merged to main. Keep GitHub issues and Project status aligned after merges and releases.

In this repository10 other files it gives its agents.
- brand-contextSkill
- content-ledgerSkill
- discord-approval-gateSkill
- discord-general-advisorSkill
- linkedin-weekly-plannerSkill
- on-demand-brief-plannerSkill
- openclaw-runtime-orchestratorSkill
- scoped-skill-resolverSkill
- strategy-plannerSkill
- x-queue-plannerSkill

The file

We split this skill into the rules it gives an agent

6 rules. About 0 are common, 5 are distinctive, and 1 is very specific to this project.

≈0
Common · estimate
Many files like this have a rule of this kind.
≈5
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.

Common
Distinctive
Very specific

Distinctive:
Use this skill when closing shipped issues, moving GitHub Project/Kanban items, finishing a PR merge, promoting a release branch to main, …
line 12
Distinctive:
Do not use it for issue creation, PR authoring, or implementation planning unless project status must also be changed.
line 14
Distinctive:
Never claim live/private Discord, Engram, production, or public readiness unless the issue evidence explicitly proves it.
line 23
Very specific:
Update Project status using exact columns: Merged to develop, Merged to main, or Done only when justified.
line 39
Distinctive:
Add a concise comment when closing or deferring an issue, naming any no-overclaim boundary.
line 40
Distinctive:
Verify the final issue list and Project status after edits.
line 42

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.

Files

SKILL.md

Activation Contract

Use this skill when closing shipped issues, moving GitHub Project/Kanban items, finishing a PR merge, promoting a release branch to main, or cleaning up a milestone after release.

Do not use it for issue creation, PR authoring, or implementation planning unless project status must also be changed.

Hard Rules

Preserve release truth: project status must reflect where the work actually landed.
PR merged to develop means Merged to develop, not Done.
Release promoted to main means the release issue and every included shipped issue move to Merged to main.
Done is only for non-merge administrative closure or work that intentionally has no branch/main promotion semantics.
Deferred issues remain open, keep their blocker/status labels, and move to the next milestone instead of being marked merged.
Never claim live/private Discord, Engram, production, or public readiness unless the issue evidence explicitly proves it.

Decision Gates

Situation	Action
PR merged into `develop`	Close linked issue if appropriate and set Project status to `Merged to develop`.
Release PR/promote to `main` completed	Set the release issue and included shipped issues to `Merged to main`.
Issue shipped only partially	Close only the shipped scope with an explicit no-overclaim comment, or keep open if acceptance remains central.
Issue deferred to next release	Move milestone, keep open/blocked, and comment the deferred gate.
Milestone still has open issues	Move/close each issue explicitly before closing the milestone.

Execution Steps

List milestone issues and Project statuses before making changes.
Identify shipped, deferred, and administrative issues separately.
Update Project status using exact columns: Merged to develop, Merged to main, or Done only when justified.
Add a concise comment when closing or deferring an issue, naming any no-overclaim boundary.
Close the milestone only after open issues are zero or explicitly moved out.
Verify the final issue list and Project status after edits.

Output Contract

Return:

Issues moved by number and final Project status.
Issues closed, deferred, or left open.
Milestone state after cleanup.
Any no-overclaim caveats or remaining release risks.

References

.atl/skill-registry.md — generated skill index used by delegators.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

It worked
Partly
It didn't

What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free