Purdue RCAC
Official@PurdueRCAC · United States of America
Research Computing at Purdue University
Agent Skills by Purdue RCAC
Showing 8 vetted skills indexed across 1 GitHub repositories.
PurdueRCACcm-publish
Publishes approved feature branches to main via squash PR or local merge with confirmation gates.
PurdueRCACcm-harness
Applies human-approved self-improvement findings to agent harness files as atomic commits.
PurdueRCACcm-build
Executes the next phase of a feature roadmap from TECH.md with verified commits.
PurdueRCACcm-plan
Generates a design document and phased YAML roadmap from a shaped feature spec.
PurdueRCACcm-feature
Shapes a feature or fix request into a refined GOAL.md specification on a new git branch.
PurdueRCACcm-review
Reviews feature branches adversarially using blind subagents and executed-command evidence.
PurdueRCACcm-release
Cuts signed, human-gated release and pre-release versions with a gated build and GitHub release.
PurdueRCACcm-roadmap
Retires shipped issue seeds and repairs ROADMAP.md references after cycles land on main.
Frequently Asked Questions About Purdue RCAC
FAQPage SchemaWhat tasks can I perform with Purdue RCAC's cluster-mcp skills?▼
You can run a full spec-driven software factory: shape features into GOAL.md specs (cm-feature), generate phased plans (cm-plan), execute phases with verification (cm-build), run adversarial QA review (cm-review), squash-merge to main (cm-publish), cut signed releases (cm-release), and maintain harness findings and roadmaps (cm-harness, cm-roadmap).
Who are these cluster-mcp skills designed for?▼
They target software engineers and research-computing developers maintaining the cluster-mcp repository who want a disciplined, human-gated lifecycle. Every irreversible or outward-facing step—pushing branches, applying harness fixes, cutting release tags—requires explicit human confirmation before proceeding.
How does the feature lifecycle run in practice?▼
Start with cm-feature to create a branch and GOAL.md, then cm-plan to produce PLAN.md and a YAML-FSM TECH.md, then cm-build to implement phases with per-phase verification, then cm-review for adversarial QA by a fresh reviewer subagent, and finally cm-publish to squash-merge via PR to main.
What are the prerequisites and dependencies?▼
The skills require a git repository with the .agents/factory methodology, uv for running and locking Python environments, the GitHub CLI (gh) for PRs and releases, and spec/ directories holding GOAL.md, PLAN.md, TECH.md, and META.md files. Releases additionally use pytest, uv build, and twine checks.
How are releases and versions handled?▼
cm-release bumps the single version source in pyproject.toml, runs uv lock, executes the pytest/build/twine gate, signs an annotated tag, and—only after explicit human approval—pushes and creates a GitHub release. It rehearses the entire process in an isolated git worktree first and supports pre-release alpha/beta/rc modes.