How to check this install's capabilities
Different Buffaly installs can have different tools, services, skills, providers, web modules, and credentials. Ask Buffaly to inventory the live install before planning work that depends on a capability.
Capability families to look for
Tools
File search, file reading, process execution, validation, session management, secrets, and other direct actions.
Skills
Groups of related actions such as file/workspace, process, memory, wiki, browser, service discovery, or session skills.
Services
Projected service methods and domain services that Buffaly can discover and call through typed boundaries.
Configured integrations
Provider modules, browser/voice modules, Google Workspace, GitHub, MCP bindings, SQL, HTTP, or other environment-specific surfaces.
How to verify capabilities
- Ask Buffaly to list loaded action tools.
- Ask for registered skills and the actions inside a relevant skill.
- Ask whether a capability is loaded, loadable, or missing.
- For integrations, ask for a harmless live verification before relying on them.
- Separate read-only capabilities from write, send, save, deploy, or delete capabilities.
Good request: “Show this install's capabilities for files, GitHub, Google Workspace, browser automation, model providers, and session history. Tell me which are ready now and which need setup.”
Good user requests
- “What tools are already loaded in this session?”
- “Which skills can help with this task?”
- “Can this install read Google Sheets? Verify without changing anything.”
- “Can this install edit code and commit? Show the safe workflow first.”
- “Which capabilities require credentials or explicit approval?”
Use the inventory before automation
Once you know what the install can do, choose one capability and ask Buffaly to propose a safe first workflow with validation and approval points.
Example prompts and expected output
- “Show this install's tools, loaded actions, and available skills.”
- “Can this install use GitHub, Google Workspace, Codex, browser/UI tools, and provider/model calls?”
- “List what is configured, what is available but not loaded, and what needs credentials.”
A good inventory separates configured capabilities from possible-but-not-configured ones, and it should name the validation evidence rather than guessing.