15 AI Coding Prompts for Codex and Claude Code

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.

Comments

[infracore]

Prompt 3 is the sleeper in this pack. The line about introducing a representative fault in a disposable environment and confirming the gate catches it is the part most agent-setup docs skip - an unverified check is just a comment that runs.

One addition for prompt 1 (slop audit) and prompt 5 (scoped merges): when the agent's edits can touch a public contract, keep the contract check deterministic and outside the model. "Trace usage before deleting" works fine inside one repo, but a removed response field or a newly-required param is invisible to a local reference search - the callers aren't in your tree.

Cheap version: commit the generated openapi.json and diff it in CI on every PR, classifying changes into typed classes (endpoint_removed, required_field_added, enum_value_removed, type_changed) rather than eyeballing the diff. We published a run of that against cal.com's v2 spec - 321 changes, 314 of them breaking, while info.version sat unchanged at 1.0.0: delimit.ai/reports/cal-com-v2-attestation. Version strings lie; the diff doesn't.

Have you found a prompt phrasing that reliably gets the agent to report a contract change instead of silently absorbing it?