Better context.More reliable builds.
Explore reusable prompts and working patterns for understanding a codebase, planning a change, reviewing a build, and documenting the result.
Start with context
Give the assistant a concrete task, the relevant files, and a clear definition of done.
Review every boundary
Plan how data, permissions, errors, and external actions should behave before building.
Keep the result useful
Leave maintainers with clear implementation notes and evidence of the checks that ran.
A starting point for your next build.
Find a useful pattern, read the brief, and save it for your project.
Codebase orientation
Find the entry points, conventions, and dependencies before changing code.
Read the brief
# Codebase orientation Inspect the project instructions, package scripts, route structure, and relevant modules. Identify the files that own the requested behavior. Explain the current flow, likely change points, and unresolved questions. Do not edit code during orientation.
Implementation plan
Break a concrete change into reviewable work with explicit checks.
Read the brief
# Implementation plan Describe the user-visible outcome. List the smallest coherent changes and the files they affect. Identify data migrations, external dependencies, and compatibility risks. Define useful validation and acceptance criteria. Flag questions that affect the implementation.
Focused code review
Look for behavioral regressions, missing validation, and failure paths.
Read the brief
# Focused code review Review the proposed change against the original requirement. Prioritize correctness, authorization, input validation, failure handling, and regressions. Cite specific files and behavior. Separate confirmed defects from questions. Avoid style-only feedback unless it affects maintainability.
Test planning
Choose checks that cover the behavior and its meaningful edge cases.
Read the brief
# Test planning Identify the behavior that could break. Cover a representative success path, invalid inputs, empty data, and relevant failure modes. Prefer tests of observable behavior. State what each check proves and what remains unverified.
Delivery note
Explain what changed, why, and how it was checked.
Read the brief
# Delivery note Lead with the user-visible result. Explain the main implementation choices. List checks actually run and their outcomes. State material limitations, configuration requirements, and follow-up work without claiming unperformed verification.
Before you
get started.
More questions about adapting these resources to your business?
Talk to ManasFlowDo these resources connect to my Claude account?
No. You can read, copy, or download the local prompt briefs. No account, model API, or external execution is connected to this page.
Can I use the patterns with other coding assistants?
The task framing, review, and verification principles are portable. Adapt commands and project instruction files to the assistant and repository you use.
What should I put in a project instruction file?
Include the commands that work, repository conventions, important architectural boundaries, and the checks required before delivery. Keep instructions specific and current.
Make it work
for your business.
Bring the task, the tools, and the result you need. We will help you scope the next step.
Book a free strategy call