القائمة
Use when turning Git history into standup reports, weekly updates, changelogs, PR summaries, OSS activity logs, or multi-repository development summaries with the git-standup CLI.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | git-standup |
| description | Use when turning Git history into standup reports, weekly updates, changelogs, PR summaries, OSS activity logs, or multi-repository development summaries with the git-standup CLI. |
| metadata | {"author":"Tresnanda","project":"https://github.com/Tresnanda/git-standup"} |
Use this skill when the user asks for a standup, weekly update, daily summary, branch activity report, changelog draft, OSS activity log, or multi-repository development summary.
Use the git-standup CLI as the source of truth for commit selection,
grouping, author filtering, and report formatting. Do not manually reconstruct
the report with ad hoc git log commands unless the CLI is unavailable.
git-standup is installed:git-standup --help
curl -fsSL https://raw.githubusercontent.com/Tresnanda/git-standup/main/install.sh | bash
Windows PowerShell:
irm https://raw.githubusercontent.com/Tresnanda/git-standup/main/install.ps1 | iex
When setup is unclear, run:
git-standup doctor
It is read-only, prints Git/Python/AI diagnostics, and masks credentials.
Use these commands as defaults:
git-standup --no-wizard --markdown
Last 7 days:
git-standup --no-wizard --days 7 --markdown
Today only:
git-standup --no-wizard --since YYYY-MM-DD --markdown
Since the last checkpointed report:
git-standup --no-wizard --since-last --write-checkpoint --markdown --no-ai
Use --write-checkpoint only when the user wants git-standup to update its
non-secret local checkpoint file after a successful report. If --since-last
has no saved checkpoint yet, run an initial explicit date/window report with
--write-checkpoint or ask for the desired starting date.
Only the current user's commits:
git-standup --no-wizard --author me --markdown
Specific authors:
git-standup --no-wizard --author "Alice|Bob" --markdown
Branch comparison:
git-standup --no-wizard --base-branch main --markdown
Specific paths:
git-standup --no-wizard --path src --path tests --markdown
PR-aware digest:
git-standup --no-wizard --markdown --include-prs
Use --include-prs / --pr-digest only when the user wants pull request
context. The flag may query GitHub through gh to enrich PR metadata; without
the flag, do not perform PR lookups.
Another local repository:
git-standup --no-wizard --repo /path/to/repo --markdown
Multiple GitHub repositories:
git-standup --no-wizard --remote-repo owner/api --remote-repo owner/web --markdown
Remote GitHub API mode, no local clone:
git-standup --no-wizard --remote-repo owner/api --remote-backend api --days 7 --markdown
Remote branch selection:
git-standup --no-wizard --remote-repo owner/api --remote-backend api --remote-branch main --remote-branch release/next --markdown
Remote repository note: --remote-repo uses temporary clone mode by default.
Clone mode supports git-native filters such as --base-branch and --path.
GitHub API mode avoids cloning and supports date ranges, author matching, merge
exclusion, commit budgets, changed-file stats, PR links, --remote-branch, and
--all-branches. Prefer explicit --remote-branch filters when the user knows
the branch names; --all-branches can be much slower on repositories with many
branches.
--markdown: best for GitHub, Slack, Notion, OSS updates, and PR notes.--no-ai: use when the user wants raw local output or no network/API use.--json: use for automation, scripts, dashboards, or agent parsing.--stats-only: use for compact aggregate counts without per-commit details.--changelog: use for release-note style Markdown grouped by conventional
commit type.--include-prs / --pr-digest: opt into PR numbers, titles, and URLs when
local merge/squash metadata or GitHub CLI lookup can resolve them.--since-last: opt into the last saved report checkpoint instead of typing a
--since date; combine with --write-checkpoint for recurring standups.--output <file>: use when the user wants the report saved.If the user asks for terminal output that is easy to read, prefer Markdown and let git-standup render it in the terminal. If the user asks for copy/paste content, preserve the raw Markdown.
git-standup can use OpenAI-compatible providers or local CLI harnesses. Prefer the user's saved default when one exists. If no default exists, prefer a ready detected CLI harness before asking for a new API key.
Supported saved harnesses include codex, cursor-agent, agent, opencode,
gemini, aider, goose, copilot, kiro-cli, amp, ollama, and lms.
Other detected AI tools should not be saved unless git-standup has a tested
headless adapter for them.
OpenAI-compatible provider defaults should use the providers exposed by
git-standup config set-provider. Azure OpenAI is ready when
AZURE_OPENAI_API_KEY, AZURE_OPENAI_ENDPOINT, and AZURE_OPENAI_DEPLOYMENT
are set.
Useful setup command:
git-standup config
Show saved defaults:
git-standup config show
Do not ask for Claude/Anthropic setup; git-standup intentionally skips that in installer detection.
When the user wants to choose options manually, run:
git-standup
The wizard supports:
In the wizard, q cancels. Do not treat cancellation as a selected default.
GitHub API mode requires the GitHub CLI (gh) with valid credentials. If the
command fails with Bad credentials or HTTP 401, check:
gh auth status
Then refresh login with gh auth login or remove/replace stale token environment
variables such as GH_TOKEN, GITHUB_TOKEN, GH_ENTERPRISE_TOKEN, or
GITHUB_ENTERPRISE_TOKEN. Do not print token values.
Recent git-standup versions mark placeholder commit subjects such as wip,
fix, update, changes, misc, or tmp as low-signal in JSON/Markdown and
in the AI prompt. Treat those notes as evidence limits, not as proof that the
work was bad: summarize concrete file/body evidence, and do not turn vague git
history into polished claims.
When presenting a report: