Replying to
Railspike is a prompting framework we created to help my agentic developers and me stay on track in our work.
The pain points Railspike address are: requirements drift, misunderstandings in what's being developed, additions of undesired frameworks and third-party components, and the agent working for a long time before we realize what's happening.
The goals of Railspike are to document much of the planning, keep intent clear as a feature is developed, and keep reminding the agent what it is working on.
Railspike accomplishes this with a multiple instruction prompts that split the development process into four steps: brainstorming, outlining, planning, and actual development work. This process has proven to work well for us in developing new features, reshaping existing features, fixing bugs, writing documentation, writing checklists for bigger pieces of work that take multiple cycles, and basically any task that we have thrown at it.
Sometimes even a simple, seemingly one-shot bugfix can go off-track when an agent misunderstands what we meant or intended, or chooses a solution that we do not agree with. Railspike has almost completely eliminated this occurrence by locking in what is planned.
The main [basic component] of Railspike is the plan stored in a file. Railspike began to take shape when we realized that, for most tasks, it is helpful to have the agent write its own prompt before actually starting the work. We could inspect this prompt and alter it, also with the agent's help, before any actual code was written.
We then set out to emulate a minimal planning process, not unlike agile or waterfall, where we first ideated on possible solution types and made a decision for what to do, fleshed out our decision in a detailed high-level plan, wrote an even more detailed development plan, breaking down the task into multiple atomic sub-tasks, and then began development following this third plan.
The process started out as one file with instructions, but we soon noticed that the instructions would often be forgotten out of the context window, so we split it into several files that we inserted into the conversation as they were needed. We then further added instructions for before, during, and after certain steps.
We spent a year refining these prompts as we used them to build multiple projects (mostly web-based online social spaces frameworks, but also some random things like documentation.)
Eventually, we started recommending this process to others and seeing it help them, and realized that it needed a catchier name than FEATURE_DEVELOPMENT_PROCESS.md. We also realized that it needed a debug mode, so we added that.
And here it is!
The pain points Railspike address are: requirements drift, misunderstandings in what's being developed, additions of undesired frameworks and third-party components, and the agent working for a long time before we realize what's happening.
The goals of Railspike are to document much of the planning, keep intent clear as a feature is developed, and keep reminding the agent what it is working on.
Railspike accomplishes this with a multiple instruction prompts that split the development process into four steps: brainstorming, outlining, planning, and actual development work. This process has proven to work well for us in developing new features, reshaping existing features, fixing bugs, writing documentation, writing checklists for bigger pieces of work that take multiple cycles, and basically any task that we have thrown at it.
Sometimes even a simple, seemingly one-shot bugfix can go off-track when an agent misunderstands what we meant or intended, or chooses a solution that we do not agree with. Railspike has almost completely eliminated this occurrence by locking in what is planned.
The main [basic component] of Railspike is the plan stored in a file. Railspike began to take shape when we realized that, for most tasks, it is helpful to have the agent write its own prompt before actually starting the work. We could inspect this prompt and alter it, also with the agent's help, before any actual code was written.
We then set out to emulate a minimal planning process, not unlike agile or waterfall, where we first ideated on possible solution types and made a decision for what to do, fleshed out our decision in a detailed high-level plan, wrote an even more detailed development plan, breaking down the task into multiple atomic sub-tasks, and then began development following this third plan.
The process started out as one file with instructions, but we soon noticed that the instructions would often be forgotten out of the context window, so we split it into several files that we inserted into the conversation as they were needed. We then further added instructions for before, during, and after certain steps.
We spent a year refining these prompts as we used them to build multiple projects (mostly web-based online social spaces frameworks, but also some random things like documentation.)
Eventually, we started recommending this process to others and seeing it help them, and realized that it needed a catchier name than FEATURE_DEVELOPMENT_PROCESS.md. We also realized that it needed a debug mode, so we added that.
And here it is!