# Team playbook

> Faithful English translation of the Polish original.

This playbook is meant to help us work together: everyone knows what matters most, who is responsible for the result, where to find knowledge, and when to show a change. A new person should be able to join the work without reconstructing decisions from many conversations.

I based the outline below on my own playbook. I expanded it with neutral examples so you can see how to fill it in. Treat the former rules from my document as a starting point for discussion. In your version, write down how you want to work and what you actually use.

**The examples concern a fictional case-management application. They do not describe the composition, results, or current rules of my team.** Labels A–D show an example division of work, not required job titles. Fill in fields in square brackets together with the agent.

## 1. How to use this file

1. Attach it to the project conversation. Point to the existing playbook, documentation, and team tools.
2. Go through the areas below. The agent should compare the examples with your work, cite sources, and ask about gaps.
3. Keep the agreements that make sense. For the rest, write down what needs clarification. If a playbook already exists, add to it.
4. Save the agreed version in one place and link it in the project. Check the rules against current work, then improve whatever gets in the way.

You do not have to adopt every example or create a separate file for each area. Also agree on which materials may be shared with the agent. Do not put passwords, keys, or confidential employee information into this template.

| Agreement status | Meaning |
| --- | --- |
| In force | The team agreed to it; it is clear from when and to whom it applies |
| To confirm | It is in an old document, but we have not checked whether we still use it |
| Proposal | We want to discuss or try it; it is not in force yet |
| To decide | A decision or responsible person is missing |

## 2. Why the team exists and what it develops

Start with whom you help and what should improve. Delivering another feature alone does not yet say whether it was needed.

| Field | Example | For us |
| --- | --- | --- |
| Product and user | Application for people handling customer cases | [enter] |
| Need | Find cases waiting for a response faster | [enter] |
| Product boundaries | Case handling; billing remains in a separate system | [enter] |
| Who sets priorities | Person A, responsible for the product | [role or named person] |
| Where the work list is | Team board in Jira | [link] |
| Where the playbook applies | Playbook home page in Confluence | [link] |
| Who keeps it current | Person A collects feedback; everyone is responsible for their own areas | [agreement] |
| Version and review | [version / date / who confirmed] | [enter] |

**Example rule:** before starting a change, we can say what the user will do faster, more easily, or with fewer errors because of it. If we cannot, we return to the need.

### Roadmap and quarterly goals

In our work, we look at roadmap goals, and people have individual goals and a quarterly area of responsibility. In the playbook, write where your current plan is, who agrees the goals, and when you revisit them.

The [Roadmap, team goals and individual goals](team-cele-i-roadmapa-en.md) template includes a plan for important outcomes, team goals, a person's responsibility card, and a weekly priority review. Connect these agreements to tasks with links. Goals do not replace the current work queue; they show why you do the work and who leads a given area.

## 3. Map of rules and knowledge

In my playbook, the main page leads to six areas. Each rule has one home, and other documents link to it.

| Area | What we keep there | Example entry | For us: link / who fills it in / who checks |
| --- | --- | --- | --- |
| Product rules | Audiences, goal, priorities, and decision criteria | “The priority is shortening case handling, not the number of screens added” | [complete] |
| Domain knowledge | Terms, rules, exceptions, and their rationale | What an “urgent case” means and who decides an ambiguous case | [complete] |
| Team organisation | Responsibilities, work rhythm, communication, and tasks | Who leads a change, who checks it, and who covers an absent person | [complete] |
| Delivering changes | Implementation, demo, tests, acceptance, releases, and incidents | How a small fix reaches the user | [complete] |
| Interface | User journey, forms, messages, and shared elements | How we show a save error and retain entered data | [complete] |
| Technical rules | System construction, work with code, agents, and tests | Where the project instructions are and how to run checks | [complete] |

The playbook also leads to **operational documentation in Confluence**. It describes the state of the system: architecture, repositories, data, integrations, environments, deployments, monitoring, backups, tests, access, and instructions for problems. The playbook specifies who updates this knowledge and when we check it. Code remains the source of implementation information; do not guess the historical reason for a decision from code alone.

| What we record with a source | To complete |
| --- | --- |
| Product and scope it concerns | [e.g. case handling, excluding billing] |
| Person who maintains the content and person who checks it | [agreement] |
| Date last confirmed / system version | [date and version or “not checked”] |
| Known gaps and further work | [link to existing task or plan] |

### Working with an external contractor

Review these agreements before the first task, including when you commission a modernization or rewrite of a system. On your side, one person sets the framework and checks the result; the contractor is responsible for the agreed work and its description. This is a template for operational agreements to adapt, not ready-made contract wording.

| What to agree | Your wording |
| --- | --- |
| Documentation from the start | [location, outline, required descriptions; who completes and who accepts] |
| Company tools and assets from the start | [GitHub organisation, Jira/Confluence, boards in use, e.g. Miro, GCP projects, all domains including technical and test ones; company owner, administrator, billing, and confirmation of control] |
| Exit plan in the contract from the start | [link to agreed end-of-engagement plan; handover scope, dates, contractor support, and acceptance conditions] |
| Knowledge inside the company | [who learns development, deployment, and maintenance; when they perform it independently] |
| Availability and coverage | [key roles and named people in your agreements, availability, coverage, and how knowledge is handed over] |

For every tool, cloud project, and domain actually used, record separately: who the asset is registered to, the company administrator, the payer, and the access-check result. Include technical and test domains as well, with the person responsible for renewal. This is a list of your assets, not a set of tools to install.

**Exit plan — agreements before the start:**

- What triggers the handover and from when we count the agreed dates: **[agreement]**
- What the handover covers exactly: **[assets, data and history, documentation, knowledge, open tasks]**
- Who leads it on each side and who can cover them: **[responsibilities]**
- What contractor availability we need and how we settle agreed support: **[agreement]**
- Who maintains the system during the takeover and until when: **[agreement]**
- How we confirm completeness, where we record gaps, and who fills them: **[acceptance conditions and next steps]**

Link these agreements to the contract and the current handover list. Company accounts from the start reduce later transfers; they do not replace knowledge transfer and checking that the team can work independently.

**Handover list — complete it in the existing plan.** Each row is a result to demonstrate, not a general promise of handover. The conditions below are examples to adapt; trials concern a safe environment and the agreed scope.

| What we hand over | Responsible on the contractor side / our recipient | Date | Acceptance condition | Evidence and status |
| --- | --- | --- | --- | --- |
| Control over tools, GCP, and all domains | [roles] | [date] | A company person confirms the owner, administrator, and billing for every asset; including technical domains, their renewal, and the history of tasks and documents | [link to confirmation; no secrets] |
| Code and startup | [roles] | [date] | A person on our side starts the application from the company repository following the instructions | [version, trial result / gap] |
| System documentation | [roles] | [date] | The team finds the feature description and can carry out the agreed instruction without the author filling in details | [pages and trial result / gap] |
| Deployment and maintenance | [roles] | [date] | Our person deploys a version in testing, performs the agreed rollback trial, and knows where to check an incident | [version, results / gaps] |
| Knowledge and current work | [roles] | [date] | The taking-over person explains the agreed rule and leads a selected change; they know where open tasks are | [trial result / questions to clarify] |

For legacy systems, add who maintains the current system during changes and who takes over maintenance after the switch. Separate today's state from what you have only agreed. Repository access alone or a knowledge-transfer meeting does not confirm independence.

Approve handover based on evidence. This list is not authorization to transfer accounts, change permissions, contracts, or production — those actions require the appropriate decision in your project. Share permitted materials with the agent without passwords, private data, or confidential commercial terms.

## 4. Who is responsible for what

In the model I am aiming for, there are two roles: a domain Product Owner with analytical aptitude and AI Engineers. The Product Owner sets the need, rules, and priority, then accepts the result. The AI Engineer leads a change through the screen, logic, and data, checks it, and prepares a release with the help of agents.

**Example division of responsibilities in a four-person team:**

| Person | Responsible for | Who they check with / who covers |
| --- | --- | --- |
| A — Product Owner | Need, rules, priority, interface decisions, and user acceptance | Agrees intent with the lead AI Engineer; coverage agreed before absence |
| B — AI Engineer | Complete features in their area; additionally, release coordination | C checks the change; release cover agreed with D |
| C — AI Engineer | Complete features in another area; additionally, shared quality checks | B checks the change; this is not a separate testing department |
| D — AI Engineer | Complete features in their area; additionally, environments and shared technical decisions | B knows the maintenance instructions; cover has the required access |

A–D are a fictional example, not a description of the actual team composition. Record your own division of areas and coverage. There is no separate tester here: the AI Engineer uses agents to run tests, check evidence, and arrange an independent review. The Product Owner accepts product behaviour. When skills are missing, name the support needed.

| Decision | Who makes it for us | Where it is recorded |
| --- | --- | --- |
| What we do now and what we defer | [person responsible for product] | [work list] |
| How a rule and its exceptions should work | [person who knows the domain] | [rule source] |
| Which technical solution we will use | [person responsible for technology] | [decision in plan or documentation] |
| Whether the result meets the need | [accepting person] | [acceptance on the task] |
| When we release and who responds to a problem | [person responsible for release] | [release card / portal] |

## 5. One main task and a work rhythm

In my playbook, I adopted one main task per person. Helping others, code review, and incident response fit alongside it. If urgent work comes in, we explicitly agree what we defer and how the deadline changes.

| When | Example rule from my playbook | What should remain afterwards |
| --- | --- | --- |
| Daily, without a meeting | Short message: today, tomorrow, planned completion | It is clear what moved and when to expect a result |
| Once a week | An hour for priorities, blockers, outcomes, and main tasks | Agreed order and responsibility |
| When a blocker appears | Chat conversation and, if needed, a quick meeting of the right people | A decision or concrete help |
| When there is something to show | Ongoing demo and acceptance | Feedback, a decision, and the next step |

These are examples from an older playbook, not a mandatory calendar of ceremonies. Today, I rely on a short conversation between the Product Owner and AI Engineer when intent must be conveyed, a decision made, or a result seen. Record the essence: for whom, expected result, out of scope, and open question. The Product Owner confirms the summary prepared by the agent. Do not wait for the weekly review with a question that stops work.

**Example short message** — I added a blocker field to the basic format:

```text
Today: the urgent-case filter works in the local preview.
Tomorrow: I will check the empty list and behaviour after a priority change.
Planned completion: tomorrow after checking and demo.
I need: confirmation of what should happen to a case without a priority.
Task: [link].
```

Do not repeat the entire task history in the message. Status and evidence stay with the task, while chat helps people agree quickly.

## 6. Where we work and where we ask questions

The table gives an example based on tools we use. In your version, name specific places; do not install the whole list just to tick it off.

| Place | What it is for | What we record there |
| --- | --- | --- |
| Jira | Agreed work and its status | Goal, scope, responsibility, check results, links to code and acceptance |
| Confluence | Shared rules and knowledge | Playbook, decisions, rules, and maintained system documentation |
| GitHub and CodeRabbit | Code and change review | Change proposal, comments, and review result; automated comments require assessment |
| Google Chat — team conversations | Questions, blockers, and a short daily update | Topic, help needed, and task link |
| Google Chat — releases and incidents | Production status and quick response | What was released, where, check result, and who leads the problem |
| Deployment portal | View of versions in environments | The version actually running and the result of checking it |
| Monitoring, e.g. UptimeRobot | Information about an availability problem | Alert and indication of who responds; an alert alone does not confirm correct calculations |

The names of the two conversation places above are descriptive. Enter your own channels and their rules of use. Link the remaining tools, including cloud, VPN, and access management, to instructions in operational documentation. The playbook should lead to them.

**Example rule:** if we agree a rule change in chat, the person leading records the decision and its reason in the appropriate document. They add a link to the task. The agreement does not remain only in conversation.

## 7. What a Jira task looks like

This is a shared standard for recording work. The playbook itself covers the whole team; the card below only shows how to apply the standard.

| Field | Example completion |
| --- | --- |
| Title | Show urgent cases in the list |
| Why and for whom | A person handling cases should quickly find cases requiring action |
| Scope | Priority filter, empty list, and behaviour after a priority change |
| Out of scope | Automatic priority determination and sending notifications |
| Acceptance | After enabling the filter, only cases marked urgent are visible; no results has a clear message |
| Rule | We use the existing priority definition [link]; no rule requires an agreement |
| Lead / accepting person | B / A — example, not an actual assignment |
| Risk and check | The filter, no results, and permission behaviour must be checked: the filter does not reveal other people's cases |
| Links | [plan], [rule], [GitHub change proposal], [test results] |
| Status | Example task before implementation; tests have not yet been run |

A larger initiative can be grouped in an **Epic**, meaning a topic connecting several outcomes. A **Task / Story** describes an independent change, and a **Bug** describes a defect fix. Add subtasks when they help divide the work.

| Status | What it means in this example |
| --- | --- |
| Backlog | The topic is waiting its turn |
| To do | It is clear what is to be created, who leads it, and how we will check the result |
| In progress | Discovery, implementation, demo, or fixes are under way |
| Ready for acceptance | There is a result, check evidence, and a person who can assess it |
| Technically accepted | The change meets agreed conditions; we record release status separately |

**A release has its own status:** not applicable / awaiting decision / planned / deployed and checked / rolled back. Agree which status corresponds to your “Done” in Jira. Demo acceptance is not authorization for production.

You can mark a blocker with a flag on the task. Add what is missing and from whom help is needed. Do not leave only the word “blocked.”

## 8. How much we check before accepting a change

In my playbook, I distinguished three modes depending on risk. Below are examples to agree. A small code scope does not always mean small risk.

| Mode | Example | How we lead and check it |
| --- | --- | --- |
| Small change — Fast | Typo or spacing, without a behaviour change | We view the result and check what could have broken; the appropriate person accepts the result |
| Normal implementation — Standard | New filter, integration, rule change, or permissions | Requirements and decisions first; then demo, review, risk-appropriate tests, and checking in a test environment |
| Incident — Emergency | Application unavailable or data at risk | One person leads the response; we agree a safe fix or rollback, check the critical journey, and complete the record after service is restored |

If scope, risk, or uncertainty grows, we change how we lead the work. An urgent fix still requires a responsible person and checking the result. It does not give the agent extra production permissions.

## 9. Working with agents, demo, and review

These rules combine examples from the playbook with my way of working described in The A-Team. Adapt them to your tools and permissions.

| Moment | What we do | What remains after this work |
| --- | --- | --- |
| Start of a stage | Identify the need, project instructions, knowledge, scope, and checking method | One plan linked to the task; questions and decisions before implementation |
| Work | Lead the main topic in one chat; the agent implements the agreed fragment | A working increment and current status in the plan |
| Side question | A general explanation can be obtained in a separate chat, without changing files | An important decision returns to the main task |
| First screens | The Product Owner accepts main journeys and the design system; the AI Engineer records the rules and points agents to components | Subsequent views follow these agreements; a new pattern requires agreement |
| Parallel work | AI Engineers lead different features. Before starting, they check shared files, data, and components; they agree who owns a collision | Separate branches and work directories; order of shared change and a person checking the combination |
| Demo | A person views the result of even a small task; they stop the show, record feedback, or request a fix now | One feedback list in the existing plan or task and a clear acceptance scope |
| After the demo | We fix feedback and check the effects; we view small fixes, while larger ones go through another demo. After acceptance, we tidy code and perform needed refactoring | A rechecked and viewed version, without leftovers from trials |
| Independent review | Another agent in a fresh chat checks requirements, readability, duplication, defects, and readiness for use | Concrete findings with evidence, fixes, and check results |
| End of a stage | Update the plan; check Confluence pages related to the change and correct them if the change affects them | Version, result, limitations, and next step; the next larger stage can start a new chat |

For a larger change or at the end of a project, I use a second perspective, for example a stronger Claude model from Anthropic. First, we ask for a review, then agree fixes and refactoring. Using another model alone does not confirm quality. After changes, the behaviour must be checked again.

The agent may propose, write, and test. The lead person checks the result; the appropriate person accepts the rule, product, and release. brAIn, middleware, and MiddleBrain are described separately in The A-Team as my developing approach to knowledge. Using this template does not require implementing them.

## 10. When we accept a change and when we release it

| Question before acceptance | Where we look for the answer |
| --- | --- |
| Does it solve the agreed need? | Task criteria, demo, and the accepting person's decision |
| Do rules and exceptions still work? | The appropriate knowledge source and checks for this version |
| Have review findings been resolved? | Code review and a record of fixes made and open items |
| What was actually checked? | Test results; checks not performed are named |
| Does the documentation match the change? | Checked pages, sources, version, and checking person; needed fixes or confirmation that the change does not affect the content |
| Can it be released for use? | Configuration, permissions, data, behaviour on errors, and maintenance appropriate to the application |
| Is there a release decision? | An explicit agreement for a specific version and environment |

Before deployment, agree who leads it, what they check at the target address, and how they respond to a problem. The rollback method must account for data if the change affects it. Detailed instructions are in operational documentation.

**Example post-deployment message** — an extension of the short message from my playbook. In a real message, include only confirmed information:

```text
[EXAMPLE — this is not a report of an actual deployment]
Case-management application • v0.4 • test environment
Change: urgent-case filtering. Task: [link].
Version confirmed in the portal: [version / time / link].
Post-deployment check: [what was checked and the result].
Open problems: [list or confirmed absence of known problems].
Release lead: [person]. Report problems: [place].
Rollback and any data restoration: [instruction].
```

During an incident, name one person to lead the response. Assess the impact, agree a fix or rollback, check the critical journey, and inform the right people. After service is restored, complete the task and the instruction if it can prevent a repeat.

## 11. How a new person joins the work

| Step | How we know it works |
| --- | --- |
| Reads the product goal and playbook | Can say whom we help, who sets priorities, and where to ask |
| Receives approved access to needed tools | Opens the right project; does not use someone else's account |
| Starts a safe preview and follows the main scenario | Understands what the user does from the start to the result |
| Checks the agent with instructions and one knowledge source | The agent cites the source of the answer and names what it does not know |
| Makes a small change with a second person | Goes from task through demo and checks to acceptance |

Record who helps at the start: **[person / cover]**. Missing access or an unclear description returns as a fix to the instruction, instead of remaining a problem for every next person.

## 12. Does this way of working help us

In my playbook, I looked at the outcome of the initiative, delivery time, and post-deployment problems. First we collect a baseline, then set goals. The number of prompts or lines of code does not say whether the user is better off.

| What we observe | Example source | What we discuss |
| --- | --- | --- |
| User outcome | Attempting the same task before and after the change | Do they find urgent cases more easily and make fewer mistakes? |
| Delivery time | Dates when a task was agreed, accepted, and deployed | Where do we wait, return for knowledge, or make fixes? |
| Post-release problems | Incidents, regressions, rollbacks, and reports | What do we need to check better or simplify? |
| People's work with agents | Conversation about a specific task | What helps, where do we not trust the result, and what support do we need? |

This is a conversation about how the team works, not a ranking of people. On the first attempt, write “we have not measured it yet” if there is no data.

Also agree how to measure work with AI. I compare the number of completed tasks, measure time to production, and look at roadmap goals. People have individual goals and a quarterly area of responsibility. An increase in task count alone does not show delivery of these goals, quality, or safety. You will find a practical card to complete in the [conversation about change and measuring AI outcomes](team-ai-transition-en.md).

| Team agreement | What to write in our rules |
| --- | --- |
| What we count as a completed task | Shared definition of acceptance; a separate release date if it occurs later; no double-counting subtasks |
| What we compare | Similar types of work, equal periods, team availability, and the same error-observation period |
| How we measure delivery time | Agreed event entering the process → confirmed production; explicit time unit and list of changes not yet released |
| What we check alongside task count | AI use in real work, time to production, work still undelivered, fixes, post-release problems, security checks, and goal outcomes |
| Who collects data and where we discuss it | [responsibility, existing record location, review rhythm, and date of first comparison] |

Do not create a second register: the card leads to data from tasks, releases, and checks. No measurement means “no data,” not zero. Using an agent does not prove acceleration, and no detected defects does not confirm safety. Shared rules define the scope of checks and problems that block a release — a higher task count does not change that.

## 13. How we maintain the playbook

When a tool, responsibility, or release method changes, correct the appropriate section. During a team review, return to records that no longer match the work.

| What requires a decision | Proposal | Who agrees and by when | Result / source |
| --- | --- | --- | --- |
| Example: demo waits for the weekly meeting | Show the finished fragment immediately to the accepting person | [agree] | Proposal — to try |
| Example: documentation remains out of date after a change | Update and check the relevant pages during acceptance | [agree] | Proposal — to confirm |
| [your topic] | [proposal] | [responsibility and date] | [decision / link] |

**Finished result:** you can find shared rules, identify responsibility, and carry work through according to them. The agreed playbook has a current version. Open decisions are visible, and confirmed agreements go into the appropriate sources.

## Prompt for working on your playbook

```text
Read the attached playbook and our current agreements: [links].
We want to tailor rules for the whole team's work, not create a plan for one task.

First identify what we already have: product goals, knowledge sources, responsibilities,
work rhythm, tools, task standard, and the way we check and release changes.
Separate confirmed rules from old records, proposals, and gaps.
Do not copy example people A–D, dates, or outcomes as our data.

Go through one area with us at a time. Fill in tables based on answers
and sources; ask about gaps. Prepare examples tailored to our work.
Keep one record of each rule and references to existing documents.
Include operational documentation in Confluence and its update during changes.
Do not impose new roles or tools.

Show proposed changes for shared agreement. Establish who maintains each
area and who checks the content. After we approve changes and identify the
specific document to update, save them in the agreed place.
Without such an instruction or without write access, prepare the
content and say what still needs to be recorded. Do not change accounts, permissions,
environments, or tool configuration. Do not publish or deploy.
At the end, propose a trial of the rules on one current task.
```