Introduction

​

A Project is your workspace for a specific repo or codebase.

A Project is your home base in blprnt for a specific codebase or initiative. It’s where context lives, where access is scoped, and where the app can stay grounded.

• Connect your project folder: this defines the sandbox the agent can safely read from and write to while working on your project.
• Add an Agent Primer: this is the “always-on” starting context for new sessions in the project.
  • Include things like code conventions, naming patterns, architecture notes, workflow preferences, and project goals.
  • The better your primer, the less you have to repeat yourself every time you start fresh.

• Memories are created automatically: the agent will save key decisions, definitions, and structure as it goes.
  • Future sessions (and subagents) can reference these memories to stay consistent and avoid re-litigating the same choices.
  • Memories can also be user-specific preferences-e.g., “I hate the color red, use blue instead”-so the app adapts to how you like to work. These memories are stored outside of the project context and can be referenced by other projects.

​

A Session is where you collaborate with the agent on real work.

A Session is where you actually collaborate with the AI-think of it as an ongoing working thread with memory, momentum, and the ability to produce real outcomes (not just advice).

• Capture the conversation and the decisions: you get a clear record of what was discussed, what was chosen, and what the agent was asked to do.
• Sessions are action-oriented: they’re designed for turning requests into results-planning work, drafting changes, and helping move tasks to completion.
• Depending on what you need, the system can switch between exploratory chat, structured planning, focused execution, or verification-style review.
• When tasks can be split cleanly, blprnt will delegate to specialized subagents and keep the output coordinated in the session.

​

Plan work with a real structure (not a pile of messages)

A Plan is how blprnt turns “we should do X” into work you can actually track and finish. Plans are created by an agent (or a focused subagent) and include both the written plan and a checklist of todos with clear statuses, so you always know what’s next, what’s in progress, and what’s done.

• Agents create plans so execution stays aligned: the same system that writes the plan uses it as the source of truth while doing the work, reducing drift and forgotten steps.
• Subagents can own individual todos: blprnt can delegate specific items (e.g., “implement the UI change” or “update persistence logic”) to specialized subagents while keeping everything tracked in one place.
• Plans support safe iteration: if requirements change midstream, the agent updates the plan/todos rather than silently improvising-so you can see what changed and why.
• Plans make verification natural: todos are scoped so results can be reviewed and validated before moving on, catching mistakes early instead of at the end.

Subagents are focused specialists blprnt can spin up to handle one part of the work while keeping everything coordinated in your session and plan.

• Research: read-only discovery to find where things live and how they work.
  • Used for: locating files, tracing flows, summarizing patterns, mapping “where is X implemented?”
  • Output: paths, key snippets, and a concise summary you can act on.
• Design: UX/UI direction and interaction guidance without writing code.
  • Used for: layout decisions, component behavior, visual hierarchy, token/variable guidance, UI consistency.
  • Output: a design brief you can hand to an executor (or implement yourself).
• Planning: turns a goal into a concrete plan plus a todo list with statuses.
  • Used for: breaking down multi-step work, sequencing dependencies, defining acceptance criteria.
  • Output: a plan you can execute safely, one todo at a time.
• Execution: implements a well-scoped todo by making actual changes.
  • Used for: adding or modifying code, wiring features, updating configs, creating migrations, implementing components.
  • Output: the completed change for that specific todo (kept intentionally scoped).
• Verification: reviews the work for correctness and completeness before you move on.
  • Used for: catching mistakes, mismatched requirements, edge cases, regressions, or incomplete scope.
  • Output: a pass/fail verdict with concrete fixes if anything is off.