Menu
Evaluate GitHub changes for community interest and produce a ranked list
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Design or edit a Mediforce WorkflowDefinition package through a structured interview. Use when authoring a new workflow from an idea, editing an existing workflow folder, or reviewing whether a workflow follows the golden standards. Interviews the user, challenges the design toward the standards, generates the package, and validates the .wd.json against the current checkout. Triggers include "design a workflow", "author a workflow", "create a .wd.json", "build a workflow package", "edit this workflow", "new Mediforce workflow".
Review pull requests, branches, or your own pre-PR diff along three parallel axes — Standards (file-by-file conventions, dead code, DRY/KISS, comments), Spec (does it match the originating issue/PRD), and Big Picture (scope creep, removable features, duplicated mechanisms). Use when asked to review a PR, diff, branch, specific files, or your own changes before shipping.
Write a Discord update for the MediForce community from rough notes. Use when the user asks for a "Discord update", "Discord post", "community update", "weekly digest for Discord", or hands over bullet-point notes to turn into a community announcement. Produces two versions (short and detailed) in engineer-to-peers tone, no marketing language.
Write and run L4 UI E2E journey tests. Use when implementing UI features (TDD red-green), adding tests for existing features, or when E2E tests need updating. Handles the workflow: write test → run → green.
Write a new test for a feature, endpoint, handler, or pure function. Use when adding test coverage for new or changed code, or when starting a feature TDD-style (RED → GREEN). Triggers include "write a test for", "add unit test", "add integration test", "add API E2E", "TDD this", "red-green this", "cover X with a test", "test plan for". Decides the right level (L1 unit / L2 integration / L3 API E2E / L4 UI E2E / L5 external), scaffolds the file, and walks the RED-GREEN loop. Use `/e2e-test` instead for the L4 UI journey workflow.
Keep project documentation in sync with code changes. Detects stale docs in current worktree diff (default), a specific commit, a PR, or across all monitored files (--audit). Auto-fixes Tier 1 executable docs (commands, ports, env vars); proposes Tier 2 narrative doc updates as an editable git diff. Triggers: "sync docs", "update docs", "check docs", "are docs up to date", "docs stale", "documentation outdated".
Based on SOC occupation classification
| name | rank-changes |
| description | Evaluate GitHub changes for community interest and produce a ranked list |
You are given a list of recent GitHub changes (commits, merged PRs, new/closed issues) from a repository.
Evaluate each change for community interest — how relevant and interesting is this change to developers and domain experts following the project?
Write a JSON file to /output/result.json with this structure:
{
"output_file": "/output/result.json",
"summary": "Ranked N changes from REPO"
}
The result.json should contain:
{
"rankedChanges": [
{
"rank": 1,
"score": 9,
"category": "feature",
"title": "Short title of the change",
"description": "One-line rationale for the ranking",
"source": "pr",
"sourceId": "123",
"url": "https://github.com/..."
}
],
"metadata": {
"totalChanges": 42,
"rankedCount": 10,
"topCategory": "feature"
}
}
feature — new functionalitybugfix — bug fixinfra — CI/CD, tooling, dependenciesdocs — documentation changesrefactor — code restructuring without behavior changebreaking — breaking changes