Technical frame

This is the step where discovery stops producing documents only. The technical frame decides what the product is built with. Then it writes down the workbench that follows from those decisions.

Skill name: discovery-tech-frame-atlassian. This is the last discovery page before the build, and it reads every page before it: the brief, the personas and journeys, the domain model and the design brief. From each one it takes only what changes a technology decision.

How to start it

In a session that already has the domain model in it:

Let's settle the stack now. What would you propose, and why?

In a new session, name the skill and say where the pages are:

/discovery-tech-frame-atlassian The brief and the domain model are at
<Confluence URL>. Let's work out the technical frame.

What it works out with you

One concrete proposal per area, each with a reason. You correct it. Not every area applies to every product.

Note

From three building blocks up, the page also gets a component diagram: each part with its technology, and an arrow for who calls whom. It is an image, so you can open it full screen. The text and the tables stay the place where the decisions really live.

Area	What it wants from you
Backend	The language, and what it does in this product.
Frontend	Only where the brief needs a browser interface. The design brief already decided the shape, so this is about what delivers it.
Auth	Only where there is a login.
Data storage	Which service, taken from the domain model and not from habit: how many entities, what kind of relationships, and whether you need full-text or vector search.
How the data gets in	Migrations instead of an init script, and with which tool. The backlog puts this into the first story that needs a schema.
Object storage	Which service, if the app stores files.
External dependencies	A real service, a mock component in the repository, or a part of the backend. You decide this, it does not just happen.
Internal structure	Only when the domain model has more than one subject area. Whether each area becomes a module or a service of its own, and how the build checks that one area does not reach into another.
Operating frame	What the product has to cope with. In rough sizes, not in exact numbers nobody has, and only where it changed a decision.

Two things belong to every decision, and they are what makes the page useful a year later. The alternative you did not take, in half a sentence. Otherwise nobody can tell later whether you chose this or just inherited it. And one sentence on what the decision has to deliver. A requirement like “we can configure the usual OpenID providers” belongs there, not on a journey page.

Then the skill maps the decisions onto the workbench yml. It is strict about three words here. A database in its own container is a service. A tool installed into the workspace is a feature. Anything that comes from the project’s own package manifest, like Spring Boot, Django or Next.js, is a dependency, and it does not belong in the yml at all. The skill marks those as not part of it.

Note

The skill reads the component catalog live, through the bundled Monoceros docs connector. It does not remember component names, so the languages, services and features in the result really exist. If it cannot reach the connector, it uses the published catalog or asks you to paste the output of monoceros list-components --json. It never falls back to memory.

Where it lands

One Confluence page under the brief. It holds a short architecture overview, the building blocks and their interfaces, the technology decisions with their reasons, the operating frame, the conventions, the mapping onto the Monoceros definition, deployment, and the open points.

The mapping section holds the command itself, something like:

monoceros init acme --template=discovery-atlassian --with-languages=node --with-services=postgres --with-features=github

Note

acme is a sample workbench name, whatever you decide to call it. Use your own.

The command starts from the template on purpose. Claude Code, the discovery plugin, the three build roles and the Atlassian CLI come with it, so --with-features only carries what goes on top. The plugin is the reason. It is a nested block under a feature entry, and no flag and no add-* command can write one, so a workbench built without the template has Claude Code but not the discovery skills.

A repository on github.com, gitlab.com or bitbucket.org goes into that command as a --with-repos line. For any other host the page shows a second command below it:

monoceros add-repo acme https://git.example.com/acme/guestbook.git --provider=gitlab

A private repository needs a token in both cases, see Git and repos.

If you already have a workbench, from Setup, you do not need a second one. The mapping table lists the components flag by flag, and each flag has its own command: monoceros add-language, monoceros add-service and monoceros add-feature. Add them to the workbench you have and run monoceros apply once.

Watch the features there. The template applies to init and to nothing else, so a workbench you build this way needs claude, claude-code-roles and atlassian/twg named as well, not only the ones in the --with-features line above. That line is short because the template already brought the other three.

The plugin is the one thing you add by hand. There is no command for it, so open acme.yml and write a plugins: block under the claude feature entry. monoceros add-feature leaves a commented example there that you can overwrite. Then run monoceros apply acme.

features:
  - ref: ghcr.io/getmonoceros/monoceros-features/claude-code:1
    plugins:
      - url: https://github.com/getmonoceros/monoceros-discovery.git
        enable:
          - discovery-atlassian

Next

Now you have the workbench with the stack in it: your first workbench. Discovery continues with the backlog.