AI-agnostic. Works with Qwen, Claude, Gemini, GPT, or any coding assistant. Copy this file into your project. Fill each layer in order. Do not advance without user validation.
Read these files first:
.forgerc.json— AI model, gate mode, active layers.forge-memory— persistent project rules and context (load only what's relevant)
Rules that apply to ALL AI models:
- Execute layers in order (1→7). Never skip.
- Stop at each
[ GATE ]and wait for user confirmation. - Do NOT infer or fill sections without explicit user input when required.
- Do NOT suggest alternatives when a
[DECISION]or[THOUGHT]is locked. - Documentation (Layer 7) must reflect what was actually built, not what was planned.
About .forge-memory:
- This file stores persistent project rules (e.g., "PostgreSQL only", "no microservices")
- Read it before starting each session — apply memories as implicit Locked Paths
- Only load memories relevant to the current context — don't dump everything
- Never delete or modify this file — use
forge memorycommands
Instruction: Read all project files, code, and materials the user provided. Synthesize your understanding below. Do not infer intent — only describe what exists. Then stop and wait for validation.
[ GATE 1 ] — User validates context before proceeding. If anything is wrong, correct it here before moving on.
Instruction: Based on the validated context, list the problems the user needs to solve. Do NOT suggest solutions. List only problems, ordered by priority. If there are no problems, state that explicitly — nothing will be executed.
Rule: If this section is empty or marked "no problems", execution stops. There is nothing to build.
[ GATE 2 ] — User confirms problem list and priority order before proceeding.
Instruction: Record all restrictions provided by the user. These are non-negotiable. Never suggest alternatives inside a locked path. Never explore approaches that contradict these entries.
[ GATE 3 ] — User confirms all locked paths are correctly registered before proceeding.
Instruction: Decompose the problems into ordered tasks. For each task, list which skills will be used. Respect dependencies between tasks. Do not begin implementation here.
| # | Task | Depends On | Skills |
|---|---|---|---|
| T1 | — | ||
| T2 | T1 | ||
| T3 | T2 |
| Skill | Layer | Status |
|---|---|---|
| existing / to create |
[ GATE 4 ] — User approves the task plan and skill list before execution begins.
Instruction: Execute tasks in the approved order, one at a time. After each task, stop and report what was done. Do not proceed to the next task without confirmation. Do not do anything outside the task scope.
- Status:
pending/in progress/done - Output:
- Notes:
- Status:
pending/in progress/done - Output:
- Notes:
Instruction: For each completed task, generate and run the appropriate tests. Tests are part of task delivery — a task is only
donewhen its tests pass.
- Unit:
- Acceptance:
- Unit:
- Acceptance:
Instruction: Generate documentation based on what was actually implemented, not what was planned. If something in the plan was not built, it should not appear here.