hraness/hraness-engineering
Source-auditable workflows that turn repository questions into bounded maps, explanations, proof, tests, measurements, docs, or safe refactors.
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 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 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.
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.
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.
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 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.
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.
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.
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.
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.