diff --git a/skills/alignment-check/SKILL.md b/skills/alignment-check/SKILL.md index ef63821..343dc85 100644 --- a/skills/alignment-check/SKILL.md +++ b/skills/alignment-check/SKILL.md @@ -25,33 +25,62 @@ Invoked automatically by `writing-plans` in autonomous mode. Can also be invoked ## Dispatching the Alignment Agent -Dispatch a Sonnet agent to perform the comparison: +Dispatch a `balanced`-tier subagent to verify alignment. The subagent reads both documents and produces an Alignment Report: + +**Input:** +- Design document: `docs/plans/YYYY-MM-DD--design.md` +- Implementation plan: `docs/plans/YYYY-MM-DD-.md` + +**Forward trace (design → plan):** +For each requirement in the design: +- Find the plan task(s) that implement it +- If no task covers it: flag as MISSING + +**Reverse trace (plan → design):** +For each task in the plan: +- Find the design requirement it satisfies +- If no requirement justifies it: flag as SCOPE CREEP + +**Report format:** + +### Alignment Report + +**Status:** PASS | FAIL + +**Coverage:** +| Design Requirement | Plan Task(s) | Status | +|---|---|---| +| [requirement] | Task N | ✅ Covered | +| [requirement] | — | ❌ MISSING | + +**Scope Check:** +| Plan Task | Design Requirement | Status | +|---|---|---| +| Task N | [requirement] | ✅ Justified | +| Task N | — | ⚠️ SCOPE CREEP | + +**Drift Items:** [list specific items to fix] + + +Dispatch using the Agent tool: ``` -Agent tool (general-purpose, model: sonnet): +Agent tool (general-purpose, model: balanced): description: "Check alignment: design vs plan" prompt: | You are verifying that an implementation plan aligns with its design document. - ## Design Document - [Read: docs/plans/YYYY-MM-DD--design.md] - - ## Implementation Plan - [Read: docs/plans/YYYY-MM-DD-.md] + Read docs/plans/YYYY-MM-DD--design.md and docs/plans/YYYY-MM-DD-.md. - ## Your Job + Perform a forward trace (design → plan): + - For each requirement, constraint, and acceptance criterion in the design, find the plan task(s) that implement it. + - If no plan task covers a design item, flag it as MISSING. - **Forward trace (design → plan):** - For each requirement in the design: - - Find the plan task(s) that implement it - - If no task covers it: flag as MISSING + Perform a reverse trace (plan → design): + - For each task in the implementation plan, find the design requirement, constraint, or acceptance criterion it satisfies. + - If no design item justifies a plan task, flag it as SCOPE CREEP. - **Reverse trace (plan → design):** - For each task in the plan: - - Find the design requirement it satisfies - - If no requirement justifies it: flag as SCOPE CREEP - - **Report format:** + Return exactly this report format: ### Alignment Report @@ -70,7 +99,14 @@ Agent tool (general-purpose, model: sonnet): | Task N | — | ⚠️ SCOPE CREEP | **Drift Items:** [list specific items to fix] + + Set **Status:** to PASS only if every design item is covered and every plan task is justified. Otherwise set it to FAIL. ``` + + + +Run the alignment check inline: read both documents, perform the forward and reverse traces using the Comparison Procedure above, and produce the Alignment Report. + ## On FAIL diff --git a/skills/brainstorming/SKILL.md b/skills/brainstorming/SKILL.md index 7b83cee..de249ad 100644 --- a/skills/brainstorming/SKILL.md +++ b/skills/brainstorming/SKILL.md @@ -9,7 +9,7 @@ description: "You MUST use this before any creative work - creating features, bu Help turn ideas into fully formed designs and specs through natural collaborative dialogue. -Start by understanding the current project context, then ask questions one at a time to refine the idea. Once you understand what you're building, present the design and get user approval. +Start by understanding the current project context, then ask questions using adaptive batching to refine the idea. Once you understand what you're building, present the design and get user approval. Do NOT invoke any implementation skill, write any code, scaffold any project, or take any implementation action until you have presented a design and the user has approved it. This applies to EVERY project regardless of perceived simplicity. @@ -24,7 +24,7 @@ Every project goes through this process. A todo list, a single-function utility, You MUST create a task for each of these items and complete them in order: 1. **Explore project context** — check files, docs, recent commits -2. **Ask clarifying questions** — adaptive batching: group 2-4 related questions per form, follow up with targeted singles +2. **Ask clarifying questions** — adaptive batching: group related questions to reduce round-trips; use targeted singles for follow-ups 3. **Propose 2-3 approaches** — with trade-offs and your recommendation 4. **Present design** — in sections scaled to their complexity, get user approval after each section 5. **Write design doc** — save to `docs/plans/YYYY-MM-DD--design.md` and commit @@ -58,11 +58,20 @@ digraph brainstorming { **Understanding the idea:** - Check out the current project state first (files, docs, recent commits) -- Ask questions using adaptive batching with AskUserQuestion: - - **First form:** Group 2-4 related questions covering purpose, constraints, scope, and tech choices - - **Follow-ups:** Targeted single questions based on interesting or ambiguous answers from previous forms +- Ask questions using adaptive batching — group related questions to reduce round-trips: + - **First batch:** covers purpose, constraints, scope, and tech choices + - **Follow-ups:** Targeted single questions based on interesting or ambiguous answers + + - Use multiple choice options when possible (AskUserQuestion supports 2-4 options per question) - AskUserQuestion supports up to 4 questions per form — use this to reduce round-trips + + + + - Present options as a numbered list and ask the user to reply with the chosen number + - Group no more than 3 questions per turn to avoid overloading the chat + + - Focus on understanding: purpose, constraints, success criteria **Exploring approaches:** @@ -106,7 +115,7 @@ When the user wants design exploration without execution, they pass `--design-on ## Key Principles -- **Adaptive question batching** - Group 2-4 related questions per form, follow up with targeted singles +- **Adaptive question batching** - Group related questions to reduce round-trips; use targeted singles for follow-ups - **Multiple choice preferred** - Easier to answer than open-ended when possible - **YAGNI ruthlessly** - Remove unnecessary features from all designs - **Explore alternatives** - Always propose 2-3 approaches before settling diff --git a/skills/executing-plans/SKILL.md b/skills/executing-plans/SKILL.md index c1b2533..dc381f5 100644 --- a/skills/executing-plans/SKILL.md +++ b/skills/executing-plans/SKILL.md @@ -19,7 +19,15 @@ Load plan, review critically, execute tasks in batches, report for review betwee 1. Read plan file 2. Review critically - identify any questions or concerns about the plan 3. If concerns: Raise them with your human partner before starting -4. If no concerns: Create TodoWrite and proceed +4. If no concerns: create one task entry per plan task in your host's task system, then proceed to Step 2 + + +Use TodoWrite — one entry per plan task. + + + +If your environment has no built-in task system, maintain a numbered checklist tracking each task as pending, in-progress, or completed. + ### Step 2: Execute Batch **Default: First 3 tasks** diff --git a/skills/pr-monitoring/SKILL.md b/skills/pr-monitoring/SKILL.md index 2ecebe7..eef5374 100644 --- a/skills/pr-monitoring/SKILL.md +++ b/skills/pr-monitoring/SKILL.md @@ -17,10 +17,13 @@ Invoked automatically by `finishing-a-development-branch` in autonomous mode aft ## The Process -Spawn a background agent that monitors the PR in a loop: +Run a `balanced`-tier agent that monitors the PR in a loop until all CI checks pass and no unresolved reviews remain. -``` -Agent tool (general-purpose, model: sonnet, run_in_background: true): + +Use the Agent tool to run the monitor in the background: + +```` +Agent tool (general-purpose, model: balanced, run_in_background: true): description: "Monitor PR #N for CI and reviews" prompt: | You are monitoring PR # on and automatically fixing issues. @@ -33,9 +36,7 @@ Agent tool (general-purpose, model: sonnet, run_in_background: true): Design doc: Plan doc: - ## Monitor Loop - - Repeat until exit conditions met: + Repeat the Monitor Loop until exit conditions are met: ### 1. Check CI Status @@ -88,6 +89,20 @@ Agent tool (general-purpose, model: sonnet, run_in_background: true): ### 4. Wait Between Checks Sleep 60 seconds between check cycles. Do not poll more frequently. +```` + + + + +Use your host's equivalent mechanism to periodically poll the following in a loop: +- `gh pr checks ` — fix any failing CI checks +- `gh api repos///pulls//comments` — respond to inline review comments +- `gh api repos///pulls//reviews` — handle any "CHANGES_REQUESTED" reviews + +Continue until all checks pass, no unresolved inline comments remain, and no "changes requested" reviews are pending. + + + ## Safety Limits diff --git a/skills/subagent-driven-development/SKILL.md b/skills/subagent-driven-development/SKILL.md index 88376ae..481e367 100644 --- a/skills/subagent-driven-development/SKILL.md +++ b/skills/subagent-driven-development/SKILL.md @@ -5,34 +5,54 @@ description: Use when executing implementation plans with independent tasks in t # Subagent-Driven Development -Execute plan using Agent Teams (default) or sequential subagents (fallback), with two-stage review: spec compliance first, then code quality. +Execute a plan using either a role-based subagent team or sequential subagents, with two-stage review: spec compliance first, then code quality. -**Core principle:** Role-based team with persistent agents + two-stage review (spec then quality) = high quality, parallel execution +**Core principle:** Structured roles + two-stage review (spec then quality) = high-quality, parallel execution. -## Execution Mode Detection +## Execution Mode -**Default: Agent Teams** — when TeamCreate tool is available and `CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS` is set. + -**Fallback: Sequential Subagents** — when Agent Teams is not available. Uses the legacy one-subagent-at-a-time flow. +**Default: Agent Teams** — when the TeamCreate tool is available and +`CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS` is set, use persistent parallel agents with a shared +task list. Each agent claims work independently; the team-lead orchestrates only. + +**Fallback: Sequential Subagents** — when Agent Teams is not available, dispatch one subagent +per task. See the [Sequential Mode](#sequential-mode) section below. -Check availability: ``` +# Runtime check # If TeamCreate tool exists in your tool list → use Agent Teams -# Otherwise → use sequential subagent flow (see Legacy Mode below) +# Otherwise → use Sequential Mode ``` + + + + +**Sequential Subagents** — Codex does not provide a shared task list or persistent team +chat. Spawn one subagent per task using Codex's native subagent tool, passing the full plan +task text in the prompt. Use git branch names and PR diffs as the coordination surface +instead of a task queue. See [Sequential Mode](#sequential-mode). + + + +--- + + + ## Agent Teams Mode -### Team Setup +### Team Structure ```dot digraph team { rankdir=LR; - Lead [label="team-lead (Opus)\nOrchestration only" shape=box style=filled fillcolor=lightyellow]; - I1 [label="implementer-1\n(Sonnet)" shape=box]; - I2 [label="implementer-2\n(Sonnet)" shape=box]; - SR [label="spec-reviewer\n(Sonnet)" shape=box]; - CR [label="code-reviewer\n(Sonnet)" shape=box]; + Lead [label="team-lead (frontier)\nOrchestration only" shape=box style=filled fillcolor=lightyellow]; + I1 [label="implementer-1\n(balanced)" shape=box]; + I2 [label="implementer-2\n(balanced)" shape=box]; + SR [label="spec-reviewer\n(balanced)" shape=box]; + CR [label="code-reviewer\n(balanced)" shape=box]; Lead -> I1 [label="assign tasks"]; Lead -> I2 [label="assign tasks"]; @@ -85,7 +105,7 @@ Agent tool: team_name: "" name: "implementer-1" subagent_type: "general-purpose" - model: "sonnet" + model: "balanced" prompt: | You are implementer-1 on team . @@ -125,7 +145,7 @@ Agent tool: team_name: "" name: "spec-reviewer" subagent_type: "general-purpose" - model: "sonnet" + model: "balanced" prompt: | You are spec-reviewer on team . @@ -146,7 +166,7 @@ Agent tool: - Re-review 4. If spec compliant: - DM code-reviewer: "Task N spec-approved, ready for quality review" - - Mark the "Review spec:" task as completed + - Mark the "Review spec:" task as completed via TaskUpdate ## Design Document Reference: @@ -162,7 +182,7 @@ Agent tool: team_name: "" name: "code-reviewer" subagent_type: "general-purpose" - model: "sonnet" + model: "balanced" prompt: | You are code-reviewer on team . @@ -179,7 +199,7 @@ Agent tool: - DM the implementer who built it with specific issues - Wait for fix and re-review 4. If approved: - - Mark the "Review quality:" task as completed + - Mark the "Review quality:" task as completed via TaskUpdate - DM team-lead: "Task N fully approved" ## Team Conventions @@ -214,22 +234,56 @@ TeamDelete() Invoke `superpowers:finishing-a-development-branch`. -## Legacy Mode (Sequential Subagents) + + + + +Use Sequential Mode — see the [Sequential Mode](#sequential-mode) section below. + + + +--- + +## Sequential Mode -When Agent Teams is not available, fall back to the original sequential flow: +Use when Agent Teams is not available, or on any host that does not provide persistent +parallel agents. One subagent handles one task at a time; reviews happen between tasks. -1. Read plan, extract all tasks, create TodoWrite -2. Per task: - a. Dispatch implementer subagent (./implementer-prompt.md) - b. Answer questions if any - c. Implementer implements, tests, commits, self-reviews - d. Dispatch spec reviewer subagent (./spec-reviewer-prompt.md) - e. If issues → implementer fixes → re-review - f. Dispatch code quality reviewer (./code-quality-reviewer-prompt.md) - g. If issues → implementer fixes → re-review - h. Mark task complete -3. After all tasks → dispatch final code reviewer -4. Invoke finishing-a-development-branch +### Process + +For each task in the plan: + +1. **Dispatch implementer subagent** — provide the full task text, the design doc path, and + the working directory in the prompt. Use `./implementer-prompt.md` as the base template. +2. **Answer questions** if the implementer surfaces blockers. +3. Implementer implements, tests, commits, and self-reviews per `agents/team-conventions.md`. +4. **Dispatch spec reviewer** — provide the task text and the implementer's commit SHA. + Use `./spec-reviewer-prompt.md` as the base template. +5. If spec issues found → implementer fixes → re-review until spec-approved. +6. **Dispatch code quality reviewer** — use `./code-quality-reviewer-prompt.md`. +7. If quality issues found → implementer fixes → re-review until approved. +8. Mark task complete and move to the next. + +After all tasks: invoke `superpowers:finishing-a-development-branch`. + + + +### Codex Coordination Notes + +Codex subagents do not share a task list. Use these conventions instead: + +- **Task identity**: pass `task_id: N` and the full task text in the prompt so each subagent + knows exactly what it owns. Do not rely on a shared queue. +- **Handoff surface**: use git branch names (`task-N-`) and PR diffs as the review + surface. The spec-reviewer and code-reviewer read the PR diff, not a task record. +- **Progress tracking**: after each task completes, record completion in the orchestrating + agent's own context (e.g., a local list) rather than a shared task table. +- **No DM channel**: pass reviewer output back to the orchestrator as a return value; the + orchestrator decides whether to re-dispatch the implementer. + + + +--- ## Red Flags @@ -237,11 +291,14 @@ When Agent Teams is not available, fall back to the original sequential flow: - Start implementation on main/master without explicit user consent - Skip reviews (spec compliance OR code quality) - Proceed with unfixed issues -- Make subagents/teammates read plan files (provide full text instead) -- Skip scene-setting context +- Make subagents/teammates read plan files — provide full text in the prompt instead +- Skip scene-setting context in any subagent prompt - Start code quality review before spec compliance passes - Move to next task while either review has open issues -- In Agent Teams mode: let the lead implement (orchestration only) + + +- In Agent Teams mode: let the team-lead implement (orchestration only) + **If reviewer finds issues:** - Implementer fixes them @@ -249,6 +306,8 @@ When Agent Teams is not available, fall back to the original sequential flow: - Repeat until approved - Don't skip the re-review +--- + ## Integration **Required workflow skills:** diff --git a/skills/subagent-driven-development/code-quality-reviewer-prompt.md b/skills/subagent-driven-development/code-quality-reviewer-prompt.md index 935d766..34bcba9 100644 --- a/skills/subagent-driven-development/code-quality-reviewer-prompt.md +++ b/skills/subagent-driven-development/code-quality-reviewer-prompt.md @@ -6,6 +6,14 @@ Use this template when dispatching a code quality reviewer subagent. **Only dispatch after spec compliance review passes.** + +**Agent Teams additions:** When using Agent Teams, also add to the prompt: +- Wait for DMs from spec-reviewer saying a task is spec-approved +- DM implementer when quality issues are found +- DM the orchestrator (team-lead) when task is fully approved +- Use TaskUpdate to mark "Review quality:" tasks as completed + + ``` Task tool (superpowers:code-reviewer): Use template at skills/requesting-code-review/code-reviewer.md @@ -22,11 +30,9 @@ Task tool (superpowers:code-reviewer): For the bug-class checklist and verdict vocabulary, use `skills/requesting-code-review/SKILL.md`. - When operating as a team member: - - Wait for DMs from spec-reviewer saying a task is spec-approved - - DM implementer when quality issues are found - - DM team-lead when task is fully approved - - Use TaskUpdate to mark "Review quality:" tasks as completed + When notified that a task is spec-approved and ready for quality review: + - Notify the implementer when quality issues are found + - Notify the orchestrator (team-lead on Claude Code) when the task is fully approved ``` **Code reviewer returns:** Strengths, Issues (Critical/Important/Minor), Assessment diff --git a/skills/subagent-driven-development/spec-reviewer-prompt.md b/skills/subagent-driven-development/spec-reviewer-prompt.md index 089ea73..48d60b9 100644 --- a/skills/subagent-driven-development/spec-reviewer-prompt.md +++ b/skills/subagent-driven-development/spec-reviewer-prompt.md @@ -4,6 +4,14 @@ Use this template when dispatching a spec compliance reviewer subagent. **Purpose:** Verify implementer built what was requested (nothing more, nothing less) + +**Agent Teams additions:** When using Agent Teams, also add to the prompt: +- Wait for DMs from implementers saying a task is ready +- DM code-reviewer when spec compliance passes +- DM implementer when issues are found +- Use TaskUpdate to mark "Review spec:" tasks as completed + + ``` Task tool (general-purpose): description: "Review spec compliance for Task N" @@ -27,9 +35,7 @@ Task tool (general-purpose): - ✅ Spec compliant (after code inspection) - ❌ Issues found: [list specifically what's missing or extra, with file:line references] - When operating as a team member: - - Wait for DMs from implementers saying a task is ready - - DM code-reviewer when spec compliance passes - - DM implementer when issues are found - - Use TaskUpdate to mark "Review spec:" tasks as completed + When notified that a task is ready for review: + - Notify the code-reviewer when spec compliance passes + - Notify the implementer when issues are found ``` diff --git a/skills/using-superpowers/SKILL.md b/skills/using-superpowers/SKILL.md index 9079376..8314a6b 100644 --- a/skills/using-superpowers/SKILL.md +++ b/skills/using-superpowers/SKILL.md @@ -26,32 +26,32 @@ This is not negotiable. This is not optional. You cannot rationalize your way ou ```dot digraph skill_flow { "User message received" [shape=doublecircle]; - "About to EnterPlanMode?" [shape=doublecircle]; + "About to enter plan mode?" [shape=doublecircle]; "Already brainstormed?" [shape=diamond]; "Invoke brainstorming skill" [shape=box]; - "Invoke writing-plans skill\n(prefers Claude's Plan Mode)" [shape=box]; + "Invoke writing-plans skill" [shape=box]; "Might any skill apply?" [shape=diamond]; "Invoke Skill tool" [shape=box]; "Announce: 'Using [skill] to [purpose]'" [shape=box]; "Has checklist?" [shape=diamond]; - "Create TodoWrite todo per item" [shape=box]; + "Create task entry per checklist item" [shape=box]; "Follow skill exactly" [shape=box]; "Respond (including clarifications)" [shape=doublecircle]; - "About to EnterPlanMode?" -> "Already brainstormed?"; + "About to enter plan mode?" -> "Already brainstormed?"; "Already brainstormed?" -> "Invoke brainstorming skill" [label="no"]; - "Already brainstormed?" -> "Invoke writing-plans skill\n(prefers Claude's Plan Mode)" [label="yes"]; + "Already brainstormed?" -> "Invoke writing-plans skill" [label="yes"]; "Invoke brainstorming skill" -> "Might any skill apply?"; - "Invoke writing-plans skill\n(prefers Claude's Plan Mode)" -> "Might any skill apply?"; + "Invoke writing-plans skill" -> "Might any skill apply?"; "User message received" -> "Might any skill apply?"; "Might any skill apply?" -> "Invoke Skill tool" [label="yes, even 1%"]; "Might any skill apply?" -> "Respond (including clarifications)" [label="definitely not"]; "Invoke Skill tool" -> "Announce: 'Using [skill] to [purpose]'"; "Announce: 'Using [skill] to [purpose]'" -> "Has checklist?"; - "Has checklist?" -> "Create TodoWrite todo per item" [label="yes"]; + "Has checklist?" -> "Create task entry per checklist item" [label="yes"]; "Has checklist?" -> "Follow skill exactly" [label="no"]; - "Create TodoWrite todo per item" -> "Follow skill exactly"; + "Create task entry per checklist item" -> "Follow skill exactly"; } ``` diff --git a/skills/writing-skills/SKILL.md b/skills/writing-skills/SKILL.md index c6388e6..86f0324 100644 --- a/skills/writing-skills/SKILL.md +++ b/skills/writing-skills/SKILL.md @@ -670,7 +670,11 @@ Deploying untested skills = deploying untested code. It's a violation of quality ## Skill Creation Checklist (TDD Adapted) -**IMPORTANT: Use TodoWrite to create todos for EACH checklist item below.** +**IMPORTANT: Track each checklist item below as a task in your host's task system.** + + +Use TodoWrite to create a todo for EACH checklist item below. + **RED Phase - Write Failing Test:** - [ ] Create pressure scenarios (3+ combined pressures for discipline skills) diff --git a/skills/writing-skills/anthropic-best-practices.md b/skills/writing-skills/anthropic-best-practices.md index a5a7d07..11c69e8 100644 --- a/skills/writing-skills/anthropic-best-practices.md +++ b/skills/writing-skills/anthropic-best-practices.md @@ -133,13 +133,19 @@ Do not modify the command or add additional flags. Skills act as additions to models, so effectiveness depends on the underlying model. Test your Skill with all the models you plan to use it with. -**Testing considerations by model**: +**Testing considerations by model tier** (see `agents/model-tiers.md` for host-specific names): -* **Claude Haiku** (fast, economical): Does the Skill provide enough guidance? +* **`fast` tier**: Does the Skill provide enough guidance? +* **`balanced` tier**: Is the Skill clear and efficient? +* **`frontier` tier**: Does the Skill avoid over-explaining? + + +* **Claude Haiku** (fast): Does the Skill provide enough guidance? * **Claude Sonnet** (balanced): Is the Skill clear and efficient? -* **Claude Opus** (powerful reasoning): Does the Skill avoid over-explaining? +* **Claude Opus** (frontier): Does the Skill avoid over-explaining? + -What works perfectly for Opus might need more detail for Haiku. If you plan to use your Skill across multiple models, aim for instructions that work well with all of them. +What works well with a frontier-tier model may need more detail for a fast-tier model. If you plan to use your Skill across multiple models, aim for instructions that work well with all of them. ## Skill structure @@ -1129,7 +1135,11 @@ Before sharing a Skill, verify: ### Testing * [ ] At least three evaluations created +* [ ] Tested across model tiers (fast / balanced / frontier) + + * [ ] Tested with Haiku, Sonnet, and Opus + * [ ] Tested with real usage scenarios * [ ] Team feedback incorporated (if applicable) diff --git a/skills/writing-skills/persuasion-principles.md b/skills/writing-skills/persuasion-principles.md index 9818a5f..e6f5dc7 100644 --- a/skills/writing-skills/persuasion-principles.md +++ b/skills/writing-skills/persuasion-principles.md @@ -33,7 +33,11 @@ LLMs respond to the same persuasion principles as humans. Understanding this psy **How it works in skills:** - Require announcements: "Announce skill usage" - Force explicit choices: "Choose A, B, or C" +- Use tracking: task lists for checklists + + - Use tracking: TodoWrite for checklists + **When to use:** - Ensuring skills are actually followed @@ -80,9 +84,16 @@ LLMs respond to the same persuasion principles as humans. Understanding this psy **Example:** ```markdown +✅ Checklists without task tracking = steps get skipped. Every time. +❌ Some people find task tracking helpful for checklists. +``` + + +```markdown ✅ Checklists without TodoWrite tracking = steps get skipped. Every time. ❌ Some people find TodoWrite helpful for checklists. ``` + ### 5. Unity **What it is:** Shared identity, "we-ness", in-group belonging.