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 comp