원클릭으로 Manus에서 모든 스킬 실행

gts-analyze

스타21

포크30

업데이트2026년 6월 8일 22:47

Analyze how the GTS (Global Type System) is used in a Gear — defined types, declared instances, and references across sdk / main / plugin / docs. Thin wrapper around the `gts-analyze` CLI under tools/.

설치

Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.

Manus에서 실행

출처

constructorfabric

constructorfabric/gears-rust

GitHub 저장소 열기 Creator 저장소 보기

다운로드

Manus에서 실행

gts-analyze

Thin wrapper around the workspace binary at tools/gts-analyze/. Source code, full docs, and human-readable usage live there: tools/gts-analyze/README.md.

How to invoke

Parse the user's invocation for a gear path (absolute or repo-relative). If absent, ask once.
Run from the workspace root:
```
cargo run --release -p gts-analyze -- <MODULE_PATH> [flags]
```
First invocation in a fresh checkout compiles the crate (~30s with syn); subsequent runs are instant.
Show the markdown report verbatim — don't summarise away the per-type detail.

Flags

--format json — machine-readable JSON instead of markdown.
--out FILE — write report to file instead of stdout.
--include-tests — include Rust test files (default skips integration tests, benches, *_test(s).rs, and items behind #[test] / #[cfg(test)]).
--skip-docs — drop every *.md and any file under docs/. Note: type definitions sourced from docs/schemas/*.schema.json disappear too — use only for code-only audits.
-v / --verbose — expand reference lists to per-line file:line — context. Default is compact (file + count).

Report sections

Summary — file counts and totals.
GTS Types Defined Here — per defined type: schema source (#[gts_type_schema] / *.schema.json / struct_to_gts_schema!), location, struct name when applicable, and usage breakdown across sdk / main / plugin / doc.
GTS Instances Defined Here — per declared instance: macro form, inferred typed struct, base type, location, and usage breakdown.
Other GTS IDs Referenced — table of IDs not defined here, plus a collapsible per-ID file breakdown.

Tips

A GTS ID ending with ~ is a Type, otherwise an Instance (gts-spec §8.1).
For doc-heavy gears with hundreds of .md references, suggest --skip-docs if the user only cares about code usage.
cargo run builds on first invocation; if the user is running this often, cargo build --release -p gts-analyze once up front avoids latency.

이 저장소의 다른 Skills

같은 저장소

toolkit-pr-review-v2

constructorfabric/gears-rust

Review Rust PRs against idiomatic Rust guidelines and ToolKit framework rules, post inline comments on GitHub

2026-06-1221

gear-creator

constructorfabric/gears-rust

Interactive workflow for creating new ToolKit gears and editing existing ones. Use when adding a new gear to the platform, adding features to an existing gear (REST endpoints, DB entities, OData filtering, plugins, lifecycle/background tasks, SSE events, error types), refactoring gear layer structure, or creating SDK crates. Covers the full DDD-light stack — SDK pattern, contract/API/domain/infra layers, OperationBuilder, SecureORM, ClientHub, error handling, and testing.

2026-06-0821

toolkit-pr-review

constructorfabric/gears-rust

Review Rust PRs against idiomatic Rust guidelines and ToolKit framework rules, post inline comments on GitHub

2026-06-0821

name	gts-analyze
description	Analyze how the GTS (Global Type System) is used in a Gear — defined types, declared instances, and references across sdk / main / plugin / docs. Thin wrapper around the `gts-analyze` CLI under tools/.
user-invocable	true
allowed-tools	Bash

gts-analyze

Thin wrapper around the workspace binary at tools/gts-analyze/. Source code, full docs, and human-readable usage live there: tools/gts-analyze/README.md.

How to invoke

Parse the user's invocation for a gear path (absolute or repo-relative). If absent, ask once.
Run from the workspace root:
```
cargo run --release -p gts-analyze -- <MODULE_PATH> [flags]
```
First invocation in a fresh checkout compiles the crate (~30s with syn); subsequent runs are instant.
Show the markdown report verbatim — don't summarise away the per-type detail.

Flags

--format json — machine-readable JSON instead of markdown.
--out FILE — write report to file instead of stdout.
--include-tests — include Rust test files (default skips integration tests, benches, *_test(s).rs, and items behind #[test] / #[cfg(test)]).
--skip-docs — drop every *.md and any file under docs/. Note: type definitions sourced from docs/schemas/*.schema.json disappear too — use only for code-only audits.
-v / --verbose — expand reference lists to per-line file:line — context. Default is compact (file + count).

Report sections

Summary — file counts and totals.
GTS Types Defined Here — per defined type: schema source (#[gts_type_schema] / *.schema.json / struct_to_gts_schema!), location, struct name when applicable, and usage breakdown across sdk / main / plugin / doc.
GTS Instances Defined Here — per declared instance: macro form, inferred typed struct, base type, location, and usage breakdown.
Other GTS IDs Referenced — table of IDs not defined here, plus a collapsible per-ID file breakdown.

Tips

A GTS ID ending with ~ is a Type, otherwise an Instance (gts-spec §8.1).
For doc-heavy gears with hundreds of .md references, suggest --skip-docs if the user only cares about code usage.
cargo run builds on first invocation; if the user is running this often, cargo build --release -p gts-analyze once up front avoids latency.