coding-standards-aa88f6 — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited coding-standards-aa88f6 (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
When any pattern below is detected, pause implementation and record: the triggered pattern, affected current requirement, smallest compliant alternative, and verification needed to resume. Resume when the alternative removes the pattern or a documented requirement justifies retaining it.
Inspect until the evidence identifies the lowest-total-complexity solution that delivers the required user, operator, or maintainer value while keeping the system correct and maintainable.
Judge total complexity across every activated surface: user decisions, settings, modes, concepts, outputs, persistent state, and implementation paths, together with their UX, runtime, implementation, testing, documentation, and maintenance cost. Compare only dimensions that differ between viable approaches. Prefer reuse or no new mechanism when it delivers the same confirmed value and proof at lower total complexity.
Fail quickly on errors to prevent processing continuation in invalid states. Propagate the failure or return an explicit typed error with the original diagnostic context.
For detailed implementation methods (Result type, custom error classes, layered error handling, etc.), refer to language and framework-specific rules.
How to handle duplicate code based on Martin Fowler's "Refactoring":
| Duplication Count | Action | Reason |
|---|---|---|
| 1st time | Inline implementation | Cannot predict future changes |
| 2nd time | Consider future consolidation | Pattern beginning to emerge |
| 3rd time | Implement commonalization | Pattern established |
Cases for Commonalization
Cases to Keep Separate
Prompt paths are investigation starting points. Include another repository file when evidence shows that it implements the accepted outcome, is a required dependency or wiring path, or must change to preserve a contract affected by the work. Callers, consumers, tests, configuration, imports, and data flow are useful evidence rather than a required checklist.
When adopting a pattern, API, or dependency, inspect the relevant feature and repository uses that share its responsibility and current contract. Prefer the compatible implementation in that responsibility. Frequency helps locate candidates but does not make a pattern authoritative; when approaches coexist, use their callers, lifecycle, and compatibility to distinguish the current pattern from a legacy or unrelated one.
Resolve external dependency versions from manifests, lockfiles, and compatible consumers. Escalate only when those sources cannot resolve a choice that changes compatibility or architecture.
Symptom: Fixing one error causes new errors Cause: Surface-level fixes without understanding root cause Avoidance: Identify root cause with 5 Whys before fixing
Symptom: any or as declares a type that no check or contract establishes Cause: Impulse to avoid type errors Avoidance: Apply the evidence criteria in Type Safety Fundamentals.
Symptom: Many bugs after implementation Cause: Accepted behavior left without a test that proves it Avoidance: Prove each delivered behavior at the boundary where it is observed
Symptom: Dependent work fails, or workarounds accumulate, once an assumed premise proves false Cause: Treating an assumed capability, behavior, or existing implementation as fact Avoidance: When an unverified premise could invalidate the chosen approach, check it by the cheapest sufficient means before building dependent work on it. When results contradict the premise, reconsider the approach before patching its parts. Keep this reasoning in the active task; it needs no separate artifact.
Symptom: Duplicate implementations, architecture inconsistency, integration failures, adopting outdated patterns Cause: Insufficient understanding of existing code before implementation; referencing only nearby files without verifying representativeness Avoidance Methods:
Trace each answer to observed evidence until reaching a cause whose correction prevents the original failure. Record each question, evidence, and the final causal link; stop when the next answer would be speculation and name the evidence needed.
Type Safety Principle: Base type narrowing on runtime checks or an established contract. A type guard must guarantee only what its checks establish.
unknown for input whose structure is not established, and validate the properties needed by the consumer.Type Complexity Management
Basic Policy
Implementation Procedure: Understand Current State -> Gradual Changes -> Behavior Verification -> Final Validation
Priority: Duplicate Code Removal > Large Function Division > Complex Conditional Branch Simplification > Type Safety Improvement
Before implementation, trace callers, dependencies, and data flow (generation -> modification -> reference) of the changed code until another file cannot change the change boundary defined in Change Boundary and Reference Representativeness. Carry the direct and indirect impact that the implementation or its verification relies on into that work.
When unused code is detected, determine from current requirements and reachable call paths whether it is used before task completion.
Target: Code, documentation, configuration files
Recommended: Mock external dependencies in unit tests
Unit-test boundary: Use deterministic substitutes for external connections; exercise real external boundaries in integration or E2E tests selected for that contract
Fix tests: Wrong expected values, references to non-existent features, dependence on implementation details, implementation only for tests Fix implementation: Valid specifications, business logic, important edge cases Both readings remain compatible with the available requirements: Return the unresolved behavior decision — state the two candidate behaviors, the source that would settle which is correct, and the condition for stopping rather than picking one
Test through observable boundaries: Public APIs, return values, exceptions, external calls, and persisted state. Reach private methods, internal state, and algorithm details only through those observable boundaries.
references/security-checks.md~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.