From nacl
Define system boundaries in Neo4j graph: scope, stakeholders, external entities, data flows.— all data stored as graph nodes and edges. Use when: define system scope with graph, system context diagram, or the user says "/nacl:ba-context".
How this skill is triggered — by the user, by Claude, or both
Slash command
/nacl:ba-contextsonnetThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Define system boundaries: what is automated, what stays outside, who interacts with the system and what data is exchanged. All facts are persisted as Neo4j nodes and relationships — no markdown files are produced. Mermaid diagrams are generated from graph queries at render time.
Define system boundaries: what is automated, what stays outside, who interacts with the system and what data is exchanged. All facts are persisted as Neo4j nodes and relationships — no markdown files are produced. Mermaid diagrams are generated from graph queries at render time.
The interactive protocol is identical; only the storage backend changes.
┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ Phase 1 │ │ Phase 2 │ │ Phase 3 │ │ Phase 4 │
│ System │───▶│ External │───▶│ Data │───▶│ Context │
│ Scope │ │ Entities │ │ Flows │ │ Diagram │
└─────────────┘ └─────────────┘ └─────────────┘ └─────────────┘
interactive interactive constructive automated
Each phase ends with:
Do not proceed to the next phase without explicit user confirmation!
| Tool | Purpose |
|---|---|
mcp__neo4j__read-cypher | Read-only queries (list, verify, diagram data) |
mcp__neo4j__write-cypher | Create / update nodes and relationships (MERGE) |
Connection details are in ${CLAUDE_PLUGIN_ROOT}/nacl-core/SKILL.md.
| Node Label | Format | Example | Counter |
|---|---|---|---|
| SystemContext | SYS-NNN | SYS-001 | Global sequential |
| Stakeholder | STK-NN | STK-01 | Global sequential |
| ExternalEntity | EXT-NN | EXT-01 | Global sequential |
| DataFlow | DFL-NNN | DFL-001 | Global sequential |
To get the next available ID:
// Example: next SystemContext ID
MATCH (n:SystemContext)
WITH max(toInteger(replace(n.id, 'SYS-', ''))) AS maxNum
RETURN 'SYS-' + apoc.text.lpad(toString(coalesce(maxNum, 0) + 1), 3, '0') AS nextId
fullMATCH (sc:SystemContext) RETURN sc.id, sc.name
updateMATCH (sc:SystemContext)
OPTIONAL MATCH (sc)-[:HAS_STAKEHOLDER]->(stk:Stakeholder)
OPTIONAL MATCH (sc)-[:HAS_EXTERNAL_ENTITY]->(ext:ExternalEntity)
OPTIONAL MATCH (ext)-[flow:HAS_FLOW]->(sc)
RETURN sc, collect(DISTINCT stk) AS stakeholders,
collect(DISTINCT ext) AS external_entities,
collect(DISTINCT {entity: ext.name, direction: flow.direction, data: flow.data_description}) AS data_flows
(This is the named query ba_system_context from graph-infra/queries/ba-queries.cypher.)full modeGoal: Define automation boundaries — what the system does, for whom, what is excluded.
**Phase 1: System Scope**
1. What is the system called?
2. What are the automation goals? (what problems should it solve)
3. Who are the stakeholders? (who is interested and why)
4. What areas are automated? (what is in scope)
5. What is NOT in scope? (explicit exclusions)
6. Are there known constraints or assumptions?
Answer by number: 1 — ..., 2 — ..., 3 — ...
Ask numbered questions. If the user cannot answer — propose reasonable assumptions explicitly marked [assumption].
MERGE (sc:SystemContext {id: $sysId})
SET sc.name = $systemName,
sc.goals = $goals, // list of strings
sc.in_scope = $inScope, // list of strings
sc.out_of_scope = $outOfScope, // list of strings
sc.constraints = $constraints, // list of strings
sc.assumptions = $assumptions, // list of strings
sc.success_criteria = $criteria, // list of strings
sc.status = 'draft',
sc.created = date(),
sc.updated = date()
For each stakeholder:
MERGE (stk:Stakeholder {id: $stkId})
SET stk.name = $name,
stk.role = $role,
stk.interest = $interest
WITH stk
MATCH (sc:SystemContext {id: $sysId})
MERGE (sc)-[:HAS_STAKEHOLDER]->(stk)
Show the user a Phase 1 summary and ask:
Phase 1 summary:
- System: {{system_name}}
- Goals: {{brief list}}
- Scope: {{what is in}}
- Exclusions: {{what is out}}
- Stakeholders: {{count}} recorded
All correct? Proceed to external entities?
After confirmation -> Phase 2
Goal: Identify who and what interacts with the system — users, external systems, organizations.
**Phase 2: External Entities**
Who and what interacts with the system?
For each entity provide:
- Name
- Type: User / External System / Organization
- Description: what it does, why it interacts
Examples:
- "Sales Manager" (User) — creates orders, tracks statuses
- "1C:Accounting" (External System) — receives shipment data
- "Suppliers" (Organization) — provide price lists
For each entity record:
For each entity:
MERGE (ext:ExternalEntity {id: $extId})
SET ext.name = $name,
ext.type = $type, // "User" | "ExternalSystem" | "Organization"
ext.description = $description
WITH ext
MATCH (sc:SystemContext {id: $sysId})
MERGE (sc)-[:HAS_EXTERNAL_ENTITY]->(ext)
I have recorded the following external entities:
| # | Entity | Type | Description |
|---|--------|------|-------------|
| 1 | {{entity_1}} | {{type}} | {{description}} |
| 2 | {{entity_2}} | {{type}} | {{description}} |
Is the list complete? Anyone missing?
After confirmation -> Phase 3
Goal: Determine what data enters and exits the system for each external entity.
This is a constructive phase: the agent proposes data flows based on entity descriptions from Phase 2; the user confirms or corrects.
The agent does NOT invent flows from nothing — it structures and names flows based on what the user already described in Phase 1 and Phase 2.
For each external entity from Phase 2 determine:
Name flows concretely:
If the direction is ambiguous for an entity — ask a clarifying question
Based on entity descriptions I propose the following data flows:
| # | Entity | Incoming flows (-> system) | Outgoing flows (system ->) |
|---|--------|----------------------------|----------------------------|
| 1 | {{entity_1}} | {{data_in}} | {{data_out}} |
| 2 | {{entity_2}} | {{data_in}} | {{data_out}} |
Questions:
1. Are the flow directions correct?
2. Are there flows I missed?
3. Should any flows be renamed?
For each confirmed flow:
MERGE (df:DataFlow {id: $dflId})
SET df.name = $flowName,
df.direction = $direction, // "IN" | "OUT" | "BOTH"
df.data_description = $dataDescription
WITH df
MATCH (ext:ExternalEntity {id: $extId})
MATCH (sc:SystemContext {id: $sysId})
MERGE (ext)-[:HAS_FLOW {direction: $direction, data_description: $dataDescription}]->(sc)
After confirmation -> Phase 4
Goal: Build a Mermaid context diagram from the graph and present the final result.
Query the full system context from the graph using ba_system_context:
MATCH (sc:SystemContext {id: $sysId})
OPTIONAL MATCH (sc)-[:HAS_STAKEHOLDER]->(stk:Stakeholder)
OPTIONAL MATCH (sc)-[:HAS_EXTERNAL_ENTITY]->(ext:ExternalEntity)
OPTIONAL MATCH (ext)-[flow:HAS_FLOW]->(sc)
RETURN sc,
collect(DISTINCT stk) AS stakeholders,
collect(DISTINCT {id: ext.id, name: ext.name, type: ext.type}) AS external_entities,
collect(DISTINCT {entity: ext.name, direction: flow.direction, data: flow.data_description}) AS data_flows
Build a Mermaid flowchart from query results
Show the diagram to the user for final confirmation
-->|"flow"| for unidirectional flows<-->|"flow"| for bidirectional flowsflowchart LR for horizontal layoutextStyle for external entities, sysStyle for the systemflowchart LR
subgraph ext ["External Entities"]
E1["{{entity_1}}"]
E2["{{entity_2}}"]
end
subgraph sys ["{{system_name}}"]
S["{{system_short_name}}"]
end
E1 -->|"{{flow_in_1}}"| S
S -->|"{{flow_out_1}}"| E1
E2 <-->|"{{flow_2}}"| S
classDef extStyle fill:#fff3cd,stroke:#ffc107
classDef sysStyle fill:#d4edda,stroke:#28a745
class E1,E2 extStyle
class S sysStyle
Context diagram generated from Neo4j graph.
Graph nodes created:
- SystemContext: {{sysId}} ({{system_name}})
- Stakeholders: {{count}} nodes
- External Entities: {{count}} nodes
- Data Flows: {{count}} nodes
Verification query:
ba_system_context (graph-infra/queries/ba-queries.cypher)
Diagram correct? Ready to finalize?
agent: nacl-ba-context
trigger: /nacl:ba-context
mode: interactive (dialogue with user)
reads:
- Neo4j: SystemContext, Stakeholder, ExternalEntity, DataFlow (in update mode)
- Reference query: ba_system_context (graph-infra/queries/ba-queries.cypher)
writes:
- Neo4j node: SystemContext (SYS-NNN)
- Neo4j node: Stakeholder (STK-NN)
- Neo4j node: ExternalEntity (EXT-NN)
- Neo4j node: DataFlow (DFL-NNN)
- Neo4j rel: (:SystemContext)-[:HAS_STAKEHOLDER]->(:Stakeholder)
- Neo4j rel: (:SystemContext)-[:HAS_EXTERNAL_ENTITY]->(:ExternalEntity)
- Neo4j rel: (:ExternalEntity)-[:HAS_FLOW]->(:SystemContext)
creates_directories: [] # No file output — graph only
calls_next:
- nacl-ba-process
parameters:
scope: full | update # full = from scratch, update = modify existing context
lang: ru | en # output language (default: ru)
Supports --lang=en for English output. See ${CLAUDE_PLUGIN_ROOT}/nacl-core/lang-directive.md.
When --lang=en: all generated text, node names, descriptions in English.
Default: Russian (ru).
If the user cannot answer all questions:
Assumption: The system has one external user role — "Client".
Justification: Only one end-user type was mentioned in the description.
SystemContext.assumptions property (string list)After Phase 4:
Run the verification query to confirm graph state:
MATCH (sc:SystemContext)
OPTIONAL MATCH (sc)-[:HAS_STAKEHOLDER]->(stk)
OPTIONAL MATCH (sc)-[:HAS_EXTERNAL_ENTITY]->(ext)
OPTIONAL MATCH (ext)-[flow:HAS_FLOW]->(sc)
RETURN sc.id, sc.name,
count(DISTINCT stk) AS stakeholder_count,
count(DISTINCT ext) AS entity_count,
count(DISTINCT flow) AS flow_count
Suggest next steps:
System context defined in Neo4j graph.
Next steps:
1. /nacl:ba-process — define business processes in the graph
2. /nacl:ba-full — run full BA cycle in graph mode
Node property documentation from graph-infra/schema/ba-schema.cypher:
SystemContext {
id: String, // SYS-NNN
name: String,
goals: [String],
in_scope: [String],
out_of_scope: [String],
constraints: [String],
assumptions: [String],
success_criteria: [String],
status: String, // "draft" | "confirmed"
created: Date,
updated: Date
}
Stakeholder {
id: String, // STK-NN
name: String,
role: String,
interest: String
}
ExternalEntity {
id: String, // EXT-NN
name: String,
type: String, // "User" | "ExternalSystem" | "Organization"
description: String
}
DataFlow {
id: String, // DFL-NNN
name: String,
direction: String, // "IN" | "OUT" | "BOTH"
data_description: String
}
Relationships:
(:SystemContext)-[:HAS_STAKEHOLDER]->(:Stakeholder)
(:SystemContext)-[:HAS_EXTERNAL_ENTITY]->(:ExternalEntity)
(:ExternalEntity)-[:HAS_FLOW {direction, data_description}]->(:SystemContext)
Before completing, verify:
npx claudepluginhub itsalt/nacl --plugin naclGuides collaborative design exploration before implementation: explores context, asks clarifying questions, proposes approaches, and writes a design doc for user approval.
Creates structured, bite-sized implementation plans from specs or requirements before writing code. Useful for breaking down multi-step tasks into testable steps with file structure and task boundaries.
Synthesizes the current conversation into a structured spec (PRD) and publishes it to the project issue tracker with a ready-for-agent label, without interviewing the user.