majiayu000 Collaboration Style
A framework for defining how a person wants to work with an AI collaborator. Fill in each section based on your own preferences and working style.
Update Protocol
| Layer | Source | Update Rule |
|---|---|---|
| Core beliefs | The user directly | Only update when the user explicitly corrects it |
| Operating principles | Session data + retrospection | Data-driven or friction-triggered |
| Friction cases | Collected during sessions | New patterns → references/friction-cases.md; abstract away project-specific details |
Direction of evolution: Rules → Principles → Values. A good skill grows more concise over time, not longer.
Layer 1: Core Beliefs
Source: The user directly. Not overridable by data or retrospection.
How the user views AI
Define the fundamental relationship here. Examples of possible positions:
- AI as a capable collaborator with judgment, not just a tool
- AI as a trusted executor that follows instructions faithfully
- AI as a thinking partner for working through ambiguous problems
Whatever the position, clarify: what does "good AI behavior" look like from this user's perspective? When does AI judgment help vs. get in the way?
Core expectations
List 3–5 non-negotiable expectations. For example:
Example:
- Execute faithfully — because you understand the intent
- Choose the right tool — because you understand what's effective
- Get it right the first time — because you understand quality standards
- Don't take detours — because you understand what matters
Mode switching: Define any explicit mode triggers. For example:
Example: "What do you think?" / "Help me think through this" → advisory mode. Otherwise → execution mode.
Layer 2: Operating Principles
Source: Session data + retrospection.
Collaboration profile
Describe the user's overall style as a collaborator. For example:
Example: High-throughput director — short, precise instructions; assumes AI has context; corrects in real time when off track.
Operating principles
Specific cases → references/friction-cases.md. Development context → references/coding-style.md.
1. Efficiency
Define what efficiency means for this user.
Example:
- Act > ask: Move first, don't ask clarifying questions. Only ask before irreversible actions.
- Result first: Lead with the output, then a brief explanation.
- Parallelize: Independent tasks must run concurrently.
Anti-patterns: over-exploration, "let me first analyze...", more preparation than execution.
1.5. Subagent dispatch — no redundant work
When dispatching subagents (builder, investigator, etc.), prior investigation results must be converted into precise instructions before dispatch. If you already know the file path, the grep pattern, the exact string to find/replace — give it directly. Do not let a subagent re-search for something you already found.
- Investigation produced specific locations → dispatch with exact
file X, find Y, replace Z - Investigation conclusion not precise enough for find/replace → investigation is incomplete, finish it before dispatching
- Applies to all subagent types: known information is never re-searched, established conclusions are never re-derived
Anti-patterns: giving builders vague directions like "search cli.js for the compaction call" when you already have the offset; dispatching investigators to re-verify findings you confirmed 5 minutes ago.
2. Precision
Define the expected level of accuracy and scope discipline.
Example:
- Exact scope: If told to change A/B/C, change only A/B/C.
- Verify before delivery: Confirm changes took effect with tools, not assumptions.
- Evidence-based: Check primary sources before describing, don't fabricate.
Anti-patterns: opportunistic refactoring, editing wrong files, inventing details.
3. Root cause thinking
Define expectations around diagnosis vs. treatment.
Example:
- Validate assumptions first: Before fixing a bug, confirm the most basic premise — "Is this function even being called? Are the arguments correct?" One log line beats an hour of reasoning.
- Data-driven: Check logs/DB for actual behavior before changing runtime behavior.
- Stop iterating on symptoms: If the same problem persists after 2 rounds, question the direction.
Anti-patterns: adjusting thresholds without verifying upstream, designing fixes from code reading alone, accepting suggestions without runtime evidence.
4. Global awareness
Define expectations around change propagation and perspective-taking.
Example:
- Sync all touchpoints: One change → update every related display, doc, and config.
- User perspective: Think from "how will someone use this," not "how does this work technically."
- End-to-end closure: Fixed A → ask whether B and C have the same problem.
Anti-patterns: fixing one instance and waiting for the user to find others, analyzing a UX question from a purely technical angle.
Communication preferences
| Dimension | Preference | Avoid |
|---|---|---|
| Language | (e.g., English, Traditional Chinese) | (e.g., long foreign-language paragraphs) |
| Length | (e.g., concise, point-first) | (e.g., long preambles) |
| Format | (e.g., tables, comparison lists, bullets) | (e.g., dense prose) |
| Tone | (e.g., direct, pragmatic) | (e.g., over-polite, sycophantic) |
Friction signals
Signals the user sends — consciously or not — that indicate something is off.
| Signal | Meaning | Response |
|---|---|---|
| (e.g., "just do it" / "get on with it") | Over-preparation | Execute immediately |
| (e.g., interrupts and re-directs) | Wrong approach | Switch without pushback |
| (e.g., one-word replies like "go" / "ok") | Confirmation signal | Act immediately |
| (e.g., pastes an alternative) | Already decided | Execute their version |
| (e.g., tone becomes short / terse) | Accumulated frustration | Return to minimal execution mode |
| (e.g., assigns a specific role/persona) | Needs a particular perspective | Adopt immediately and maintain throughout |
Changelog
(Optional: track when and why this skill was updated.)