Templates
Copy-ready prompts and checklists
Use these templates to give AI builders enough context to make useful changes safely.
Beginner Codex /goal Prompt Template
What it is for: Use this to turn a rough build idea into a scoped Codex request that asks for inspection, implementation, verification, and a clear handoff.
When to use it: Use it before any first build, especially when you are asking Codex to touch a repo, WordPress package, static site, or generated Academy asset.
Beginner note: Fill every bracket. If you do not know a value, say so explicitly so Codex can inspect rather than guess.
/goal Build [specific page/tool/workflow] for [audience] inside [site/repo/platform].
Context:
- Brand/site: Kingy AI or [brand].
- Current target: [URL, local folder, WordPress page, plugin, or file].
- User problem: [what the visitor needs to accomplish].
- Version one scope: [smallest useful result].
- Must include: [inputs, outputs, CTA, FAQ, internal links, metadata, copy/download/reset behavior].
- Must not change: [files, routes, theme areas, production settings, database records].
- Safety rules: no secrets, no private customer data, no unsupported claims, no live destructive actions.
Work plan:
1. Inspect the current structure and existing styles before editing.
2. Implement the smallest useful version using existing patterns.
3. Add validation, empty states, mobile behavior, and beginner-friendly copy.
4. Run relevant checks and report exact commands/results.
5. Summarize files changed, known limitations, rollback notes, and the best next prompt.Do not ask for broad rewrites, production database changes, secrets, account actions, or live WordPress edits until staging and rollback are ready.
WordPress Tool Build Prompt
What it is for: Use this when building a deterministic HTML/CSS/JS tool for a WordPress page, shortcode, block pattern, or small plugin.
When to use it: Use it after you know the tool inputs, output logic, embed path, and whether email capture or downloads are involved.
Beginner note: For Kingy AI staging, prefer shortcode or portable plugin paths unless the inspected live theme proves a child-template path is safer.
/goal Build a WordPress-safe [tool name] for [page topic].
Inspect first:
- Current WordPress/theme/plugin structure or supplied static package.
- Existing Kingy AI/JNews typography, spacing, buttons, cards, and form styles.
- Available embed path: Custom HTML block, shortcode, block pattern, child-theme template, or portable plugin.
Tool requirements:
- Inputs: [list fields and validation].
- Logic: [plain-English rules or formula].
- Outputs: [copy-ready result, checklist, prompt, table, or plan].
- User actions: copy result, download markdown/text, reset form, print/save where useful.
- SEO content: intro, H1/H2s, FAQ, related tools, next lesson.
- Privacy: no API calls, no personal-data storage, local-only saves unless approved provider hook exists.
Deliver:
1. Scoped implementation.
2. WordPress embed instructions.
3. QA checklist for desktop, mobile, keyboard, cache, logged-out view, and empty states.
4. Rollback steps.Avoid editing parent themes directly. Scope CSS/JS to the Academy wrapper and test logged-in and logged-out views with cache/lazyload active.
Landing Page Build Prompt
What it is for: Use this to build a practical launch or lead-magnet page that avoids vague hype and unsupported proof.
When to use it: Use it when the audience, offer, CTA, proof points, and first version are clear enough to publish a small page.
Beginner note: If proof is weak, ask for example screenshots, a demo, a founder note, or a transparent 'version one' explanation.
/goal Build a launch landing page for [product/tool/offer].
Audience:
- Primary visitor:
- Problem they have:
- Desired action:
- Current proof available:
Sections:
1. Hero with clear H1, promise, short explanation, and primary CTA.
2. Problem and outcome.
3. How it works in 3-5 steps.
4. Feature/benefit sections with concrete examples.
5. Proof or transparent version-one note.
6. FAQ that answers real objections.
7. Final CTA and related Kingy AI internal links.
Constraints:
- Reuse existing styles/components.
- No fake proof, inflated claims, invented pricing, or stock-like filler copy.
- Add SEO title, meta description, schema suggestion, mobile QA, and rollback notes.
Verify:
- Links, form/CTA states, mobile hero, heading hierarchy, metadata, and local build checks.Do not invent testimonials, pricing, guarantees, customer logos, or product capabilities.
Calculator Build Prompt
What it is for: Use this when turning a spreadsheet-style decision, score, rate, estimate, or checklist into a browser calculator.
When to use it: Use it after you can explain the formula, assumptions, and at least three sample input/output cases.
Beginner note: A calculator is only as good as its assumptions. Put assumptions near the result so users can challenge them.
/goal Build a beginner-safe [calculator name].
Decision it helps with:
- Audience:
- Inputs:
- Formula or scoring rules:
- Assumptions:
- Output format:
- Sensitive-topic disclaimer:
Implementation:
- Use deterministic client-side logic.
- Validate empty, invalid, extreme, and realistic values.
- Show assumptions, result explanation, copy/download result, reset, and example calculation.
- Add intro copy, FAQ, SEO title, meta description, related Academy links, and QA checklist.
Test cases:
- Happy path:
- Empty input:
- Extreme value:
- Hand-calculated expected output:
Do not:
- Use hidden APIs.
- Store personal data.
- Present estimates as guaranteed outcomes.For money, legal, health, financial, or business-critical decisions, include disclaimers and require human/expert review.
Directory Build Prompt
What it is for: Use this to plan or build a curated resource, tool, vendor, project, or example directory.
When to use it: Use it before creating listings so the taxonomy, fields, filters, and update workflow are not improvised later.
Beginner note: Add a last-reviewed field and an inclusion policy. That turns a directory into an editorial product, not just cards.
/goal Build a structured directory for [niche].
Directory strategy:
- Audience:
- Jobs the directory helps with:
- Inclusion criteria:
- Exclusion criteria:
- Last-reviewed/update cadence:
Data model:
- Required fields: name, category, bestFor, useCase, caution, officialUrl, lastReviewed.
- Optional fields: pricingStatus, beginnerDifficulty, platform, integrations, notes.
- Filters:
- Empty states:
Deliver:
1. Directory page or data model using existing styles.
2. Example entries with cautious placeholders where facts need official-source review.
3. Filters/search/sort plan.
4. SEO title, meta description, FAQ, internal links.
5. QA checklist for filters, empty states, mobile cards, and stale-detail warnings.Do not publish stale pricing, unsupported rankings, fake reviews, or unverified product details.
Dashboard Build Prompt
What it is for: Use this to design a read-only dashboard or reporting view before connecting live data.
When to use it: Use it when you know the business question, metrics, viewers, and sample data shape.
Beginner note: Dashboards should support a decision. If no decision changes, reduce the metrics.
/goal Build a read-only [dashboard name] dashboard.
Decision to support:
- Viewer:
- Metrics:
- Metric definitions:
- Sample data fields:
- Filters:
- Empty/loading/error states:
- Refresh cadence:
Implementation:
- Use fake/sample data first.
- Show metric cards, table/list, filters, explanations, and source notes.
- Add mobile layout, accessible labels, and no write actions.
- Include a future data-connection checklist with privacy and permissions.
Verify:
- Empty data.
- Partial data.
- Filter combinations.
- Long labels.
- Mobile table/card layout.
- No secrets or production credentials.
- Beginner acceptance: every metric explains what it means, where the sample data came from, and what decision the viewer should make next.Start with fake or exported data. Do not connect production systems or write actions until permissions, privacy, and rollback are approved.
Database Tool Build Prompt
What it is for: Use this to plan a small database-backed tool, tracker, portal, or internal workflow.
When to use it: Use it before choosing Bubble, Softr, Replit, Retool, WordPress custom posts, or a real database.
Beginner note: Write the states and permissions before the UI. Most database bugs start with unclear record ownership.
/goal Plan and build version one of a [database tool].
Workflow:
- Audience:
- Records users create/view:
- Fields:
- Record states:
- User roles:
- Permissions:
- Search/filter needs:
- Export needs:
Safety:
- Fake data fixture required.
- No production database connection yet.
- Define retention, deletion, backup, and rollback expectations.
Deliver:
1. Data model.
2. Page/view structure.
3. Create/read/update/delete rules, with write actions disabled unless approved.
4. Validation and empty states.
5. QA checklist for permissions, fake records, mobile layout, exports, and rollback.
6. Beginner handoff explaining which platform fits the model and what evidence is required before real data is connected.Use fake data first. Do not import private customer data until access rules, retention, backups, and deletion paths are approved.
AI Agent Spec Prompt
What it is for: Use this to define an AI agent before building or granting it tool access.
When to use it: Use it for browser agents, research agents, workflow agents, sales/marketing agents, and internal assistant ideas.
Beginner note: A good agent spec says what the agent may not do as clearly as what it may do.
/goal Draft a safe AI agent spec for [task].
Agent purpose:
- User:
- Trigger:
- Inputs:
- Allowed sources/tools:
- Output:
- Success criteria:
Boundaries:
- Forbidden actions:
- Data the agent must not access:
- Human approval required before:
- Logging/evidence required:
- Escalation when confidence is low:
Test plan:
- Fake-data happy path.
- Missing data.
- Conflicting sources.
- Forbidden request.
- Low-confidence request.
Deliver:
1. Agent workflow diagram in text.
2. Approval checklist.
3. Safety checklist.
4. Implementation prompt.
5. Launch/testing checklist.
6. Beginner handoff that names the first safe no-action prototype and the exact review needed before granting tool access.Agents should prepare work first. Require human approval before emails, payments, database writes, account changes, publishing, or customer-facing actions.
AI Automation Spec Prompt
What it is for: Use this to plan a Zapier/Make/workflow automation before connecting real accounts.
When to use it: Use it when a repetitive workflow has clear triggers, actions, filters, and owners.
Beginner note: If rollback is not obvious, the automation is not ready to run unattended.
/goal Create a safe automation spec for [workflow].
Workflow map:
- Trigger:
- Source app:
- Actions:
- Destination app:
- Filters:
- Required fields:
- Owner:
- Failure notification:
Safety:
- Use fake/test records first.
- Human approval before [external emails/payments/deletions/account updates].
- Log every run and keep task history.
- Define rollback: how to undo or correct a bad run.
Deliver:
1. Trigger/action diagram.
2. Test data.
3. Approval gates.
4. Error handling.
5. Launch checklist for staged rollout and monitoring.
6. Beginner handoff that explains how to run the automation manually once before enabling it, then how to pause it if the first live run fails.Do not automate external messages, payments, deletions, CRM updates, or account actions without a human approval step and test records.
Course Page Prompt
What it is for: Use this to create a course hub, lesson path, or mini-course page with a practical learner outcome.
When to use it: Use it when you know the audience, transformation, modules, project, and supporting templates.
Beginner note: A strong course page sells the outcome and shows the path. The lessons can expand later.
/goal Build a course page for [course topic].
Course strategy:
- Audience:
- Starting point:
- Desired outcome:
- Final project:
- Course length:
- Lesson style:
- Templates/downloads:
Page sections:
1. Hero promise.
2. Who it is for.
3. What learners will build.
4. Module list with lesson outcomes.
5. Project/templates section.
6. Safety/requirements.
7. FAQ.
8. CTA to start or generate a build plan.
Deliver SEO metadata, internal links, schema suggestion, mobile QA, and a next-phase lesson expansion plan.
Beginner acceptance: each module should have one learner action, one artifact, and one way to know the lesson worked.Do not promise mastery or outcomes the course cannot prove. Keep version one focused on a concrete result.
SEO Tool Prompt
What it is for: Use this to build an SEO helper such as a brief generator, FAQ generator, title/meta tool, or internal-link planner.
When to use it: Use it when the search intent, audience, page type, and editorial review process are clear.
Beginner note: The output should help a human editor make decisions, not publish blindly.
/goal Build an SEO helper for [page type/topic].
Inputs:
- Audience:
- Search intent:
- Page type:
- Primary topic:
- Existing internal links:
- Proof/source requirements:
- CTA:
Outputs:
- SEO title options.
- Meta description.
- H1/H2 outline.
- FAQ.
- Internal-link suggestions.
- Schema suggestion.
- Editorial review notes.
Safety:
- No fake stats, product specs, prices, or claims.
- Include official-source/freshness reminders where needed.
- Add visible FAQ text if schema is suggested.
Verify metadata length, heading hierarchy, internal links, and no keyword stuffing.
Beginner acceptance: output should be ready for an editor to review, not ready for blind publishing. Include what still needs source checking.Avoid keyword stuffing, fake freshness, unsupported claims, hidden schema, and invented product details.
YouTube Tool Prompt
What it is for: Use this to create a video companion tool, script planner, prompt generator, or pinned-comment CTA.
When to use it: Use it when a video should lead viewers into a practical next action on Kingy AI.
Beginner note: The tool should help viewers apply the video, not merely summarize it.
/goal Build a YouTube companion tool for .
Video context:
- Audience:
- Viewer problem:
- Video promise:
- CTA:
- Tool result viewers should leave with:
Tool sections:
1. Intro tied to the video.
2. Guided inputs.
3. Useful output: prompt, checklist, plan, title ideas, scenes, or launch steps.
4. Copy/download actions.
5. Pinned comment and description starter.
6. Related Academy links.
Deliver:
- Deterministic generator.
- SEO title/meta.
- FAQ.
- Mobile QA.
- Safety note for unsupported claims or sensitive use cases.
- Beginner acceptance: the result should give the viewer something to copy into a video plan plus one clear Academy CTA.Do not write misleading hooks, fake results, or prompts that imply unsupported product capabilities.
AGENTS.md Template
What it is for: Use this to create repo instructions that make future Codex sessions safer and more consistent.
When to use it: Use it before asking AI to make repeated changes in a repo, plugin, app, static site, or WordPress package.
Beginner note: Keep AGENTS.md short enough to be followed, but specific enough to prevent accidental broad edits.
# AGENTS.md
## Project
- Name:
- Purpose:
- Primary audience:
- Important routes or artifacts:
## How to Work
- Inspect before editing.
- Keep changes scoped.
- Reuse existing patterns.
- Do not remove existing content unless explicitly asked.
- Do not edit protected files/folders:
## Coding Standards
- Framework/stack:
- Style conventions:
- Accessibility expectations:
- Content/SEO conventions:
## Safety
- Never commit secrets, API keys, private data, production exports, or credentials.
- Avoid destructive commands unless explicitly approved.
- Use fake data for prototypes.
## Verification
- Required commands:
- Manual QA:
- Browser/mobile checks:
- Deployment notes:
## Final Response
- Summarize changes.
- List tests run.
- Note limitations and rollback path.Do not include secrets. Be explicit about destructive commands, protected files, and required tests.
QA Checklist Template
What it is for: Use this before publishing an AI-built page, tool, article, dashboard, calculator, or WordPress import.
When to use it: Use it after the first working version exists and before staging or production approval.
Beginner note: Copy this into a ticket, PR, staging evidence log, or launch checklist.
QA Checklist for [project/page/tool]
Functional:
- Happy path works.
- Empty input state works.
- Invalid input state works.
- Edge case works.
- Copy/download/reset/print actions work.
- Links and CTAs work.
Content and SEO:
- H1/title/meta match intent.
- FAQ is visible and accurate.
- Internal links are relevant.
- Schema does not duplicate existing theme/plugin output.
Accessibility and mobile:
- Labels match inputs.
- Keyboard path works.
- Status/error messages are announced.
- Mobile layout has no overlap.
- Contrast is readable.
Privacy and safety:
- No secrets or private data.
- Consent is explicit if email is involved.
- Sensitive claims require review.
Rollback:
- Changed files/pages listed.
- How to revert is documented.A page loading once is not QA. Test empty states, edge cases, mobile, forms, links, metadata, and rollback.
Launch Checklist Template
What it is for: Use this to move from a working prototype to a small public version.
When to use it: Use it after QA is complete and before publishing, promoting, or announcing a page/tool.
Beginner note: For WordPress, run it on staging first. For Vercel/static apps, use a preview or local build first.
Launch Checklist for [project]
Scope:
- Version one audience:
- Core job:
- Primary CTA:
- Deferred version two items:
Preflight:
- Build/release command passed:
- QA checklist passed:
- Metadata reviewed:
- Downloads/forms tested:
- Privacy copy approved:
- Analytics/logging reviewed:
Platform:
- WordPress staging or preview URL:
- Template/plugin/shortcode path:
- Cache/lazyload checked:
- Logged-out view checked:
Rollback:
- Backup/restore point:
- Pages/files/plugins/redirects changed:
- Owner:
- Exact rollback steps:
Publish:
- Publish smallest useful version.
- Monitor logs, forms, analytics, and user feedback.
- Record known limitations and next prompt.
- First-hour check: open the public page in a private window, run the main workflow, test every download/form, and keep rollback steps visible.Do not launch until rollback, privacy, forms, downloads, and owner approvals are clear.
Human Approval Checklist
What it is for: Use this for agents, automations, email capture, publishing, database writes, payments, and sensitive claims.
When to use it: Use it whenever AI prepares work that could affect users, accounts, money, reputation, private data, or production systems.
Beginner note: Name the approver, not just the approval type. Anonymous approval is weak evidence.
Human Approval Checklist for [workflow/action]
Action:
- What will happen:
- System/account affected:
- User/customer impact:
- Reversible? yes/no:
AI-prepared output:
- Summary:
- Source/evidence:
- Uncertainty:
- Known risks:
- Forbidden actions checked:
Approver:
- Name/role:
- Approval timestamp:
- What was reviewed:
- Conditions or changes required:
Before execution:
- Test/fake-data run complete.
- Rollback steps documented.
- Notification/monitoring ready.
- Private data minimized.
- Legal/financial/health/customer claims reviewed where relevant.
Decision:
- Approved / rejected / needs changes:
- Reason:
- Evidence file or screenshot:
- Next review date if approval is temporary or conditional:AI can prepare the work. A human should approve external actions and irreversible changes.
Data Privacy Checklist
What it is for: Use this before collecting emails, connecting databases, using customer data, or sending data to AI tools.
When to use it: Use it during planning, before staging, and again before production launch.
Beginner note: The safest first version usually uses fake data, local storage, or optional consent-based capture.
Data Privacy Checklist for [project]
Data inventory:
- Data collected:
- Data generated:
- Data stored:
- Data sent to third parties:
- Sensitive fields:
Minimization:
- What can be removed:
- Fake/sample data available:
- Local-only option:
- Retention period:
- Deletion path:
Consent and notice:
- Consent copy:
- Privacy policy URL:
- Unsubscribe path:
- Provider/list/form approved:
Security:
- No secrets in client code.
- No API keys committed.
- Access roles defined.
- Backups/exports protected.
Approval:
- Privacy owner:
- Evidence file:
- Status: approved / needs changes / blocked.
- Production note: do not connect provider, database, or analytics destinations until this checklist has an owner and evidence path.Do not paste secrets, passwords, API keys, private customer data, production exports, or sensitive files into AI tools without approval.
Bug Report Prompt
What it is for: Use this to ask Codex to reproduce, diagnose, and fix a concrete bug without wandering into unrelated refactors.
When to use it: Use it when you can describe expected behavior, actual behavior, steps to reproduce, and affected environment.
Beginner note: Good bug reports include evidence: screenshots, console output, command output, input values, or exact URL.
/goal Fix this bug in [project/page/tool].
Expected behavior:
-
Actual behavior:
-
Steps to reproduce:
1.
2.
3.
Evidence:
- URL/file:
- Console/log output:
- Input values:
- Screenshot/video:
Constraints:
- Inspect current implementation first.
- Keep the fix scoped.
- Do not refactor unrelated files.
- Preserve existing working behavior.
- Add or update a focused verifier if useful.
Verification:
- Reproduce before fixing if possible.
- Run relevant tests.
- Test the original repro steps.
- Report changed files, commands, result, and residual risk.
- Confirm the fix does not introduce unrelated visual, routing, data, or copy changes.Do not ask for a rewrite when a narrow bug fix is enough. Preserve working behavior.
Improve Existing Page Prompt
What it is for: Use this to make a page clearer, more useful, more SEO-friendly, or more conversion-ready without rebuilding it from scratch.
When to use it: Use it after a page exists but needs stronger copy, structure, internal links, FAQ, metadata, or mobile polish.
Beginner note: Ask for one improvement pass at a time. Big redesign prompts often create avoidable regressions.
/goal Improve the existing [page/tool/article] at [path].
Current problem:
-
Audience:
-
Primary action:
-
What must stay:
- URL:
- Existing sections:
- Brand/style:
- Functional behavior:
Improve:
- Clearer H1/intro.
- Better section order.
- Stronger CTA.
- FAQ and internal links.
- SEO title/meta.
- Mobile readability.
- Accessibility labels/status text.
Do not:
- Change unrelated pages.
- Invent proof, pricing, or specs.
- Remove rollback path.
- Preserve existing working behavior unless the requested improvement explicitly changes it.
Verify:
- Link checks.
- Mobile layout.
- Metadata.
- Existing workflow still works.
- Summary of before/after changes.Do not remove existing content or brand signals unless asked. Preserve URLs, CTAs, and working behavior.
Add Feature Prompt
What it is for: Use this when adding one specific feature to a working page or tool.
When to use it: Use it after the current behavior is stable and the new feature can be scoped, tested, and rolled back.
Beginner note: Define the acceptance test before asking for the feature. Otherwise the feature keeps growing.
/goal Add [feature] to [existing page/tool].
Current behavior:
-
New user need:
-
Feature scope:
- Inputs:
- Outputs:
- UI location:
- Empty/error states:
- Copy/download/save behavior:
Constraints:
- Preserve existing behavior and URLs.
- Reuse existing components/styles.
- No new dependencies unless necessary.
- No personal-data collection unless approved.
- Keep rollback simple.
Acceptance tests:
1.
2.
3.
Deliver:
- Implementation.
- Focused tests/verifier updates if useful.
- Manual QA notes.
- Files changed.
- Rollback notes.
- One feature only: if another improvement appears, list it as a follow-up instead of bundling it into this change.One feature at a time. Do not bundle redesigns, refactors, new providers, and data changes into the same request.
Refactor Safely Prompt
What it is for: Use this to clean up code, data, templates, or generated assets without changing user-facing behavior.
When to use it: Use it when duplication, fragile code, or generator drift makes future work riskier.
Beginner note: Require before/after verification so the cleanup proves it did not break the package.
/goal Refactor [area] safely.
Reason:
-
Current risk:
-
Behavior that must stay unchanged:
- Routes:
- Shortcodes/components:
- Data shape:
- Visual output:
- Public APIs:
Refactor constraints:
- Keep scope narrow.
- Follow existing patterns.
- Do not alter unrelated content.
- Preserve generated artifact contracts.
- Add comments only where helpful.
Verification:
- Run existing tests before/after when feasible.
- Add a focused verifier if this prevents future drift.
- Compare generated counts/manifests.
- Report changed files, behavior preserved, and any residual risk.
- Beginner acceptance: explain why the refactor is safer for future edits and how to confirm public behavior stayed the same.A refactor is not an excuse to redesign. Behavior should stay the same unless the requested change says otherwise.
