Shreyp087 Hack Scaffold
Goal
Make the chosen project easy to start, exercise and hand to a teammate, with the smallest foundation that supports its MVP.
Foundation
Inspect the existing repository, brief and commands before adding files. Preserve useful structure and the user's framework and hosting decisions. If choices remain open, select or recommend them from the actual project constraints; there is no default language, framework, database or cloud.
Provide a real one-command development entry point after documented prerequisites and setup. Use the ecosystem's normal task mechanism and verify that the documented command starts the actual application. Add a real one-command test or focused smoke-check entry point appropriate to the flow; explain its coverage and do not label an empty command a passing test.
When the application reads environment variables, create .env.example with those actual settings, placeholders instead of credentials, and a clear distinction between required and optional values. Otherwise document that no environment configuration is required. Keep local secrets out of version control. Identify external prerequisites and their purpose without implying an unconfigured service is installed or connected.
Provide deterministic seed data and a documented way to restore the demo's starting state where the product has state. Limit reset behavior to clearly identified development/demo data. Make any replay, stub or simulation visibly distinct from a live integration.
Write a concise README covering purpose, prerequisites, setup, development, checks, configuration, seed/reset and known limitations. Document deployment only for a provider or target the project actually selected; otherwise state that deployment is undecided without generating speculative provider files.
Create or update a short project AGENTS.md with the actual stack, verified dev/test commands, and a definition of done tied to the main flow. Permit ordinary local checks on disposable fixtures within existing permissions, including fixing failures from the change and rerunning. Link architecture or deployment documentation only if it exists and is relevant to that work. Preserve useful existing instructions.
Constraints
- Prefer the smallest real end-to-end path over speculative architecture or services.
- Reuse existing package scripts and tooling; avoid introducing a second task runner or test framework without a concrete benefit.
- A dependency declaration is not evidence that installation succeeded. A configuration file is not evidence that a service or deployment exists.
- Do not fabricate successful tests, working integrations or a deployment URL. Report unavailable credentials or tools and which checks they prevented.
- Installing local dependencies may support the task; creating paid resources, provisioning accounts or publishing needs the user's existing authorization.
- Do not erase user data to make a seed repeatable. Keep demo resets explicit and bounded.
Definition of done
The chosen stack runs through the documented development command; the relevant test or smoke-check command has been exercised; configuration and prerequisites match the code; demo state can be reproduced when applicable; and the README and project instructions accurately distinguish verified behavior from remaining setup. Deployment notes match only the selected target.