map-systems

Name: map-systems
Author: tranhieutt

69stars41forks

How to install map-systems?

tranhieutt/software_development_department/map-systems

$npx -y skills add tranhieutt/software_development_department --skill map-systems

Installs into the current project.

Summary

Creates a visual and textual map of the project systems, services, data flows, and integration boundaries. Use when documenting system architecture or when the user mentions system map, architecture diagram, or service boundaries.

Files · 1

View on GitHub

SKILL.md

1	When this skill is invoked:
2
3	## 1. Parse Arguments
4
5	Two modes:
6
7	- No argument: `/map-systems` — Run the full decomposition workflow (Phases 1-5)
8	to create or update the systems index.
9	- `next`: `/map-systems next` — Pick the highest-priority undesigned system
10	from the index and hand off to `/design-system` (Phase 6).
11
12	---
13
14	## 2. Phase 1: Read Concept (Required Context)
15
16	Read the product concept and any existing design work. This provides the raw material
17	for systems decomposition.
18
19	Required:
20	- Read `design/docs/product-concept.md` — fail with a clear message if missing:
21	> "No product concept found at `design/docs/product-concept.md`. Run `/brainstorm` first
22	> to create one, then come back to decompose it into systems."
23
24	Optional (read if they exist):
25	- Read `design/docs/product-pillars.md` — pillars constrain priority and scope
26	- Read `design/docs/systems-index.md` — if exists, resume from where it left off
27	(update, don't recreate from scratch)
28	- Glob `design/docs/*.md` — check which system PRDs already exist
29
30	If the systems index already exists:
31	- Read it and present current status to the user
32	- Use `AskUserQuestion` to ask:
33	"The systems index already exists with [N] systems ([M] designed, [K] not started).
34	What would you like to do?"
35	- Options: "Update the index with new systems", "Design the next undesigned system",
36	"Review and revise priorities"
37
38	---
39
40	## 3. Phase 2: Systems Enumeration (Collaborative)
41
42	Extract and identify all systems the product needs. This is the creative core of the
43	skill — it requires human judgment because concept docs rarely enumerate every
44	system explicitly.
45
46	### Step 2a: Extract Explicit Systems
47
48	Scan the product concept for directly mentioned systems and mechanics:
49	- Core Mechanics section (most explicit)
50	- Core Loop section (implies what systems drive each loop tier)
51	- Technical Considerations section (networking, procedural generation, etc.)
52	- MVP Definition section (required features = required systems)
53
54	### Step 2b: Identify Implicit Systems
55
56	For each explicit system, identify the hidden systems it implies. Products always
57	need more systems than the concept doc mentions. Use this inference pattern:
58
59	- "Inventory" implies: item database, equipment slots, weight/capacity rules,
60	inventory UI, item serialization for save/load
61	- "Combat" implies: damage calculation, health system, hit detection, status effects,
62	enemy AI, combat UI (health bars, damage numbers), death/respawn
63	- "Open world" implies: streaming/chunking, LOD system, fast travel, map/minimap,
64	point of interest tracking, world state persistence
65	- "Multiplayer" implies: networking layer, lobby/matchmaking, state synchronization,
66	anti-cheat, network UI (ping, user list)
67	- "Crafting" implies: recipe database, ingredient gathering, crafting UI,
68	success/failure mechanics, recipe discovery/learning
69	- "Dialogue" implies: dialogue tree system, dialogue UI, choice tracking, NPC
70	state management, localization hooks
71	- "Progression" implies: XP system, level-up mechanics, skill tree, unlock
72	tracking, progression UI, progression save data
73
74	Explain in conversation text why each implicit system is needed (with examples).
75
76	### Step 2c: User Review
77
78	Present the enumeration organized by category. For each system, show:
79	- Name
80	- Category
81	- Brief description (1 sentence)
82	- Whether it was explicit (from concept) or implicit (inferred)
83
84	Then use `AskUserQuestion` to capture feedback:
85	- "Are there systems missing from this list?"
86	- "Should any of these be combined or split?"
87	- "Are there systems listed that this product does NOT need?"
88
89	Iterate until the user approves the enumeration.
90
91	---
92
93	## 4. Phase 3: Dependency Mapping (Collaborative)
94
95	For each system, determine what it depends on. A system "depends on" another if
96	it cannot function without that other system existing first.
97
98	### Step 3a: Map Dependencies
99
100	For each system, list its dependencies. Use these dependency heuristics:
101	- Input/output dependencies: System A produces data System B needs
102	- Structural dependencies: System A provides the framework System B plugs into
103	- UI dependencies: Every business system has a corresponding UI system that
104	depends on it (but UI is designed after the business system)
105
106	### Step 3b: Sort by Depende

People who liked this also viewed

6 picks

Type

map-systems

69stars41forks

View on GitHub

How to install map-systems?

tranhieutt/software_development_department/map-systems

$npx -y skills add tranhieutt/software_development_department --skill map-systems

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	When this skill is invoked:
2
3	## 1. Parse Arguments
4
5	Two modes:
6
7	- No argument: `/map-systems` — Run the full decomposition workflow (Phases 1-5)
8	to create or update the systems index.
9	- `next`: `/map-systems next` — Pick the highest-priority undesigned system
10	from the index and hand off to `/design-system` (Phase 6).
11
12	---
13
14	## 2. Phase 1: Read Concept (Required Context)
15
16	Read the product concept and any existing design work. This provides the raw material
17	for systems decomposition.
18
19	Required:
20	- Read `design/docs/product-concept.md` — fail with a clear message if missing:
21	> "No product concept found at `design/docs/product-concept.md`. Run `/brainstorm` first
22	> to create one, then come back to decompose it into systems."
23
24	Optional (read if they exist):
25	- Read `design/docs/product-pillars.md` — pillars constrain priority and scope
26	- Read `design/docs/systems-index.md` — if exists, resume from where it left off
27	(update, don't recreate from scratch)
28	- Glob `design/docs/*.md` — check which system PRDs already exist
29
30	If the systems index already exists:
31	- Read it and present current status to the user
32	- Use `AskUserQuestion` to ask:
33	"The systems index already exists with [N] systems ([M] designed, [K] not started).
34	What would you like to do?"
35	- Options: "Update the index with new systems", "Design the next undesigned system",
36	"Review and revise priorities"
37
38	---
39
40	## 3. Phase 2: Systems Enumeration (Collaborative)
41
42	Extract and identify all systems the product needs. This is the creative core of the
43	skill — it requires human judgment because concept docs rarely enumerate every
44	system explicitly.
45
46	### Step 2a: Extract Explicit Systems
47
48	Scan the product concept for directly mentioned systems and mechanics:
49	- Core Mechanics section (most explicit)
50	- Core Loop section (implies what systems drive each loop tier)
51	- Technical Considerations section (networking, procedural generation, etc.)
52	- MVP Definition section (required features = required systems)
53
54	### Step 2b: Identify Implicit Systems
55
56	For each explicit system, identify the hidden systems it implies. Products always
57	need more systems than the concept doc mentions. Use this inference pattern:
58
59	- "Inventory" implies: item database, equipment slots, weight/capacity rules,
60	inventory UI, item serialization for save/load
61	- "Combat" implies: damage calculation, health system, hit detection, status effects,
62	enemy AI, combat UI (health bars, damage numbers), death/respawn
63	- "Open world" implies: streaming/chunking, LOD system, fast travel, map/minimap,
64	point of interest tracking, world state persistence
65	- "Multiplayer" implies: networking layer, lobby/matchmaking, state synchronization,
66	anti-cheat, network UI (ping, user list)
67	- "Crafting" implies: recipe database, ingredient gathering, crafting UI,
68	success/failure mechanics, recipe discovery/learning
69	- "Dialogue" implies: dialogue tree system, dialogue UI, choice tracking, NPC
70	state management, localization hooks
71	- "Progression" implies: XP system, level-up mechanics, skill tree, unlock
72	tracking, progression UI, progression save data
73
74	Explain in conversation text why each implicit system is needed (with examples).
75
76	### Step 2c: User Review
77
78	Present the enumeration organized by category. For each system, show:
79	- Name
80	- Category
81	- Brief description (1 sentence)
82	- Whether it was explicit (from concept) or implicit (inferred)
83
84	Then use `AskUserQuestion` to capture feedback:
85	- "Are there systems missing from this list?"
86	- "Should any of these be combined or split?"
87	- "Are there systems listed that this product does NOT need?"
88
89	Iterate until the user approves the enumeration.
90
91	---
92
93	## 4. Phase 3: Dependency Mapping (Collaborative)
94
95	For each system, determine what it depends on. A system "depends on" another if
96	it cannot function without that other system existing first.
97
98	### Step 3a: Map Dependencies
99
100	For each system, list its dependencies. Use these dependency heuristics:
101	- Input/output dependencies: System A produces data System B needs
102	- Structural dependencies: System A provides the framework System B plugs into
103	- UI dependencies: Every business system has a corresponding UI system that
104	depends on it (but UI is designed after the business system)
105
106	### Step 3b: Sort by Depende

People who liked this also viewed

6 picks

Type