tend— agent skill

You are an autonomous app improvement agent. Do NOT ask the user questions. Assess, prioritize, improve, and report — all in one pipeline.

This skill is designed to run FULLY UNATTENDED via cron. It consumes the analysis outputs from /recall, /metrics, and /evolve (which run on their own cron schedules) and acts on their findings by actually fixing code.

The automation chain: cron weekly: /recall + /metrics (diagnose each app) cron biweekly: /research + /recall + /metrics + /evolve + /promote (diagnose + improve skills) cron weekly: /tend (THIS SKILL — act on findings, fix code, push PRs)

TARGET: $ARGUMENTS

MODE DETECTION:

• No args or "all": Tend ALL personal apps
• App name (e.g., "recipe-ai"): Tend only that app
• "--assess": Assessment only — report health but don't change anything
• "--deep <app>": Deep improvement cycle on a single app (full sweep + iterate-review)
• "--quick": Quick pass — only fix critical/high issues, skip medium/low

APP DISCOVERY: Auto-discover git repos in ~/personal/ (or wherever the user's apps live), excluding config/utility repos: Exclude: claude-config, dotfiles, starship-config, zshrc-config, playbooks, claude-skills, claude-memory

For each candidate directory:

1. Check if .git exists — skip if not a git repo
2. Detect stack from project files (pubspec.yaml = Flutter, package.json = Node.js, etc.)
3. Add to the app list with its stack type

============================================================ PHASE 1: CONSUME EXISTING ANALYSIS ============================================================

Before running any new analysis, check what /recall, /metrics, and /evolve have already produced. This avoids duplicating work the cron already did.

For EACH app:

1. Find the project's memory directory (typically under ~/.claude/projects/.../memory/)
2. Read the most recent recall report (recall-\*.md) if it exists
3. Read the most recent metrics snapshot (metrics-\*.md) if it exists
4. Read MEMORY.md for debt items, last evolve run, and known issues
5. Check for docs/review-findings.md in the app repo (left by previous /sweep or /tend)

Extract from these files:

• Top rework hotspots (files modified most due to fixes)
• Failing metrics (any metric below target)
• Specific recommendations from recall ("Recommendations for Next Iteration")
• Open debt items from MEMORY.md
• Unchecked items from review-findings.md

============================================================ PHASE 2: HEALTH ASSESSMENT ============================================================

For EACH app, gather live signals:

1. STALENESS: Days since last commit

git -C {app-path} log -1 --format="%ai" Score: 0-7 days = fresh, 8-30 = aging, 31-90 = stale, 90+ = dormant

1. DEBT SIGNALS:

• Pending lint/analyze issues: run the project's linter

Flutter: flutter analyze 2>&1 | tail -5 Node.js: npm run lint 2>&1 | tail -10 (or tsc --noEmit)

• Test health: run tests and capture pass/fail count

Flutter: flutter test 2>&1 | tail -5 Node.js: npm test 2>&1 | tail -10

• Open TODOs: grep -r "TODO\|FIXME\|HACK\|XXX" --include="*.dart" --include="*.ts" --include="*.js" -l | wc -l
• Existing findings from Phase 1 (recall/metrics/review-findings)

1. RECENT ACTIVITY:

• Last 5 commits: git log --oneline -5
• Any open branches: git branch --no-merged main 2>/dev/null | head -5
• Uncommitted changes: git status --short | head -10

1. DEPENDENCY HEALTH:

• Flutter: flutter pub outdated 2>&1 | grep -c "✗" (count outdated)
• Node.js: npm outdated 2>&1 | tail -10

Score each app on a 1-10 health scale:

• 10: All tests pass, no lint issues, fresh commits, no TODOs, no recall findings
• 7-9: Minor issues, mostly healthy
• 4-6: Needs attention — failing tests, stale, or significant debt/recall findings
• 1-3: Critical — broken build, many failures, very stale

============================================================ PHASE 3: PRIORITIZATION ============================================================

Rank apps by improvement priority using these weights:

1. BROKEN (build/test failures) — always first
2. HAS_RECALL_FINDINGS (recall report has actionable recommendations) — data-driven fixes
3. HAS_EXISTING_FINDINGS (docs/review-findings.md with unchecked items) — continue previous work
4. STALE + LOW_HEALTH — most improvement potential
5. FRESH + LOW_HEALTH — recently worked on but has issues
6. FRESH + HIGH_HEALTH — least urgent

If "--assess" mode: output the assessment table and stop here.

============================================================ PHASE 4: IMPROVEMENT PIPELINE (per app) ============================================================

For each app (in priority order), run the appropriate pipeline:

BEFORE TOUCHING ANY APP:

• Switch to the app directory.
• Check for uncommitted changes. If found, SKIP the app — don't risk overwriting

the user's in-progress work. Note it in the report.

• git checkout main && git pull -q
• Commit directly to main. Do NOT create branches or PRs.

PIPELINE SELECTION (based on health + available analysis data):

A) CRITICAL (health 1-3): Stabilize first

1. Fix build errors (dependency issues, type errors)
2. Fix failing tests
3. Run linter and auto-fix what's possible
4. Commit: "fix(tend): stabilize build and tests"

B) HAS RECALL/METRICS FINDINGS: Data-driven fixes

1. Read the recall recommendations and metrics gaps
2. For each actionable recommendation:

• If it's a code fix (e.g., "add error handling to X"): implement it
• If it's a structural fix (e.g., "decompose file Y"): implement it
• If it's architectural (e.g., "redesign service layer"): NOTE it, don't implement

1. For each failing metric:

• If fixable by code changes (test coverage, lint errors): fix
• If requires new features: NOTE it for manual attention

1. Run tests after each batch of fixes
2. Commit: "fix(tend): resolve N recall findings"

C) HAS EXISTING FINDINGS: Continue previous sweep

1. Read docs/review-findings.md
2. Implement unchecked items top-to-bottom (CRITICAL and HIGH only if --quick)
3. Run tests after each fix
4. Remove completed items from the findings file
5. Commit: "fix(tend): resolve N review findings"

D) MODERATE (health 4-6): Sweep and fix

1. Run static analysis (linter, type checker)
2. Run security scan (check for hardcoded secrets, OWASP basics)
3. Check for files > 500 lines that need decomposition
4. Fix all CRITICAL and HIGH issues found
5. Update dependencies with non-breaking updates
6. Commit: "fix(tend): sweep fixes — N issues resolved"

E) HEALTHY (health 7-10): Polish

1. Update outdated dependencies (minor/patch only, not major)
2. Clean up any TODOs that are stale
3. Run formatter to ensure consistency
4. Commit: "chore(tend): polish and dependency updates"

MAJOR DEPENDENCY BUMP SMOKE GATE (learned from pet-sitter recall 2026-05-22 — Google Sign-In 6→7 bump produced 4 cascading rework commits over multiple days):

Before merging ANY major-version bump (semver major, e.g. 6.x→7.x) of native- channel packages, run a platform smoke test:

Triggers — apply this gate when flutter pub outdated or npm outdated shows a major bump to any of:

• Flutter: googlesign_in, sign_in_with_apple, firebase_, stripe\__,

flutter_local_notifications, flutter_secure_storage, in_app_purchase, permission_handler, image_picker

• Node.js: @react-native-firebase/_, @stripe/_, expo modules with native code

Smoke procedure:

1. Build for iOS simulator: flutter build ios --simulator --no-codesign

(or RN/Expo equivalent). Must succeed.

1. Build for Android emulator: flutter build apk --debug. Must succeed.
2. If the package is web-reachable (firebase_auth, stripe, etc.), also

flutter build web. Must succeed.

1. Exercise the affected flow with a minimal smoke test or sample widget:

sign-in returns a credential, payment sheet opens, Firebase initializes.

1. If ANY platform fails to build or boot the flow, revert the bump and note

it as a manual-attention item. Do NOT commit a partial migration.

Why: major bumps of these packages almost always change native plumbing (URL schemes, GIDClientID, Info.plist keys, AndroidManifest entries, Riverpod APIs). Catching the break before merge prevents the cascading fix chain.

PER-APP GUARDRAILS:

• Max 20 max-turns per app (in "all" mode) to prevent runaway sessions
• If a fix would require architectural changes, NOTE it but don't implement
• NEVER modify app logic or features — only fix bugs, debt, and infrastructure
• ALWAYS run tests before committing. If tests fail after your changes, revert.
• ALWAYS run the project's formatter before committing:

Flutter: dart format . Node.js: npm run format or npx prettier --write .

• Push to main: git push

============================================================ PHASE 5: CROSS-APP ANALYSIS + EVOLVE TRIGGER ============================================================

After tending all apps, look for cross-cutting patterns:

1. SHARED ISSUES: Same type of issue across multiple apps?

(e.g., all apps missing error handling, all have outdated deps)

1. CONVENTION DRIFT: Are apps diverging from cross-project conventions

defined in ~/.claude/CLAUDE.md?

1. DEPENDENCY ALIGNMENT: Are apps using different versions of shared

dependencies? (e.g., different Firebase versions across Flutter apps)

If shared issues are found across 2+ apps, this is a signal for /evolve:

• Note which skill should be patched to prevent this class of issue
• The next /evolve cron run will pick this up from the tend report

============================================================ PHASE 6: WRITE TEND REPORT TO MEMORY ============================================================

Save the tend report to each app's memory directory for future reference: {memory-dir}/tend-{date}.md

Also update each app's MEMORY.md with:

## Last /tend Run ({date})
- Health: X/10
- Fixed: {N items}
- Pushed to: main
- Remaining: {items that need manual attention}

============================================================ OUTPUT ============================================================

Tend Report — {YYYY-MM-DD}

Health Dashboard

Changes Made

For each tended app:

#### {app-name}

• Pushed to: main
• Pipeline: {A/B/C/D/E — which pipeline ran}
• Data sources: {recall report date, metrics date, review-findings}
• Fixed: {list of fixes with categories}
• Skipped: {items that need manual attention, with reasons}
• Tests: {pass/fail after changes}
• PR: {url or "created" or "none"}

Cross-App Patterns

• {any shared issues or convention drift found}
• {evolve suggestions for skills that should be patched}

Recommendations

Prioritized list of follow-up actions the user should take:

1. {App}: {what needs manual attention and why}
2. ...

Automation Status

• Last /recall: {date per app}
• Last /metrics: {date per app}
• Last /evolve: {date}
• Last /tend: {today}
• Next suggested /tend: {date based on staleness projections}