optflow
Use when the user asks to discover and deliver repository optimization work end to end: identify performance/reliability/maintainability/security/dx/cost optimization points, prioritize by impact-effort-risk, then execute fixes step by step with continuous testing and explicit commit policy (`final_only`, `per_step`, `milestone`). Default to `per_step` for implementation work so each feature is tested then committed before the next feature. Supports optional BDD (Given/When/Then).
What this skill does
# Optflow ## Overview Use this skill to discover repository optimization opportunities and execute selected optimizations end to end: - Discover optimization points first (performance, reliability, maintainability, security, cost, DX). - Prioritize by impact/effort/risk. - Execute in strict sequence with validation and explicit commit policy. - Add BDD behavior specs when requested or when requirements are ambiguous. ## Trigger Cues Trigger this skill when the user asks for one or more of: - Ask to find optimization opportunities in a repository/library. - Ask for optimization roadmap + implementation. - Require test-first optimization delivery and commit (final or per step). - Require behavior-driven delivery (BDD) or acceptance scenarios. ## Workflow ### 0. Discover Optimization Backlog - Scan the repository before planning changes. - Classify findings into: performance, reliability, maintainability, security, developer experience, and cost. - For each finding, record: - symptom and evidence (file/path/metric) - expected impact - effort estimate - risk level - Build a prioritized backlog using impact/effort/risk. - Explicitly mark low-confidence findings as hypotheses. ### 1. Define Ready Criteria (DoR) > See shared delivery base: [`references/delivery-base.md`](./references/delivery-base.md) Additional for optflow: - If implementation is requested and commit style is not explicitly specified, use `per_step` (default). - If user says "per step optimize and test then commit", use `per_step`. ### 2. Build Complete Plan Before Editing > See shared delivery base: [`references/delivery-base.md`](./references/delivery-base.md) ### 3. Add BDD Layer When Needed Use BDD if user requests it, or if requirements are unclear. For BDD Lite, Scenario Quality Checklist, Scenario Outline, and Test Layer mapping, see the shared reference: > [`references/bdd-guide.md`](./references/bdd-guide.md) ### 4. Execute Step by Step > See shared delivery base: [`references/delivery-base.md`](./references/delivery-base.md) - Treat one planned step as one feature boundary whenever possible. - If `commit_policy = per_step` (default for implementation): - Stage only files for current step/feature. - Run step-level checks first. - Commit immediately after step checks pass. - Record step -> commit hash mapping. ### 5. Apply No-Backward-Compatibility Mode (When Requested) > See shared delivery base: [`references/delivery-base.md`](./references/delivery-base.md) ### 6. Validate with Test Matrix > See shared delivery base: [`references/delivery-base.md`](./references/delivery-base.md) Per-step mandatory loop (when `commit_policy = per_step`): 1. Implement current feature step. 2. Run mapped step checks (at least one automated command). 3. If checks pass, commit this step immediately. 4. Move to next feature step. ### 7. Commit and Handoff > See shared delivery base: [`references/delivery-base.md`](./references/delivery-base.md) - `per_step`: each step must already be committed before next step starts. ## Output Templates ### Optimization Backlog Template ```text Finding: Category: <performance|reliability|maintainability|security|dx|cost> Evidence: <file/metric/log> Impact: <high|medium|low> Effort: <high|medium|low> Risk: <high|medium|low> Priority score: <...> Decision: <implement now|defer> ``` ### Optimization Plan Template ```text Selected Findings: 1. <finding> 2. <finding> Execution Steps: 1. <step> (done condition: <...>) 2. <step> (done condition: <...>) Expected Gains: - <metric or qualitative gain> ``` ## Guardrails - Do not stop at planning when implementation is expected. - Do not leave partially completed plan steps. - Do not defer required testing when it can be run now. - Do not move to the next plan step before committing when `commit_policy = per_step`. - Do not merge multiple completed feature steps into one commit when `commit_policy = per_step`. - Do not claim compatibility if user explicitly requested no compatibility work. - Do not include unrelated pre-existing dirty files in commits. - Do not hand off without concrete validation evidence.
Related in Security
mac-ops
IncludedComprehensive macOS workstation operations — diagnose kernel panics, identify failing drives, audit launchd startup items, decode wake reasons, triage TCC permission denials, manage APFS snapshots, recover from no-boot. Use for: Mac is slow, slow bootup, won't boot, kernel panic, kernel_task hot, mds_stores CPU, photoanalysisd, cloudd, login loop, gray screen, sleep wake failure, drive failing, IO errors, APFS snapshots eating space, Time Machine local snapshots, Spotlight indexing, launchd, LaunchAgent, LaunchDaemon, login items, TCC permissions, Full Disk Access, Screen Recording denied, Gatekeeper, quarantine, com.apple.quarantine, app is damaged, helper tool, /Library/PrivilegedHelperTools, pmset, wake reasons, dark wake, sysdiagnose, panic.ips, DiagnosticReports, configuration profile, MDM profile, remote diagnostics over SSH.
a11y-audit
IncludedRun accessibility audits on web projects combining automated scanning (axe-core, Lighthouse) with WCAG 2.1 AA compliance mapping, manual check guidance, and structured reporting. Output is configurable: markdown report only, markdown plus machine-readable JSON, or markdown plus issue tracker integration. Use this skill whenever the user mentions "accessibility audit", "a11y audit", "WCAG audit", "accessibility check", "compliance scan", or asks to check a web project for accessibility issues. Also trigger when the user wants to verify WCAG conformance or map findings to a specific standard (CAN-ASC-6.2, EN 301 549, ADA/AODA).
erpclaw
IncludedAI-native ERP system with self-extending OS. Full accounting, invoicing, inventory, purchasing, tax, billing, HR, payroll, advanced accounting (ASC 606/842, intercompany, consolidation), and financial reporting. 413 actions across 14 domains, 43 expansion modules. Constitutional guardrails, adversarial audit, schema migration. Double-entry GL, immutable audit trail, US GAAP.
assess
IncludedAssesses and rates quality 0-10 across multiple dimensions (correctness, maintainability, security, performance, testability, simplicity) with pros/cons analysis. Compares against project conventions and prior decisions from memory. Produces structured evaluation reports with actionable improvement suggestions. Use when evaluating code, designs, architectures, or comparing alternative approaches.
spring-boot-security-jwt
IncludedProvides JWT authentication and authorization patterns for Spring Boot 3.5.x covering token generation with JJWT, Bearer/cookie authentication, database/OAuth2 integration, and RBAC/permission-based access control using Spring Security 6.x. Use when implementing authentication or authorization in Spring Boot applications.
code-hardcode-audit
IncludedDetect hardcoded values, magic numbers, and leaked secrets. TRIGGERS - hardcode audit, magic numbers, PLR2004, secret scanning.