메뉴
Guidelines for validation, staging, amending, and commit messages.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Guidelines for creating, reviewing, and improving agent skills.
Guidelines for dependency injection patterns.
Guidelines for ensuring architectural changes are validated against core use cases.
Orchestrates efficient read and write interactions with the engram unified memory store via MCP tools. Provides deterministic workflows for decomposing observations into atomic memories, composing four-dimensional queries (context, similarity, relationship, time) for maximum retrieval accuracy, managing agent-managed focus context, and linking memories into associative webs at write time. Ensures memories are discoverable, precisely ranked, and structurally connected across sessions.
Guidelines for dual-use architecture (CLI and Go Library), dependency separation, and extensible registry patterns.
Guidelines for configuring the pi.hitl CEL-based permission sandbox via permissions.yaml files.
| name | git |
| description | Guidelines for validation, staging, amending, and commit messages. |
Before committing any changes, ensure that your work does not break the application and meets all quality standards.
Run the validate task just prior to commit:
task validate
When staging changes, stage only the files that you have changed as part of your current stream of work
git add ./path/to/file ./path/to/file2
⚠️ Never stage changes by adding the whole directory:
git add .
Instead, if you wish to stage folders, stage those also deliberately:
git add path/to/folder
If you need to update the previous commit (e.g., to squash changes or fix a mistake), append changes to the last commit:
git commit --amend
If you have already pushed, you will need to force push:
git push --force-with-lease
Commit messages should follow the standard format:
Maximally 72 characters, descriptive, using imperative mood (e.g., "Deploy changes automatically" not "Deployed changes").
Maximally 72 characters, Explain why the change was made (justification), not just what changed. Use headers for structured context if applicable:
Design:
Describe the design of the change here.
Tradeoffs:
Explain any tradeoffs (performance, complexity, etc).
Justification:
Provide the reasoning for this change.
If pair programming or crediting others, add co-authors at the end of the body:
Co-authored-by: NAME <NAME@EXAMPLE.COM>
Coding agents are pair-programmers and must credit themselves. Use a consistent format that includes both the model and the harness:
Co-authored-by: ${MODEL} <${MODEL}@${HARNESS}.agent>
Claude, Gemini).pi). If no harness is present, use direct.Examples:
Co-authored-by: Claude <claude@pi.agent>
Co-authored-by: Gemini <gemini@pi.agent>
Co-authored-by: Claude <claude@direct.agent>
When there is a reference to an existing issue tracker (e.g., GitHub Issues, Jira, Linear, etc.), include it as a Trailer at the end of the commit message. Use Rel: when the commit is related to the issue but does not resolve it:
Rel: https://github.com/org/repo/issues/123
Use Fixes: only when you are certain the commit fully resolves the issue:
Fixes: https://github.com/org/repo/issues/123