@kurokeita/add-skill 1.21.0 → 2.0.0

package/dist/skills/git-commit/SKILL.md

@@ -1,22 +1,95 @@
 ---
 name: git-commit
-description: This skill should be used when the user asks to "commit changes", "commit message", or "follow conventional commits". Provides guidelines for Conventional Commits specification and commit message formatting.
-version: 1.0.0
+description: Use BEFORE running any write-side git or gh command (git commit, git commit --amend, git push --force / --tags, git reset --hard, git rebase, gh pr create, gh pr merge), and whenever the user asks to commit changes, write a commit message, or follow conventional commits. Provides the hard pre-commit protocol (stop, summarize, propose, ask, wait) plus the Conventional Commits format used for the proposed message.
+version: 2.0.0
 ---
 
 # Git Commit
 
-Guide for managing version control commit message formatting following the Conventional Commits specification.
+This skill enforces the pre-commit protocol AND specifies the commit-message format. Both are mandatory before any gated git/gh write operation runs.
 
-## When to Use This Skill
+## When to Use
 
-- Formatting commit messages to follow project standards
-- Learning the Conventional Commits specification
-- Ensuring consistency across the repository's history
+Invoke this skill BEFORE calling Bash for any of:
 
-## Conventional Commits
+- `git commit` (any form, including `-m`, `-am`, no-args, heredoc, chained via `&&`/`;`)
+- `git commit --amend` (any form)
+- `git push --force` / `git push -f` / `git push --force-with-lease`
+- `git push --tags`
+- `git reset --hard`
+- `git rebase` (any form, interactive or non-interactive)
+- `gh pr create`
+- `gh pr merge`
 
-Format commit messages according to the [Conventional Commits](https://www.conventionalcommits.org/) specification to enable automated changelog generation and easier history browsing.
+Also invoke when the user asks to commit changes, write a commit message, or follow conventional commits.
+
+The `permissions.ask` rule in `~/.claude/settings.json` will surface a permission prompt for these commands regardless. This skill ensures the prompt arrives with a proper proposal already presented to the user.
+
+## Pre-Commit Protocol (HARD RULE)
+
+Every gated command, every time. No exceptions for "tiny" or "obvious" changes. Each commit gets its own gate even within the same session. Plan approval, prior "go ahead" signals, and approvals of earlier commits do NOT carry over.
+
+### Step 1 — STOP
+
+Do not retry the command yet. The first attempt is your trigger, not your green light.
+
+### Step 2 — Emit a detailed technical summary
+
+```bash
+### Technical summary
+- Scope: <files added/modified/deleted, one-line purpose each>
+- Behavior change: <user-visible / API-visible effect, or "none" for pure refactors>
+- Architecture/contract impact: <new exports, removed symbols, changed signatures, new dependencies, or "none">
+- Tests: <what was added/updated, what was run, the result>
+- Risk notes: <edge cases, deferred follow-ups, impact-analysis severity>
+```
+
+Fill every bullet. "None" is a valid answer; an omitted bullet is not.
+
+### Step 3 — Propose a commit message
+
+Format per the Conventional Commits section below. No `Co-Authored-By: Claude` trailer. Imperative present tense, no trailing period in the subject. When a body is included, it explains the why.
+
+**Match the message size to the change.** For small commits — single file, trivial scope, narrow type change, doc tweak, small revert, one-line config flip, renamed prop — propose a title-only message. No body, no bullets. The subject alone conveys intent and a body adds friction without value.
+
+```bash
+### Proposed commit message
+<type>(<scope>): <imperative subject>
+```
+
+Reserve the full proposal format (body + bullets) for commits that touch multiple files, change behavior in subtle ways, or introduce risk worth flagging:
+
+```bash
+### Proposed commit message
+<type>(<scope>): <imperative subject>
+
+<body paragraph(s) explaining motivation and behavior change>
+
+- bullet of notable change
+- bullet of notable change
+```
+
+### Step 4 — Ask the user verbatim
+
+Print exactly: **"Commit as-is, edit the message, or skip?"**
+
+### Step 5 — Wait for explicit approval
+
+Only after the user replies with an affirmative answer may you re-attempt the command. The OS permission prompt will then surface for final confirmation.
+
+If the user declines or asks to edit, do not commit. Update the proposal and re-ask.
+
+## Multi-commit work
+
+If you have several logical commits ready, emit one full proposal per commit and gate each independently. Do not batch proposals. Do not commit any of them until each is individually approved.
+
+## Subagent delegation
+
+If you dispatch a subagent that will end in a gated command, you (the orchestrator) own the proposal step. Either instruct the subagent to stop before the command and report back, or require it to wait for an "approved" signal you forward only after the user approves the proposal. A subagent that commits on its own initiative is a rule violation.
+
+## Conventional Commits format
+
+Format the proposed message per the [Conventional Commits](https://www.conventionalcommits.org/) specification.
 
 ### Structure
 
@@ -30,36 +103,27 @@ Format commit messages according to the [Conventional Commits](https://www.conve
 
 ### Types
 
-- `feat`: A new feature
-- `fix`: A bug fix
-- `docs`: Documentation only changes
-- `style`: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc.)
-- `refactor`: A code change that neither fixes a bug nor adds a feature
-- `perf`: A code change that improves performance
-- `test`: Adding missing tests or correcting existing tests
-- `build`: Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm)
-- `ci`: Changes to our CI configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs)
-- `chore`: Other changes that don't modify src or test files
-- `revert`: Reverts a previous commit
+- `feat`: a new feature
+- `fix`: a bug fix
+- `docs`: documentation only changes
+- `style`: changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc.)
+- `refactor`: a code change that neither fixes a bug nor adds a feature
+- `perf`: a code change that improves performance
+- `test`: adding missing tests or correcting existing tests
+- `build`: changes that affect the build system or external dependencies
+- `ci`: changes to CI configuration files and scripts
+- `chore`: other changes that do not modify src or test files
+- `revert`: reverts a previous commit
 
 ### Guidelines
 
-- **Description**: Use the imperative, present tense (e.g., "add", not "added" or "adds").
-- **Case**: The description should be in lower-case or sentence-case.
-- **Scope**: Use a scope to provide additional contextual information (e.g., `feat(auth): add login validation`).
-- **Body**: Use the body to explain the "what" and "why" of the change, not the "how".
-- **Footer**: Use the footer to reference issues (e.g., `Closes #123`) or breaking changes.
-
-## Additional Resources
-
-### Reference Files
-
-For detailed patterns and advanced git workflows, consult:
-
-- **`references/conventional-commits.md`** - Detailed Conventional Commits specification.
-
-### Example Files
+- **Description**: imperative, present tense ("add", not "added" or "adds")
+- **Case**: lower-case or sentence-case, no trailing period
+- **Scope**: noun in parentheses describing a section of the codebase (e.g., `feat(auth): add login validation`)
+- **Body**: explain the what and why, not the how
+- **Footer**: reference issues (`Closes #123`) or breaking changes (`BREAKING CHANGE: ...`)
+- **Breaking changes**: indicate with `!` after the type/scope OR a `BREAKING CHANGE:` footer
 
-Working examples in `examples/`:
+### Reference files
 
-- **`commit-messages.txt`** - Examples of well-formatted commit messages.
+For detailed patterns and edge cases, see `references/conventional-commits.md`.

package/dist/skills/handoff/SKILL.md

@@ -0,0 +1,16 @@
+---
+name: handoff
+description: Compact the current conversation into a handoff document for another agent to pick up.
+argument-hint: "What will the next session be used for?"
+disable-model-invocation: true
+---
+
+Write a handoff document summarising the current conversation so a fresh agent can continue the work. Save to the temporary directory of the user's OS - not the current workspace.
+
+Include a "suggested skills" section in the document, which suggests skills that the agent should invoke.
+
+Do not duplicate content already captured in other artifacts (PRDs, plans, ADRs, issues, commits, diffs). Reference them by path or URL instead.
+
+Redact any sensitive information, such as API keys, passwords, or personally identifiable information.
+
+If the user passed arguments, treat them as a description of what the next session will focus on and tailor the doc accordingly.

package/dist/skills/init-agents-md/SKILL.md

@@ -0,0 +1,51 @@
+---
+name: init-agents-md
+description: Analyze a codebase to initialize or update its AGENTS.md (or CLAUDE.md) file, extract architectural patterns to docs/architectural_patterns.md, and procedural skills to .agents/skills/. Use when initializing a project's agent instructions, updating CLAUDE.md/AGENTS.md, or documenting project structure and workflows.
+---
+
+# Initialize Agent Instructions & Patterns
+
+Use this skill to analyze a workspace and create or update standard developer onboarding and workflow guidelines.
+
+## Workflow
+
+### 1. Analyze Codebase
+
+Explore the codebase to identify:
+
+- **WHAT**: Core technology stack, languages, frameworks, main libraries.
+- **WHY**: Core business logic or project purpose.
+- **HOW**: Scripts and CLI commands (e.g., in package.json, Makefile, etc.).
+- **Files/Docs**: Existing documentation, configuration files, and key source directories.
+- **Workflows**: Critical operational workflows (specifically: build, test, release).
+
+### 2. Generate or Update AGENTS.md
+
+Create or update the `AGENTS.md` (or `CLAUDE.md`) file in the project root.
+
+- Keep the file **under 150 lines** (optimum is 100–150 lines).
+- Reference [agents_template.md](references/agents_template.md) for the structure.
+- Follow these constraints strictly:
+  1. Cover: WHAT (tech stack), WHY (purpose), and HOW (commands).
+  2. Index all major documentation files or folders using progressive disclosure (one-line description each).
+  3. Use **file:line references** (e.g., `src/main.ts:L42`) instead of embedding code snippets.
+  4. Document exactly 2–3 critical workflows (e.g., build, test, release) as numbered steps.
+  5. Do not include formatting or code styling rules (assume linters handle them).
+  6. Always include these two lines under rules/guidelines:
+     - `Be extremely concise. Sacrifice grammar for concision.`
+     - `At the end of each plan, list unresolved questions.`
+
+### 3. Extract Architectural Patterns
+
+Identify recurring design patterns, folder structure conventions, or key abstractions in the codebase.
+
+- Extract these into `docs/architectural_patterns.md`.
+- Reference [patterns_template.md](references/patterns_template.md) for the structure.
+- Provide file:line references for concrete code examples of these patterns.
+
+### 4. Extract Procedural Know-How
+
+Identify step-by-step procedures, deployment configurations, setup guides, or domain-specific instructions that would clutter the main `AGENTS.md` file.
+
+- Extract these into `.agents/skills/<name>/SKILL.md` under the project scope.
+- Reference the newly created skills in `AGENTS.md` or `docs/architectural_patterns.md` where relevant.

package/dist/skills/init-agents-md/references/agents_template.md

@@ -0,0 +1,42 @@
+# AGENTS.md
+
+## Purpose & Tech Stack
+
+- **WHAT**: [Tech stack, e.g., Next.js, TypeScript, TailwindCSS]
+- **WHY**: [Core project purpose, target users, problem solved]
+
+## Commands
+
+```bash
+pnpm dev             # Run local dev server
+pnpm build           # Build project for production
+pnpm test            # Run test suite
+pnpm lint            # Check types and linting
+```
+
+## Documentation Index
+
+- [docs/architecture.md](file:///path/to/docs/architecture.md) — One-line overview of architecture
+- [docs/api.md](file:///path/to/docs/api.md) — One-line overview of API design
+
+## Critical Workflows
+
+### 1. Development & Build
+
+1. Run local environment: `command`
+2. Validate changes: `command`
+
+### 2. Testing
+
+1. Run unit tests: `command`
+2. Run integration tests: `command`
+
+### 3. Release/Deployment
+
+1. Build assets: `command`
+2. Deploy command or CI pipeline trigger: `command`
+
+## Guidelines
+
+- Be extremely concise. Sacrifice grammar for concision.
+- At the end of each plan, list unresolved questions.

package/dist/skills/init-agents-md/references/patterns_template.md

@@ -0,0 +1,19 @@
+# Architectural & Design Patterns
+
+This document details the recurring architectural, design, and structural patterns found in this codebase.
+
+## 1. [Pattern Name]
+
+- **Intent**: [What problem does this pattern solve?]
+- **Location/Example**: [e.g., src/utils/paths.ts:L10-L40]
+- **Implementation Details**:
+  - [Key implementation note 1]
+  - [Key implementation note 2]
+
+## 2. [Pattern Name]
+
+- **Intent**: [What problem does this pattern solve?]
+- **Location/Example**: [e.g., src/commands/add.ts:L45-L90]
+- **Implementation Details**:
+  - [Key implementation note 1]
+  - [Key implementation note 2]