Project files

A new project directory is empty. Everything that is true for every task has to come from somewhere: the stack, the conventions, the names, the way the work runs. Without one place for it, every story repeats it, or somebody guesses it. This skill writes that place.

Skill name: handoff-project-files-atlassian. It reads all of the discovery, including the backlog.

Caution

Run this skill where the project directory is and where the agent can write to it: in a workbench, or in Claude Code with that directory open. It does not matter whether there is code in it yet. The skill then writes the files itself. The README and the public agent instructions go into the project root. The private instructions go into .claude/ or .opencode/, and the skill adds that path to .gitignore.

In claude.ai and in the desktop app the agent cannot write files. You get the same content as Markdown blocks in the chat, one per file, with its target path above it. You then create the files and the .gitignore entry yourself.

How to start it

From the workbench, in the directory the project lives in:

Let's write the project files for this project.

In a new session, name the skill and say where the discovery is:

/handoff-project-files-atlassian The discovery is at <Confluence URL>.
Write the project files into this directory.

What it asks first

One question, and the skill never assumes the answer: who may see what. Is the code public? Is the discovery public? Is the tracker public? Those three answers decide what may go into a file you commit and what has to stay in a private file. They are the difference between a useful handover and a leak.

Then it proposes a development flow instead of assuming one, and it shows you both files before it writes anything.

What goes into the README

Short, and only from the discovery pages. A README for a new project gains nothing from being long.

Part	What goes in it
Name and one sentence	From the one-line pitch in the brief.
The problem and who has it	Two or three sentences from the brief. A stranger reads this part, and no generator can invent it.
Status	Honest: early, and what does not exist yet.
Getting it running	What you need and which commands to run, from the technical frame. Plain steps if the project is not a workbench.
Configuration	The environment variables the technical frame names. The names, never the values, and never a default that would work in production.
License	Only if you decided on one. If you did not, the README says that it is missing. The skill does not pick one for you.

The README is the most public file in the repository, so the rule about internal pages is strictest here. No link into Confluence, no issue key, no customer name, not even under “see also”.

What goes into the agent instructions

Only what is true for every task, and only what is in the discovery pages.

Part	What goes in it
What the product is	Two sentences from the brief. An agent that knows the purpose makes better small decisions.
The stack	From the technical frame: the languages, the services, and what the app brings as its own dependency.
Cross-cutting conventions	Word for word from the technical frame: authentication, validation, the shape of an error, how identifiers are built, migrations instead of an init script.
Domain vocabulary	The entity names, one line each, and the language you chose for names in the domain model. This is what keeps every story from inventing its own words.
Structure	Only with more than one subject area: one module per area, the entities it owns, and the direction between them. The agent reads this file while it builds, so this is how the areas get into the code.
Where decisions go	docs/adr/, numbered, plus the rule that nobody reopens a decision that is written down.
How the work is run	Servers through monoceros-ctl and .monoceros/launch.json, not by starting them in a shell. Plus what an acceptance command looks like, including the check that keeps the areas apart.
The development flow	Only if the tracker is public. If it is not, the whole flow goes into the private file.

The file is CLAUDE.md for Claude Code and AGENTS.md for OpenCode. Both are English unless you ask for something else, even when the discovery pages are in your language. They sit next to the code, the ADRs and the commit messages.

Note

Run it again whenever the technical frame or the domain model changes. An old guide is worse than no guide, because the agent believes it.

Next

The project has what it needs, and the build starts. In the workbench the Claude Code roles pick up a story: one writes the plan, one implements it, one reviews the result against the plan.