Skip to content

hraness/hraness-engineering

v0.2.1MIT

Source-auditable workflows that turn repository questions into bounded maps, explanations, proof, tests, measurements, docs, or safe refactors.

assess-change-impact

Assess the direct and indirect blast radius of a proposed or existing code change, including callers, contracts, state, operations, and validation needs. Use when preparing to ship or when a small diff may have hidden effects; do not use to generate competing designs, explain an unchanged subsystem, or implement the change.

compare-approaches

Compare viable technical approaches against explicit constraints and evidence, producing a decision-ready recommendation. Use when a real architecture or implementation choice remains open; do not use when the answer is observable from the existing system, when one approach is already required, or to implement the winner.

create-app-verifier

Create and prove a new project-local application-verifier Agent Skill that launches, health-checks, drives, observes, and safely cleans up the real application with a user-facing feature map. Use when a repository lacks an application verifier; do not use to maintain an existing verifier, write ordinary tests, or repair product behavior.

docs-maintainer

Create or update repository documentation so commands, behavior, examples, navigation, and operational guidance match authoritative current sources. Use for README, guide, reference, runbook, or release-documentation maintenance; do not use for general copywriting, historical rationale, or product-code changes.

maintain-app-verifier

Audit and correct drift in an existing project-local application verifier, its driver, and references/features map using source and live evidence. Use when a verify-app skill already exists; do not use to create one, change product code, or treat a product regression as documentation drift.

performance-investigator

Diagnose and improve a measured performance problem using controlled baselines, profiling, hypotheses, and before/after evidence. Use for latency, throughput, CPU, memory, startup, rendering, or scaling regressions; do not use for unmeasured optimization, general refactoring, or infrastructure capacity planning.

reconstruct-rationale

Reconstruct why code, an API, or an architecture reached its current shape from version history and other authorized records, with calibrated confidence. Use for design-history and intent questions; do not use for a current-behavior walkthrough, speculative justification, or a change recommendation.

refactor-maintainer

Perform behavior-preserving structural changes with an explicit invariant, caller migration, deletion of obsolete paths, and focused plus repository-required validation. Use for refactors and internal migrations; do not use for feature work, intentional behavior changes, speculative cleanup, or performance changes without measurement.

repository-feature-map

Build or refresh a navigable, evidence-backed map of a repository's domains, entry points, runtime flows, data ownership, and validation surfaces. Use when someone needs orientation or a maintained repository map; do not use to explain one subsystem in depth, infer historical rationale, or assess a proposed change.

semantic-code-analysis

Explain how a code path or subsystem behaves now by tracing entry points, data flow, state, boundaries, failures, and verification evidence. Use for current-behavior questions; do not use to reconstruct historical intent, estimate change blast radius, or implement a fix.

test-engineer

Design, implement, or repair focused automated tests that reproduce behavior and provide reliable regression evidence at the right layer. Use for test strategy and test-code work; do not use to create an application-driving skill, perform performance tuning, or change product behavior beyond an explicitly requested fix.