Code audits, performance work, feature planning, and product research, with an installable workflow skill. Theo shared six ways he uses Astra: code cleanup, performance work, agent setup, PR and issue triage, merging, and taking over stalled work. I wrote a prompt for each and added nine for other development tasks, including feature planning, competitor research, and SEO/GEO audits. You can copy them from AI Coding Prompts on GitHub or install the included Astra Workflows skill for Codex or Claude Code. How to use this pack Copy the shared instructions and one task prompt below. You can also copy each prompt from the GitHub repository. Fill in the bracketed fields and review the permissions: prompt 4 allows issue and PR closures, prompt 5 allows scoped merges and staging deployment, and prompts 6 and 12 allow draft PRs. Start a new session for a new objective. Keep a feature and its debugging together. Give parallel tasks separate branches or worktrees and clear ownership of the files they change. Check the combined result before merging. Start with prompt 3 if the agent cannot run or test the app. For product work, use 14 to research an opportunity, 13 to plan it, and 12 to build the accepted plan. Use 15 to audit the website. Adapt the shared rules for your project AGENTS.md or CLAUDE.md and keep the task prompts separate. Run one task at a time within a session. Select the model and connect its tools in your agent setup. Shared instructions Work in the current repository unless I specify another scope. Read applicable AGENTS.md and contribution instructions. Prefer existing solutions, standard libraries, native features, and small changes. Follow the repository's established toolchain, package manager, lockfile, runtime, and test runner unless I request a migration. Understand the affected behavior, callers, and contracts before editing. Preserve unrelated changes and user work. Use an isolated branch or worktree when needed. State the outcome and verification method, then proceed. Make routine implementation decisions yourself. Ask when a missing decision changes the scope or product behavior, or an action exceeds your authorization. Continue other work while waiting. You may investigate, edit local files, run checks, and create local branches/worktrees. Use authorized access for remote reads. Remote writes, PR creation, comments, closures, merges, and deployments require authorization in the task or existing conversation. Reuse permission from this conversation. Complete the preparation before asking for approval of a blocked action. Establish the relevant baseline and record existing failures. Distinguish pre-existing failures, environment problems, and regressions from your changes. Fix unrelated failures only when they block this task and the fix is a small, understood prerequisite; report larger blockers. Check the behavior users or callers depend on. Add regression tests; avoid assertions that restate the implementation. Run relevant checks and required repository checks. Broaden or repeat them only when changes or unresolved concerns justify it. Keep required gates and intended behavior intact. Complete the agreed scope and verification. For broad audits, state what you inspected and what remains; do not imply exhaustive coverage from a sample. Prioritize useful findings without inventing a quota. Report the result, verification, and unresolved blockers. Cite files, commands, revisions, or artifacts where they help someone reproduce your findings. Distinguish observed facts from inferences. 1. Slop audit and cleanup Find and remove unnecessary complexity in this repository. Look for wrappers with no useful behavior or boundary, duplicated logic, speculative abstractions, dead code, unused dependencies, obsolete configuration, and stale comments or documentation. Inspect tests that assert their own mocks, duplicate existing coverage, or lock down implementation details without protecting behavior. Trace usage before deleting anything. Check public exports, dynamic loading, generated code, framework conventions, and external contracts where relevant. A missing local reference does not establish that code is unused. For each removed or consolidated test, identify the behavior it protected and why the remaining coverage is sufficient. Preserve useful regression tests, security checks, validation, error handling, accessibility, and architectural boundaries. Judge short functions and small tests by the behavior or boundary they protect. Group related cleanup changes and verify the affected behavior. Keep edits tied to the maintenance problem; avoid line-count targets and cosmetic churn. Report what you removed, the checks you ran, and the scope you inspected. List uncertain findings you left untouched. Leave the code as it is if you find no useful cleanup. 2. Hunt for measurable performance wins Find and implement performance improvements in this repository. Identify important user flows and expensive operations. Use available profiles, traces, query plans, browser tooling, or benchmarks to locate bottlenecks. If I have not named a priority, choose representative flows from the repository and explain the choice. Establish a reproducible baseline before editing. Record the workload, dataset, environment, revision, and relevant measurements. If tooling is missing, add the smallest useful harness with existing tools. Prioritize repeated work, unnecessary requests, N+1 queries, avoidable allocations, large payloads, and inefficient algorithms where measurements show an opportunity. Choose an improvement, implement it, and compare before and after under equivalent conditions. Repeat measurements enough to assess noise. Include relevant tradeoffs such as memory, throughput, tail latency, freshness, and failure behavior. Check correctness as well as timing. Keep changes that improve the measured result while preserving correctness. Revert failed experiments. If an experiment still simplifies the code, report that benefit without claiming a speedup. Report before/after measurements, reproduction commands, correctness checks, and remaining bottlenecks. Label results limited to synthetic workloads or local hardware. If you cannot measure a proposed speedup, say so and name the tool or access you need. 3. Improve agent setup and verification Improve this repository so an agent can set it up, make changes, and verify its own work with minimal human intervention. Attempt the documented workflow from a fresh checkout or isolated worktree. Record actual blockers involving installation, configuration, startup, development authentication, test data, service isolation, ports, logs, debugging, targeted checks, and end-to-end QA. For each blocked check, identify the tool, script, documentation, or access you need. Fix agent instructions that cause setup or verification failures. Implement useful repository-local improvements. Reuse established tools and commands. Document setup, checks, debugging, and common failures in the appropriate existing documentation or AGENTS.md. Keep instructions short enough to maintain. Use development credentials and isolated data, and keep secrets out of tracked files and logs. Request the minimum specific external access only when needed; continue other improvements while waiting. Validate the revised workflow from a clean worktree. Exercise a representative user flow. For a new or changed verification gate, introduce a representative fault in a disposable environment, confirm the gate catches it, and remove the fault. Provide the working commands, remaining manual steps, and access you still need. Include measured setup or verification times if they help assess the change. 4. Audit and clean up open PRs and issues Review open PRs and issues in this repository. Resolve the items whose history and current code justify closure. Inventory the backlog, including pagination. Read descriptions, discussions, linked work, relevant code, and CI. Classify items as resolved, duplicate or superseded, actionable, promising merge candidate, or requiring a maintainer decision. You may post concise factual comments, apply existing labels, and close issues or PRs when evidence and repository policy support closure. Link the resolving commit, canonical issue, or superseding PR and explain the disposition. Before closing superseded work, record its unresolved requirements in a linked issue or PR. For bug-resolution claims, check the original scenario against the current default branch where feasible. Failure to reproduce alone does not prove resolution. Age, inactivity, and passing CI alone are insufficient reasons to close an item. Leave uncertain items open and state the next check or decision. Identify easy-win PRs by reviewing their changes, required checks, compatibility, and unresolved feedback. This task authorizes triage and supported closures; identify merge candidates for the merge workflow. Report links to the actions you took, merge candidates and their remaining checks, maintainer decisions, and the backlog you could not inspect. Use no closure quota. 5. Review, merge, and verify staging Review and merge PRs in this explicit scope: [PR URLs or a precise selection rule] You may merge qualifying PRs without asking again and deploy the resulting revision to staging through the established workflow. Production deployment is outside this authorization. Inspect merge policies and deployment triggers first. Confirm that merging will not automatically deploy to production or mutate production data without separate authorization. If it would, complete review and preparation but leave the merge blocked on that boundary. For each PR, understand the intended result, review the complete diff, resolve material concerns within its scope, and verify affected behavior. Run relevant checks and confirm required CI, approvals, and blocking feedback. Passing CI alone is insufficient evidence of correctness. Check compatibility, migrations, and rollback limitations where the diff makes them relevant. Use existing staging services and fixtures without destructive shared-data resets. Use the repository's normal merge method or queue and respect protections and required human approvals. Merge the revision you reviewed and verified. Process dependent PRs in order and revalidate when the base or PR changes. After merging, verify the resulting revision, its staging deployment, and affected flows. Stop further merges if staging fails and investigate. Execute rollback only where policy or existing authorization permits it; otherwise prepare the specific recovery action. Report PR links and revisions, checks, and the staging results. Mark pending deployments and blocked PRs as unfinished, with the reason. 6. Take over work stuck in a loop Take over and complete this stalled work: [PR, branch, issue, or specification] Read the original requirements, implementation, review discussion, failed checks, and relevant history. Define the intended behavior and acceptance criteria. Identify why progress stalled: misunderstood requirements, excess scope, a flawed approach, missing verification, environmental problems, or repeated symptom fixes. You may discard or replace the existing implementation when a simpler approach better satisfies the requirements. Preserve the original branch and uncommitted work before replacing anything, and use a recovery branch when appropriate. Preserve shared history rather than force-pushing over someone else's work. Keep valid requirements and useful tests. Remove speculative infrastructure and unnecessary scope. Ask one focused question if acceptance criteria conflict or a material product decision is missing, while continuing independent work. Choose to repair, simplify, or restart based on what it takes to meet the requirements. Explain the choice and implement it. Establish a runnable reproduction or acceptance check early. Use failed attempts to revise the diagnosis or approach. Continue until the acceptance criteria pass or an external dependency prevents completion; name that dependency. You may open or update a draft PR for the final work. Describe the final scope, verification, and limitations. Merging requires the separate merge authorization. 7. Hunt for bugs and fix their root causes Find and fix correctness bugs in [scope; default: important flows in this repository]. Identify intended behavior from requirements, contracts, callers, and existing tests. Prioritize concrete failures in state transitions, boundaries, concurrent operations, retries, cancellation, partial failure, and data persistence where applicable. For each suspected bug, reproduce the failure or trace the code path that demonstrates it. Distinguish confirmed bugs from plausible concerns. Trace the root cause and affected callers before editing. Group fixes by root cause and preserve unrelated code. Add the smallest meaningful regression check and demonstrate that it fails before the fix and passes afterward where feasible. Verify neighboring behaviors that share the cause. Use local or isolated environments for failure injection and test data. Do not treat undocumented product choices as defects; ask if the intended behavior would change the fix. For each confirmed bug, report its trigger, impact, root cause, fix, and regression check. List unverified suspicions and the scope you inspected. 8. Review security boundaries and repair confirmed gaps Review security in [scope; default: externally reachable paths in this repository] and fix confirmed vulnerabilities within that scope. Map the relevant entry points, identities, sensitive operations, data, and trust boundaries. Inspect authentication, authorization, tenant isolation, input handling, secrets, file access, outbound requests, and sensitive logging where applicable. For each finding, describe the concrete path from attacker-controlled input to unauthorized behavior, the prerequisites, and the impact. Validate it with local or isolated tests using synthetic data. Keep hypotheses separate from demonstrated findings; check how the application uses the affected code before assigning impact. Implement focused fixes that preserve intended access. Test both the legitimate operation and the denied case, including cross-user or cross-tenant cases where relevant. Keep validation at the boundary that owns the rule. This task authorizes repository changes and isolated testing. Active probing of live third-party or production systems, credential rotation, and production data changes require separate authorization. Use source inspection and local reproductions to continue useful work. Rank confirmed findings by impact. Include code locations, fixes, checks, and unresolved assumptions. State the scope you inspected and its coverage limits. 9. Make CI and tests trustworthy Diagnose and fix unreliable verification in [CI job, test suite, or recent failures; default: failing checks in this repository]. Collect the failing revision, commands, environment, logs, and repeatability. Determine whether each failure comes from a product bug, test defect, shared state, timing, infrastructure, or environment drift before changing anything. Prioritize failures that prevent developers from trusting CI. Fix root causes such as leaked state, ordering assumptions, nondeterministic data, missing readiness checks, or incorrect assertions. Preserve the behavior the check protects. Keep required checks enabled. Avoid solving failures by weakening assertions, adding arbitrary sleeps, increasing retries, or raising timeouts without evidence that the underlying behavior requires it. Quarantine only under established repository policy with a tracked cause and recovery condition. Verify the fix in the affected execution conditions, including repeated or parallel runs when relevant. Report the number and conditions of runs, including runs with no failures. State what those observations cannot rule out. Report root causes, changes, before/after failure observations, and remaining limitations. Leave unrelated test-suite redesign for a separate task. 10. Exercise real user journeys and fix failures Run user-journey QA for [flows; default: the app's primary flows] and fix confirmed defects. Start the app in its supported local or preview environment. Use the available browser, device, or app tools to complete realistic tasks. State the flows, roles, and viewports you cover. Check success paths and relevant loading, empty, validation, error, cancellation, and recovery states. Inspect keyboard navigation, focus, accessible names, and responsive behavior where applicable. Use console and network evidence to diagnose failures observed during interaction. Judge behavior against requirements and established product conventions. Distinguish broken behavior from subjective design preferences. Implement focused fixes without turning the task into an unrequested redesign. Use isolated accounts and synthetic data. Avoid real purchases, messages to real users, or other live side effects unless separately authorized. Repeat the affected journeys after each fix. Automate regression checks for behavior likely to break again. If interaction tools are unavailable, complete code-level checks and identify which journeys remain unverified. Report defects, fixes, reproduction steps, checks, and the roles and journeys you did not cover. 11. Maintain dependencies with a concrete purpose Review dependencies in [scope; default: this repository] and fix the security, support, or compatibility problems you confirm. Inventory direct dependencies, runtime versions, lockfiles, and relevant transitive dependencies. Prioritize verified security exposure, unsupported runtimes, compatibility problems, unnecessary packages, and upgrades that resolve a concrete issue. Verify current support status, advisories, release notes, and migration instructions using official sources. Check whether reported vulnerabilities affect the installed version and how the application uses it. Treat scanner output as evidence to investigate. Choose the smallest compatible upgrade or removal that solves the identified problem. Group changes by compatibility or shared purpose rather than upgrading every package at once. Preserve the established package manager and lockfile. Review migration requirements and transitive changes. Adapt affected code, run relevant builds and checks, and exercise integrations that static checks do not cover. Separate major upgrades that require an unresolved product or platform decision. List version changes or removals, the reason and source for each, checks, and deferred changes with their blockers. Publish no package or production release under this task. 12. Deliver a complete feature or project without expanding the scope Implement this feature or project: [desired user outcome, requirements, and examples, or the approved plan from prompt 13] If I supply a plan, check its assumptions against the current repository and environment before following it. Preserve the accepted scope and flag assumptions that no longer match the code or environment. Find the relevant existing flows and establish concrete acceptance criteria. Infer routine details from repository conventions. Ask about unresolved decisions that change product behavior, data contracts, or scope. Choose the smallest complete implementation that satisfies the outcome. Reuse established patterns and dependencies. Include required persistence, validation, authorization, error handling, and UI or API integration where the feature needs them. Preserve explicit requirements while excluding speculative flexibility and unrelated cleanup. Implement the feature end to end. Use local or disposable infrastructure to verify schema changes; document rollout and compatibility requirements without applying production migrations. Verify each acceptance criterion with the available tools suited to that check. Check the primary user flow and relevant failure cases. Add focused regression coverage for new behavior and update affected documentation. Review the final diff for correctness and unnecessary complexity, then resolve findings within scope. You may open or update a draft PR describing the final feature, verification, and rollout requirements. Merging and deployment require separate authorization. Report the result for each acceptance criterion and any limitations. Complete the essential integrations before calling the feature done. 13. Plan a new feature or build from scratch Create an implementation plan for this idea: [describe the idea, problem, desired outcome, or selected opportunity and research brief from prompt 14] Context, if known: - Existing project or new project: [details] - Intended users and primary use case: [details] - Constraints: [requirements, budget, deadline, integrations, or preferences] Plan this work before implementation. You may inspect available code and documentation and save the planning document. This task overrides the shared permission to change application code or environments; leave implementation, dependency installation, external writes, and deployment for a subsequent implementation request. For an existing project, inspect its architecture, relevant flows, conventions, and verification tools. Ground the plan in actual code and identify what can be reused. Distinguish discovered file paths from proposed new files. For a new project, define the users, problem, and smallest useful first release. Recommend a simple stack based on the requirements. Verify current compatibility and service constraints in official sources when they affect the recommendation. If the idea is exploratory, suggest up to three concrete directions, explain their value and main tradeoff, and recommend one. If I have defined the outcome, plan it. Ask up to three questions if the answers would change scope or architecture. Continue planning independent parts and mark unresolved decisions. Prefer the simplest design that meets the requirements. Preserve explicit requirements and define what the first release excludes. Avoid infrastructure or abstractions justified only by hypothetical future scale. For an unproven approach, plan a small feasibility check and define the result you need before committing to it. Produce: 1. The user problem, intended outcome, and observable success criteria. 2. First-release scope, non-goals, assumptions, and unresolved decisions. 3. The recommended approach, including relevant user flows, components, data, and integrations. Include alternatives only where a real tradeoff warrants a choice. 4. Ordered implementation milestones. For each, state the working behavior delivered, affected areas, dependencies, and completion checks. Start with the smallest useful end-to-end flow. Identify work suitable for separate parallel tasks and work that must remain sequential. 5. A verification plan mapped to acceptance criteria, including required tools, access, test data, and relevant failure cases. Include security, accessibility, performance, or migration checks where the feature requires them. 6. Rollout and recovery steps where relevant, concrete risks, and decisions that block implementation. State the assumptions behind any rough estimates. 7. A copyable prompt for the first implementation task, carrying its objective, context, scope, dependencies, and acceptance criteria into a fresh session. Scale the plan to the work: a small feature may need only a few paragraphs. Save one planning document in the established project location, or an appropriate output location if no convention exists, and link it. Finish after delivering the plan; implementation begins when I request it. After reviewing the plan, pass it to prompt 12 or run the implementation prompt from the plan. 14. Research competitors and customer pain points to find product opportunities Research competitors and customer pain points to identify worthwhile improvements to our product. Context, if known: - Our product: [name, description, website, repository, or documentation] - Target users and their main job: [audience and desired outcome] - Competitors or alternatives: [names or URLs; discover them if omitted] - Focus and constraints: [product area, market, language, business model, budget, or exclusions] Research the opportunities before proposing implementation. You may inspect available product materials, read public sources or authorized connected sources, and save the research report. This overrides the shared implementation permissions: leave code changes, purchases, outreach, external publishing, and deployment for a subsequent request. Do not apply coding skills unless the task later includes technical design or implementation. First understand our product's current capabilities, positioning, intended users, and known feedback from available materials. Distinguish confirmed behavior from marketing claims and assumptions. If you cannot establish the product or audience, ask for that context and mark the conclusions it affects. Choose three to five relevant competitors and explain why each is comparable. Include indirect alternatives or manual workarounds when customers use them for the same job. If I specify competitors, cover those and justify any additions. Research two kinds of evidence: - Current competitor capabilities, pricing, plan restrictions, integrations, documentation, changelogs, and public roadmaps. Prefer official sources for these claims and distinguish shipped functionality from announced plans. - Firsthand customer experiences in reviews, community discussions, public support threads, issue trackers, and feedback boards. Look for failed tasks, recurring friction, costly workarounds, switching reasons, and outcomes people value. Include positive experiences and counterevidence to avoid selecting only complaints. Prefer evidence from the last twelve months. Use older reports if you can confirm that the problem persists. Record source URLs, publication or update dates when available, and the research date. Open the underlying sources instead of relying on search snippets. Use short attributed quotations only when the exact wording adds value. Deduplicate repeated or syndicated complaints and record the relevant user segment, product version, and plan when available. Show observed counts and sampling limits when describing recurrence. Reviewers choose to post; their complaints may not represent the wider market. Report the sample limits and treat isolated anecdotes as leads for further research. Before calling something a competitor gap, check current documentation, plans, and changelogs for a fix or an existing solution. Distinguish a missing capability from discoverability, usability, reliability, onboarding, pricing, or support problems. Mark inaccessible sources and unresolved claims as unknown. Report a feature as unknown if you cannot establish whether it exists. For each verified pain point, identify who among our target users shares it. Check whether our product already solves each problem, shares it, or serves a different audience. Recommend the smallest useful response, which may be a workflow fix, documentation improvement, pricing change, or feature. Explain the differentiation and product fit. Use our own customer evidence when available to corroborate demand; competitor feedback alone is a hypothesis about our users. Rank opportunities by pain severity, fit for our users, confidence in the evidence, differentiation, and rough effort. Explain the tradeoffs behind the ranking. Estimate effort from our product or repository where possible. Mark feasibility as unknown if you have not inspected the relevant code or integration. Avoid fabricated market sizes, revenue forecasts, or precise scores without data. Produce one research brief containing: 1. A concise recommendation and the main limits of the research. 2. A competitor comparison covering audience, relevant strengths, current capabilities, pricing or plan constraints where relevant, and supporting sources. 3. An evidence table linking each pain point to its affected users, observed impact, dated sources, corroboration, counterevidence, and confidence. 4. A prioritized opportunity shortlist. For each, show the evidence, user outcome, our current coverage, proposed response, differentiation, rough effort, and open assumptions. Recommend up to three priorities only when the evidence supports them. 5. A cheap validation experiment for each priority, with the hypothesis, target participants or data, proposed success and failure criteria, and what result would change the recommendation. Suggest interviews or outreach without sending messages under this task. 6. A copyable handoff for prompt 13 containing the recommended opportunity, source evidence, intended outcome, constraints, validation status, and unresolved decisions. Mark whether it is ready for implementation planning or needs validation first. Link claims to sources and label your inferences. If the evidence is weak, recommend further validation. Save the brief in the established project location or an appropriate output location and link it. Finish after delivering the research and recommended next decision. Validate the demand with your target users before committing to a feature. Pass the selected opportunity and its evidence to prompt 13. 15. Audit landing pages and websites for SEO/GEO Audit our landing pages and website for SEO and GEO (generative engine optimization: visibility and accurate representation in AI-powered search and answers). Context, if known: - Website and priority URLs: [domain, URLs, sitemap, or preview] - Product and intended audience: [description] - Markets and languages: [details] - Main conversion: [signup, purchase, demo, contact, or other outcome] - Priority searches and competitors: [optional] - Available access: [repository, Search Console, Bing Webmaster Tools, analytics, or logs] This is an audit. You may inspect public pages, available source code, and authorized analytics, run non-destructive checks, draft improvements in the report, and save audit artifacts. This overrides the shared implementation permissions: leave application files, CMS content, search settings, crawler policies, and live deployments unchanged until I request implementation. Identify the pages the owner wants people to find through search and the pages they want excluded. Identify production versus preview environments. If you cannot identify the website or audience from the available context, ask for it and continue checks that do not depend on the answer. Inspect every nominated priority URL. For larger sites, inventory relevant URLs and sample representative templates, languages, and page types; state the sample and coverage limits. Keep crawling within the stated site scope and avoid unbounded parameter combinations. Compare HTTP responses and initial HTML with browser-rendered content where tools permit. Distinguish repository findings from observed deployed behavior. Use current official search-engine and provider documentation for technical rules, bot controls, structured-data eligibility, and measurements. Cite sources and the audit date. Label judgment calls and experiments, and cite provider evidence for claims about ranking factors. Check these areas where applicable: 1. Discovery and technical eligibility Inspect response codes, redirect chains, soft errors, robots.txt, robots meta tags, X-Robots-Tag, canonical URLs, sitemaps, internal links, and access restrictions. Check JavaScript rendering, crawlable navigation, duplicate URLs, and multilingual annotations. Check that visitors and the intended crawlers can access the content and follow its links. Distinguish crawling, indexing, and ranking. Use authoritative inspection data when available; absence from a search or site: query alone does not establish an indexing failure. Preserve deliberate exclusions for private, duplicate, or preview pages. 2. Page purpose and search intent Determine what question or task each landing page should satisfy. Assess descriptive titles and meta descriptions, logical headings, useful internal links, image alternatives, URL clarity, content overlap, and intent alignment. Check whether visitors can understand the product, audience, value, limitations, and next step. Identify thin or redundant pages without assuming that a particular word count, keyword density, or heading count improves rankings. Separate search recommendations from conversion and social-preview improvements. 3. Content quality and credibility Check whether claims are accurate, specific, current, and supported. Look for useful examples, original evidence, clear pricing or limitations where relevant, consistent product/company identity, and appropriate ownership or author information. Identify unanswered customer questions and missing evidence. Propose page-specific improvements using verified product facts; mark information that requires input. Do not invent expertise, testimonials, reviews, statistics, or customer results. 4. Structured data Inspect existing markup and validate relevant types against current provider requirements. Check that entities and properties match visible page content. Recommend only markup that applies to the page and distinguish schema validity from eligibility for a particular search feature. Correct markup does not guarantee rich results, ranking gains, or AI citations. 5. Mobile experience and performance Check mobile rendering, intrusive overlays, layout movement, loading, interactions, and accessibility problems that obstruct the page's main task. Use available Core Web Vitals field data and reproducible lab diagnostics. Record the tool, device conditions, date, and whether data describes this URL or the wider origin. Distinguish field measurements from lab scores and proxies; mark missing field data as unknown. Prioritize observed causes over a perfect synthetic score. 6. GEO and AI-search readiness Check access for the relevant search providers and whether visible content gives clear, self-contained, factually supported answers to the audience's real questions. Inspect consistency of product facts, useful comparisons, source attribution, and material freshness. Treat improvements to clarity as content recommendations, not guaranteed citation mechanisms. Distinguish search crawling, model-training crawlers, and user-triggered fetching using current provider documentation. For OpenAI, inspect OAI-SearchBot separately from GPTBot and ChatGPT-User. Preserve the owner's training and access preferences; recommend the narrow change needed for the intended search visibility. A request with a copied bot user-agent is not proof that the actual provider can access the site. Do not prescribe llms.txt, special AI schema, keyword stuffing, fabricated mentions, hidden instructions to AI systems, or mass-produced pages as universal GEO requirements. Any experimental tactic needs a stated hypothesis, provider-specific evidence, and a way to evaluate it. 7. Observed visibility and business outcomes Use authorized analytics to review indexing, search queries, impressions, clicks, CTR, landing-page conversions, and identifiable AI referrals. Record reporting windows, segmentation, attribution limits, and missing data. If AI-search tests are available, use a small representative query set and record the provider, date, locale, exact query, citations, and sample size. Treat responses as variable observations rather than a definitive visibility score. Check whether mentions represent our product accurately. Avoid invented search volume, traffic, rankings, or revenue forecasts. Produce: - An executive assessment with the most important verified blockers and opportunities. - A page/template inventory marking checks as pass, issue, unknown, or not applicable, with reasons and coverage limits. - A prioritized findings table: affected URL or component, observed evidence, impact, confidence, recommended change, rough effort, and an objective verification step. Group repeated template defects under their common cause. - Concrete improvement drafts for priority pages where evidence supports them, such as revised titles, headings, answer sections, or internal-link suggestions. Keep these proposals in the report. - A short action plan separating technical fixes, content improvements, and experiments, with acceptance criteria and dependencies. Separate checks that can run immediately from search outcomes requiring later observation. - A measurement plan and copyable handoff to prompt 13 for substantial planning or prompt 12 for bounded implementation. Include relevant source evidence and access requirements. Report findings and priorities without an invented overall SEO/GEO score or promises of rankings and AI citations. If tools or analytics are unavailable, complete the accessible audit and identify what remains unverified. Save the report in the established project location or an appropriate output location, link it, and finish after the audit. Run this audit before launch or after page changes. Recheck the pages after fixes, then track search results over the reporting period you chose. For the technical checks, I used Google's AI-search guidance and structured-data policies, OpenAI's crawler documentation, and the Web Vitals guide to field and lab measurements. Optional modifiers Append a modifier to change the task's permissions or add a review step. Report only For this run, inspect and verify without editing repository files or making remote writes. Use disposable scratch data if needed. Rank the findings and include evidence, proposed fixes, and checks. Deliver a draft PR You may push the task branch to the configured repository and open or update a draft PR for these changes. Use the repository template and describe the final scope and checks. This permission excludes merging and deployment. Independent review with a subagent If subagents are available, use one independent reviewer for the final diff and verification evidence. Give it the requirements, acceptance criteria, and changed scope; ask it to look for concrete defects and missing checks. Keep the reviewer read-only, resolve material findings, and verify changes made in response. Verify the combined result yourself. State if you could not obtain an independent review. Resume after an interruption Reconcile the current branch, diff, and prior task evidence before continuing. Preserve completed work. Identify the remaining acceptance criteria and resume there. Repeat checks only if the code, environment, or validity of prior evidence has changed. If an external blocker stops the task, leave a continuation note with the remaining work and the dependency you need resolved. Use the pack as a skill The repository includes installation instructions for Codex and Claude Code. Install Astra Workflows once, then name the workflow and describe the task. For example, ask it to plan a feature or audit a website. The skill loads the shared instructions and the workflow you select. It uses the model and tools available in your agent setup. Installing it does not switch models or authorize closures, merges, or deployments. Your request and existing conversation determine those permissions. Start with a planning or report-only task to check whether the workflow fits your project. Give the agent a bounded implementation task when you are ready to make changes. A note on personal tooling I use Bun 1.4.1 for JavaScript and TypeScript projects. Keep an existing repository's package manager unless you want to migrate it. Pin the version in local tooling and CI; decide on runtime and test-runner migrations as separate changes. I use Ponytail to keep coding solutions small and Stop Slop to edit prose. Add either skill to your instructions if you have it installed. The full pack and skill are in AI Coding Prompts on GitHub. I write about building software in Build notes at 0xmassi.dev. Subscribe for more.