| name | callable-sub-summary |
| description | give me a marketing summary. what features can I expect from these callable subs?. |
| argument-hint | [optional: path-glob for process files] |
| user-invocable | true |
Callable Sub Summary
Generate a concise, marketing-oriented summary of connector capabilities from process files where:
- process kind is CALLABLE_SUB
- start element type is CallSubStart
- tags contains connector
The summary must be grouped by what a workflow team can actually do with the callable subs.
Inputs
- Optional file glob argument. Default: ./**/*.p.json
- Optional prose output file path. Default: stdout
Procedure
Before running, check the current OS. If on Windows, git bash or WSL is recommended to use for best compatibility.
- Run the prose summary script (it reuses the JSON extractor internally):
- bash ./.github/skills/callable-sub-summary/scripts/list-callable-sub-starts-json.sh
- For file output, run:
- bash ./.github/skills/callable-sub-summary/scripts/list-callable-sub-starts-json.sh './**/*.p.json' docs/callable-sub-capabilities-summary.txt
- Inspect the generated callable-sub capability output and summarize it in marketing language.
Output Rules
When asked for a summary such as "give me a marketing summary" or "what features can I expect", produce this format:
- Intro sentence: one concise value statement.
- Section heading:
What you get
- 4-6 bullets, each describing concrete workflow capabilities (prefer grouping by domain when present: calendar, mail, files, chat, todo).
- Section heading:
At a glance
- 3-5 bullets with compact proof points such as callable count, domain coverage, read/write mix, typed payload usage, connector-tag discoverability.
- Section heading:
Expected developer experience
- 2-4 bullets focused on developer outcomes (integration speed, reusable orchestration patterns, fit for real workflow use cases).
- Optional final sentence: clearly visible coverage limits only (for example input-only or result-only starts).
Additional requirements:
- Keep the response concise and scannable (typically 10-16 lines).
- Focus on signatures and typed input/result params as proof of capability.
- Use marketing language, but keep claims grounded in detected starts only.
- Prefer action-oriented phrasing that explains what teams can build.
- Do not paste raw JSON in the final summary.
