ctxforge: discovering what to build before coding

An LLM has a broad store of engineering knowledge. I wanted to use that knowledge earlier in a project, when an idea still needs to become a clear set of requirements.

The idea behind ctxforge is to have the model act like a senior engineer interviewing the person with the idea. It should ask relevant questions, uncover constraints and help define the scope. That gives a coding agent a specific task to carry out, with a boundary around features that haven't been requested.

ctxforge is the public experimental toolkit I built around that process. A Node command-line installer adds editable Markdown instructions and project notes to a repository.

Turn an idea into decisions

The questions follow the work. For a new project, the entry document asks about its vision, technical foundation and the first thing a user should be able to do. That starts the conversation; a task-specific protocol then asks for more detail.

The README uses “Add search functionality” as a teaching example. It asks which data should be searchable, how many items there are, what matching is needed, when results should appear and what response time is acceptable. Accessibility is part of the discussion too.

Those answers connect the product need to the technical choices. Searching a small list of names on demand creates different requirements from searching a large catalogue while someone types, including misspellings.

The intended output is an agreed task: what the person needs, what behavior will count as working and which decisions are still open. The point of the interview is to discover that context before implementation makes assumptions expensive to unwind.

For a bug, the questions change. The core document's duplicate-search example asks how to reproduce the behavior and whether it happens consistently or intermittently. It routes the assistant toward investigation instead of treating the request as a new feature.

These are examples in the repository, not client incidents or measured results.

Make the proposed scope reviewable

The core instruction is short:

Make ALL technical assumptions explicit
Show confidence levels (HIGH/MEDIUM/LOW)
Present inferences BEFORE writing any code
Wait for human approval/correction

This is an excerpt from CORE.md. After asking, the assistant should explain what it inferred before writing code. A suggestion about storage, matching behavior or an error case can then be corrected while it is still a proposal.

The confidence words make assumptions easier to inspect. They aren't probabilities and don't make an inference correct. The human still decides whether the proposed task matches the idea.

Keep the task available as work continues

The toolkit installs six core documents and 16 task protocols. One entry document selects the relevant protocol, so the assistant doesn't need to load every workflow for every task.

Project decisions and learnings live in project.md. Its initial structure records the vision, stack, current focus and next task. The initializer leaves an existing copy alone. After a task, the instructions ask for a state snapshot: what changed, what is current and what a later session needs to know.

That saved state supports the discovery goal: a later session has somewhere to recover the project and current task. Old discussion can move out of the active context while relevant decisions remain available. Reload instructions return to the core protocol, project state and quality directives.

I also had to make this purpose clearer in the README. Programmers I showed the work to didn't fully understand its explanation, and I asked for simpler examples without inflated claims.

The public result is an editable framework that can be inspected and tried. It gives teams a way to discuss requirements and scope with an LLM before handing work to a coding agent. The CLI installs instructions; it doesn't enforce the scope or guarantee model behavior. I haven't established a controlled reduction in mistakes, delivery time or token use.