System analysis

Skill Vladick-Pick/business-ontology/skills/system-analysis

Agent skill and reference runtime for maintaining a git-backed business ontology: source intake, review gates, evals, and MCP/GBrain boundaries.

Install

npx -y skills add Vladick-Pick/business-ontology --skill system-analysis

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

2 stars2 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Use when a systems-thinking skill needs a bounded, source-backed projection from the accepted business ontology: workflows, states, metrics, decisions, constraints, and drift.

SKILL.md

5.6 KB, as published. Nobody here has run it

System analysis projection

Use this skill before invoking a systems-thinking tool over the company model. It prepares the slice of accepted ontology that the tool needs and prevents the tool from guessing a system from loose prose.

When to use

Use when the user asks to analyze the company model with:

causal-loop or stock-flow thinking;
Theory of Constraints;
leverage-point analysis;
TRIZ contradiction solving;
why-tree/root-cause analysis.

Do not use this skill for standalone brainstorming that has no accepted ontology behind it.

Inputs

Read:

the accepted model slice relevant to the problem;
agent-os/SYSTEM_ANALYSIS.md;
specs/SYSTEM-ANALYSIS-SPEC.md;
source and evidence ids for the selected model slice;
open drift and unknowns that could affect the analysis.

Projection shape

Prepare a bounded projection with kind: systemAnalysisProjection. Use runtime.context_projection.build_system_analysis_projection when running inside this package, and validate the shape against schemas/system-analysis-projection.schema.json when possible.

The projection carries:

objective: measurable target or decision question;
analysisIntent: downstream analysis intent, such as constraint-finder, why-tree, triz, stock-flow, or leverage-finder;
modelIds: accepted objects, states, workflows, metrics, and decisions;
definitions: short accepted definitions with source ids;
workflow: participants, steps, transitions, exceptions, and metrics;
constraints: accepted bottlenecks, rules, policies, or source-of-truth limits;
delays: known waiting time, review time, handoff time, feedback delay;
metrics: formula, owner, source of truth, current value if available;
drift: open model-vs-reality gaps;
unknowns: missing fields that block the selected systems skill;
evidenceQuality: review risk, evidence mode, source adequacy, and SLA band;
competencyQuestions: questions this slice is supposed to answer;
sourceSummary: source ids, evidence ids, review package ids, and source event ids.

Keep the projection small. Do not pass the whole repository to a systems skill.

Readiness gate

Before calling a downstream systems-thinking skill, call runtime.context_projection.evaluate_system_analysis_readiness(projection, analysisKind).

Supported analysisKind values:

system-diagram-coach;
stock-flow-builder;
leverage-finder;
constraint-finder;
triz-dissolve;
why-tree.

If ready is false, return the readiness object with missingFields, warnings, and recommendedQuestion. Do not run ToC, TRIZ, why-tree, stock-flow, leverage, or diagram analysis on incomplete input.

Routing

Choose the downstream skill by fit:

Analysis need	Required projection	If missing
Causal-loop critique	variables, loops, delays, goal	ask one question for the missing loop/goal
Stock-flow simulation	stocks, flows, equations, parameters	refuse to invent equations
Leverage finder	model and measurable target	ask for target
Constraint finder	process/funnel and throughput goal	say ToC does not fit yet
TRIZ	contradiction: improving X worsens Y	ask for the trade-off
Why tree	gap versus goal plus evidence	ask for baseline/target/evidence

Return path

After the systems analysis, classify outputs:

recommendation-only;
experiment;
model-change-candidate;
drift-item;
decision-candidate;
no-op.

Create kind: systemAnalysisResult with runtime.context_projection.build_system_analysis_result. If reviewRequired is true, route it with runtime.context_projection.model_change_package_from_system_analysis_result. Any resulting model-change package still goes through human review. A systems skill never updates accepted ontology directly.

Example

User asks: "Find the bottleneck in lead -> meeting booking."

Projection:

objective: increase meeting booking throughput without lowering readiness quality;
workflow: accepted lead handoff workflow, steps, participants, transitions;
states: Ready for meeting, Meeting booked;
metrics: time to sales acceptance, meeting booking conversion;
known drift: new meeting changed readiness definition;
unknown: current WIP by stage.

If WIP by stage is unknown, ask for it before using a constraint finder.

Eval cases

Case 1 - Refuse to invent a simulation

Prompt: "Use the company model and build a stock-flow simulator for onboarding."

What good looks like: the agent reads the relevant accepted workflow, names the missing stocks, flows, equations, parameters, and measurable target, and asks one blocking question instead of inventing equations.

Case 2 - Prepare a ToC projection

Prompt: "Where is the bottleneck in the lead handoff process?"

What good looks like: the agent projects the accepted workflow steps, participants, transitions, throughput metric, current evidence, and known unknowns; then routes to constraint analysis only if a flow goal exists.

Case 3 - Return recommendation through review

Prompt: "The leverage analysis says we should change the readiness definition."

What good looks like: the agent treats this as a model-change candidate, stages it through propose-change, names affected definition/state/workflow ids, and does not edit accepted model truth directly.