ソース情報
- リポジトリ
- kapilvirenahuja/garura
- ソースの最終更新活動
- 2026年7月3日 06:46
- 検出された SKILL.md の言語
- 英語
- スター
- 3
- フォーク
- 0
インストール方法
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
ソースファイルを確認
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
メニュー
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。
npx skills add https://github.com/kapilvirenahuja/garura --skill create-commitコマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか?SkillsMP が現在取得できるファイルをダウンロードできます。
Install Garura into a target project or repository so its skills, agents, and plays become discoverable by a host coding tool — Claude Code or the OpenAI Codex CLI. Reads this garura checkout's core/components and runs a per-tool ADAPTER that lays them down in the host's native shape: for claude, .claude/ skills + agents with model tiers resolved to Claude models; for codex, .agents/skills Agent Skills plus AGENTS.md and ~/.codex model/sandbox/approval profiles. Always writes a .garura/ tooling tree (config + STM scaffold) and copies shared memory to the machine-global ~/.garura, and records an install manifest so uninstall-garura can reverse exactly what was placed. Use when the user wants to install, set up, bootstrap, add, or enable Garura in another folder or repo for claude or codex — "install garura into X", "set up garura in this repo for codex", "bootstrap garura", "make codex see the garura skills". Takes the target path, an optional --tool, and an optional --scope (full = everything, the default; ha
Compile a deterministic "play" (a multi-step, gated workflow recipe) from an intent. Interviews for the intent triple, generates the expectation, identifies the skills, scripts, and agents the play needs, selects a workflow structure, generates evals, and emits a compiled play (a SKILL.md plus bundled scripts for its mechanical work). Use this whenever the user wants to create, build, compile, or review a play — or says "create a play", "new play", "compile this into a play", "play-creator", "turn this intent into a play", or "review my play for gaps" — even if they don't say the word "play" explicitly but are describing a repeatable, multi-step, checkpoint-gated workflow they want captured as a runnable recipe.
Modify an existing compiled play — change its goal, a constraint, a failure condition, a success scenario, a step, the workflow shape, or the agents/skills it uses — by editing the play's ICE source and recompiling, never by hand-patching the output into disagreement with its intent. This is the companion to play-creator (which makes new plays). Use this whenever the user wants to edit, change, modify, update, tweak, extend, or fix an existing play — or says "edit the play", "change this play", "add a constraint to the play", "the play needs a new failure condition / step / scenario", "play-editor", or "recompile the play after I changed its intent" — even if they don't say "play" outright but are clearly reshaping a workflow recipe that already exists.
SOC 職業分類に基づく
SKILL.md を表示中
| name | create-commit |
| description | Stage files and create one or more commits in a single pass |
| user-invocable | false |
| model | haiku |
| allowed-tools | Bash |
Model-invocable skill for creating commits. The grouping and the messages are decided
before this skill runs (by analyze-changes); this skill only executes that
plan. git is the tool and it is already known — so run it directly, in one pass. Do not
reason between commits, do not re-decide grouping, do not invoke a sub-agent per commit.
Stage the decided files and create the decided commits. Pure execution, no decision-making. When handed several groups, commit all of them in this one invocation — never one call per group.
Receive from the caller a commit plan — one or more groups, each:
files: list of files to stage for this grouptype: conventional type (feat, fix, refactor, docs, chore, …)scope: component/areasubject: imperative, present tensebody: optional descriptionissue: optional issue numberThe plan may arrive inline or as a path to the analysis/groups file (e.g.
analysis.yaml); read the file if a path is given. Either way, treat it as the final
plan — execute, don't revise.
Loop over the groups in order, in this single invocation. For each group, run the two git commands directly — no thinking step in between:
Stage that group's files (only the files listed — never git add . / -A)
git add "file1" "file2" "file3"
Commit with the conventional message
git commit -m "type(scope): subject
body
Issue: #123"
Record the hash
git rev-parse --short HEAD
After the last group, confirm the tree is clean (git status --porcelain). Do not
push — pushing is the caller's separate step.
Return using template: templates/commit-output.md — one entry per commit (hash +
message), and the final clean-tree confirmation.
git add . or git add -A.| Field | Value |
|---|---|
| Version | 2.0.0 |
| Category | operations |