Mejores prompts para GitHub Copilot: 52 prompts para programar con IA

Explain this code before making any changes.

Describe:

- its purpose
- inputs and outputs
- main execution flow
- external dependencies
- side effects
- error handling
- security-sensitive behavior
- assumptions it relies on

Then identify
the functions or modules
that interact with it.

Do not modify code yet.

Trace the complete data flow
for [FEATURE / VALUE].

Start at the external input
and follow it through:

1. request or event
2. validation
3. business logic
4. persistence
5. downstream calls
6. response or UI output

For each step identify:

- file
- function
- data transformation
- trust boundary
- possible failure point

Do not change anything.

Analyze the function [FUNCTION NAME].

Find:

- every caller
- important downstream calls
- public behavior
- implicit assumptions
- error paths
- tests covering it
- data it mutates
- compatibility constraints

Then explain
what could break
if its behavior changes.

Do not edit the function.

Analyze this legacy code
without refactoring it.

Reconstruct:

- what problem it solves
- current observable behavior
- important invariants
- hidden coupling
- global state
- side effects
- external integrations
- backwards compatibility requirements

Separate:

1. verified facts from the code
2. reasonable hypotheses
3. unknowns that require testing

Do not modernize anything yet.

Analyze this repository
before making changes.

Identify:

- application purpose
- important directories
- entry points
- architectural layers
- data stores
- external services
- authentication
- authorization
- build commands
- test commands
- lint / typecheck commands
- deployment-related files
- project-specific conventions

Then produce
a concise architecture map.

Do not modify files.

Review this repository
for architectural debt.

Look for:

- circular dependencies
- duplicated abstractions
- unclear module boundaries
- business logic in transport layers
- persistence leaking into UI
- excessive global state
- tightly coupled services
- abstractions used only once
- inconsistent architectural patterns

Rank findings by:

1. maintenance cost
2. defect risk
3. difficulty to improve

Do not recommend a rewrite.

Find every important file
involved in [FEATURE].

Include:

- entry points
- routes
- controllers / handlers
- domain logic
- database access
- frontend components
- tests
- configuration
- documentation

Explain the role
of each file
and how they connect.

Do not edit anything.

Create a technical onboarding guide
for a developer joining this repository.

Cover:

- what the system does
- architecture
- important directories
- local setup
- required environment variables
- database setup
- how to run tests
- how to run lint / build
- important conventions
- common development workflows
- risky areas of the codebase

Only include information
supported by the repository.

Mark unknowns explicitly.

Implement [FEATURE].

Before coding:

1. inspect the existing architecture
2. find similar functionality
3. identify affected public interfaces
4. identify tests
5. propose the smallest safe plan

Requirements:

[REQUIREMENTS]

Constraints:

[CONSTRAINTS]

After implementation:

- run relevant tests
- run lint / typecheck / build
  when available
- inspect the complete diff
- verify backwards compatibility
- report anything not verified.

Make the smallest safe change
that solves [PROBLEM].

Do not:

- rename unrelated symbols
- reformat unrelated files
- introduce a new abstraction
  unless necessary
- change public APIs
- change behavior outside scope

Reuse existing project patterns.

After the change,
show why each modified file
was necessary.

Run the narrowest relevant tests.

Refactor [TARGET]
without changing observable behavior.

First identify:

- current public behavior
- existing tests
- callers
- side effects
- compatibility constraints

Then refactor incrementally.

Do not mix
behavioral changes
with structural cleanup.

Run the relevant tests
before and after.

Report any behavior
that could not be verified.

Review the duplicated code
in [FILES / FEATURE].

Determine whether
the duplication represents:

- the same concept
- coincidentally similar code
- different behavior
  that may diverge later

Only extract an abstraction
if it represents
a stable shared concept.

Prefer clarity
over reducing line count.

Preserve all existing behavior
and run relevant tests.

Investigate this bug
before editing code.

Problem:
[DESCRIBE BUG]

First:

1. reproduce the failure
2. collect the exact error
3. inspect relevant logs
4. trace the execution path
5. identify the first incorrect state
6. form a root-cause hypothesis
7. find evidence supporting it

Then explain:

- root cause
- affected code
- why it fails
- smallest safe fix
- regression test required

Only implement after
the cause is supported by evidence.

Investigate the failing test.

Do not modify
the test or implementation yet.

Determine:

- what behavior the test expects
- whether that expectation
  matches the intended contract
- the exact failing assertion
- the code path producing
  the unexpected result
- whether the failure is
  implementation,
  test,
  fixture,
  environment,
  or timing related

Do not weaken assertions
just to make the suite pass.

Investigate this regression.

Known good behavior:
[DESCRIPTION]

Current broken behavior:
[DESCRIPTION]

Use git history
and relevant tests
to identify the smallest change
that introduced the regression.

Compare:

- behavior before
- behavior after
- assumptions that changed

Do not revert unrelated work.

Propose the smallest fix
that restores the intended behavior.

Investigate this intermittent failure.

Do not assume
the first plausible explanation
is correct.

Look for:

- race conditions
- shared mutable state
- retries
- caching
- ordering assumptions
- time dependencies
- async operations
- network dependencies
- test pollution
- database isolation problems

Design a way
to increase reproduction frequency.

Only propose a fix
after identifying evidence
for the failure mechanism.

Create focused tests
for [TARGET].

Test observable behavior,
not private implementation details.

Cover:

- normal path
- invalid input
- boundary values
- error path
- regression scenario
- important security condition

Reuse existing test helpers
and project conventions.

Avoid tests
that simply duplicate
the implementation logic.

Before fixing this bug,
write the smallest regression test
that reproduces it.

Requirements:

- fail for the current bug
- test observable behavior
- avoid private implementation details
- isolate the failing condition

Run it
and confirm it fails
for the expected reason.

Then implement the fix
and prove the same test passes.

Review the tests
for [FEATURE].

Do not optimize
for coverage percentage.

Find high-risk behavior
that is not tested.

Prioritize:

- authorization failures
- destructive operations
- edge cases
- error handling
- backwards compatibility
- concurrency
- external API failures
- previous bug-prone paths

Recommend
the smallest set of tests
that most improves confidence.

Verify the implementation
before declaring the task complete.

Run the checks
available in this repository:

- targeted tests
- broader related tests
- lint
- typecheck
- build
- syntax checks

Then inspect git diff.

Confirm:

- requirements are satisfied
- no unrelated files changed
- no debug code remains
- public behavior is preserved

List anything
you could not verify.

Perform a security review
of [TARGET].

First map:

- trust boundaries
- attacker-controlled input
- authentication
- authorization
- secrets
- persistence
- external calls
- output surfaces

Then look for:

- injection
- authorization bypass
- privilege escalation
- IDOR
- XSS
- CSRF
- SSRF
- insecure deserialization
- secret exposure
- path traversal
- unsafe file handling

Only report findings
with a concrete failure path.

Audit authorization
for [FEATURE / API].

For every state-changing operation
identify:

- authenticated actor
- target resource
- required permission
- ownership relationship
- authorization check
- location of enforcement

Look for:

- missing authorization
- authentication-only checks
- IDOR
- tenant isolation failures
- privilege escalation

For each issue,
describe a realistic
unauthorized request.

Review the repository
for accidental secret exposure.

Look for:

- API keys
- access tokens
- private keys
- database credentials
- passwords
- webhook secrets
- credentials in tests
- secrets in example files
- sensitive logging

Do not print secret values
in your response.

Report:

- file
- secret type
- exposure risk
- remediation
- whether rotation is required.

Review the dependency changes
in this diff.

Identify:

- newly added dependencies
- major version changes
- transitive impact
- runtime vs development usage
- duplicated functionality
- unnecessary permissions
- lockfile changes

Determine whether
each new dependency
is actually needed.

Do not remove anything
until compatibility
and usage are verified.

Review the current git diff
before I commit.

Check for:

- accidental changes
- unrelated refactors
- debug statements
- commented-out code
- missing error handling
- security regressions
- backwards compatibility
- missing tests
- generated files
  that should not be committed

Do not change anything.

Return a prioritized checklist.

Inspect the staged changes
and write a concise commit message.

The message should explain:

- what changed
- why it changed

Do not list
every modified file.

Do not claim
tests were run
unless they actually were.

Use the repository's
existing commit style
if one is clearly established.

Create a pull request description
from this branch's diff.

Use this structure:

## Problem
What was wrong or missing?

## Solution
What approach was implemented?

## Important decisions
What tradeoffs matter?

## Verification
What tests or checks were actually run?

## Risk
What could still go wrong?

## Review focus
Which areas deserve
extra reviewer attention?

Only state verified facts.

Analyze this merge conflict
before resolving it.

Determine:

- intent of our branch
- intent of the incoming branch
- whether both behaviors
  are still required
- tests covering each side
- public contracts involved

Resolve the conflict
by preserving
the intended behavior
of both changes
when compatible.

Do not simply choose
one side based on recency.

Run relevant tests afterward.

Implement an endpoint for:

[GOAL]

Before coding,
find existing endpoint patterns.

Define:

- HTTP method
- route
- request schema
- authentication
- authorization
- validation
- response schema
- error responses
- idempotency requirements

Preserve existing API conventions.

Add tests for:

- success
- invalid input
- unauthenticated access
- unauthorized access
- missing resource.

Review this API change
for backwards compatibility.

Compare the previous
and new contract.

Check:

- required parameters
- optional parameters
- response fields
- field types
- status codes
- error format
- pagination
- sorting
- authentication
- authorization

Identify clients
that may break.

Prefer additive changes
when possible.

Review this database query.

Analyze:

- correctness
- parameterization
- injection risk
- indexes likely used
- full table scans
- joins
- sorting
- pagination
- result-set size
- locking
- concurrency
- N+1 behavior

Separate:

1. correctness issues
2. security issues
3. performance concerns

Do not optimize
without evidence
that behavior remains equivalent.

Design a database migration plan.

Do not execute it.

Document:

- current schema
- target schema
- expected data volume
- compatibility during rollout
- backfill strategy
- batching
- idempotency
- locking risk
- timeout risk
- rollback strategy
- application deployment order

Identify
the most dangerous step
and how to reduce its risk.

Investigate this frontend bug.

Before editing:

- reproduce the behavior
- inspect browser console
- inspect network requests
- inspect relevant DOM state
- identify event handlers
- identify data entering the component
- check duplicate initialization
- check race conditions

Explain the root cause
before modifying code.

After fixing,
verify the user flow
in the browser.

Fix this responsive layout issue.

First identify
the CSS rule
that creates the failure.

Test the layout at:

- small mobile
- large mobile
- tablet
- laptop
- wide desktop

Preserve existing desktop behavior.

Avoid:

- arbitrary pixel overrides
- unnecessary !important
- duplicating entire style blocks

Make the smallest
responsive change
that fixes the underlying constraint.

Review this UI
for accessibility.

Check:

- semantic HTML
- keyboard navigation
- focus order
- visible focus
- form labels
- error announcements
- modal focus management
- button vs link semantics
- aria-expanded
- aria-controls
- dynamic status messages

Prefer native HTML semantics.

Do not add ARIA
when a native element
already solves the problem.

Review this frontend
for measurable performance risks.

Look for:

- unnecessary JavaScript
- duplicate network requests
- render-blocking resources
- large bundles
- unnecessary rerenders
- unbounded DOM work
- expensive event handlers
- oversized images
- layout shifts
- work executed before needed

For each finding explain
which user-visible metric
or behavior it can affect.

Do not optimize
purely theoretical issues.

Complete this task:

[GOAL]

Work autonomously,
but keep the scope focused.

Process:

1. inspect the relevant code
2. understand existing patterns
3. create a short implementation plan
4. implement incrementally
5. run the narrowest relevant tests
6. fix failures caused by your change
7. run broader verification
8. inspect git diff

Do not:

- hide failing tests
- change unrelated behavior
- claim verification
  that was not performed

Finish with:

- files changed
- tests run
- result
- remaining uncertainty.

Investigate [PROBLEM]
from the command line.

You may use
read-only inspection commands
without changing files first.

Inspect:

- repository status
- relevant source
- configuration
- test output
- logs
- dependency state

Explain your diagnosis
before applying changes.

Ask for approval
before any destructive command.

Use available tools
to complete this task.

You may freely perform:

- code search
- file reads
- test execution
- lint
- build
- git diff/status

Ask before:

- deleting files
- resetting git state
- modifying remote systems
- deploying
- publishing
- rotating credentials
- destructive database operations

Prefer the least privileged
tool that can complete
each step.

Create an implementation plan
for [GOAL].

Do not modify code.

Investigate enough
to make the plan repository-specific.

Include:

- affected files
- existing patterns to reuse
- data-flow changes
- public API impact
- database impact
- security considerations
- tests required
- rollout concerns

Prefer the smallest design
that satisfies the requirements.

Call out assumptions explicitly.

Implement this issue:

[ISSUE]

Acceptance criteria:

[CRITERIA]

Before coding:

- inspect existing architecture
- find related implementation
- identify tests

Constraints:

[CONSTRAINTS]

After implementation:

- run relevant tests
- run lint / build
- inspect diff
- ensure no unrelated changes

Open a pull request
with:

- problem
- solution
- verification
- remaining risk.

Fix this bug:

[BUG]

Expected behavior:
[EXPECTED]

Current behavior:
[CURRENT]

First reproduce
and identify the root cause.

Add a regression test
that fails before the fix.

Implement the smallest safe fix.

Run relevant tests.

Do not change unrelated behavior.

Open a pull request
explaining:

- root cause
- fix
- regression test
- verification.

Refactor [TARGET]
without changing behavior.

Before editing:

- identify public contracts
- identify callers
- run relevant tests
- document current behavior

Refactor incrementally.

Do not mix
new functionality
with the cleanup.

Run the same tests
afterward.

Open a pull request
focused only
on this refactor.

Update the documentation
for [FEATURE].

Use the current implementation
as the source of truth.

Verify:

- setup steps
- configuration
- API examples
- command names
- defaults
- limitations
- error cases

Do not invent behavior
that is not supported
by the code.

Keep the change
limited to documentation.

Review this change
as if it were going to production.

Prioritize:

1. functional bugs
2. security vulnerabilities
3. authorization failures
4. data loss
5. race conditions
6. API contract breaks
7. backwards incompatibility
8. missing regression tests

For every finding include:

- severity
- affected code
- concrete failure scenario
- impact
- smallest safe fix

Ignore cosmetic preferences
without behavioral impact.

Use GitHub MCP
to investigate issue #[NUMBER].

Read:

- issue description
- comments
- labels
- linked pull requests
- relevant repository history

Then inspect the codebase
and determine:

- likely affected area
- root cause hypothesis
- files involved
- tests needed
- implementation risk

Do not modify code yet.

Use the browser tools
to verify [FEATURE].

Test the real user flow:

1. open the application
2. perform the normal path
3. test one invalid-input path
4. inspect console errors
5. inspect failed network requests
6. verify visible success state
7. verify error state

Do not infer success
only from the implementation.

Report the behavior
you actually observed.

Review this implementation
against the documentation
available through [MCP SERVER].

First retrieve
only the relevant requirements.

Then compare them
with the changed code.

Separate findings into:

- definite violations
- potential incompatibilities
- documentation ambiguities

Cite the requirement
that supports each finding.

Do not invent requirements
not present in the source.

Analyze this WordPress plugin
before changing anything.

Identify:

- plugin entry point
- classes
- actions
- filters
- AJAX handlers
- REST routes
- shortcodes
- custom tables
- $wpdb usage
- cron jobs
- WooCommerce integration
- admin assets
- frontend assets
- security-sensitive code
- tests

Explain the architecture
and data flow.

Do not modify files.

Perform a WordPress security audit.

Inspect:

- wp_ajax_*
- wp_ajax_nopriv_*
- register_rest_route()
- admin_post_*
- forms
- shortcodes
- file operations
- $wpdb queries

Check:

- authentication
- capabilities
- ownership
- nonce usage
- permission_callback
- validation
- sanitization
- output escaping
- SQL injection
- XSS
- CSRF
- privilege escalation

Remember:
nonce is not authorization.

Audit this WooCommerce extension
for HPOS compatibility.

Find all order reads and writes.

Flag:

- direct wp_posts access
- direct wp_postmeta access
  for orders
- get_post_meta() on orders
- update_post_meta() on orders
- WP_Query used for orders
- SQL tied to legacy storage
- internal WooCommerce APIs

Prefer:

- wc_get_order()
- wc_get_orders()
- WC_Order getters/setters
- supported WooCommerce CRUD APIs

Explain each required change.

Investigate this WordPress bug.

Do not edit code immediately.

First inspect:

- failing user flow
- browser console
- network request
- HTTP response
- PHP errors
- debug.log
- AJAX or REST handler
- nonce
- authentication
- capabilities
- input data
- database operation
- response generation

Identify the first incorrect state.

Then:

1. explain the root cause
2. write a regression test when practical
3. implement the smallest fix
4. run relevant checks
5. verify the user flow again.