ワンクリックで
gcli
Google Workspace CLI (Gmail, Calendar, Drive) via gcli — use --for-ai flag for token-efficient structured output.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
メニュー
Google Workspace CLI (Gmail, Calendar, Drive) via gcli — use --for-ai flag for token-efficient structured output.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | gcli |
| description | Google Workspace CLI (Gmail, Calendar, Drive) via gcli — use --for-ai flag for token-efficient structured output. |
Single binary for Gmail, Calendar, and Drive. Always use --for-ai for structured, token-efficient output.
NEVER send, reply, forward, or delete email/calendar events without explicit user confirmation of the recipient(s), subject, and body. Always show the user what will be sent and wait for approval before executing. The same applies to cal create, cal edit, cal delete, and drive upload.
Before using any gcli command, verify it is installed:
command -v gcli >/dev/null 2>&1 && echo "gcli: installed" || echo "gcli: not installed — install from https://github.com/AryaLabsHQ/gcli and run 'gcli login'"
If gcli is not installed, tell the user and stop. Do not attempt gcli commands without this check.
# List inbox (default 20)
gcli mail list --for-ai
gcli mail list 10 --unread --for-ai
# Read a thread
gcli mail get <thread-id> --for-ai
# Search
gcli mail search "from:boss subject:review" --for-ai
# Send
gcli mail send -t "user@example.com" -s "Subject" --body-file msg.txt
# Reply (use thread-id from list/search)
gcli mail reply <thread-id> --body-file reply.txt
gcli mail reply <thread-id> --all --body-file reply.txt
# Forward / mark
gcli mail forward <thread-id> -t "other@example.com"
gcli mail mark <message-id> --read
gcli mail mark <message-id> --trash
# Today's events
gcli cal list --for-ai
# Next 7 days
gcli cal list 7 --for-ai
# All calendars
gcli cal list 7 --all-calendars --for-ai
# Event details
gcli cal get <event-id> --for-ai
# Create
gcli cal create "Meeting" -s "tomorrow 2pm" -d "1h" --attendee "person@example.com"
# Edit / delete
gcli cal edit <event-id> -s "tomorrow 3pm"
gcli cal delete <event-id>
# List root
gcli drive list --for-ai
# List folder
gcli drive list "path/to/folder" --for-ai
# Search
gcli drive search "quarterly report" --for-ai
# Shared files
gcli drive list -s --for-ai
# Download / upload
gcli drive download "path/to/file" -o ./local-file
gcli drive upload ./local-file "path/to/folder"
# Info / permissions
gcli drive info "path/to/file" --for-ai
gcli drive permissions "path/to/file" --for-ai
When writing email body:
tmp=$(mktemp)--body-file "$tmp" to send — avoids shell escaping issuesrm -f "$tmp"mail list and mail search feed into mail get, mail reply, mail forwardcal list feed into cal get, cal edit, cal delete--for-ai strips HTML and formats for LLM consumption — always use it for reads-A file1.pdf -A file2.pdf (repeatable)Generate Architecture Decision Records — use when asked to document a decision, create an ADR, record why we chose X, or capture architectural rationale.
Generate documentation for code — use when asked to document a module, generate API docs, create a README for code, or write reference documentation. Triggers the deterministic doc-gen workflow (analyze → generate via documenter agent → write).
Check devkit health — which external CLIs (codex, gemini, gh, rtk, sg, gcli) are installed, which agents are available, which skills are ready to use. Use when asked about devkit health, devkit status, "is devkit working?", "what's installed?", "what devkit capabilities do I have?", diagnosing devkit setup issues, or running /devkit:health. Read-only diagnostic, safe to auto-invoke.
Fan-out PR review that runs BOTH `/devkit:tri-review` AND `/pr-review-toolkit:review-pr` in parallel for maximum coverage, then presents unified results — this skill does not compete with its sub-skills, it delegates to both simultaneously. Use when the user asks for "mega PR review", "mega-pr", "mega review", "full PR review with everything", "both review tools", "maximum coverage review", or explicitly wants every available reviewer looking at a change at once (Claude + Codex + Gemini model diversity PLUS specialized aspect reviewers like silent-failure-hunter, type-design-analyzer, test-analyzer, code-reviewer). Worth the extra cost when: the PR is high-stakes and the user wants every angle covered, or before merging a critical or hard-to-revert change. Do NOT use when the user only wants one review system (use tri-review or pr-review-toolkit:review-pr directly). Do NOT use for routine code review where a single reviewer suffices. This is deliberate overkill for when you want absolutely everything.
Generate a codebase onboarding guide — use when asked to explain this codebase, help understand the architecture, give a tour of the repo, or onboard a new contributor. Triggers the deterministic onboard workflow (analyze structure → architect via researcher agent → write guide).
Full end-to-end PR pipeline — validate → necessity-check → lint (loop) → test (loop) → security scan → doc-check → changelog → create-pr → monitor reviews (loop). Takes a branch from "code done" to "merged" with every gate enforced. Use when the user asks to "submit a PR", "open a pull request", "ship this", "make this PR-ready", "finalize this branch", or wants the full pipeline run end-to-end with CI monitoring and reviewer-comment handling automated. Worth the ceremony when: lint and test gates must pass before the PR opens, docs need syncing alongside code (README, ROADMAP, SKILL.md, workflows), security scan is required, or the user wants reviewer comments automatically classified and responded to. Do NOT use for a quick commit+push+PR without gates — use `/commit-commands:commit-push-pr` for that lighter path. Do NOT use when already mid-PR and just handling existing review comments in isolation. Do NOT use on the main branch or with uncommitted changes — the validate step will block you. This is devkit