Back to Blog
want you to inspect the SOURCE PROJECT thoroughly and implement the same Blogs and Gallery functionality in the current/target project
September 15, 2026 40 views
<p>You are working on a Next.js project.</p><h2>SOURCE PROJECT</h2><p>The existing project containing the properly implemented Blogs and Gallery features is:</p><p>E:\expert_squad\exp_self\expertsquad-portfolio-june-2026</p><p>This is the <strong>reference/source project</strong>.</p><p></p><p>http://media.pennom.com/logo1786286576821.png</p><p></p><h2>TASK</h2><p>I want you to inspect the SOURCE PROJECT thoroughly and implement the same <strong>Blogs</strong> and <strong>Gallery</strong> functionality in the current/target project where you are running OpenCode.</p><p>The goal is NOT to blindly copy files.</p><p>You must first understand how Blogs and Gallery are implemented in the source project, then adapt the implementation to the architecture, naming conventions, API structure, components, styling system, and existing patterns of the target project.</p><h1>PHASE 1 — SOURCE PROJECT AUDIT</h1><p>First, inspect:</p><p>E:\expert_squad\exp_self\expertsquad-portfolio-june-2026</p><p>Do NOT modify the source project.</p><p>Find and analyze everything related to:</p><h3>Blogs</h3><ul><li>Blog listing page</li><li>Blog details/single page</li><li>Blog cards</li><li>Blog components</li><li>Blog API/data fetching</li><li>Blog types/interfaces</li><li>Blog categories/tags if available</li><li>Blog pagination/load-more if available</li><li>Blog search/filter if available</li><li>Blog metadata/SEO</li><li>Blog images</li><li>Rich text/content rendering</li><li>Loading states</li><li>Empty states</li><li>Error states</li><li>Dynamic routes</li><li>Related blogs if available</li></ul><h3>Gallery</h3><ul><li>Gallery listing/page</li><li>Gallery cards</li><li>Gallery components</li><li>Gallery API/data fetching</li><li>Gallery types/interfaces</li><li>Categories/filtering if available</li><li>Image grid/layout</li><li>Image preview/lightbox/modal</li><li>Pagination/load-more if available</li><li>Loading states</li><li>Empty states</li><li>Error states</li><li>Image optimization</li><li>Responsive behavior</li></ul><p>Also inspect:</p><ul><li>app/</li><li>components/</li><li>lib/</li><li>services/</li><li>hooks/</li><li>types/</li><li>utils/</li><li>API utilities</li><li>fetch/mutation utilities</li><li>state management</li><li>authentication requirements</li><li>environment variables</li><li>Tailwind/configuration</li><li>reusable UI components</li><li>routing conventions</li></ul><p>Search the entire source project for relevant keywords such as:</p><p>blog</p><p>blogs</p><p>gallery</p><p>galleries</p><p>slug</p><p>category</p><p>image</p><p>lightbox</p><p>modal</p><p>Do not assume the folder names. Discover the actual implementation.</p><h1>PHASE 2 — DOCUMENT THE SOURCE IMPLEMENTATION</h1><p>Before coding, summarize your findings internally.</p><p>Determine:</p><ol><li>How blog data is fetched.</li><li>How gallery data is fetched.</li><li>Which API endpoints are used.</li><li>What request/response structures are expected.</li><li>Which components are reusable.</li><li>Which components are page-specific.</li><li>How dynamic routes work.</li><li>How images are handled.</li><li>How loading/error/empty states work.</li><li>How responsive layouts work.</li><li>How SEO/metadata is handled.</li><li>Which parts depend on source-project-specific configuration.</li><li>Which parts can be safely reused.</li><li>Which parts must be adapted for the target project.</li></ol><p>Do not copy source-specific business logic that does not belong in the target project.</p><h1>PHASE 3 — TARGET PROJECT AUDIT</h1><p>Now inspect the current project thoroughly.</p><p>Understand:</p><ul><li>Next.js version</li><li>React version</li><li>TypeScript configuration</li><li>App Router / Pages Router</li><li>Tailwind version</li><li>Existing component architecture</li><li>Existing API/fetching architecture</li><li>Existing authentication</li><li>Existing image configuration</li><li>Existing routing</li><li>Existing layouts</li><li>Existing reusable UI components</li><li>Existing SEO/metadata implementation</li><li>Existing state management</li><li>Existing folder conventions</li></ul><p>Before creating new utilities/components, check whether equivalent functionality already exists in the target project.</p><p>Prefer reusing existing target-project infrastructure instead of introducing duplicate abstractions.</p><h1>PHASE 4 — API COMPATIBILITY</h1><p>This is extremely important.</p><p>Do NOT blindly assume that the source project's API endpoints, environment variables, IDs, response structures, or backend configuration are identical to the target project.</p><p>Compare the source and target API patterns.</p><p>If the target project already has APIs for Blogs and Gallery:</p><ul><li>Use the target APIs.</li><li>Adapt the UI to the target API response.</li></ul><p>If the target project uses the same backend/API:</p><ul><li>Reuse the existing API structure correctly.</li></ul><p>If the APIs differ:</p><ul><li>Create/adapt the required frontend types and data mapping.</li><li>Do NOT modify backend code unless explicitly required.</li></ul><p>Do not invent API endpoints.</p><p>If something is unclear, inspect the existing project further before making assumptions.</p><h1>PHASE 5 — IMPLEMENT BLOGS</h1><p>Implement Blogs in the target project with the same overall design, UX, and behavior as the source project.</p><p>Preserve:</p><ul><li>Visual hierarchy</li><li>Card design</li><li>Typography</li><li>Spacing</li><li>Image aspect ratios</li><li>Responsive behavior</li><li>Hover effects</li><li>Buttons/links</li><li>Content structure</li><li>Loading state</li><li>Empty state</li><li>Error handling</li><li>Pagination/load-more behavior</li><li>Dynamic blog details</li><li>Related content behavior</li><li>SEO behavior</li></ul><p>However, adapt the implementation to the target project's existing design system.</p><p>Do not unnecessarily duplicate source components if equivalent target components already exist.</p><p>Use:</p><ul><li>TypeScript</li><li>Proper types</li><li>Existing project utilities</li><li>Existing API/fetching patterns</li><li>Existing UI primitives</li><li>Existing styling conventions</li></ul><p>Avoid unnecessary dependencies.</p><h1>PHASE 6 — IMPLEMENT GALLERY</h1><p>Implement Gallery in the target project based on the source project's implementation.</p><p>Preserve the same:</p><ul><li>Grid structure</li><li>Image sizing/aspect ratio</li><li>Responsive layout</li><li>Spacing</li><li>Hover behavior</li><li>Image preview behavior</li><li>Modal/lightbox behavior</li><li>Navigation behavior</li><li>Filtering/categories if present</li><li>Pagination/load-more behavior</li><li>Loading state</li><li>Empty state</li><li>Error handling</li></ul><p>Use the target project's existing image handling and UI architecture where possible.</p><p>Do not introduce a new gallery library unless the source project already depends on one and there is a strong reason to use it.</p><h1>PHASE 7 — ROUTING</h1><p>Identify the exact routes used in the source project.</p><p>Then implement equivalent routes in the target project.</p><p>For example, if the source uses something like:</p><p>/blogs</p><p>/blogs/[slug]</p><p>/gallery</p><p>adapt those routes to the target project's routing structure.</p><p>Do not change unrelated routes.</p><p>Ensure:</p><ul><li>Direct URL access works.</li><li>Dynamic routes work.</li><li>Refreshing dynamic pages works.</li><li>Navigation works.</li><li>Back/forward navigation works.</li></ul><h1>PHASE 8 — SEO</h1><p>If the source project has SEO implementation for Blogs/Gallery, inspect and reproduce the relevant behavior.</p><p>Implement appropriate:</p><ul><li>Page title</li><li>Description</li><li>Canonical URL where applicable</li><li>Open Graph metadata</li><li>Twitter metadata</li><li>Dynamic blog metadata</li><li>Relevant structured data if already used</li></ul><p>Do not invent blog information for SEO.</p><p>Use actual data available from the API/content.</p><p>Follow the target project's existing SEO architecture.</p><h1>PHASE 9 — IMAGE CONFIGURATION</h1><p>Check how the source project handles remote images.</p><p>Inspect:</p><ul><li>next.config.*</li><li>remote image domains/patterns</li><li>image loaders</li><li>optimization settings</li></ul><p>Then verify the target project's configuration.</p><p>If required, add only the necessary image host configuration.</p><p>Do not disable Next.js image optimization just to make images work.</p><h1>PHASE 10 — CODE QUALITY</h1><p>Follow production-grade standards.</p><p>Requirements:</p><ul><li>TypeScript-first</li><li>No unnecessary any</li><li>No duplicated logic</li><li>No duplicated API calls</li><li>Reusable components where appropriate</li><li>Clear naming</li><li>Proper server/client component boundaries</li><li>Correct async handling</li><li>Proper loading/error states</li><li>Responsive design</li><li>Accessible buttons and links</li><li>Accessible image alt text</li><li>No console errors</li><li>No unnecessary dependencies</li></ul><p>Do not refactor unrelated parts of the project.</p><p>Keep the change focused on Blogs and Gallery.</p><h1>PHASE 11 — VISUAL MATCHING</h1><p>The source project is the design reference.</p><p>Try to make the target implementation visually and behaviorally equivalent.</p><p>Compare:</p><ul><li>Desktop</li><li>Tablet</li><li>Mobile</li><li>Blog listing</li><li>Blog details</li><li>Gallery</li><li>Gallery image preview</li><li>Loading states</li><li>Empty states</li></ul><p>If the target project has a slightly different global design system, preserve the target project's global design while keeping the Blogs/Gallery experience consistent with the source.</p><h1>PHASE 12 — VALIDATION</h1><p>After implementation:</p><ol><li>Run TypeScript/type checking.</li><li>Run ESLint if configured.</li><li>Run the production/build command if practical.</li><li>Check all new routes.</li><li>Check dynamic blog routes.</li><li>Check API requests.</li><li>Check images.</li><li>Check responsive behavior.</li><li>Check browser console for errors.</li><li>Check for broken imports.</li><li>Check for hydration issues.</li><li>Check loading/error/empty states.</li></ol><p>Fix any issues introduced by your implementation.</p><h1>IMPORTANT RULES</h1><h3>Rule 1</h3><p>The source project is READ-ONLY.</p><p>Do not modify:</p><p>E:\expert_squad\exp_self\expertsquad-portfolio-june-2026</p><h3>Rule 2</h3><p>Do not blindly copy the entire source project.</p><p>Only extract/adapt the Blogs and Gallery implementation.</p><h3>Rule 3</h3><p>Do not overwrite unrelated target-project functionality.</p><h3>Rule 4</h3><p>Do not introduce unnecessary dependencies.</p><h3>Rule 5</h3><p>Do not invent APIs, data fields, routes, or environment variables.</p><h3>Rule 6</h3><p>Prefer existing target-project utilities/components over creating duplicates.</p><h3>Rule 7</h3><p>If source and target architectures differ, adapt the implementation instead of forcing the source architecture into the target.</p><h3>Rule 8</h3><p>Do not stop after analyzing the source. Actually implement the complete feature in the target project.</p><h3>Rule 9</h3><p>Do not ask me for information that can be discovered by inspecting the codebase.</p><h3>Rule 10</h3><p>Before finishing, verify the implementation end-to-end.</p><h1>FINAL REPORT</h1><p>When everything is completed, provide a concise report containing:</p><h2>Source Analysis</h2><ul><li>How Blogs work</li><li>How Gallery works</li><li>Important reusable patterns discovered</li></ul><h2>Implemented</h2><ul><li>Blog routes</li><li>Gallery routes</li><li>Components created/modified</li><li>API/data integration</li><li>SEO implementation</li><li>Image configuration</li></ul><h2>Validation</h2><ul><li>TypeScript result</li><li>ESLint result</li><li>Build result</li><li>Any remaining issues</li></ul><h2>Files Changed</h2><p>List every file created or modified, with a one-line explanation of what changed.</p><p>Do not modify the source project.</p><p>Only modify the current target project.</p>