FORM NOT VOID, MIND NO CORE

Appendix J: Collaboration Templates

2026.09.12

These four templates support the everyday collaboration practices in Chapters 30-33: make information workable asynchronously, then make expectations, feedback, status, and conclusions traceable. Remove inapplicable fields before copying. Templates support expression; they do not replace authorization, judgment, or repairing a relationship face to face.

J.1 Personal Working Habits Manual

Chapter 31's personal working habits manual makes collaboration defaults negotiable information, rather than requiring colleagues to guess.

# [Name]'s Personal Working Habits Manual

[Working hours and time zone] I usually work [start-end] in [time zone].
Regular unavailable periods: [times; reason optional].
[Focus time] I turn off instant notifications during [period].
For nonurgent matters, leave complete context in [task system/public channel].
[Response expectations] Flag urgent matters through [channel].
For other messages, I usually reply or acknowledge within [agreed period].
[Communication preferences] I prefer discussing matters through
[documents/task comments/voice]. Before synchronous discussion, provide the
purpose, materials, and desired conclusion.
[Feedback preferences] I prefer feedback [privately/in an agreed public
retrospective]. Focus on specific behavior, impact, and next steps.
[How I can help] I know [domain/system]. When asking for help, include context,
the observed problem, actions already tried, and the decision needing my input.
[Boundaries to align in advance] [For example: on-call duty, customer-site work,
accessibility needs, handoff arrangements].

Usage: Complete this when joining a team, starting a project, or changing collaboration arrangements, and keep it in the team's agreed shared location. For health, family, or other sensitive personal matters, disclose only the minimum you are comfortable sharing. Response deadlines and emergency channels require shared team agreement, not unilateral declarations.

J.2 SBI-I Feedback Script

Section 31.4's SBI-I grounds feedback in behavior and impact. Here, the final I consistently means this book's Intent / Invitation: state the feedback's purpose and invite a response, rather than substituting another acronym expansion.

I'd like to discuss a specific collaboration incident.
Is this a suitable time and channel?

[S - Situation] During [specific date, task, meeting, or PR]...
[B - Behavior] I observed [verifiable action, exact words, or missing information].
[I - Impact] This caused [specific effect] for [project, users, reviewers,
or collaboration].
[I - Intent / Invitation] My purpose is [shared goal/desired improvement].
I may be missing some context. How do you see it?
Can we agree together on [specific next action]?

Usage: Verify facts first and choose a channel appropriate to their sensitivity. Ordinary improvement suggestions can be discussed privately or in an agreed retrospective. Personal circumstances, performance, harassment or discrimination, assessments of customer personnel, and other sensitive matters should not enter public channels or bypass established personnel, security, or customer-contact authority. If a discussion becomes formal handling, route it to authorized people under the organization's process. This script grants no authority to investigate, discipline, or speak for the customer.

J.3 Example Board Labels

Chapter 33 requires truthful board status and consistent labels. This minimal set can serve a small team. Labels support filtering; they do not replace a task description, owner, or acceptance criteria.

DimensionExample labelsRule
PriorityP0 / P1 / P2 / P3Exactly one priority per card; P0 must state impact, current response, and escalation recipient
Typefeature / bug / chore / refactor / tech-debtAt least one, describing the nature of the work
Domainauth / payment / user / [team-domain]One primary domain; describe cross-domain relationships in the card body
Collaboration statusblocked / needs-reviewBlocked must include the reason, impact, and who needs to do what
Risk reminderurgent / money / [security]Reminder only; does not replace incident response, approval, or security procedures
Title: [P1][feature][user] Customer-service tag management
Owner: [name]                 Acceptor: [name]
Current column: In Progress  Labels: P1, feature, user
Context/goal: [why this work; how success is judged]
Blocker, if any: [reason | impact | who must decide by when]
Acceptance criteria: [checkable results]

Usage: Agree on names, colors, and P0 response rules before applying labels widely. Review obsolete or overlapping labels each iteration. Do not merely tag content as customer-restricted, containing personal data, or containing secrets and then publish the card. These are first questions of access and authority. Use an approved restricted space and only the minimum necessary information.

J.4 Asynchronous Message Template

Chapter 30's standard is to turn "Are you there?" into complete information. Recipients should be able to understand, handle, or explicitly escalate it at their own pace. Internal communication defaults to public only within the already authorized team scope.

[Subject] [One sentence: decision, update, or help needed]
[Recipient / deadline] Please [role/name] [decide/confirm/add information]
by [date and time zone].
[Context] [Why this needs attention now; links to tasks, documents, or records]
[Current facts] [Confirmed facts; do not present guesses as conclusions]
[My proposal] [Recommended action].
Alternative: [option and main tradeoff].
[Response needed] Please answer [specific question or options].
If no reply, I will [default action only within existing authorization].
[Impact and risk] [Delay, users, quality, or dependencies affected]
[Permissions and scope] [Internal public / customer-restricted /
personal data / secrets]. Authorized readers: [roles or names].
[Next step] After the response, I will record the conclusion, owner, and date
in [location].

Usage: Internal project discussions, technical proposals, and progress updates can prioritize public channels, with conclusions returned to the task or document. Confirm information scope and access before sending. Customer-restricted information belongs only in customer-approved spaces. Personal data goes only to authorized people with a business need. Keys, tokens, and other secrets belong in approved secret-management channels; messages contain only references or redacted information. If scope is unclear, permissions insufficient, disclosure crosses departments or customers, or the default action could change customer systems, data paths, scope, or commitments, stop distribution and escalate under Chapter 28's authority boundaries to the appropriate customer contact, security or compliance lead, or project sponsor. Public by default does not mean authorized access by default.


Order of use: Use J.1 to align everyday expectations; J.2 for concrete collaboration friction; J.3 to make work status traceable; and J.4 to preserve asynchronous information and conclusions. Together they support Chapters 30-33's predictable, collaborative, accountable delivery culture.