From paad
Creates or updates project Makefiles ensuring standard targets (help, all, test, cover, lint, format) exist. Detects stack from CLAUDE.md, README, package.json, pyproject.toml; asks before modifying existing targets.
npx claudepluginhub ovid/paad --plugin paadThis skill uses the workspace's default tool permissions.
Creates or updates a project Makefile with standard targets. **Never modifies an existing target without explicit user approval.**
Checks and configures project Makefile with standard targets (help, test, build, clean, lint) for Python, Node, Rust, Go, or generic projects. Detects project type and services; supports --check-only and --fix.
Generates Makefiles for Python, Rust, and TypeScript projects with standard targets for help, install, lint, format, typecheck, test, build, clean, and automation. Use when projects lack Makefiles or need dev workflow setup.
Generates Makefiles for C/C++, Python, Go, Java projects with .PHONY targets, GNU standards, standard targets, security hardening, and CI/CD integration.
Share bugs, ideas, or general feedback.
Creates or updates a project Makefile with standard targets. Never modifies an existing target without explicit user approval.
digraph makefile_flow {
"Detect stack" -> "Makefile exists?";
"Makefile exists?" -> "Create from scratch" [label="no"];
"Makefile exists?" -> "Identify missing targets" [label="yes"];
"Create from scratch" -> "Include all required targets";
"Include all required targets" -> "Done";
"Identify missing targets" -> "Add new targets";
"Add new targets" -> "Existing target needs change?";
"Existing target needs change?" -> "Done" [label="no"];
"Existing target needs change?" -> "STOP: ask user for approval" [label="yes"];
"STOP: ask user for approval" -> "Approved?" [shape=diamond];
"Approved?" -> "Apply change" [label="yes"];
"Approved?" -> "Skip change" [label="no"];
"Apply change" -> "Done";
"Skip change" -> "Done";
}
Read project files in this order to understand the technology and available commands:
CLAUDE.md or AGENTS.md — often lists exact commands for test, lint, format, buildREADME.md — frequently documents dev workflowpackage.json, pyproject.toml, Cargo.toml, go.mod, Gemfile, etc.) — reveals available scripts/tasksUse the commands the project already documents. Do not invent commands that aren't confirmed to exist.
Every Makefile must include at minimum:
| Target | Purpose |
|---|---|
help | List all targets with descriptions |
all | Full CI pass (lint + format + test at minimum) |
test | Run test suite |
cover | One-shot coverage report |
lint | Lint (with autofix if available) |
format | Format code |
Add extra targets (e.g. build, dev, preview) only if the project supports them.
Every target gets a ## description. help extracts them with grep + awk:
.PHONY: all test cover lint format help
all: lint format test ## Lint, format, and test
test: ## Run full test suite
<stack-specific command>
cover: ## Generate code coverage report (one-shot)
<stack-specific command, forced one-shot — see below>
lint: ## Lint with autofix
<stack-specific command>
format: ## Format code
<stack-specific command>
help: ## Show this help
@grep -E '^[a-zA-Z_-]+:.*?## .*$$' $(MAKEFILE_LIST) | awk 'BEGIN {FS = ":.*?## "}; {printf " %-10s %s\n", $$1, $$2}'
All targets must appear in .PHONY.
If an existing target's implementation would change, stop and tell the user:
"The existing
covertarget runsX. I'd change it toYbecause [reason]. Should I make this change?"
Wait for explicit approval. Adding a brand-new target never requires approval.
Coverage tools often default to watch mode. Force one-shot execution:
-- --run-- --watchAll=falsemake test output should be actionable, not overwhelming. Avoid both extremes:
Goal: On success, show a concise summary (total passed/failed/skipped). On failure, show the failing test name, assertion, and enough context to act on it.
Common approaches by stack:
| Stack | Flag / Approach |
|---|---|
| vitest | --reporter=default is usually fine; avoid --reporter=verbose |
| jest | Default is good; avoid --verbose |
| pytest | -q or --tb=short — default is often too verbose |
| cargo test | Default is fine; --quiet if too noisy |
| go test | Default is fine; avoid -v unless debugging |
| prove (Perl) | Default is fine; avoid --verbose |
If the testing tool doesn't support balanced output (e.g., only offers silent vs. firehose), inform the user and ask how they'd like to handle it rather than guessing.