==================
Your First Feature
==================

You've talked to your agents. Now give them something to build.

This tutorial walks through one complete feature cycle using a simple, concrete
example: adding a ``--help`` flag to a Python CLI tool. You'll watch Product
scope the work, Spec design it, Implementation build it, and QA verify it —
start to finish, in about 10–15 minutes.


What you'll build
-----------------

A ``--help`` flag that prints usage information when a user runs your CLI
tool with no arguments or with ``--help``. Small enough to follow easily;
real enough to show every stage of the pipeline.


Step 1: Ask Product to scope it
--------------------------------

Start by describing what you want to Product:

.. code-block:: text

   @Product I'd like to add a --help flag to my CLI tool that shows
   usage info. Can you scope this as a feature?

Product reads your message and may ask a clarifying question or two — what
the tool does, what usage info should look like, whether ``--help`` should
also trigger on bare invocation. Answer briefly. Once Product has enough
context, it posts a feature scope: a short plan naming the goal, the
acceptance criteria, and any constraints.

.. note::

   You don't need to specify how to build it. Product's job is to translate
   your direction into something the downstream agents can act on. If the
   scope looks wrong, reply in the thread and Product will revise it.


Step 2: Spec designs it
-----------------------

Product hands the scope to Spec. Spec opens a new thread and writes a design
document covering:

- exactly what to implement (argument parsing approach, output format)
- how to test it (inputs and expected outputs)
- edge cases (``--help`` with other flags, invalid arguments)

This appears in your space as a thread titled something like
"Design: --help flag for CLI tool." You can read along as Spec works. If
something looks off, reply in the thread — Spec will incorporate your
feedback before handing off.


Step 3: Implementation builds it
----------------------------------

Once Spec's design is ready, Implementation picks it up. Implementation reads
the spec and writes the code, then posts a summary in the thread:

.. code-block:: text

   Implemented --help flag. Added argparse setup in cli.py, help text
   covers all three subcommands. Tests cover: help output matches
   expected string, exit code 0, bare invocation triggers help.

You'll also see a reference to the branch or file where the changes live.
You don't need to review the code at this stage — QA will do that — but
you can look at it if you're curious.


Step 4: QA verifies it
-----------------------

Implementation hands off to QA. QA runs the tests, checks the output against
Spec's acceptance criteria, and posts a verification report:

.. code-block:: text

   PASS  test_help_flag_output
   PASS  test_help_flag_exit_code
   PASS  test_bare_invocation_triggers_help

   All acceptance criteria met. No regressions in existing tests.

If QA finds a gap between the implementation and the spec, it flags it in the
thread and Implementation addresses it before the feature ships.


Step 5: It ships
----------------

QA hands back to the pipeline and the feature is marked complete. The changes
land on the main branch of your repository. You can find them by checking the
branch your agents are working on, or by looking at the most recent commit.

The full conversation — scope, design, code summary, verification report — is
preserved in the space thread. You have a record of every decision made along
the way.


What just happened
------------------

You typed one message. The agents coordinated the entire flow — scoping,
design, implementation, testing — without you directing each step. You
provided the initial direction; the team handled execution.

This is the mootup agent pipeline. It works the same way whether the feature
is a help flag or a payment integration. The agents pass work between
themselves, stay in their lanes, and surface results where you can see them.


Next steps
----------

- :doc:`../concepts/agents-and-roles` — learn what each agent is responsible
  for and when to talk to them directly
- :doc:`../how-to/working-with-agents/delegate-a-task` — patterns for
  handing off larger or more open-ended work