Forge (LucasDuys) — Prompt Excerpts
Excerpt 1: brainstorm.md — Mandatory Q&A + Approach Proposal Pattern
Source: commands/brainstorm.md
## Step 3: Start brainstorming
**IMPORTANT: The brainstorm phase is mandatory before planning and execution.** The spec files
produced by this workflow are the ONLY way to get `status: approved` specs, which are required
by `/forge plan` and `/forge execute`. Do NOT skip this step. Do NOT write spec files directly
without going through the full interactive brainstorm flow.
Now invoke the `forge:brainstorming` skill with the user's arguments, plus any auto-detected
context (design system path, graph summary).
**Workflow enforcement:** The brainstorming skill MUST:
1. Ask clarifying questions (minimum 3, even for simple topics)
2. Present 2-3 approach proposals with trade-offs
Prompting technique: Gate enforcement via metadata (status: approved required by downstream commands). This makes the approval gate verifiable by code rather than by conversational contract.
Excerpt 2: execute.md — Pre-flight Gate Enforcement
Source: commands/execute.md
## Pre-flight Check
**The Forge workflow is strictly sequential: brainstorm -> plan -> execute.** These pre-flight
checks enforce that the prior phases completed correctly.
3. **Verify ALL spec files have `status: approved` in their YAML frontmatter.** Read each
`spec-*.md` file and parse its frontmatter. If ANY spec does not have `status: approved`,
stop and tell the user:
> Unapproved specs found: {list}. The brainstorm workflow must complete with explicit user
> approval before execution. Run `/forge brainstorm` and approve an approach.
This is the critical gate that prevents skipping the interactive brainstorm Q&A. A spec only
gets `status: approved` when the brainstorming skill writes it after the user explicitly
approves an approach.
Prompting technique: Machine-readable approval gate — the status: approved frontmatter field is parsed programmatically, not checked conversationally. Unusual: the gate is enforced by the receiving command, not by the producing command.
Excerpt 3: execute.md — v2.1 Feature Block (Worktree Isolation)
Source: commands/execute.md
## New in v2.1
- **Token budgets** are now enforced as hard ceilings, not warnings. Exhaustion transitions to
`budget_exhausted` phase with a handoff doc at `.forge/resume.md`.
- **Git worktree isolation** per task: each task runs in `.forge/worktrees/{task-id}/` and is
squash-merged on success.
- **Lock file acquisition** at session start: refuses to run if another valid lock is held
(unless stale >5min).
- **Per-task checkpoints** at each step: resume picks up exactly where the last checkpoint
was written.
- **Headless mode** for CI: see `node scripts/forge-tools.cjs headless execute --help`
Prompting technique: Changelog-in-prompt — the "New in v2.1" block inside the command prompt ensures Claude knows which behaviors are current, preventing it from describing deprecated behavior.
Source: commands/execute.md
**Live status header.** Every iteration of `/forge:execute` is automatically prefixed with a
compact dashboard-style status block (phase, current task + step, agent, progress bar, tokens,
per-task budget, lock status). You see what forge is doing without leaving Claude Code or running
a separate command. The block is generated by `scripts/forge-status-block.cjs`, called from the
Stop hook on every iteration. Opt out by setting `execute.status_header: false` in
`.forge/config.json`.
Prompting technique: Observability contract defined in the prompt — the status block is mandatory behavior described in the command, with an explicit opt-out path.