Forge Project Cleanup Vision
Problem
The Forge system has been migrated from LibreChat to uvilo-mono. The Forge Project system has to be updated across its knowledge documents, bot prompts, and skill definitions to be compatible with the AI tools and capabilities of the new environment. For example, the Erik_Todo system is outdated and needs to start using the new AI tools in the todos group. The WIP system is now unnecessary since convos save on every step. Agents are not consistently communicating through the standard work-product system (Vision, Research, Spec, Plans, Evals), leading to duplicated information in ephemeral convos rather than durable documentation. The project bots (project-runner, project-thinker, project-worker, project-evaluator) must be updated to be fully compatible with the new environment and to resolve drift from Knowledge documents. Additionally, the project flow needs alignment with the principles in the Forge Charter.
Definitions and Evaluation Scope
- Project system means the active, non-archived Forge project workflow: project Knowledge and Guides, project Skills and templates, project bot prompts/configuration for
project-runner,project-thinker,project-worker, andproject-evaluator, Inngest schedules or workflow configuration that drives project phases, and active project files used by the workflow. - Current references means executable or instructional references in non-archived docs, skills, templates, bot prompts, configs, and active project files. Historical mentions in archived projects or durable evaluation history are out of scope unless they are still used as active instructions.
todosgroup replacement means using the exact AI tools available in thetodostool group at implementation time and documenting how the old Erik_Todo actions map to those tool calls.- Functional means the implementation can be inspected or smoke-tested through the relevant tools, scripts, prompt records, or generated site output, with evidence recorded in the project work-product.
Requirements
R1: Replace Erik_Todo with AI tools in the todos group
The documented Erik_Todo system (sometimes called “Erik_Todo”) must be replaced with the new todos group tools across all current project skills, knowledge documents, guides, bot prompts, and relevant project workflow configuration. The implementation must identify the exact todos tool names and document a mapping from each prior Erik_Todo behavior to the replacement todos behavior. All current instructional references to Erik_Todo must be updated or removed.
R2: Remove the WIP system
The entire WIP (Work In Progress) system must be removed from the active project workflow. Since convos now save on every step, the WIP file is no longer needed to prevent state loss. This includes removing WIP instructions from project skills, templates, the Project Create skill, bot prompts, and active project files. Existing active WIP files must be deleted or migrated when they are workflow artifacts (for example, LibreChat_Removal_WIP.md and Project_Automation_WIP.md). Archived projects are out of scope.
R3: Enforce work-product-based communication
Agents must communicate with the user and with spawned agents primarily through the standard durable work-products: Vision, Research, Spec, Plans, and their Evals. Conversations should contain only concise routing context: project, phase, skill, work-product, status, next step, and links/artifacts for the latest work-product. Agents should not duplicate substantive work-product content in conversation bodies unless needed to ask a specific user decision question.
R4: Verify bot compliance with Knowledge documents
The four project bots (project-runner, project-thinker, project-worker, project-evaluator) must be reviewed and updated to ensure they are compliant with the canonical Knowledge documents, especially Forge Project Workflow and Forge Project User Guide. Any discrepancies between bot prompts and Knowledge must be documented and resolved in favor of the Knowledge documents unless a user-approved exception is recorded.
R5: Verify project system infrastructure
Every component of the project system must be inventoried and verified as installed, configured, and functioning. This includes project skills, templates, bot configurations, prompt records, Inngest schedules or workflow triggers, generated sidebar/page output, and the project lifecycle flow. Verification must include concrete evidence such as file inspection, prompt diff review, build results, script output, tool smoke tests, or documented manual checks.
R6: Align project flow with Forge Charter
The Forge Charter principles must be reviewed against the project workflow. The implementation must produce a Charter alignment matrix that lists each relevant Charter principle, whether the current project flow complies, any violation or gap, and the correction made or user decision required. The project flow must be improved so no known Charter violations remain unaddressed.
R7: Flag ambiguities for user decision
Any areas of ambiguity encountered during the project must be brought to the user’s attention rather than having the agent make assumptions. This includes unclear requirements, conflicting documentation, or design decisions that could go multiple ways. Each ambiguity must be recorded with the affected work-product, decision needed, options considered, and the user’s decision or escalation status.
R8: Globally unique project names incorporating department
Project names must be globally unique across all departments, not just unique within a single department. The project name must use the format {Department}/{ProjectShortName}, mirroring the bot naming convention {group}/{handle}. This prevents naming collisions between departments, makes cross-department references clear, and provides a consistent identity pattern across the system.
R9: User-configurable human gates
When a project is created, the user must be asked which phases they want human gates after. The available gate points are: after Vision_Eval, after Research, after Spec_Eval, after Plan_Eval, after Execute_Eval, after Verify, and after Extract_Eval. This establishes how much oversight the user wants for the project. The selected gates are recorded in the project configuration and respected by the Runner throughout the project lifecycle. The default gate set (used when the user does not specify) must be clearly documented.
Success Criteria
| # | Criterion | Measured by |
|---|---|---|
| V1 | Erik_Todo fully replaced with todos group | Search and prompt review show no remaining current instructional references to Erik_Todo; a replacement mapping to exact todos tools exists; todos usage is inspected or smoke-tested |
| V2 | WIP system fully removed | Search shows no current active workflow instructions depending on WIP files; WIP templates are removed or retired; active WIP files are deleted or migrated; archived projects are excluded |
| V3 | Agents communicate via work-products | Bot prompts explicitly instruct work-product-based communication; handoff and user-report formats reference work-products/artifacts instead of duplicating substantive content in convos |
| V4 | All four project bots compliant with Knowledge | Audit shows zero unresolved discrepancies between the four project bot prompts and canonical Knowledge documents, or records explicit user-approved exceptions |
| V5 | Project system infrastructure verified | Inventory and verification evidence cover skills, templates, bot configs, prompt records, Inngest schedules/triggers, generated pages/sidebar, and lifecycle flow |
| V6 | Project flow aligned with Forge Charter | Charter alignment matrix shows every relevant principle reviewed and no known unaddressed violations remain |
| V7 | Ambiguities surfaced to user | Ambiguity log contains every unresolved decision with options and status; no ambiguous design decision is implemented without user approval |
| V8 | Project names globally unique with department | No two active projects share the same name across departments; every project name contains its department identifier; cross-department references are unambiguous |
| V9 | Human gates are user-configurable | Project creation asks the user which gate points they want; the selected gates are recorded and enforced by the Runner; the default gate set is documented |
Out Of Scope
- Changes to the Forge Charter itself
- Changes to non-project Forge bots (for example, chat and page-manager)
- Refactoring of archived projects
- Changes to the Astro/Starlight infrastructure unrelated to generated project pages/sidebar entries
- Adding new project phases or new work-product types
- Renaming existing archived or completed projects to conform to the new naming convention