Tools Reference

Manifest exposes 27 tools that AI agents use to manage features, projects, and versions. Agents receive built-in instructions that tell them which tool to call and when, so you don't need to remember specific tool calls. Just use natural language. In practice, if you have a well-organized feature tree, the most common workflow is just asking "what's next?" and letting the agent take it from there.

This page is a reference for when you want to understand what's happening under the hood.

Each tool is tagged with a category that indicates its role in the workflow:

Tag	Purpose
ORIENT	Read-only tools for understanding what exists
SETUP	Create projects and structure the feature tree
DISCOVER	Analyze existing code to generate features
CLAIM	Signal the start of implementation work
UPDATE	Modify feature fields (state, details, priority)
DOCUMENT	Record completed work and ship versions
PLAN	Organize features into release milestones
CLEANUP	Permanently remove archived features

Discovery

Read-only tools for understanding the current state of projects, features, and versions.

list_projects ORIENT

List all projects, or find the project associated with a specific directory. This is typically the first tool an agent calls to discover what project it's working in.

When to use

At the start of any session, or when the agent needs to resolve a project_id for other tools.

Key parameter

directory_path (optional): pass the current working directory to find the matching project automatically.

get_project_instructions ORIENT

Get full project-level instructions: coding guidelines, conventions, and architectural decisions. Returns the complete root feature details.

When to use

When the breadcrumb summary from get_feature mentions that more context is available, or when starting work on an unfamiliar project.

get_active_feature ORIENT

Get the feature currently selected in the Manifest web app. This is the default tool for resolving what the user means when they say "this feature", "work on this", or "implement it".

When to use

Whenever the user references a feature without naming it explicitly. Call this first, then confirm by naming the feature in your response.

Returns

The focused feature, or null if nothing is selected.

get_next_feature ORIENT

Get the highest-priority workable feature from the next unreleased version. Returns the top proposed or in_progress feature.

When to use

Only when the user explicitly asks "what's next?", "what should I work on?", or "next feature". Do not use this when the user references a specific feature.

find_features ORIENT

Search for features by project, state, or keyword query. Returns summaries only. Use get_feature for full details.

When to use

When looking for a feature by name or filtering by state (e.g., "show me all in-progress features").

Key parameters

project_id, state (proposed / blocked / in_progress / implemented / archived), query (keyword search).

get_feature ORIENT

Get the full feature specification with hierarchical context. Returns the feature details plus a breadcrumb showing ancestor context (architectural decisions, conventions, constraints).

When to use

Before starting implementation, to read the spec and understand parent context. Set include_history=true to see past work sessions.

render_feature_tree ORIENT

Render the full feature tree as ASCII art with status indicators. Essential for understanding project structure at a glance.

When to use

When the user asks to "show the tree", "show features", or when you need an overview of the project structure.

Status symbols

▣ project root, ▪ feature set, ◇ proposed, ⊘ blocked, ○ in_progress, ● implemented, ✗ archived.

get_project_history ORIENT

Get recent activity across a project. Returns a pre-rendered timeline of completed work with summaries and commits, grouped by time. Mirrors the web app's Activity tab.

When to use

When the user asks for "recent activity", "what happened", "show history", or "changelog".

orient ORIENT

Session bootloader — get all project context in a single call. Returns project info, condensed feature tree, active feature (if selected in UI), work queue (top 3 proposed), active agent sessions, and recent completions.

When to use

As the first call when starting a session, instead of calling list_projects → get_active_feature → render_feature_tree separately.

Follow up with

get_feature for full details on a specific feature, or start_feature to claim work.

list_versions ORIENT

List all versions for a project with their lifecycle status: next (first unreleased), planned (remaining unreleased), or released (shipped).

When to use

Before assigning features to versions, or when the user asks about the release roadmap.

Setup

Tools for creating projects, structuring feature trees, and bootstrapping from existing codebases.

init_project SETUP

Initialize a project from a directory. Analyzes the codebase (language, framework, structure) and creates a project with the directory linked.

When to use

When setting up Manifest for a new codebase. Can also link a directory to an existing project by passing a project name or UUID.

Typical sequence

init_project → generate_feature_tree → plan → create_version

add_project_directory SETUP

Associate an additional directory with an existing project. Use this for monorepos where multiple directories belong to one project.

When to use

After init_project, when you need to add more directories (e.g., a separate frontend and backend repo under one project).

generate_feature_tree DISCOVER

Analyze an existing codebase's code structure and git history to generate a feature tree document. Returns a markdown description of system capabilities.

When to use

When onboarding an existing codebase. Use the since parameter to limit analysis to recent commits (e.g., v1.0.0).

plan SETUP

Decompose a PRD or vision into a hierarchical feature tree. Supports a two-step flow: call with confirm=false to preview, then confirm=true to create.

When to use

When breaking down requirements into features. Always provide a target_version_id so features land in a release. Otherwise they go to the Backlog.

After confirming

Use update_feature to distill the root feature: replace the full PRD with high-level project context since details now live in child features.

create_feature SETUP

Create a single feature. Name features by capability (e.g., "Router") not by task. Use parent_id for grouping. For bulk creation, prefer plan.

When to use

When adding a single feature to an existing tree, or when the user asks to "add a feature for X".

Leaf vs parent

Leaf features should have a concise specification in details. Parent features should have shared context (architecture, patterns) that applies to all children.

Implementation

Tools for the implementation lifecycle: starting work, updating specs, recording completion.

start_feature CLAIM

Signal that you are starting work on a feature. Transitions state to in_progress and returns the full feature spec. Mandatory before implementing.

When to use

Always call this before implementing a feature, even if you just created it or already have context. It validates that the feature has a spec.

Spec gate

Rejects features with no details. Write a spec first using update_feature. Warns on sparse specs.

Blocked guard

Rejects blocked features and features under a blocked ancestor feature set. All blockers must reach implemented before the feature can be started.

Leaf features only

Rejects feature sets (parents with children). Work on child features instead.

update_feature UPDATE

The Swiss Army knife for feature modifications. Can change any field: title, details, state, priority, parent, or version assignment.

When to use

During implementation: update details to reflect what was actually built. For reorganizing: change parent_id to move features. For proposing changes: set desired_details for human review instead of modifying directly.

Key parameters

details (set directly), desired_details (propose for review), state, priority, parent_id, target_version_id, blocked_by (required when setting state to blocked).

complete_feature DOCUMENT

Mark work as done. Records a history entry with your summary and commit references, then transitions state to implemented. Mandatory after implementing.

When to use

After implementation is verified. Provide a summary describing what was built and key decisions. Include commit SHAs via the commits parameter.

Leaf features only

Rejects feature sets. Parent status is derived from children automatically.

prove_feature DOCUMENT

Record test evidence for a feature. Accepts structured test results with pass/fail outcomes, enabling Manifest to track proof across the TDD cycle.

When to use

After running tests during implementation. Call once with failures (red), then again after implementation with passes (green). Required before complete_feature.

Key parameters

exit_code (0 for passing), results (array of structured test outcomes with name, suite, state, file, line, duration_ms, message).

get_feature_proof ORIENT

Get the latest proof and verification status for a feature, rendered as a checklist. Shows proof status, test command, structured test results with pass/fail symbols, acceptance criteria from the spec, and verification comments. Read-only.

When to use

When reviewing a feature's test evidence, or before calling complete_feature to confirm proof exists and is passing.

verify_feature DOCUMENT

Verify that an implemented feature still works correctly. Runs acceptance criteria checks against the current codebase and records the outcome.

When to use

After major refactors or dependency updates, to confirm existing features haven't regressed.

record_verification DOCUMENT

Record a manual or automated verification result for a feature. Unlike prove_feature (which records test evidence during implementation), this records post-implementation verification.

When to use

When verifying features outside the implementation flow, such as QA reviews, manual testing, or periodic verification sweeps.

delete_feature CLEANUP

Permanently delete a feature and all its descendants. This action cannot be undone.

When to use

Only for archived features that are no longer needed. Prefer archiving (via update_feature with state: "archived") to preserve history.

Sync

Tools for synchronizing Manifest state with external systems.

sync DISCOVER

Synchronize the project's feature tree with the current codebase state. Analyzes code changes and suggests feature state updates based on what has been implemented, modified, or removed.

When to use

After significant code changes outside of Manifest's workflow (e.g., manual commits, merges from other branches), to bring the feature tree in sync with reality.

Version Management

Tools for organizing features into release milestones.

create_version PLAN

Create a release milestone. Names must be semantic versions in MAJOR.MINOR.PATCH format (e.g., 0.2.0, v1.0.0).

When to use

When defining a new release milestone for feature planning.

set_feature_version PLAN

Assign a feature to a release version, or unassign it (move to Backlog). Only unreleased versions are valid targets.

When to use

When scheduling features for a release. Pass null for version_id to move a feature back to the Backlog.

release_version DOCUMENT

Mark a version as shipped. Sets the released_at timestamp and the next Planned version becomes the new Next.

When to use

When all features in a version are implemented and the user confirms it should be shipped. Always ask before releasing.

Typical workflow

The standard sequence an agent follows when implementing a feature:

1. list_projects: find the project for the current directory
2. get_active_feature or get_next_feature: find the right feature
3. start_feature: claim the work, get the spec
4. Write failing tests
5. prove_feature: record red proof
6. Implement the feature
7. prove_feature: record green proof
8. update_feature: update details to reflect what was built
9. complete_feature: record summary and commits

Next step

Continue to Web UI.