makefile-generator
Skill0 starsChanged 5 days agoMITView on GitHub
Use when creating or standardizing a Makefile for a Python, MCP, Node.js/Electron or Java/Gradle project.
- Deletes or force-pushes
1 other project uses a version of this.
Adopted by
Most recently taken up by
- ehtbanton/ClaudeSkillsRepotheir own version, first seen Dec 17, 2025
Other versions1 project uses a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 1
- ehtbanton/ClaudeSkillsRepo★ 0same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository14 other files it gives its agents.
- AGENTS.mdAGENTS.md
- codebase-designSkill
- desloppifySkill
- domain-modelingSkill
- grill-meSkill
- proseSkill
- pyproject-generatorSkill
- release-notesSkill
- repo-bootstrapSkill
- researchSkill
- retroSkill
- to-specSkill
- to-ticketsSkill
- writing-for-agentsSkill
The file
We split this skill into the rules it gives an agent
2 rules. About 0 are common, 1 is distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈1
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: line 35
Ask the user for:
- Very specific: line 47
Use the appropriate template from templates/ and customize:
≈ “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.
Files
Makefile Generator
Generates standardized Makefiles for the supported project types.
Usage
Invoke this skill when:
- Creating a new repository
- Initializing a new service/module
- Standardizing an existing Makefile
Project Types Supported
| Type | Package Manager | Use Case |
python-library | UV | PyPI packages, shared libraries |
python-service | UV | FastAPI services, workers |
mcp-server | UV + private index | Model Context Protocol servers |
python-service-db | UV + Alembic | Services with database migrations |
electron-frontend | npm | Electron UI applications |
electron-backend | UV + PyInstaller | Python backends for Electron apps |
java-gradle | Gradle | JVM projects, plugins |
Generation Process
Step 1: Gather Requirements
Ask the user for:
- Project type (from table above)
- Project slug (e.g.,
my-service, used in Docker image names) - Venv prompt name (short name for shell prompt, e.g.,
msfor management-service) - Service port (if applicable, for
runtarget) - Docker support (yes/no for services)
- Private package index (a private registry, when the project needs one)
- Documentation (mkdocs for libraries)
- PyPI publishing (for libraries)
Step 2: Generate from Template
Use the appropriate template from templates/ and customize:
- Replace
{{SERVICE_SLUG}}with project slug - Replace
{{VENV_PROMPT}}with venv prompt name - Replace
{{SERVICE_PORT}}with port number - Include/exclude optional sections based on requirements
Universal Patterns (All Templates)
Header Section
SHELL := /bin/bash
UV := uv
# Variables
PYTHON_VERSION ?= $(shell python3 --version 2>/dev/null | grep -o '3\.[0-9]*' || echo "3.12")
# Venv settings - CI-aware paths
ifeq ($(CI),true)
VENV := /app/.venv
else
VENV := .venv
endif
BIN := $(VENV)/binColor Definitions
# Colors for terminal output
RED = $(shell tput setaf 1 2>/dev/null || echo "")
GREEN = $(shell tput setaf 2 2>/dev/null || echo "")
YELLOW = $(shell tput setaf 3 2>/dev/null || echo "")
BLUE = $(shell tput setaf 4 2>/dev/null || echo "")
CYAN = $(shell tput setaf 6 2>/dev/null || echo "")
NC = $(shell tput sgr0 2>/dev/null || echo "")Help System
.DEFAULT_GOAL := help
help: ## Show this help message
@echo "$(BLUE){{PROJECT_NAME}} - Development Makefile$(NC)"
@echo ""
@echo "Usage: make [target]"
@echo ""
@echo "$(CYAN)Targets:$(NC)"
@awk 'BEGIN {FS = ":.*?## "} /^[a-zA-Z_-]+:.*?## / {printf " %-20s %s\n", $$1, $$2}' $(MAKEFILE_LIST)Tool Variables
BIN := $(VENV)/bin
RUFF := $(BIN)/ruff
PYTEST := $(BIN)/pytestCore Targets (Python)
check-lockfile: ## Verify uv.lock exists
@if [ ! -f "uv.lock" ]; then \
echo "$(YELLOW)No uv.lock found, generating...$(NC)"; \
$(UV) lock; \
fi
install: $(VENV)/pyvenv.cfg check-lockfile ## Install production dependencies
@echo "$(CYAN)Installing production dependencies...$(NC)"
@$(UV) sync --locked --no-dev || { echo "$(RED)Error: Failed to install.$(NC)"; exit 1; }
@echo "$(GREEN)Production dependencies installed.$(NC)"
dev-install: $(VENV)/pyvenv.cfg check-lockfile ## Install development dependencies
@echo "$(CYAN)Installing development dependencies...$(NC)"
@$(UV) sync --locked --all-extras || { echo "$(RED)Error: Failed to install dev deps.$(NC)"; exit 1; }
@echo "$(GREEN)Development dependencies installed.$(NC)"
test: check-lockfile dev-install ## Run linters and tests with coverage
@echo "$(YELLOW)Running Ruff format...$(NC)"
@$(RUFF) format . || { \
echo "$(RED)Formatting failed.$(NC)"; \
exit 1; \
}
@echo "$(YELLOW)Running Ruff linter...$(NC)"
@$(RUFF) check . --fix || { \
echo "$(RED)Linting failed.$(NC)"; \
exit 1; \
}
@echo "$(YELLOW)Running Python tests with coverage...$(NC)"
@$(PYTEST) --cov={{PACKAGE}} --cov-report=term-missing || { \
echo "$(RED)Tests failed.$(NC)"; \
exit 1; \
}
@echo "$(GREEN)All tests passed.$(NC)"
clean: ## Remove build artifacts and caches
@echo "$(YELLOW)Cleaning up...$(NC)"
@find . -type f -name '*.py[co]' -delete
@find . -type d -name '__pycache__' -exec rm -rf {} + 2>/dev/null || true
@rm -rf .pytest_cache .ruff_cache .coverage htmlcov build dist *.egg-info
@echo "$(GREEN)Clean complete.$(NC)"
dist-clean: clean ## Full clean including venv
@echo "$(RED)Performing full clean...$(NC)"
@rm -rf $(VENV) uv.lock
@echo "$(GREEN)Full clean complete.$(NC)"Optional Sections
Docker Support
Include for containerized services:
docker-build: ## Build Docker image
@echo "$(CYAN)Building Docker image $(IMAGE_NAME):$(IMAGE_TAG)...$(NC)"
@DOCKER_BUILDKIT=1 docker build -t $(IMAGE_NAME):$(IMAGE_TAG) .
@echo "$(GREEN)Docker image built$(NC)"Alembic Migrations
Include for database services:
revision: ## Generate new migration (message="description")
@if [ -z "$(message)" ]; then echo "Error: message= required"; exit 1; fi
@$(BIN)/alembic revision --autogenerate -m "$(message)"
upgrade: ## Apply migrations to head
@$(BIN)/alembic upgrade head
downgrade: ## Rollback one migration
@$(BIN)/alembic downgrade -1Private index auth
Include when a private package index is used:
check-index-auth: ## Verify INDEX_TOKEN is set
@if [ -z "$$INDEX_TOKEN" ]; then \
echo "$(RED)Error: INDEX_TOKEN not set$(NC)"; exit 1; \
fiPyPI Publishing
Include for libraries:
build: clean ## Build distribution packages
@$(BIN)/python -m build
publish: build ## Publish to PyPI
@$(BIN)/twine upload dist/*Validation Checklist
Before finalizing, verify:
SHELL := /bin/bashis set.DEFAULT_GOAL := helpis set- All phony targets listed in
.PHONY - Colors work on systems without tput
- CI-aware venv path
- Error handling with
|| { echo "..."; exit 1; } - Consistent emoji/spacing in output
##comments for help extractioncheck-lockfiletarget for uv.lock verificationtesttarget depends oncheck-lockfile dev-installtestruns format (in-place), lint (with --fix), then pytest- Tool variables (
RUFF,PYTEST) defined for cleaner targets
Files
- templates/python-library.mk - Python library template
- templates/python-service.mk - Python service template
- templates/mcp-server.mk - MCP server template
- templates/python-service-db.mk - Service with DB template
- templates/electron-frontend.mk - Electron frontend template
- templates/electron-backend.mk - Electron backend template
- templates/java-gradle.mk - Java/Gradle template
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
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.

