Give developers the decisions behind the build.

Choose the work you are ready to hand over

The developer package starts with material already saved in your AlphaTales project. Select the features and application workflow groups that belong in the build, then include the available architecture. This lets the handoff reflect a specific delivery scope rather than every idea the team has discussed.

Each part answers a different implementation question:

• Application workflows explain the people, steps, decisions, and outcomes the software needs to support.
• Feature specifications carry the intent, scope, functional requirements, acceptance scenarios, and saved details such as permissions, data, edge cases, and verification needs.
• Architecture supplies the technical direction, stack choices, and available implementation decisions.

Customer projects can also include a PRD when one is available. Internal application projects use their workflow, feature, and architecture material without needing a separate PRD. Review what is ready before handing it over; packaging a draft does not resolve its open questions.

Take the files, or connect your coding tool

You can download a Dev Pack for a developer to use locally, or connect a compatible coding assistant to AlphaTales through Build MCP. The download gives you selected files at a point in time. The connection lets the assistant request project and feature context as it works.

A downloadable package your team can inspect

The manual download produces a ZIP or TAR.GZ archive. Inside the .alphatales/ folder, the selected planning material is organised into readable Markdown files: architecture, individual feature specifications, and application workflow documents. A manifest records the project, selection, and generation time.

Extract the package into the workspace where development will happen and let the team inspect it before implementation. A developer can read the files directly; a coding assistant with access to that workspace can use them as context. The archive contains the planning handoff, not a finished application.

Keep track of which version the team is using. If a requirement or technical decision changes in AlphaTales, the downloaded files stay as they were. Review the change and create a fresh package when you need the updated plan.

Build MCP brings project context into the coding session

MCP, or Model Context Protocol, gives a coding assistant a way to call AlphaTales tools. The Dev Pack page provides setup options for Codex, Claude Code, Antigravity, Cursor, and GitHub Copilot. Connect the client, sign in, and select the correct project before asking it to use your planning material.

Through Build MCP, the assistant can read the project’s architecture and stack choices, list features, and retrieve a feature’s requirements and any existing engineering tasks. It can also use the available assignment and progress tools when your permissions allow. This keeps implementation work tied to a specific project and feature.

If you ask the assistant to initialise the workspace, the bootstrap workflow supplies available Dev Pack files and guidance for the folder structure, dependencies, and agent instructions. The coding assistant carries out that local setup. Reading context and preparing a workspace are separate actions; connecting MCP alone does not build the application.

Agent instructions from that setup are also separate from the manual archive. The Dev Pack download does not currently include the app’s Agent Rules option.

The Agent plugin packages workflow instructions with two MCP connections. It helps an assistant follow the AlphaTales planning and build process, while Dev Pack remains the material used for the handoff.

Plan MCP

Supports organisation context and the planning workflow, including questions, research, features, and architecture.

Build MCP

Provides the approved project’s coding context, workspace setup guidance, and feature work tools.

The plugin’s build workflow checks that planning has completed before passing the same project to Build MCP. Its skills guide the assistant through the required questions and approvals; the coding client still performs the implementation. The plugin does not replace the project’s planning content or remove the need for access to it.

The Agent plugin is shown here as a preview. Direct Build MCP setup and manual Dev Pack downloads are separate options.

Keep the plan close to the implementation

A useful developer handoff leaves fewer decisions to guess. Start with the selected feature’s scope and acceptance scenarios, read the workflow it supports, and check the architecture before making technical choices. Use those same requirements to review the result.

Your team still owns code review, testing, and release decisions. When implementation exposes a missing rule, resolve it in the plan and refresh the context being used. That keeps the next change grounded in the team’s decisions.