claude-code-workflows

What the source does

• FilesystemNone observedNo reads or writes in the source
• NetworkNone observedNo outbound calls in the source
• ShellNone observedNo commands run in the source
• DependenciesNot pinnedSome versions float
• SecretsNone foundNo keys in source

Five audit layers

Gates applied: no behavioural pass.

- Read client-side environment variables through the project's bundler accessor and public prefix.

- Read client-side environment variables through the project's bundler accessor and public prefix.

lefthook

- An attacker-controllable origin allowed to read an authenticated response, typically by reflecting the request origin without checking it against an allowlist while `Access-Control-Allow-Credentials

- An attacker-controllable origin allowed to read an authenticated response, typically by reflecting the request origin without checking it against an allowlist while `Access-Control-Allow-Credentials

- An attacker-controllable origin allowed to read an authenticated response, typically by reflecting the request origin without checking it against an allowlist while `Access-Control-Allow-Credentials

Audit 0.4.1 · source sha 6a8d7c5ad03b · 23 Oct 2026Report an issue or request a re-scan

• Publishershinpr GitHub userOwner of the repository this skill is read from
• Source foldershinpr/claude-code-workflowsThe exact folder we audited
• LicenceMITAs the repository states it
• Commit pinned for this verdict6a8d7c5ad03bA new audit runs when the source changes
• Repository statusNot archivedPushed today
• Sandboxed runNot runSkills are read, not executed; layer L4 is skipped

Its description: Applies language-agnostic and backend technical decision criteria, anti-pattern detection, debugging, and quality gates. Use when reviewing general/backend implementation choices, code smells, failures, or…

---
name: ai-development-guide
description: Applies language-agnostic and backend technical decision criteria, anti-pattern detection, debugging, and quality gates. Use when reviewing general/backend implementation choices, code smells, failures, or implementation completeness.
---

# AI Developer Guide - Technical Decision Criteria and Anti-pattern Collection

## Value-First Engineering

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.
- Resolve verified problems within confirmed scope or dependencies required for the outcome; report other findings with their owning boundary and evidence without expanding the active change.
- Introduce capabilities, infrastructure, abstractions, or speculative edge-case handling when a current outcome, verified constraint, or evidence-backed material risk requires them.
- Treat behavior-preserving maintenance inside the confirmed responsibility as current maintainer value when repository evidence shows it reduces change ambiguity, duplicate ownership, defect risk, or future implementation and verification cost without expanding observable product scope.

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.

## Technical Anti-patterns (Red Flag Patterns)

Pause the affected decision and review the design when detecting the following patterns:

### Code Quality Anti-patterns
1. **Duplicating one responsibility across independently maintained locations** - Review whether the duplicated logic has one change reason and should have one owner
2. **Multiple responsibilities mixed in a single file** - Violates Single Responsibility Principle (SRP)
3. **Defining same content in multiple files** - Violates DRY principle
4. **Making changes without checking dependencies** - Potential for unexpected impacts
5. **Disabling code with comments** - Should use version control
6. **Error suppression** - Hiding problems creates technical debt
7. **Bypassing safety mechanisms (type systems, validation, contracts)** - Circumventing language's correctness guarantees

### Design Anti-patterns
- **"Make it work for now" thinking** - Accumulation of technical debt
- **Patchwork implementation** - Unplanned additions to existing code
- **Symptomatic fixes** - Surface-level fixes that don't solve root causes
- **Unplanned large-scale changes** - Lack of incremental approach

## Fail-Fast Fallback Design Principles

### Core Principle
Make all errors visible and traceable with full context. Prioritize primary code reliability over fallback implementations. Excessive fallback mechanisms mask errors and make debugging difficult.

### Implementation Guidelines

#### Default Approach
- **Give every failure an explicit outcome**: propagate it, translate it to the boundary's error contract, or recover through an accepted fallback
- **Make failures explicit**: Errors should be visible and traceable
- **Preserve error context**: Include original error information when re-throwing

#### When Fallbacks Are Acceptable
- **Accepted recovery contract**: A requirement, Design Doc, existing boundary contract, or project policy defines why degraded behavior is preferable to failure
- **Business-critical continuity**: When partial functionality is better than none
- **Graceful degradation paths**: Clearly defined degraded service levels

#### Layer Responsibilities
- **Infrastructure Layer**:
  - Preserve the original cause and operational context
  - Propagate, translate, or return the failure in the form required by the caller's boundary contract
  - Perform infrastructure-owned cleanup or retry only when that boundary owns it; business recovery decisions remain in the application layer

- **Application Layer**:
  - Make business-driven error handling decisions
  - Implement fallbacks only when an accepted recovery contract defines the degraded outcome
  - Make fallback activation observable through the project's established logging, metrics, or user-visible state when diagnosis or recovery requires it

### Error Masking Detection

**Review Triggers** (require design review):
- Adding an error handler that duplicates or fragments an existing recovery responsibility
- The same failure is caught at multiple layers without a single recovery owner
- Nested handlers obscure which state is committed, rolled back, or exposed
- A handler converts a failure to success/default output without an observable degraded-state contract
- Recovery behavior that hides a failure from the boundary responsible for diagnosis or recovery

Another handler may remain when it covers a distinct failure mode with a documented recovery owner, state outcome, and observable signal.

**Before Implementing Any Fallback**:
1. Identify the accepted requirement, boundary contract, project policy, or Design Doc entry that defines this fallback
2. Document the business justification
3. Make activation observable at the boundary that owns diagnosis or recovery through one existing UI, log, or metric channel; when logging is that channel, log once with sensitive data redacted
4. Add new monitoring or alerting only when an operational requirement or project policy requires it

### Implementation Pattern

```
AVOID: Silent fallback that hides errors
    <handle error>:
        return DEFAULT_VALUE  // Error hidden, debugging impossible

PREFERRED: Explicit failure with context
    <handle error>:
        <attach operation context>
        IF this boundary owns diagnosis: <log once>
        <propagate error>  // Re-throw exception, return Er

Excerpt, first 6,000 characters of SKILL.md, verbatim from the audited commit. It is text from someone else’s repository, quoted so you can judge it before your agent reads it.

1. 2026-10-23
   ✕BLOCK D 69 / 100

   first audit · source 6a8d7c5ad03b

Questions about claude-code-workflows

• github.com/shinpr/claude-code-workflows — the audited source at commit 6a8d7c5ad03b and every finding aboveObserved · 23 Oct 2026

Spotted something wrong? Report a correction · Methodology