Features
This page walks through Forge’s main capabilities in plain language so you can understand what the product is for, what kind of information it keeps, and how the web app, API, and companion fit into the same system.
Execution And Planning
Forge plans work through one explicit ladder: Goal > Strategy > Project > Strategy > Issue > Task > Subtask. Projects are PRD-backed initiatives. Issues are vertical slices across the stack. Tasks are one focused AI session each, and subtasks are lightweight child steps.
Forge stores long-horizon goals, PRD-backed projects, vertical-slice issues, executable tasks, and subtasks as linked first-class planning records.
Strategies remain flexible and can sit above projects or inside a project plan, which keeps both strategy layers visible in the hierarchy instead of flattening everything into one list.
Each issue can be marked AFK when AI can complete it autonomously or HITL when a human decision is required at some point in the slice.
Issues and tasks can both preserve execution mode and acceptance
criteria, while tasks keep direct AI execution guidance in
aiInstructions.
Task runs record active or historical timed work, credited duration, manual adjustments, and current focus state.
Forge's PM workspace now supports a mixed-level board and a compact hierarchy tab, so you can browse work as lanes or as a full tree without losing context.
The board and hierarchy share search, state filters, level visibility, human and bot attribution filters, and hierarchy linking flows that can select or create the right parent record from one search-first modal.
Completed work can preserve modified files, a concise work summary, and linked git refs, so agents leave behind a truthful delivery record instead of only flipping a status field.
Habits are not task aliases. They have their own recurrence logic, check-in history, and reward consequences.
Forge supports provider connections, work blocks, native events, and task timeboxes under one runtime model.
XP and reward events are attached to concrete runtime behavior rather than decorative counters.
Memory And Knowledge
Notes are first-class Markdown evidence records with links to tasks, projects, goals, Psyche records, and other entities.
The wiki is file-first and supports pages, backlinks, vault sync, ingest, search, semantic indexing profiles, and explicit settings.
Shared tags provide classification across notes, goals, projects, issues, tasks, subtasks, and other records, with Forge PM shipping explicit `feature`, `bug`, and `knowledge` tags.
Preference profiles, contexts, signals, comparisons, and inferred scores are stored as inspectable data rather than opaque assistant output.
Forge supports runtime browse views, text search, and entity-linked search across the main knowledge surfaces.
Records can belong to human or bot users, and the runtime supports explicit cross-owner reads and linked work.
Health And Reflection
Sleep sessions store start and end time, time asleep, time in bed, stage breakdown when available, derived metrics, and linked context.
Workout sessions store type, duration, distance, energy, annotations, provenance, and links back to goals, habits, sleep, and Psyche data.
Values, beliefs, behaviors, patterns, modes, reports, questionnaires, and insights all live as structured runtime records.
Review routes and stored summaries support regular close-out and system-level reflection on what changed.
Activity feeds and event logs provide an operational timeline across execution, knowledge capture, and reflection surfaces.
The iPhone companion can import HealthKit sleep and workout data into the same Forge runtime model.
Agents And Integrations
Agent adapters expose curated Forge tools for overview, mutation, notes, wiki, habits, strategies, health, and UI handoff rather than dumping the entire internal API surface.
Forge gives humans and bots their own visible identities, ownership lanes, and relationship rules so collaboration stays understandable instead of becoming hidden automation.
The runtime serves a versioned API under /api/v1/
and a generated OpenAPI 3.1 document that powers the public
interactive docs.
Collaboration contracts define who can see, message, plan with, or directly mutate someone else's work, which makes shared execution safer and more accountable.
A human can keep strategic control while letting a bot help with planning, note-taking, or execution. Forge makes that legible by separating three ideas that usually get mixed together.
Visibility answers who can inspect another lane. Coordination answers who can message, link, and plan across lanes. Execution control answers who can create or mutate target-owned records.
The result is a shared operating system where automation feels trustworthy: bots are collaborators with explicit contracts, not invisible background scripts acting without context.
Consistency
| Concern | Current behavior |
|---|---|
| Web UI |
Mounted under /forge/ with responsive desktop and
mobile surfaces.
|
| API |
Mounted under /api/v1/ with a generated OpenAPI
document.
|
| Docs | Published through GitHub Pages with a product guide and interactive API explorer. |
| Storage | Local-first SQLite plus file-backed wiki content. |