// Use when working with TeamCity CI/CD or when user provides a TeamCity build URL. Use `teamcity` CLI for builds, logs, jobs, queues, agents, and pipelines.
Use when authoring or modifying MPS IDE plugins — code that integrates with the MPS / IntelliJ host IDE shell. Covers `ActionDeclaration`, `ActionGroupDeclaration`, `ToolDeclaration` / `TabbedToolDeclaration` (dockable tool windows), `KeymapChangesDeclaration` (shortcuts), `PreferencesComponentDeclaration` (settings pages), `EditorTab` + `Order` (tabs on a concept editor), `InterfaceGroup` (bootstrap wrappers around external groups), `NonDumbAwareActions`, `IdeaConfigurationXml`, and `ApplicationPluginDeclaration` / `ProjectPluginDeclaration` / `StandalonePluginDescriptor` (lifecycle hooks). Uses the languages `jetbrains.mps.lang.plugin` and `jetbrains.mps.lang.plugin.standalone`. Trigger terms: action group, tool window, menu item, `MainMenu`, `EditorPopup`, `NodeActions`, `ModelActions`, `ModuleActions`, `ProjectViewPopupMenu`, MPS plugin solution, `ActionInstance`, `ModificationStatement`, `DataKey`, `MPSCommonDataKeys`, `MPSDataKeys`, dumb-aware, `project.tool<...>`, `project.preferenceComponent<...>`, `a
Wire MPS module and model dependencies, used languages, used devkits, extended languages, runtime solutions, accessory models, and language/dependency versions. Use when adding/removing module dependencies, importing languages or devkits into a model, declaring runtime solutions, or shipping accessory content visible to consumers without explicit import.
Use when defining or editing MPS node factories (the "actions" aspect) — `NodeFactories` roots, per-concept `NodeFactory` setup functions that initialize a freshly created node and optionally copy data from a replaced `sampleNode`, plus the actions aspect's `CopyPasteHandlers` and `PasteWrappers` roots. Reach for this skill when a substitution, side transform, completion replacement, or `add new initialized(...)` should preserve fields from the node it is replacing, or when defaults set in a constructor are not enough.
Use when defining or editing MPS `ConceptBehavior` — per-concept methods (virtual / final / abstract / static), constructors, virtual dispatch (MRO), super and interface-default calls (`super<Interface>.method`), overriding methods from `lang.core.behavior` interfaces such as `ScopeProvider.getScope` / `INamedConcept.getName` / `BaseConcept.getPresentation`, calling sibling methods (`LocalBehaviorMethodCall`) and behavior methods from other aspects via `node.method(...)`. Reach for this skill whenever the task involves authoring or modifying `<lang>/languageModels/behavior.mps`.
Use when defining or editing MPS language constraints — property validators / setters / getters, referent search scopes (imperative or inherited via `ScopeProvider.getScope`), `referentSetHandler` side effects, default-scope blocks, `canBeChild` / `canBeParent` / `canBeAncestor` / `canBeRoot` placement rules, `defaultConcreteConcept` for abstract concepts, `set <read-only>` and `{name}` aliasing, and scope helpers (`SimpleRoleScope`, `ListScope`, `CompositeScope`, `HidingByNameScope`). Reach for this skill whenever the task involves authoring or modifying `<lang>/languageModels/constraints.mps`.
Use when defining or debugging MPS dataflow builders for a concept — control/data flow declarations that drive reachability analysis and variable-use checking. Covers DataFlowBuilderDeclaration, BuilderBlock, emit instructions (code for, jump, ifjump, label, read, write, ret, mayBeUnreachable), positions (AfterPosition, BeforePosition, LabelPosition), the jetbrains.mps.lang.dataFlow language, the NodeParameter implicit, BL+smodel usage inside builder bodies, and IBuilderMode for advanced analyses such as nullable/non-null tracking.
| name | teamcity-cli |
| version | 0.9.0 |
| author | JetBrains |
| description | Use when working with TeamCity CI/CD or when user provides a TeamCity build URL. Use `teamcity` CLI for builds, logs, jobs, queues, agents, and pipelines. |
teamcity)teamcity auth status # Check authentication
teamcity run list --status failure # Find failed builds
teamcity run log <id> --failed --raw # Full failure diagnostics
Do not guess flags or syntax. Use the Command Reference or teamcity <command> --help. Builds are runs (teamcity run), build configurations are jobs (teamcity job). Never use --count — use --limit (or -n).
teamcity run tree <id>.--local-changes excludes Kotlin DSL — push .teamcity/ changes before running.--raw for logs and dump to a temp file. Always use --watch when starting builds.pipeline push does not validate — always run teamcity pipeline validate first.| Area | Commands |
|---|---|
| Builds | run list, view, start, watch, log, cancel, restart, tests, changes, tree |
| Artifacts | run artifacts, run download |
| Metadata | run pin/unpin, run tag/untag, run comment |
| Jobs | job list, view, tree, pause/resume, param list/get/set/delete |
| Projects | project list, view, tree, param, token put/get, settings export/status/validate |
| Queue | queue list, approve, remove, top |
| Agents | agent list, view, enable/disable, authorize/deauthorize, exec, term, reboot, move |
| Pools | pool list, view, link/unlink |
| Pipelines | pipeline list, view, create, validate, pull, push, delete |
| API | teamcity api <endpoint> — raw REST API access |
See Workflows for full details on each.
Investigate failure: teamcity run list --status failure → teamcity run log <id> --failed --raw → teamcity run tests <id> --failed
Debug build chain: teamcity run tree <run-id> → find deepest failed child → investigate that build
Fix build failure: diagnose → classify → fix (code: --local-changes, DSL: settings validate, pipeline: pipeline validate) → push
Monitor until green: start → watch → fix if failed → push → watch new build → repeat (max 3 attempts)
Pipeline: teamcity pipeline create <name> -p <project> / teamcity pipeline validate [file] / teamcity pipeline pull <pipeline-id> → edit → teamcity pipeline push <pipeline-id> [file]