Audits local HyperFleet repositories against team architecture standards dynamically fetched from the architecture repo. Activates when users ask to audit repos, check standards compliance, or identify standards gaps. READ-ONLY - does not modify any files. Produces JIRA-ready gap specifications for integration with jira-ticket-creator skill.
Audits local repositories against HyperFleet architecture standards dynamically fetched from the architecture repository. Activates when users ask to audit repos, check standards compliance, or identify gaps.
/plugin marketplace add openshift-hyperfleet/hyperfleet-claude-plugins/plugin install openshift-hyperfleet-hyperfleet-standards-hyperfleet-standards@openshift-hyperfleet/hyperfleet-claude-pluginsThis skill inherits all available tools. When active, it can use any tool Claude has access to.
This skill MUST NOT modify any files in the repository being audited. All operations are read-only analysis. The skill produces reports and JIRA-ready gap specifications but never changes code, configuration, or documentation.
Activate this skill when the user:
Standards are dynamically fetched from the architecture repository - never hardcoded. This ensures the skill stays current as standards evolve.
GitHub Raw Content (Primary) - Always get latest version
https://raw.githubusercontent.com/openshift-hyperfleet/architecture/main/hyperfleet/standards/
Local Architecture Repo (Fallback) - Use when offline or GitHub unavailable
/home/croche/Projects/hyperfleet/architecture/hyperfleet/standards/
GitHub (preferred):
# Use GitHub API to list files in the standards directory
gh api repos/openshift-hyperfleet/architecture/contents/hyperfleet/standards --jq '.[] | select(.name | endswith(".md")) | .name' 2>/dev/null
Local fallback:
ls /home/croche/Projects/hyperfleet/architecture/hyperfleet/standards/*.md 2>/dev/null | xargs -n1 basename
Check for standards-index.yaml which provides pre-defined metadata:
GitHub:
curl -s https://raw.githubusercontent.com/openshift-hyperfleet/architecture/main/hyperfleet/standards/standards-index.yaml 2>/dev/null
Local:
cat /home/croche/Projects/hyperfleet/architecture/hyperfleet/standards/standards-index.yaml 2>/dev/null
If the index exists, it contains:
standards:
- file: commit-standard.md
name: Commit Message Standard
severity: minor
applies_to: [all]
- file: linting.md
name: Linting Standard
severity: major
applies_to: [go-repos]
companion_files: [golangci.yml]
For each .md file discovered:
GitHub:
curl -s https://raw.githubusercontent.com/openshift-hyperfleet/architecture/main/hyperfleet/standards/FILENAME.md
Local:
cat /home/croche/Projects/hyperfleet/architecture/hyperfleet/standards/FILENAME.md
When standards-index.yaml is not available, parse metadata from each document:
Look for explicit metadata sections:
## Applicability
- API, Sentinel, Adapters
## Severity
Critical - affects reliability
Infer from content keywords:
| Keyword Pattern | Inferred Applicability |
|---|---|
SIGTERM, SIGINT, graceful shutdown | Services (API, Sentinel, Adapters) |
Makefile, make target | All repositories |
golangci, .golangci.yml | Go repositories |
RFC 9457, problem+json, error response | API services |
/healthz, /readyz, /metrics | Services |
Prometheus, hyperfleet_ metrics | Services |
LOG_LEVEL, structured logging | Services |
.gitignore, generated code | Repos with code generation |
commit message, git log | All repositories |
Infer severity from impact language:
| Severity | Indicators |
|---|---|
| Critical | "MUST", "required for production", "affects reliability", "Kubernetes integration" |
| Major | "SHOULD", "affects code quality", "affects observability" |
| Minor | "RECOMMENDED", "style", "conventions" |
For each standard document, extract checkable requirements:
File Existence Checks - Look for mentioned files:
.golangci.ymlMakefile.gitignoreFile Content Checks - Parse expected configurations:
help, build, test, lint, clean.golangci.ymlCode Pattern Checks - Grep patterns for code inspection:
syscall.SIGTERM/healthz, /readyzhyperfleet_trace_id, componentCommit Message Checks - Git log validation:
HYPERFLEET-XXX - type: subject or type: subjectBefore running applicable checks, detect the repository type.
# Check for API indicators
ls pkg/api/ 2>/dev/null && echo "HAS_API_PKG"
ls openapi.yaml 2>/dev/null || ls openapi/openapi.yaml 2>/dev/null && echo "HAS_OPENAPI"
grep -l "database" cmd/*.go 2>/dev/null && echo "HAS_DATABASE"
# Check for Sentinel indicators
basename $(pwd) | grep -i sentinel && echo "IS_SENTINEL"
grep -r "polling\|reconcile" --include="*.go" -l 2>/dev/null | head -1 && echo "HAS_RECONCILE"
# Check for Adapter indicators
basename $(pwd) | grep "^adapter-" && echo "IS_ADAPTER"
grep -r "cloudevents\|pubsub" --include="*.go" -l 2>/dev/null | head -1 && echo "HAS_CLOUDEVENTS"
# Check for Infrastructure
ls charts/Chart.yaml 2>/dev/null || ls Chart.yaml 2>/dev/null && echo "HAS_HELM"
ls *.tf 2>/dev/null && echo "HAS_TERRAFORM"
# Check for Go code
ls cmd/*.go 2>/dev/null || ls pkg/**/*.go 2>/dev/null && echo "IS_GO_REPO"
| Indicators | Repository Type |
|---|---|
| HAS_API_PKG + HAS_OPENAPI + HAS_DATABASE | API Service |
| IS_SENTINEL or HAS_RECONCILE | Sentinel |
| IS_ADAPTER or HAS_CLOUDEVENTS (without API) | Adapter |
| HAS_HELM or HAS_TERRAFORM (without Go) | Infrastructure |
| IS_GO_REPO (without service patterns) | Tooling |
| Standard Category | API | Sentinel | Adapter | Infrastructure | Tooling |
|---|---|---|---|---|---|
| Commit Messages | Yes | Yes | Yes | Yes | Yes |
| Linting | Yes | Yes | Yes | No | Yes |
| Makefile Conventions | Yes | Yes | Yes | Yes | Yes |
| Error Model | Yes | Partial | Partial | No | No |
| Graceful Shutdown | Yes | Yes | Yes | No | No |
| Health Endpoints | Yes | Yes | Yes | No | No |
| Logging Specification | Yes | Yes | Yes | No | Optional |
| Metrics | Yes | Yes | Yes | No | No |
| Generated Code Policy | If applicable | If applicable | If applicable | No | No |
File Existence:
test -f FILENAME && echo "PASS" || echo "FAIL"
Makefile Target Existence:
grep -E '^TARGET_NAME:' Makefile 2>/dev/null && echo "PASS" || echo "FAIL"
Configuration Content:
grep -q "EXPECTED_CONTENT" FILENAME && echo "PASS" || echo "FAIL"
Code Pattern:
grep -r "PATTERN" --include="*.go" -l 2>/dev/null | head -1 && echo "PASS" || echo "FAIL"
Git Commit Messages (last 20):
git log --oneline -20 --format="%s"
Validate each against regex:
^(HYPERFLEET-\d+ - )?(feat|fix|docs|style|refactor|perf|test|build|ci|chore|revert): .+$
# HyperFleet Standards Audit Report
**Repository:** [repo name]
**Path:** [full path]
**Repository Type:** [API/Sentinel/Adapter/Infrastructure/Tooling]
**Audit Date:** [ISO timestamp]
**Standards Source:** [GitHub/Local]
---
## Summary
| Standard | Status | Severity | Gaps |
|----------|--------|----------|------|
| [Standard Name] | PASS/PARTIAL/FAIL | Critical/Major/Minor | 0/N |
**Overall Compliance:** X/Y standards passing (Z%)
---
## Detailed Findings
### [Standard Name]
**Status:** PASS/PARTIAL/FAIL
**Severity:** Critical/Major/Minor
**Applicable:** Yes/No (reason if No)
#### Checks Performed
- [x] Check 1 description
- [ ] Check 2 description (FAILED)
- [x] Check 3 description
#### Gaps Found
##### GAP-XXX-001: [Brief Description]
- **Location:** [file path:line number or N/A]
- **Expected:** [what the standard requires]
- **Found:** [what was actually found]
- **Severity:** Critical/Major/Minor
---
## JIRA-Ready Gap Specifications
[For each gap, provide a complete ticket specification]
For integration with the jira-ticket-creator skill, format each gap as:
### GAP-[STANDARD]-[NUMBER]: [Brief Title]
**Suggested Ticket:**
- **Title:** [Concise title < 100 chars]
- **Type:** Task
- **Priority:** [Major/Normal/Minor based on severity]
- **Story Points:** [1/3/5 based on complexity]
- **Activity Type:** Quality / Stability / Reliability
**Description (JIRA Wiki Markup):**
h3. What
[Clear description of what needs to be done - 2-4 sentences]
h3. Why
* Required by HyperFleet [Standard Name] standard
* [Additional business justification]
* Reference: architecture/hyperfleet/standards/[filename].md
h3. Acceptance Criteria:
* [Specific, testable criterion 1]
* [Specific, testable criterion 2]
* [Specific, testable criterion 3]
h3. Technical Notes:
* [Implementation guidance]
* [Related files or patterns]
| Complexity | Points | Examples |
|---|---|---|
| Config change | 1 | Add .golangci.yml, update .gitignore, add Makefile target |
| Code changes | 3 | Add health endpoint, implement signal handler |
| Refactoring | 5 | Restructure logging, implement error model |
| Severity | Priority |
|---|---|
| Critical | Major |
| Major | Normal |
| Minor | Minor |
After generating the audit report, users can create JIRA tickets for gaps:
Workflow:
Bulk Ticket Creation: User can also request: "create tickets for all critical gaps"
The gap specifications are pre-formatted in JIRA wiki markup (not Markdown) to work directly with jira-ticket-creator.
User: "audit this repo against standards"
Skill Response:
# HyperFleet Standards Audit Report
**Repository:** hyperfleet-api
**Path:** /home/croche/Projects/hyperfleet/hyperfleet-api
**Repository Type:** API Service
**Audit Date:** 2026-01-05T12:30:00Z
**Standards Source:** GitHub (latest)
---
## Summary
| Standard | Status | Severity | Gaps |
|----------|--------|----------|------|
| Commit Message Standard | PARTIAL | Minor | 3 |
| Linting Standard | PARTIAL | Major | 1 |
| Makefile Conventions | PASS | Major | 0 |
| Error Model | PASS | Critical | 0 |
| Graceful Shutdown | PASS | Critical | 0 |
| Health Endpoints | PASS | Critical | 0 |
| Logging Specification | PARTIAL | Major | 1 |
| Metrics Standard | PASS | Major | 0 |
| Generated Code Policy | PASS | Major | 0 |
**Overall Compliance:** 6/9 standards fully passing (67%)
---
## Detailed Findings
### Linting Standard
**Status:** PARTIAL
**Severity:** Major
**Applicable:** Yes
#### Checks Performed
- [x] .golangci.yml exists
- [ ] All required linters enabled (MISSING: goimports, gocritic, exhaustive)
- [x] Generated code excluded
- [x] make lint target present
#### Gaps Found
##### GAP-LNT-001: Missing required linters in .golangci.yml
- **Location:** .golangci.yml
- **Expected:** 16 linters enabled per standard
- **Found:** 9 linters enabled
- **Missing:** goimports, gocritic, exhaustive, gofmt, lll, revive, goconst
- **Severity:** Major
---
## JIRA-Ready Gap Specifications
### GAP-LNT-001: Add missing linters to .golangci.yml
**Suggested Ticket:**
- **Title:** Add missing linters to hyperfleet-api golangci config
- **Type:** Task
- **Priority:** Normal
- **Story Points:** 1
- **Activity Type:** Quality / Stability / Reliability
**Description (JIRA Wiki Markup):**
h3. What
Update {{.golangci.yml}} to enable all 16 required linters per HyperFleet linting standard. Currently missing 7 linters: goimports, gocritic, exhaustive, gofmt, lll, revive, goconst.
h3. Why
* Required by HyperFleet Linting Standard
* Ensures consistent code quality across all HyperFleet repositories
* Reference: architecture/hyperfleet/standards/linting.md
h3. Acceptance Criteria:
* All 16 linters enabled in {{.golangci.yml}}
* {{make lint}} passes with no new violations (or violations tracked separately)
* Configuration matches reference at {{architecture/hyperfleet/standards/golangci.yml}}
h3. Technical Notes:
* Copy settings from reference config in architecture repo
* May need to add {{exclude-rules}} for existing violations to fix incrementally
* Consider creating separate ticket for fixing existing lint violations
---
## Recommendations
**Quick Wins (1 point each):**
1. GAP-LNT-001: Add missing linters - copy from reference config
**Priority Items:**
1. Fix linting configuration before merging new PRs
Would you like me to create JIRA tickets for any of these gaps?
If the skill cannot complete an audit:
Always provide partial results where possible and suggest manual verification steps for incomplete checks.
This skill should be used when the user asks to "create a hookify rule", "write a hook rule", "configure hookify", "add a hookify rule", or needs guidance on hookify rule syntax and patterns.
Create distinctive, production-grade frontend interfaces with high design quality. Use this skill when the user asks to build web components, pages, or applications. Generates creative, polished code that avoids generic AI aesthetics.