Create a concrete implementation plan for a machine learning or deep learning experiment system from a project plan, proposal, or research spec.
Turn a project plan, proposal, thesis outline, experiment brief, or similar specification into a concrete implementation plan for an ML/DL system.
The output must be an implementation plan in markdown format, not code. Create implementation-plan.md in docs/ folder.
The plan should optimize for:
The user may provide one or more of the following:
If a plan/spec file is provided, treat it as the main source of truth. Ask at most 1–3 focused follow-up questions, if you see some blockers or unclarities. If not blocked, proceed with reasonable assumptions and state them clearly.
You are planning a research/experimentation system, not a generic ML platform.
Follow these principles:
Build only what the project needs. Do not design a general-purpose framework unless the requirements genuinely demand it.
Prefer KISS over abstract purity. Use DRY and SOLID pragmatically, not aggressively. Avoid premature abstraction.
Prefer explicitness over magic. Keep configuration, experiment execution, outputs, and control flow easy to understand.
Prefer composition over inheritance. Small, focused modules are better than deep class hierarchies.
Make experiments easy to run and inspect. A user should be able to understand how an experiment works by reading its config and the few modules it touches.
Use YAML for experiment configuration whenever it fits the project. Prefer one YAML file per runnable experiment. Only introduce shared defaults/includes if they clearly reduce harmful duplication without making the system harder to reason about.
Assume correct usage unless the spec says otherwise. Do not plan for many edge cases or broad defensive programming. Add only necessary validation/error handling, such as:
Reproducibility is a first-class requirement. Include seed management, deterministic settings when reasonable, config snapshots, and structured output directories.
Keep the toolchain lightweight. Do not recommend heavyweight orchestration or configuration frameworks unless there is a strong project-specific reason.
Read the provided plan/spec carefully and extract:
When producing the implementation plan:
Unless the project constraints say otherwise, you may assume a lightweight Python-based research stack. For deep learning projects, a typical default may include only what is needed, for example:
Return the docs/implementation-plan.md using this structure exactly:
A short paragraph describing what the system exists to do.
State the assumptions you are making and how DRY, KISS, SOLID, minimalism, and limited error handling should be interpreted for this project.
Summarize the concrete capabilities the codebase must support.
List only tools/libraries that are genuinely needed and briefly justify each one.
Provide a concrete, minimal repository tree and briefly explain each top-level directory and file. Prefer src/ for the system implementation, outputs/ directory for output files of experiments, keep README.md in the repository root, and include only folders/resources that are justified by the project scope and common best practices.
For each core module, explain:
Explain:
Describe the minimal execution flow for each required experiment type. Examples may include:
Break implementation into ordered milestones aligned with the project phases or work packages. For each milestone include:
State clearly:
Cover:
Specify exactly what the README should document, including:
List only real uncertainties that could change the implementation plan. If there are no major blockers, keep this section short.