software-team-conflict-patterns

Name: software-team-conflict-patterns
Author: Stanestane

34stars3forks

How to install software-team-conflict-patterns?

stanestane/game-design-skills-bundle/software-team-conflict-patterns

$npx -y skills add Stanestane/game-design-skills-bundle --skill software-team-conflict-patterns

Installs into the current project.

Summary

Help analyze recurring conflict patterns on software or game projects by identifying likely collaboration archetypes, behavior patterns, project risks, and practical response strategies. Use when someone describes a teammate, lead, founder, stakeholder, client, producer, or colla

Files · 1

View on GitHub

SKILL.md

1	# Software Team Conflict Patterns
2
3	Analyze recurring collaboration problems without pretending to diagnose people.
4
5	Use this skill when the user describes a difficult person or recurring team conflict on a software or game project and needs help understanding the likely behavior pattern, why it causes friction, and how to respond productively. The goal is not to label people for sport. The goal is to identify useful patterns, protect project progress, and suggest practical next moves.
6
7	Read `references/neil-on-software-archetypes.md` when you need the full 48-archetype taxonomy from the Neil on Software source material, including mutation paths, dangerous pairings, likelihood-of-fixing signals, danger-to-project signals, and extracted fix strategies.
8	Read `references/pattern-notes.md` when you need a shorter local shorthand set of patterns.
9	Read `references/response-strategies.md` when you need guidance on boundaries, documentation, reframing, escalation, and other response moves.
10
11	## Core behavior
12
13	- Focus on observable behavior, not amateur clinical diagnosis.
14	- Treat archetypes as rough pattern labels, not absolute truth.
15	- Explain uncertainty when the situation could fit multiple patterns.
16	- Prioritize practical response strategy over moral judgment.
17	- Consider both the difficult behavior and the surrounding team system that enables or amplifies it.
18	- Distinguish between a one-off bad moment and a recurring pattern.
19	- Suggest safer next moves when the situation involves power imbalance, retaliation risk, or trust collapse.
20	- Avoid revenge logic, humiliation tactics, or manipulative advice.
21
22	## What to ask first
23
24	Prioritize these questions:
25	1. What is happening?
26	2. Who is involved and what role does each person have?
27	3. What recurring behavior or pattern are you seeing?
28	4. How is it affecting the project, team, or decisions?
29	5. What have you already tried?
30	6. What outcome do you want?
31	7. Is there a power imbalance, dependency, or retaliation risk?
32
33	If the user gives only a short story, infer the likely conflict pattern carefully and state assumptions.
34
35	## What to diagnose
36
37	Quickly identify:
38	- the recurring behavior pattern or archetype that best fits the description
39	- whether multiple patterns may be interacting
40	- whether the issue is primarily about ego, control, avoidance, indecision, chaos, blame-shifting, status signaling, or weak communication
41	- whether the team context is rewarding or enabling the behavior
42	- what bad responses are likely to escalate the problem
43	- what realistic response options the user actually has
44
45	Prefer the exact archetype names from the source material instead of inventing new labels when one of the named patterns fits.
46
47	## Named archetypes from the source material
48
49	Default to the 48 Neil on Software archetypes documented in `references/neil-on-software-archetypes.md`.
50
51	Use the exact archetype label when it fits. If the story does not fit one cleanly, say which two or three named archetypes are most relevant and explain why. If a locally downloaded source page was missing for one of the 48, say that the archetype name is part of the taxonomy but the local notes are incomplete.
52
53	Also use these source-material signals when available:
54	- what the archetype can mutate into
55	- what it is dangerous when coupled with
56	- likelihood of fixing
57	- danger to project
58	- the extracted fix or mitigation strategy
59
60	## Response structure
61
62	Always organize the answer using this structure.
63
64	### Situation Summary
65	- summarize the conflict in plain language
66	- state the actual project problem, not just the personality problem
67
68	### Likely Conflict Pattern(s)
69	- identify the most likely named archetype from the source material
70	- use the exact archetype label when possible
71	- mention uncertainty if more than one pattern fits
72	- if relevant, list a primary archetype and secondary archetype
73	- mention mutation paths or dangerous pairings if they materially increase the risk
74
75	### Evidence in the Story
76	- point to the behaviors that support the reading
77	- distinguish observed facts from interpretation
78
79	### Risks if This Continues
80	- project risks
81	- communication risks
82	- trust or morale risks
83	- escalation risks
84	- whether the source material marks the archetype as especially dangerous to the project or especially likely/unlikely to fix
85
86	### Recommended Strategy
87	- how to communicate
88	- what to document
89	- what boundaries to set
90	- what to avoid
91	- whethe

StanestanePublisher · 59 listings

Preview

Stanestane/game-design-skills-bundle

# Software Team Conflict Patterns

Analyze recurring collaboration problems without pretending to diagnose people.

Use this skill when the user describes a difficult person or recurring team conflict on a software or game project and needs help understanding the likely behav

Read `references/neil-on-software-archetypes.md` when you need the full 48-archetype taxonomy from the Neil on Software source material, including mutation path

RepoStanestane/game-design-skills-bundle

License—

TypeSkills

CategoryGeneral

UpdatedJun 2026

Repo stars34

First seenJul 22, 2026

People who liked this also viewed

6 picks

Type

software-team-conflict-patterns

34stars3forks

View on GitHub

How to install software-team-conflict-patterns?

stanestane/game-design-skills-bundle/software-team-conflict-patterns

$npx -y skills add Stanestane/game-design-skills-bundle --skill software-team-conflict-patterns

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Software Team Conflict Patterns
2
3	Analyze recurring collaboration problems without pretending to diagnose people.
4
5	Use this skill when the user describes a difficult person or recurring team conflict on a software or game project and needs help understanding the likely behavior pattern, why it causes friction, and how to respond productively. The goal is not to label people for sport. The goal is to identify useful patterns, protect project progress, and suggest practical next moves.
6
7	Read `references/neil-on-software-archetypes.md` when you need the full 48-archetype taxonomy from the Neil on Software source material, including mutation paths, dangerous pairings, likelihood-of-fixing signals, danger-to-project signals, and extracted fix strategies.
8	Read `references/pattern-notes.md` when you need a shorter local shorthand set of patterns.
9	Read `references/response-strategies.md` when you need guidance on boundaries, documentation, reframing, escalation, and other response moves.
10
11	## Core behavior
12
13	- Focus on observable behavior, not amateur clinical diagnosis.
14	- Treat archetypes as rough pattern labels, not absolute truth.
15	- Explain uncertainty when the situation could fit multiple patterns.
16	- Prioritize practical response strategy over moral judgment.
17	- Consider both the difficult behavior and the surrounding team system that enables or amplifies it.
18	- Distinguish between a one-off bad moment and a recurring pattern.
19	- Suggest safer next moves when the situation involves power imbalance, retaliation risk, or trust collapse.
20	- Avoid revenge logic, humiliation tactics, or manipulative advice.
21
22	## What to ask first
23
24	Prioritize these questions:
25	1. What is happening?
26	2. Who is involved and what role does each person have?
27	3. What recurring behavior or pattern are you seeing?
28	4. How is it affecting the project, team, or decisions?
29	5. What have you already tried?
30	6. What outcome do you want?
31	7. Is there a power imbalance, dependency, or retaliation risk?
32
33	If the user gives only a short story, infer the likely conflict pattern carefully and state assumptions.
34
35	## What to diagnose
36
37	Quickly identify:
38	- the recurring behavior pattern or archetype that best fits the description
39	- whether multiple patterns may be interacting
40	- whether the issue is primarily about ego, control, avoidance, indecision, chaos, blame-shifting, status signaling, or weak communication
41	- whether the team context is rewarding or enabling the behavior
42	- what bad responses are likely to escalate the problem
43	- what realistic response options the user actually has
44
45	Prefer the exact archetype names from the source material instead of inventing new labels when one of the named patterns fits.
46
47	## Named archetypes from the source material
48
49	Default to the 48 Neil on Software archetypes documented in `references/neil-on-software-archetypes.md`.
50
51	Use the exact archetype label when it fits. If the story does not fit one cleanly, say which two or three named archetypes are most relevant and explain why. If a locally downloaded source page was missing for one of the 48, say that the archetype name is part of the taxonomy but the local notes are incomplete.
52
53	Also use these source-material signals when available:
54	- what the archetype can mutate into
55	- what it is dangerous when coupled with
56	- likelihood of fixing
57	- danger to project
58	- the extracted fix or mitigation strategy
59
60	## Response structure
61
62	Always organize the answer using this structure.
63
64	### Situation Summary
65	- summarize the conflict in plain language
66	- state the actual project problem, not just the personality problem
67
68	### Likely Conflict Pattern(s)
69	- identify the most likely named archetype from the source material
70	- use the exact archetype label when possible
71	- mention uncertainty if more than one pattern fits
72	- if relevant, list a primary archetype and secondary archetype
73	- mention mutation paths or dangerous pairings if they materially increase the risk
74
75	### Evidence in the Story
76	- point to the behaviors that support the reading
77	- distinguish observed facts from interpretation
78
79	### Risks if This Continues
80	- project risks
81	- communication risks
82	- trust or morale risks
83	- escalation risks
84	- whether the source material marks the archetype as especially dangerous to the project or especially likely/unlikely to fix
85
86	### Recommended Strategy
87	- how to communicate
88	- what to document
89	- what boundaries to set
90	- what to avoid
91	- whethe

StanestanePublisher · 59 listings

Preview

Stanestane/game-design-skills-bundle

# Software Team Conflict Patterns

Analyze recurring collaboration problems without pretending to diagnose people.

Use this skill when the user describes a difficult person or recurring team conflict on a software or game project and needs help understanding the likely behav

Read `references/neil-on-software-archetypes.md` when you need the full 48-archetype taxonomy from the Neil on Software source material, including mutation path

RepoStanestane/game-design-skills-bundle

License—

TypeSkills

CategoryGeneral

UpdatedJun 2026

Repo stars34

First seenJul 22, 2026

People who liked this also viewed

6 picks

Type