Are these shortcodes WordPress shortcodes?

No. WEB-001 through WEB-120 are searchable reference IDs for prompt templates. They do not execute WordPress code.

Can I use these prompts with ChatGPT or other AI assistants?

Yes. Replace placeholders with your own non-sensitive project details, then review and test every response before deployment.

Will copied code automatically be production-ready?

No. Validate security, accessibility, supported versions, browser behavior and project requirements in staging.

How do I use search in a Kadence HTML block?

Paste the HTML snippet into a Custom HTML block. If WordPress removes script tags, enqueue the separate JavaScript once using an approved site-code method.

Do I need all 120 prompts for one project?

No. Search by topic, choose the prompt matching your task, and combine outputs into a verified project workflow.

Web Developer & AI-Assisted Development Specialist

WEB-001 · Discovery & Architecture

Requirements interview

Use when working on requirements interview for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a junior developer complete this specific task: Requirements interview.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on requirements interview within discovery & architecture, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. Requirements interview solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

WEB-002 · Discovery & Architecture

Audience and user journeys

Use when working on audience and user journeys for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a freelance developer complete this specific task: Audience and user journeys.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on audience and user journeys within discovery & architecture, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. Audience and user journeys solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

WEB-003 · Discovery & Architecture

Functional specification

Use when working on functional specification for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a product engineering team complete this specific task: Functional specification.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on functional specification within discovery & architecture, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. Functional specification solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

WEB-004 · Discovery & Architecture

Nonfunctional requirements

Use when working on nonfunctional requirements for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a WordPress developer complete this specific task: Nonfunctional requirements.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on nonfunctional requirements within discovery & architecture, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. Nonfunctional requirements solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

WEB-005 · Discovery & Architecture

Site map

Use when working on site map for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a junior developer complete this specific task: Site map.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on site map within discovery & architecture, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. Site map solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

WEB-006 · Discovery & Architecture

Component architecture

Use when working on component architecture for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a freelance developer complete this specific task: Component architecture.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on component architecture within discovery & architecture, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. Component architecture solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

WEB-007 · Discovery & Architecture

Technology selection

Use when working on technology selection for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a product engineering team complete this specific task: Technology selection.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on technology selection within discovery & architecture, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. Technology selection solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

WEB-008 · Discovery & Architecture

Data model draft

Use when working on data model draft for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a WordPress developer complete this specific task: Data model draft.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on data model draft within discovery & architecture, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. Data model draft solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

WEB-009 · Discovery & Architecture

Acceptance criteria

Use when working on acceptance criteria for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a junior developer complete this specific task: Acceptance criteria.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on acceptance criteria within discovery & architecture, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. Acceptance criteria solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

WEB-010 · Discovery & Architecture

MVP roadmap

Use when working on mvp roadmap for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a freelance developer complete this specific task: MVP roadmap.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on mvp roadmap within discovery & architecture, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. MVP roadmap solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

WEB-011 · HTML & Semantic Structure

Accessible page skeleton

Use when working on accessible page skeleton for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a junior developer complete this specific task: Accessible page skeleton.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on accessible page skeleton within html & semantic structure, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. Accessible page skeleton solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

WEB-012 · HTML & Semantic Structure

Navigation landmarks

Use when working on navigation landmarks for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a freelance developer complete this specific task: Navigation landmarks.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on navigation landmarks within html & semantic structure, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. Navigation landmarks solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

WEB-013 · HTML & Semantic Structure

Article structure

Use when working on article structure for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a product engineering team complete this specific task: Article structure.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on article structure within html & semantic structure, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. Article structure solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

WEB-014 · HTML & Semantic Structure

Product detail markup

Use when working on product detail markup for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a WordPress developer complete this specific task: Product detail markup.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on product detail markup within html & semantic structure, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. Product detail markup solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

WEB-015 · HTML & Semantic Structure

Contact form markup

Use when working on contact form markup for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a junior developer complete this specific task: Contact form markup.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on contact form markup within html & semantic structure, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. Contact form markup solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

WEB-016 · HTML & Semantic Structure

Responsive image markup

Use when working on responsive image markup for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a freelance developer complete this specific task: Responsive image markup.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on responsive image markup within html & semantic structure, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. Responsive image markup solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

WEB-017 · HTML & Semantic Structure

Table semantics

Use when working on table semantics for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a product engineering team complete this specific task: Table semantics.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on table semantics within html & semantic structure, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. Table semantics solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

WEB-018 · HTML & Semantic Structure

Metadata audit

Use when working on metadata audit for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a WordPress developer complete this specific task: Metadata audit.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on metadata audit within html & semantic structure, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. Metadata audit solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

WEB-019 · HTML & Semantic Structure

Structured content outline

Use when working on structured content outline for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a junior developer complete this specific task: Structured content outline.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on structured content outline within html & semantic structure, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. Structured content outline solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

WEB-020 · HTML & Semantic Structure

HTML validation checklist

Use when working on html validation checklist for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a freelance developer complete this specific task: HTML validation checklist.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on html validation checklist within html & semantic structure, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. HTML validation checklist solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

WEB-021 · CSS & Responsive Design

Design tokens

Use when working on design tokens for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a junior developer complete this specific task: Design tokens.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on design tokens within css & responsive design, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. Design tokens solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

WEB-022 · CSS & Responsive Design

Mobile-first layout

Use when working on mobile-first layout for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a freelance developer complete this specific task: Mobile-first layout.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on mobile-first layout within css & responsive design, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. Mobile-first layout solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

WEB-023 · CSS & Responsive Design

Fluid typography

Use when working on fluid typography for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a product engineering team complete this specific task: Fluid typography.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on fluid typography within css & responsive design, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. Fluid typography solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

WEB-024 · CSS & Responsive Design

Responsive grid

Use when working on responsive grid for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a WordPress developer complete this specific task: Responsive grid.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on responsive grid within css & responsive design, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. Responsive grid solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

WEB-025 · CSS & Responsive Design

Navigation states

Use when working on navigation states for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a junior developer complete this specific task: Navigation states.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on navigation states within css & responsive design, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. Navigation states solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

WEB-026 · CSS & Responsive Design

Form styling

Use when working on form styling for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a freelance developer complete this specific task: Form styling.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on form styling within css & responsive design, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. Form styling solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

WEB-027 · CSS & Responsive Design

Dark mode

Use when working on dark mode for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a product engineering team complete this specific task: Dark mode.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on dark mode within css & responsive design, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. Dark mode solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

WEB-028 · CSS & Responsive Design

Container queries

Use when working on container queries for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a WordPress developer complete this specific task: Container queries.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on container queries within css & responsive design, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. Container queries solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

WEB-029 · CSS & Responsive Design

Print stylesheet

Use when working on print stylesheet for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a junior developer complete this specific task: Print stylesheet.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on print stylesheet within css & responsive design, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. Print stylesheet solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

WEB-030 · CSS & Responsive Design

Visual regression checklist

Use when working on visual regression checklist for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a freelance developer complete this specific task: Visual regression checklist.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on visual regression checklist within css & responsive design, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. Visual regression checklist solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

WEB-031 · JavaScript & TypeScript

Input validation

Use when working on input validation for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a junior developer complete this specific task: Input validation.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on input validation within javascript & typescript, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. Input validation solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

WEB-032 · JavaScript & TypeScript

Debounced search

Use when working on debounced search for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a freelance developer complete this specific task: Debounced search.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on debounced search within javascript & typescript, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. Debounced search solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

WEB-033 · JavaScript & TypeScript

State management

Use when working on state management for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a product engineering team complete this specific task: State management.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on state management within javascript & typescript, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. State management solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

WEB-034 · JavaScript & TypeScript

Fetch and error states

Use when working on fetch and error states for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a WordPress developer complete this specific task: Fetch and error states.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on fetch and error states within javascript & typescript, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. Fetch and error states solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

WEB-035 · JavaScript & TypeScript

DOM event delegation

Use when working on dom event delegation for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a junior developer complete this specific task: DOM event delegation.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on dom event delegation within javascript & typescript, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. DOM event delegation solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

WEB-036 · JavaScript & TypeScript

Async data flow

Use when working on async data flow for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a freelance developer complete this specific task: Async data flow.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on async data flow within javascript & typescript, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. Async data flow solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

WEB-037 · JavaScript & TypeScript

TypeScript interfaces

Use when working on typescript interfaces for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a product engineering team complete this specific task: TypeScript interfaces.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on typescript interfaces within javascript & typescript, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. TypeScript interfaces solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

WEB-038 · JavaScript & TypeScript

Array transformation

Use when working on array transformation for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a WordPress developer complete this specific task: Array transformation.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on array transformation within javascript & typescript, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. Array transformation solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

WEB-039 · JavaScript & TypeScript

Date and timezone handling

Use when working on date and timezone handling for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a junior developer complete this specific task: Date and timezone handling.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on date and timezone handling within javascript & typescript, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. Date and timezone handling solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

WEB-040 · JavaScript & TypeScript

Unit-test plan

Use when working on unit-test plan for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a freelance developer complete this specific task: Unit-test plan.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on unit-test plan within javascript & typescript, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. Unit-test plan solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

WEB-041 · React & Frontend Frameworks

Component decomposition

Use when working on component decomposition for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a junior developer complete this specific task: Component decomposition.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on component decomposition within react & frontend frameworks, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. Component decomposition solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

WEB-042 · React & Frontend Frameworks

Custom hook design

Use when working on custom hook design for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a freelance developer complete this specific task: Custom hook design.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on custom hook design within react & frontend frameworks, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. Custom hook design solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

WEB-043 · React & Frontend Frameworks

Accessible modal

Use when working on accessible modal for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a product engineering team complete this specific task: Accessible modal.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on accessible modal within react & frontend frameworks, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. Accessible modal solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

WEB-044 · React & Frontend Frameworks

Searchable table

Use when working on searchable table for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a WordPress developer complete this specific task: Searchable table.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on searchable table within react & frontend frameworks, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. Searchable table solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

WEB-045 · React & Frontend Frameworks

Form state

Use when working on form state for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a junior developer complete this specific task: Form state.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on form state within react & frontend frameworks, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. Form state solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

WEB-046 · React & Frontend Frameworks

Loading and error boundary

Use when working on loading and error boundary for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a freelance developer complete this specific task: Loading and error boundary.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on loading and error boundary within react & frontend frameworks, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. Loading and error boundary solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

WEB-047 · React & Frontend Frameworks

Client/server rendering decision

Use when working on client/server rendering decision for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a product engineering team complete this specific task: Client/server rendering decision.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on client/server rendering decision within react & frontend frameworks, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. Client/server rendering decision solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

WEB-048 · React & Frontend Frameworks

Routing design

Use when working on routing design for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a WordPress developer complete this specific task: Routing design.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on routing design within react & frontend frameworks, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. Routing design solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

WEB-049 · React & Frontend Frameworks

Performance profiling

Use when working on performance profiling for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a junior developer complete this specific task: Performance profiling.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on performance profiling within react & frontend frameworks, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. Performance profiling solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

WEB-050 · React & Frontend Frameworks

Component testing

Use when working on component testing for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a freelance developer complete this specific task: Component testing.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on component testing within react & frontend frameworks, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. Component testing solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

WEB-051 · APIs & Backend

REST resource design

Use when working on rest resource design for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a junior developer complete this specific task: REST resource design.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on rest resource design within apis & backend, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. REST resource design solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

WEB-052 · APIs & Backend

API contract

Use when working on api contract for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a freelance developer complete this specific task: API contract.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on api contract within apis & backend, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. API contract solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

WEB-053 · APIs & Backend

Authentication flow

Use when working on authentication flow for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a product engineering team complete this specific task: Authentication flow.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on authentication flow within apis & backend, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. Authentication flow solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

WEB-054 · APIs & Backend

Authorization matrix

Use when working on authorization matrix for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a WordPress developer complete this specific task: Authorization matrix.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on authorization matrix within apis & backend, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. Authorization matrix solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

WEB-055 · APIs & Backend

Pagination and filters

Use when working on pagination and filters for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a junior developer complete this specific task: Pagination and filters.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on pagination and filters within apis & backend, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. Pagination and filters solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

WEB-056 · APIs & Backend

Webhook receiver

Use when working on webhook receiver for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a freelance developer complete this specific task: Webhook receiver.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on webhook receiver within apis & backend, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. Webhook receiver solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

WEB-057 · APIs & Backend

Idempotency handling

Use when working on idempotency handling for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a product engineering team complete this specific task: Idempotency handling.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on idempotency handling within apis & backend, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. Idempotency handling solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

WEB-058 · APIs & Backend

Background job plan

Use when working on background job plan for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a WordPress developer complete this specific task: Background job plan.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on background job plan within apis & backend, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. Background job plan solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

WEB-059 · APIs & Backend

Database query review

Use when working on database query review for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a junior developer complete this specific task: Database query review.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on database query review within apis & backend, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. Database query review solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

WEB-060 · APIs & Backend

API integration tests

Use when working on api integration tests for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a freelance developer complete this specific task: API integration tests.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on api integration tests within apis & backend, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. API integration tests solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

WEB-061 · WordPress & Kadence

Theme compatibility review

Use when working on theme compatibility review for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a junior developer complete this specific task: Theme compatibility review.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on theme compatibility review within wordpress & kadence, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. Theme compatibility review solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

WEB-062 · WordPress & Kadence

Kadence page layout

Use when working on kadence page layout for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a freelance developer complete this specific task: Kadence page layout.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on kadence page layout within wordpress & kadence, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. Kadence page layout solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

WEB-063 · WordPress & Kadence

Custom HTML embed

Use when working on custom html embed for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a product engineering team complete this specific task: Custom HTML embed.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on custom html embed within wordpress & kadence, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. Custom HTML embed solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

WEB-064 · WordPress & Kadence

Scoped CSS strategy

Use when working on scoped css strategy for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a WordPress developer complete this specific task: Scoped CSS strategy.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on scoped css strategy within wordpress & kadence, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. Scoped CSS strategy solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

WEB-065 · WordPress & Kadence

Script enqueue plan

Use when working on script enqueue plan for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a junior developer complete this specific task: Script enqueue plan.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on script enqueue plan within wordpress & kadence, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. Script enqueue plan solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

WEB-066 · WordPress & Kadence

Custom post type design

Use when working on custom post type design for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a freelance developer complete this specific task: Custom post type design.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on custom post type design within wordpress & kadence, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. Custom post type design solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

WEB-067 · WordPress & Kadence

Block pattern blueprint

Use when working on block pattern blueprint for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a product engineering team complete this specific task: Block pattern blueprint.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on block pattern blueprint within wordpress & kadence, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. Block pattern blueprint solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

WEB-068 · WordPress & Kadence

Plugin conflict debugging

Use when working on plugin conflict debugging for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a WordPress developer complete this specific task: Plugin conflict debugging.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on plugin conflict debugging within wordpress & kadence, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. Plugin conflict debugging solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

WEB-069 · WordPress & Kadence

WooCommerce customization plan

Use when working on woocommerce customization plan for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a junior developer complete this specific task: WooCommerce customization plan.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on woocommerce customization plan within wordpress & kadence, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. WooCommerce customization plan solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

WEB-070 · WordPress & Kadence

WordPress release checklist

Use when working on wordpress release checklist for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a freelance developer complete this specific task: WordPress release checklist.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on wordpress release checklist within wordpress & kadence, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. WordPress release checklist solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

WEB-071 · Testing & Debugging

Reproduction steps

Use when working on reproduction steps for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a junior developer complete this specific task: Reproduction steps.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on reproduction steps within testing & debugging, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. Reproduction steps solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

WEB-072 · Testing & Debugging

Console error diagnosis

Use when working on console error diagnosis for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a freelance developer complete this specific task: Console error diagnosis.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on console error diagnosis within testing & debugging, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. Console error diagnosis solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

WEB-073 · Testing & Debugging

Network request diagnosis

Use when working on network request diagnosis for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a product engineering team complete this specific task: Network request diagnosis.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on network request diagnosis within testing & debugging, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. Network request diagnosis solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

WEB-074 · Testing & Debugging

Cross-browser test matrix

Use when working on cross-browser test matrix for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a WordPress developer complete this specific task: Cross-browser test matrix.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on cross-browser test matrix within testing & debugging, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. Cross-browser test matrix solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

WEB-075 · Testing & Debugging

Mobile viewport audit

Use when working on mobile viewport audit for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a junior developer complete this specific task: Mobile viewport audit.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on mobile viewport audit within testing & debugging, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. Mobile viewport audit solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

WEB-076 · Testing & Debugging

Regression test suite

Use when working on regression test suite for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a freelance developer complete this specific task: Regression test suite.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on regression test suite within testing & debugging, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. Regression test suite solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

WEB-077 · Testing & Debugging

Form edge cases

Use when working on form edge cases for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a product engineering team complete this specific task: Form edge cases.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on form edge cases within testing & debugging, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. Form edge cases solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

WEB-078 · Testing & Debugging

Accessibility test cases

Use when working on accessibility test cases for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a WordPress developer complete this specific task: Accessibility test cases.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on accessibility test cases within testing & debugging, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. Accessibility test cases solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

WEB-079 · Testing & Debugging

Mock data generation

Use when working on mock data generation for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a junior developer complete this specific task: Mock data generation.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on mock data generation within testing & debugging, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. Mock data generation solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

WEB-080 · Testing & Debugging

Bug triage report

Use when working on bug triage report for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a freelance developer complete this specific task: Bug triage report.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on bug triage report within testing & debugging, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. Bug triage report solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

WEB-081 · Performance & SEO

Core Web Vitals audit

Use when working on core web vitals audit for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a junior developer complete this specific task: Core Web Vitals audit.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on core web vitals audit within performance & seo, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. Core Web Vitals audit solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

WEB-082 · Performance & SEO

Image optimization plan

Use when working on image optimization plan for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a freelance developer complete this specific task: Image optimization plan.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on image optimization plan within performance & seo, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. Image optimization plan solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

WEB-083 · Performance & SEO

Code splitting plan

Use when working on code splitting plan for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a product engineering team complete this specific task: Code splitting plan.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on code splitting plan within performance & seo, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. Code splitting plan solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

WEB-084 · Performance & SEO

Caching policy

Use when working on caching policy for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a WordPress developer complete this specific task: Caching policy.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on caching policy within performance & seo, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. Caching policy solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

WEB-085 · Performance & SEO

Technical SEO checklist

Use when working on technical seo checklist for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a junior developer complete this specific task: Technical SEO checklist.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on technical seo checklist within performance & seo, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. Technical SEO checklist solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

WEB-086 · Performance & SEO

Canonical and redirects

Use when working on canonical and redirects for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a freelance developer complete this specific task: Canonical and redirects.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on canonical and redirects within performance & seo, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. Canonical and redirects solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

WEB-087 · Performance & SEO

Schema strategy

Use when working on schema strategy for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a product engineering team complete this specific task: Schema strategy.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on schema strategy within performance & seo, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. Schema strategy solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

WEB-088 · Performance & SEO

Internal linking architecture

Use when working on internal linking architecture for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a WordPress developer complete this specific task: Internal linking architecture.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on internal linking architecture within performance & seo, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. Internal linking architecture solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

WEB-089 · Performance & SEO

Crawlability review

Use when working on crawlability review for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a junior developer complete this specific task: Crawlability review.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on crawlability review within performance & seo, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. Crawlability review solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

WEB-090 · Performance & SEO

Performance budget

Use when working on performance budget for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a freelance developer complete this specific task: Performance budget.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on performance budget within performance & seo, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. Performance budget solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

WEB-091 · Security & Privacy

Threat model

Use when working on threat model for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a junior developer complete this specific task: Threat model.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on threat model within security & privacy, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. Threat model solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

WEB-092 · Security & Privacy

Input sanitization review

Use when working on input sanitization review for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a freelance developer complete this specific task: Input sanitization review.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on input sanitization review within security & privacy, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. Input sanitization review solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

WEB-093 · Security & Privacy

XSS prevention checklist

Use when working on xss prevention checklist for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a product engineering team complete this specific task: XSS prevention checklist.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on xss prevention checklist within security & privacy, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. XSS prevention checklist solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

WEB-094 · Security & Privacy

CSRF protection design

Use when working on csrf protection design for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a WordPress developer complete this specific task: CSRF protection design.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on csrf protection design within security & privacy, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. CSRF protection design solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

WEB-095 · Security & Privacy

Session security review

Use when working on session security review for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a junior developer complete this specific task: Session security review.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on session security review within security & privacy, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. Session security review solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

WEB-096 · Security & Privacy

Secrets management

Use when working on secrets management for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a freelance developer complete this specific task: Secrets management.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on secrets management within security & privacy, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. Secrets management solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

WEB-097 · Security & Privacy

Dependency audit plan

Use when working on dependency audit plan for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a product engineering team complete this specific task: Dependency audit plan.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on dependency audit plan within security & privacy, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. Dependency audit plan solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

WEB-098 · Security & Privacy

Privacy-by-design review

Use when working on privacy-by-design review for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a WordPress developer complete this specific task: Privacy-by-design review.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on privacy-by-design review within security & privacy, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. Privacy-by-design review solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

WEB-099 · Security & Privacy

Secure file upload plan

Use when working on secure file upload plan for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a junior developer complete this specific task: Secure file upload plan.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on secure file upload plan within security & privacy, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. Secure file upload plan solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

WEB-100 · Security & Privacy

Incident response runbook

Use when working on incident response runbook for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a freelance developer complete this specific task: Incident response runbook.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on incident response runbook within security & privacy, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. Incident response runbook solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

WEB-101 · DevOps & Maintenance

Git branching workflow

Use when working on git branching workflow for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a junior developer complete this specific task: Git branching workflow.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on git branching workflow within devops & maintenance, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. Git branching workflow solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

WEB-102 · DevOps & Maintenance

Pull request review

Use when working on pull request review for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a freelance developer complete this specific task: Pull request review.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on pull request review within devops & maintenance, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. Pull request review solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

WEB-103 · DevOps & Maintenance

CI pipeline design

Use when working on ci pipeline design for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a product engineering team complete this specific task: CI pipeline design.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on ci pipeline design within devops & maintenance, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. CI pipeline design solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

WEB-104 · DevOps & Maintenance

Environment configuration

Use when working on environment configuration for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a WordPress developer complete this specific task: Environment configuration.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on environment configuration within devops & maintenance, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. Environment configuration solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

WEB-105 · DevOps & Maintenance

Deployment rollback plan

Use when working on deployment rollback plan for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a junior developer complete this specific task: Deployment rollback plan.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on deployment rollback plan within devops & maintenance, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. Deployment rollback plan solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

WEB-106 · DevOps & Maintenance

Monitoring and alerts

Use when working on monitoring and alerts for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a freelance developer complete this specific task: Monitoring and alerts.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on monitoring and alerts within devops & maintenance, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. Monitoring and alerts solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

WEB-107 · DevOps & Maintenance

Backup and restore drill

Use when working on backup and restore drill for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a product engineering team complete this specific task: Backup and restore drill.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on backup and restore drill within devops & maintenance, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. Backup and restore drill solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

WEB-108 · DevOps & Maintenance

Database migration plan

Use when working on database migration plan for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a WordPress developer complete this specific task: Database migration plan.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on database migration plan within devops & maintenance, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. Database migration plan solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

WEB-109 · DevOps & Maintenance

Release notes

Use when working on release notes for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a junior developer complete this specific task: Release notes.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on release notes within devops & maintenance, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. Release notes solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

WEB-110 · DevOps & Maintenance

Maintenance SOP

Use when working on maintenance sop for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a freelance developer complete this specific task: Maintenance SOP.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on maintenance sop within devops & maintenance, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. Maintenance SOP solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

WEB-111 · Client Delivery & Remote Career

Proposal and scope

Use when working on proposal and scope for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a junior developer complete this specific task: Proposal and scope.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on proposal and scope within client delivery & remote career, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. Proposal and scope solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

WEB-112 · Client Delivery & Remote Career

Estimate and assumptions

Use when working on estimate and assumptions for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a freelance developer complete this specific task: Estimate and assumptions.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on estimate and assumptions within client delivery & remote career, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. Estimate and assumptions solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

WEB-113 · Client Delivery & Remote Career

Project milestones

Use when working on project milestones for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a product engineering team complete this specific task: Project milestones.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on project milestones within client delivery & remote career, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. Project milestones solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

WEB-114 · Client Delivery & Remote Career

Stakeholder update

Use when working on stakeholder update for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a WordPress developer complete this specific task: Stakeholder update.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on stakeholder update within client delivery & remote career, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. Stakeholder update solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

WEB-115 · Client Delivery & Remote Career

Handover documentation

Use when working on handover documentation for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a junior developer complete this specific task: Handover documentation.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on handover documentation within client delivery & remote career, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. Handover documentation solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

WEB-116 · Client Delivery & Remote Career

Training tutorial

Use when working on training tutorial for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a freelance developer complete this specific task: Training tutorial.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on training tutorial within client delivery & remote career, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. Training tutorial solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

WEB-117 · Client Delivery & Remote Career

Portfolio case study

Use when working on portfolio case study for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a product engineering team complete this specific task: Portfolio case study.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on portfolio case study within client delivery & remote career, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. Portfolio case study solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

WEB-118 · Client Delivery & Remote Career

Technical interview drill

Use when working on technical interview drill for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a WordPress developer complete this specific task: Technical interview drill.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on technical interview drill within client delivery & remote career, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. Technical interview drill solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

WEB-119 · Client Delivery & Remote Career

Code review simulation

Use when working on code review simulation for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a junior developer complete this specific task: Code review simulation.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on code review simulation within client delivery & remote career, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. Code review simulation solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

WEB-120 · Client Delivery & Remote Career

Remote collaboration playbook

Use when working on remote collaboration playbook for a website or client project. Replace the bracketed inputs before copying.

Act as a senior web engineer and practical mentor. Help a freelance developer complete this specific task: Remote collaboration playbook.

PROJECT INPUTS
- Website/product: [DESCRIBE PROJECT]
- Users and primary goal: [AUDIENCE AND GOAL]
- Current stack / CMS / versions: [STACK OR UNKNOWN]
- Existing code, screenshots, requirements or logs: [PASTE RELEVANT NON-SECRET DETAILS]
- Constraints (time, accessibility, browsers, hosting, budget): [CONSTRAINTS]
- Desired deliverable: [CODE / PLAN / AUDIT / TUTORIAL]

TASK-SPECIFIC INSTRUCTIONS
1. Focus on remote collaboration playbook within client delivery & remote career, not generic website advice. Explain assumptions and ask only for truly blocking missing inputs.
2. Start with a short diagnosis or implementation plan tied to the provided inputs.
3. Produce concrete, usable deliverables: file names, relevant code or configuration examples, ordered implementation steps and an expected-result example. Use current project syntax rather than mixing frameworks.
4. Explain at least three task-specific edge cases or failure scenarios and how to address them.
5. Include accessibility, responsive behavior, security and performance considerations where relevant. Never fabricate test results, metrics, installed packages or API behavior.
6. Give a manual verification checklist, suggested automated tests and safe rollback steps when changes affect a live site.
7. Identify what requires developer approval, staging validation or official documentation verification. Avoid real credentials and use placeholders for sensitive values.

OUTPUT FORMAT
A. Objective and assumptions
B. Remote collaboration playbook solution
C. Implementation artifacts (copyable code/configuration where applicable)
D. Risks and edge cases
E. Test checklist and definition of done
F. Client-friendly summary in five sentences or fewer.

Wait! Don't Lose Another Client.

How to use this complete tutorial

Suggested end-to-end portfolio project

Browse the prompt library

Requirements interview

Audience and user journeys

Functional specification

Nonfunctional requirements

Site map

Component architecture

Technology selection

Data model draft

Acceptance criteria

MVP roadmap

Accessible page skeleton

Navigation landmarks

Article structure

Product detail markup

Contact form markup

Responsive image markup

Table semantics

Metadata audit

Structured content outline

HTML validation checklist

Design tokens

Mobile-first layout

Fluid typography

Responsive grid

Navigation states

Form styling

Dark mode

Container queries

Print stylesheet

Visual regression checklist

Input validation

Debounced search

State management

Fetch and error states

DOM event delegation

Async data flow

TypeScript interfaces

Array transformation

Date and timezone handling

Unit-test plan

Component decomposition

Custom hook design

Accessible modal

Searchable table

Form state

Loading and error boundary

Client/server rendering decision

Routing design

Performance profiling

Component testing

REST resource design

API contract

Authentication flow

Authorization matrix

Pagination and filters

Webhook receiver

Idempotency handling

Background job plan

Database query review

API integration tests

Theme compatibility review

Kadence page layout

Custom HTML embed

Scoped CSS strategy

Script enqueue plan

Custom post type design

Block pattern blueprint

Plugin conflict debugging

WooCommerce customization plan

WordPress release checklist

Reproduction steps

Console error diagnosis

Network request diagnosis

Cross-browser test matrix

Mobile viewport audit

Regression test suite