Create a git commit for the current changes using Conventional Commits format with a polished, highly descriptive message. If there are commit hooks - do not skip them, it's your responsability to leave things better than they were.

Format

<type>(<scope>): <summary>

type REQUIRED. Use feat for new features, fix for bug fixes. Other common types: docs, refactor, chore, test, perf.
scope OPTIONAL. Short noun in parentheses for the affected area (e.g., api, parser, ui).
summary REQUIRED. Short, imperative, <= 72 chars, no trailing period.

Notes

Body is strongly encouraged — always include one unless the change is trivially obvious (e.g., fixing a typo). The body should explain what changed, why it changed, the approach taken, and any notable decisions. A reader of git log should understand the change without looking at the diff.
Do NOT include breaking-change markers or footers.
Do NOT add sign-offs (no Signed-off-by).
Only commit; do NOT push.
If it is unclear whether a file should be included, ask the user which files to commit.
Treat any caller-provided arguments as additional commit guidance. Common patterns:
- Freeform instructions should influence scope, summary, and body.
- File paths or globs should limit which files to commit. If files are specified, only stage/commit those unless the user explicitly asks otherwise.
- If arguments combine files and instructions, honor both.

Steps

Infer from the prompt if the user provided specific file paths/globs and/or additional instructions.
Review git status and git diff to understand the current changes (limit to argument-specified files if provided).
(Optional) Run git log -n 50 --pretty=format:%s to see commonly used scopes.
If there are ambiguous extra files, ask the user for clarification before committing.
Stage only the intended files (all changes if no files specified).
Run git commit -m "<subject>" (and -m "<body>" if needed).

Más de este repositorio

mismo repositorio

improve-codebase-architecture

HazAT/pi-config

Find deepening opportunities in a codebase, informed by CONTEXT.md and docs/adr/. Records findings in Solo scratchpads and can turn selected refactors into Solo todos. Use when improving architecture, finding refactoring opportunities, or making a codebase more testable and AI-navigable.

2026-07-11426

plan

HazAT/pi-config

Solo-native planning workflow. Use when asked to "plan", "brainstorm", "design", "create a plan", "I want to build", or "let's build". Covers both orchestrating a plan (scout → planner → workers → review) and acting as the interactive planner subagent.

2026-07-11426

review

HazAT/pi-config

Review code changes for quality, security, and correctness. Use when asked to "review", "code review", "check my changes", or when acting as a reviewer subagent. Produces a structured review with prioritized findings, saved to a Solo scratchpad when one is provided.

2026-07-11426

scout

HazAT/pi-config

Fast codebase reconnaissance — map existing code, conventions, and patterns for a task. Use when asked to "scout", "explore the codebase for", or when acting as a scout subagent gathering context for a planner or worker.

2026-07-11426

worker

HazAT/pi-config

Implement one Solo todo — write code, verify it, commit with the commit skill, save a result note, and close the todo. Use when acting as a worker subagent executing a single well-scoped Solo todo.

2026-07-11426

write-todos

HazAT/pi-config

Write clear Solo todos that workers can execute without losing architectural intent. Use when asked to "create todos", "write todos", "break into tasks", "plan todos", or create work items from a plan. Ensures each todo has outcomes, examples, constraints, and verification criteria.

2026-05-14426

name	commit
description	Read this skill before making git commits

Format

<type>(<scope>): <summary>

type REQUIRED. Use feat for new features, fix for bug fixes. Other common types: docs, refactor, chore, test, perf.
scope OPTIONAL. Short noun in parentheses for the affected area (e.g., api, parser, ui).
summary REQUIRED. Short, imperative, <= 72 chars, no trailing period.

Notes

Body is strongly encouraged — always include one unless the change is trivially obvious (e.g., fixing a typo). The body should explain what changed, why it changed, the approach taken, and any notable decisions. A reader of git log should understand the change without looking at the diff.
Do NOT include breaking-change markers or footers.
Do NOT add sign-offs (no Signed-off-by).
Only commit; do NOT push.
If it is unclear whether a file should be included, ask the user which files to commit.
Treat any caller-provided arguments as additional commit guidance. Common patterns:
- Freeform instructions should influence scope, summary, and body.
- File paths or globs should limit which files to commit. If files are specified, only stage/commit those unless the user explicitly asks otherwise.
- If arguments combine files and instructions, honor both.

Steps

Infer from the prompt if the user provided specific file paths/globs and/or additional instructions.
Review git status and git diff to understand the current changes (limit to argument-specified files if provided).
(Optional) Run git log -n 50 --pretty=format:%s to see commonly used scopes.
If there are ambiguous extra files, ask the user for clarification before committing.
Stage only the intended files (all changes if no files specified).
Run git commit -m "<subject>" (and -m "<body>" if needed).