Auto

--- name: auto description: "Run the SEO /GEO pack-local Aaron workflow implied by a natural-language goal, at the smallest safe depth. Add --deep for exhaustive, maximum-rigor, or stress-test runs." argument-hint: "<natural-language-goal> [--deep]" parameters: - name: goal type: string required: true description: "Any SEO /GEO goal, URL, domain, topic, draft, or question" - name: deep type: boolean required: false description: "Run maximum-depth, exhaustive, phase-gated orchestration" --- # Auto Command Run the SEO /GEO pack-local Aaron workflow implied by a natural-language goal, at the smallest safe depth. Add --deep for an exhaustive, phase-gated, maximum-rigor run. ## Route - resolver across all 20-skillss, expressed through the four mode commands: research, create, audit, track ## Rules - Follow the Product-API Contract in references/aaron-product-api-contract.md; use evals/product-api-scenarios.md as the scenario library. Natural-language auto-invocation is host-dependent unless /aaron:auto is explicit; clearly non-SEO/GEO operations stop with a pack-boundary note. - Memory-management exemption: Memory-management lifecycle operations (query, archive, restore, purge) operate on user-owned project memory regardless of topical scope and are NOT subject to the pack-boundary check; safety is enforced by user confirmation for each operation. - Algorithm: parse the goal -> assign the closest scenario family -> attach risk gates -> choose the smallest mode command (research / create / audit / track) or chain that completes the outcome -> ask only for blocking inputs -> continue to the natural stopping point. - Ambiguity rule: If there is an object (URL /domain/topic/draft) but no clear goal, perform a lightweight triage and select the safest, most useful starting chain; if there is no actionable object and no outcome, ask one concise blocking question. - Default to a single mode command when it achieves the goal; otherwise, chain research → create → audit → track as needed. - **--deep** (which incorporates the former “/aaron:max”): run only when the user explicitly requests maximum-depth, exhaustive, or stress-test work. First output a phase plan, success criteria, evidence inventory, risk gates, permission checkpoints, and stop condition. Phase order: preflight → research → audit (tech / quality / visibility / authority) → optional memory → create (brief / write / series) → publish gate (/aaron:create --publish) → track. Do not enable “--deep” for ordinary, broad-scope work. - Apply scenario-library risk gates: publish readiness, YMYL, schema factuality, batch scale, external side effects, memory/entity writes, reputation ethics, GEO visibility claims, insufficient data, technical indexing. - Respect specialist boundaries: batch content remains chunked; audit/publish readiness require full veto-aware evidence; GEO visibility cannot guarantee citations; memory cleanup remains the responsibility of memory management; canonical entity writes remain the responsibility of the entity optimizer. - Do not route repository maintenance, version sync, release, permission, or governance requests through /aaron:auto; they fall outside the pack-local SEO /GEO workflow. - Terms such as “apply,” “commit,” “release,” “publish,” or “fix” do not automatically grant permissions. Publish-package and readiness tasks are routed through /aaron:create --publish; actual CMS/external publication, commits, releases, and repo edits require explicit confirmation. - If input begins with an old-/seo:*s, preserve the arguments and return a single copyable replacement: audit-page -> /aaron:audit, audit-domain -> /aaron:audit --authority, check-technical -> /aaron:audit --tech, generate-schema -> /aaron:create --schema, keyword-research -> /aaron:research, optimize-meta -> /aaron:create --meta, report -> /aaron:track --report, setup-alert -> /aaron:track --alert, write-content -> /aaron:create. - Return an execution summary by default: completed steps, evidence used, blockers or gate stops, artifacts produced, assumptions, and next safe action. The diagnostic route trace appears only when explicitly requested. - Never write files unless explicitly requested and supported by the runtime. ## Output Return inline a