npx claudepluginhub peteski22/agent-pragma --plugin pragmaThis skill is limited to using the following tools:
Run all applicable validators against recent changes and report findings.
Validates git changes against .hoyeon/rules/ checklists, reports PASS/WARN for missed cascading changes, and proposes new rules for unmatched patterns before push.
Reviews code against project rules and reference files, flagging violations in correctness, security, reliability, architecture, dead code, complexity, and conventions.
Share bugs, ideas, or general feedback.
Run all applicable validators against recent changes and report findings.
Step 2 (rule injection) runs before validation. If no project rules are found, validation continues with validator built-in rulesets. Run /setup-project to configure project-specific rules.
Get changed files. Combine committed, staged, and unstaged changes to capture all recent work:
{ git diff HEAD~1 --name-only --diff-filter=ACMRT 2>/dev/null; git diff --cached --name-only --diff-filter=ACMRT 2>/dev/null; git diff --name-only --diff-filter=ACMRT 2>/dev/null; } | sort -u
The --diff-filter=ACMRT includes Added, Copied, Modified, Renamed, Type-changed (excludes Deleted).
Collect the list of changed files and their directories.
Collect project rules from the project's rule directory. Rule file locations vary by agent platform:
.claude/rules/*.mdopencode.json instructions arrayFor Claude Code, use the Glob tool to discover .claude/rules/*.md files, then the Read tool to load them. OpenCode auto-loads rules from opencode.json at the platform level.
Path-scoped filtering: Always include universal and local-supplements rule files. For files with paths: frontmatter, include only if at least one declared path pattern matches a changed file from Step 1. Files without paths: frontmatter are treated as global and always included. This prevents unrelated language rules from being applied (e.g., Go rules on a Python-only change).
De-duplicate (a rule file only needs to be read once even if multiple files share it).
If no rule files are found: Log "No project rules found — using validator built-in rulesets." and skip to Step 3. Validators have built-in rules and do not require project-specific rule files to function.
Precedence: Most specific (path-scoped) rules override more general (universal) rules. Local supplements have highest priority.
If two rules conflict and precedence is unclear, prefer the more specific rule and note the conflict in the report.
Record which rule files were loaded.
Check for a local supplements file (e.g., CLAUDE.local.md for Claude Code) at the project root and read it if present. This is a per-user, unversioned file for machine-specific overrides (e.g., custom validation commands).
If it exists, read it. Pay particular attention to any "Validation Commands" section, which overrides defaults.
Check rules for custom validation commands first: Look for a "Validation Commands" section in loaded project rules, in precedence order:
Use the highest-precedence match.
If no custom commands found, use these defaults based on file types:
Go:
golangci-lint run -v 2>&1 | tail -50
Python:
uv run pre-commit run --all-files 2>&1 | tail -50
TypeScript:
pnpm run lint 2>&1 | tail -50
# or: npx biome check . 2>&1 | tail -50
Report linter results. If linters fail, report and stop - fix these first.
Use the Task tool to spawn validators in parallel based on what changed:
Always run:
securitystate-machineerror-handlingIf Go files changed (.go):
go-effectivego-proverbsIf Python files changed (.py):
python-styleIf TypeScript files changed (.ts, .tsx):
typescript-styleCollect all results.
## Review Results
### Rules Applied
- python rules (scoped to backend/**)
- universal rules
### Files Changed
- cmd/main.go
- internal/service/handler.go
- internal/service/handler_test.go
### Linting
✓ golangci-lint passed
### Security Validation
✓ passed (no HARD, no unexplained SHOULD)
### State Machine Validation
✓ passed (no HARD, no SHOULD)
### Go Effective Validation
✗ FAILED (1 HARD, 1 SHOULD unexplained)
**HARD violations (must fix):**
1. handler.go:45 - Exported function `ProcessRequest` missing doc comment
**SHOULD violations (fix or justify):**
1. handler.go:78 - Function has 6 parameters (>5 requires justification)
**Warnings:**
1. handler.go:120 - Complex function, consider breaking up
### Summary
- Rules applied: 2
- Hard violations: 1
- Should violations: 1 (0 justified)
- Warnings: 1
### Recommended Actions
1. Add doc comment to ProcessRequest
2. Consider using options pattern for ProcessRequest parameters