agentleFS
jasonmichaelbell78-creatorjasonmichaelbell78-creator/sonash-v0/.claude/skills/audit-engineering-productivity/SKILL.md

audit-engineering-productivity

Skill2 starsChanged 9 months agoApache-2.0View on GitHub

Run a single-session engineering productivity audit on the codebase

  • Reads credentials

We split this skill into the rules it gives an agent

11 rules. About 0 are common, 7 are distinctive, and 4 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈7

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 4

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Dependency constraints: All 3 agents are independent -- no ordering required.

    line 146
  2. Distinctive:

    Check for setup/doctor automation scripts

    line 158
  3. Distinctive:

    Search for correlation ID patterns

    line 166
  4. Distinctive:

    Check Sentry integration in logger

    line 168
  5. Distinctive:

    Check Firebase persistence configuration

    line 173
  6. Distinctive:

    Look for service worker implementation

    line 174
  7. Distinctive:

    Search for write queue patterns

    line 176
  8. Very specific:

    Check docs/audits/single-session/engineering-productivity/ for prior findings and track carryover issues.

    line 304
  9. Very specific:

    When you only need to audit code quality — use /audit-code instead

    line 335
  10. Very specific:

    When you need CI/CD pipeline health — use /audit-process instead

    line 336
  11. Very specific:

    When you need a comprehensive multi-domain audit — use /audit-comprehensive

    line 337

≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Single-Session Engineering Productivity Audit

Purpose

Evaluates developer experience (DX), debugging capabilities, and offline support infrastructure. Identifies friction points in development workflows and provides actionable recommendations for improvement.

Execution Mode Selection

ConditionModeTime
Task tool available + no context pressureParallel~15 min
Task tool unavailableSequential~45 min
Context running low (<20% remaining)Sequential~45 min
User requests sequentialSequential~45 min

Section A: Parallel Architecture (3 Agents)

When to use: Task tool available, sufficient context budget

Step 0: Load False Positives

# Read false positives to avoid re-flagging known issues
cat docs/technical-debt/FALSE_POSITIVES.jsonl 2>/dev/null

Agent 1: dx-golden-path-auditor

Focus Areas:

  • Developer onboarding friction
  • npm scripts completeness
  • Setup automation (doctor scripts, env validation)
  • Development workflow ergonomics

Files:

  • package.json (scripts section)
  • scripts/ directory
  • .env.example, .env.local
  • README.md, DEVELOPMENT.md

Checks:

# Count npm scripts
grep -c '"[^"]*":' package.json

# Check for setup/doctor scripts
ls scripts/*.js 2>/dev/null | grep -E 'setup|doctor|verify'

# Check for dev:offline script
grep -c "dev:offline" package.json

Agent 2: debugging-ergonomics-auditor

Focus Areas:

  • Structured logging vs console.log ratio
  • Correlation ID support for request tracing
  • Error message quality and user guidance
  • Sentry integration completeness

Files:

  • lib/logger.ts
  • *.ts *.tsx files (console.log patterns)
  • functions/src/**/*.ts (Cloud Functions logging)
  • app/**/error.tsx (error boundaries)

Checks:

# Console.log to logger ratio
echo "Console.log calls:"
grep -r "console.log" --include="*.ts" --include="*.tsx" app/ lib/ components/ | wc -l
echo "Logger calls:"
grep -r "logger\." --include="*.ts" --include="*.tsx" app/ lib/ components/ | wc -l

# Correlation ID patterns
grep -r "correlationId\|correlation-id\|x-request-id" --include="*.ts" .

Agent 3: offline-support-auditor

Focus Areas:

  • Firebase IndexedDB persistence configuration
  • Service worker presence and functionality
  • Offline write queue implementation
  • Network status indicators and user feedback

Files:

  • lib/firebase.ts
  • public/sw.js (if exists)
  • components/status/offline-indicator.tsx
  • lib/offline-queue.ts (if exists)

Checks:

# Firebase persistence
grep -r "enableIndexedDbPersistence\|enablePersistence" lib/ app/

# Service worker
ls -la public/sw.js 2>/dev/null || echo "No service worker"

# LocalStorage vs IndexedDB usage
grep -r "localStorage" --include="*.ts" --include="*.tsx" | wc -l
grep -r "indexedDB\|IDB\|Dexie" --include="*.ts" --include="*.tsx" | wc -l

Parallel Execution Command

Invoke all 3 agents in a SINGLE Task message:

Task 1: dx-golden-path-auditor agent - audit setup, scripts, onboarding Task 2:
debugging-ergonomics-auditor agent - audit logging, error handling Task 3:
offline-support-auditor agent - audit persistence, service workers

Each agent prompt MUST end with:

CRITICAL RETURN PROTOCOL:

- Write findings to the specified output file using Write tool or Bash
- Return ONLY: `COMPLETE: [agent-id] wrote N findings to [output-path]`
- Do NOT return full findings content — orchestrator checks completion via file

Dependency constraints: All 3 agents are independent -- no ordering required. Each audits a separate domain and writes to separate output sections.


Section B: Sequential Fallback

When to use: Task tool unavailable, context pressure, or user request

Step 1: Golden Path & DX (10 min)

  1. Review package.json scripts section
  2. Check for setup/doctor automation scripts
  3. Verify .env.example completeness
  4. Assess README setup instructions
  5. Identify missing "golden path" scripts

Step 2: Debugging Ergonomics (10 min)

  1. Calculate console.log vs logger ratio
  2. Search for correlation ID patterns
  3. Review error boundary implementations
  4. Check Sentry integration in logger
  5. Assess error message quality

Step 3: Offline Support (10 min)

  1. Check Firebase persistence configuration
  2. Look for service worker implementation
  3. Review offline indicator component
  4. Search for write queue patterns
  5. Assess localStorage vs IndexedDB usage

Output Requirements

Report File

Create docs/audits/single-session/engineering-productivity/audit-report.md:

# Engineering Productivity Audit - {DATE}

## Baselines

| Metric                   | Value |
| ------------------------ | ----- |
| npm scripts count        | X     |
| Console.log calls        | X     |
| Logger calls             | X     |
| Structured logging ratio | X:Y   |
| LocalStorage usages      | X     |
| IndexedDB usage          | X     |
| Service worker           | Y/N   |
| Firebase persistence     | Y/N   |

## Findings Summary

| Severity | Count | Category       |
| -------- | ----- | -------------- |
| S0       | X     | -              |
| S1       | X     | Category names |
| S2       | X     | Category names |
| S3       | X     | Category names |

## Detailed Findings

### 1. Golden Path & DX

[Findings here]

### 2. Debugging Ergonomics

[Findings here]

### 3. Offline Support

[Findings here]

## Quick Wins (E0-E1)

[Prioritized list of low-effort fixes]

## Recommendations

### Immediate (E0-E1)

[List]

### Short-term (E2)

[List]

### Long-term (E3)

[List]

JSONL File

Create docs/audits/single-session/engineering-productivity/audit-findings.jsonl:

CRITICAL - Use this exact schema:

{
  "category": "engineering-productivity",
  "title": "Short specific title",
  "fingerprint": "engineering-productivity::primary_file::identifier",
  "severity": "S0|S1|S2|S3",
  "effort": "E0|E1|E2|E3",
  "confidence": 75,
  "files": ["array/of/file/paths.ts"],
  "why_it_matters": "1-3 sentences explaining impact",
  "suggested_fix": "Concrete remediation direction",
  "acceptance_tests": ["Array of verification steps"],
  "evidence": ["code snippet", "grep output", "measurement data"]
}

Category Definitions

CategoryDescription
GoldenPathSetup, scripts, onboarding, dev workflow
DebuggingLogging, tracing, error handling, messages
OfflinePersistence, service workers, queues, sync

Severity Scale

LevelNameDefinition
S0CriticalData loss risk, production breaking
S1HighSignificant dev friction, missing core
S2MediumMaintainability drag, inconsistency
S3LowPolish, minor improvements, nice-to-have

Effort Scale

LevelNameDefinition
E0MinutesQuick fix, trivial change
E1HoursSingle-session work
E2Days1-3 days or staged PR
E3WeeksMulti-PR, multi-week effort

Prior Audit Reference

Check docs/audits/single-session/engineering-productivity/ for prior findings and track carryover issues.


Standard Audit Procedures

Read .claude/skills/_shared/AUDIT_TEMPLATE.md for: Evidence Requirements, Dual-Pass Verification, Cross-Reference Validation, JSONL Output Format, Context Recovery, Post-Audit Validation, MASTER_DEBT Cross-Reference, Interactive Review, TDMS Intake & Commit, Documentation References, Agent Return Protocol, and Honesty Guardrails.

Skill-specific TDMS intake:

node scripts/debt/intake-audit.js \
  docs/audits/single-session/engineering-productivity/audit-findings.jsonl \
  --source "audit-engineering-productivity-$(date +%Y-%m-%d)"

When to Use

  • User explicitly invokes /audit-engineering-productivity
  • Engineering productivity or DX audit is needed
  • Called as part of /audit-comprehensive (Stage 2)

When NOT to Use

  • When you only need to audit code quality — use /audit-code instead
  • When you need CI/CD pipeline health — use /audit-process instead
  • When you need a comprehensive multi-domain audit — use /audit-comprehensive

Related Skills

  • /audit-comprehensive - Run all 7 domain audits
  • /audit-process - CI/CD and automation audit (overlaps with DX)
  • /audit-code - Code quality audit

Version History

VersionDateDescription
1.12026-02-23Add mandatory MASTER_DEBT cross-reference step before interactive review
1.02026-02-03Initial skill creation

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

Reviews can't be read right now.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.