icpg
by alinaqiicpg adds a WHY layer to code understanding with ReasonNodes, formal contracts, and drift detection. Use it for code review, refactoring, and pre-task analysis when you need intent, ownership, and risk context before changing code.
This skill scores 68/100, which means it is list-worthy but moderately constrained: directory users get a real, specialized workflow for intent-aware code reasoning, yet should expect to do some interpretation because the repository does not include install automation or supporting files. It is a reasonable install for agents that need a structured "why this code exists" layer before making changes, but not a plug-and-play asset.
- Clear intended trigger: the frontmatter says to use it "Before any code change" to query intent, constraints, and risk.
- Substantive workflow content: the body is long and structured, with multiple headings, workflow steps, and canonical pre-task queries rather than placeholder text.
- Operationally specific concept: defines ReasonNodes, typed edges, contracts, drift detection, and a per-project SQLite store, giving agents concrete artifacts to work with.
- No install command or companion files are present, so users must infer setup and execution steps from SKILL.md alone.
- Supporting assets are absent (scripts, references, resources, rules), which limits immediate trust and may increase guesswork for first-time adopters.
Overview of icpg skill
What the icpg skill does
The icpg skill adds a “WHY layer” to code understanding. Instead of only mapping structure, it links functions, classes, and modules to the reason they exist, who owns them, and whether they still match their original intent. If you need icpg for Code Review, refactoring, or autonomous maintenance, the main value is reducing guesswork before a code change.
Who it is best for
icpg fits engineers and agents working in active codebases where behavior, ownership, and design intent matter more than a quick syntax scan. It is most useful when a repo has accumulated drift, unclear task history, or repeated “why was this written?” questions.
What makes it different
The skill centers on ReasonNodes, formal contracts, and drift detection across multiple dimensions. That means icpg is not just a code map; it is a decision-support layer for pre-task analysis. The practical benefit is better change safety, clearer review context, and fewer edits that silently violate original intent.
How to Use icpg skill
Install and locate the core file
Use the repo’s skill install flow, then start with skills/icpg/SKILL.md. Since this repository exposes no helper scripts or supporting folders, the skill file itself is the main source of truth. For a quick install decision, read the frontmatter and the first sections before anything else.
Turn a vague goal into a usable prompt
icpg usage works best when you provide a concrete task, target path, and desired output shape. Good inputs look like this: “Review src/payments/charge.ts for intent drift before I change retry logic” or “Bootstrap ReasonNodes for the auth flow and identify missing ownership links.” Weak inputs like “analyze this repo” are too broad and usually miss the skill’s intent-tracking strengths.
Suggested workflow for first use
Start by asking for the intended purpose of the target code, then ask what constraints or contracts protect it, then ask where drift is likely. That sequence matches the skill’s design and helps the agent move from structure to intent to risk. For icpg guide workflows, keep the request centered on one module or one change set instead of the whole repository.
What to read first in the repo
Begin with SKILL.md, especially the purpose statement, the CLI examples, and the sections covering the core principle, canonical pre-task queries, ReasonNode, and edge types. Those are the pieces most likely to affect adoption decisions and the quality of icpg output for code review.
icpg skill FAQ
Is icpg only for autonomous agents?
No. icpg is useful for humans and agents, but it is most compelling when a system needs repeatable pre-task reasoning. If you only want a one-off summary, a normal prompt may be enough; if you want intent-aware code review or change planning, icpg is a better fit.
How does icpg compare to a generic code prompt?
A generic prompt can summarize code, but icpg is built to preserve intent, ownership, and drift context across tasks. That makes it more useful when you need to answer “what is this code for?” before changing it, not just “what does this code do?”
Is icpg beginner-friendly?
It is usable by beginners, but the strongest results come from users who can name a file, feature, or change boundary precisely. If you are new to the repo, start with a single module and ask for intent, constraints, and review risks rather than a full-system analysis.
When should I not use icpg?
Skip icpg when the task is trivial, the code is isolated, or you only need a fast surface-level explanation. It is also a poor fit if you cannot provide a target area or any change context, because the skill’s value depends on mapping code to a specific reason for existing.
How to Improve icpg skill
Give stronger task context
The best icpg results come from prompts that include the change goal, affected files, and what must not break. For example, “review src/billing for drift after the new tax rule” is stronger than “check billing code.” This helps the skill surface the right ReasonNodes and constraints for icpg for Code Review.
Ask for intent before implementation
A common failure mode is jumping straight to edits without asking what the code was meant to protect. Improve output by requesting the original purpose, current contract, and suspected drift first, then ask for the change plan. That order reduces unforced regressions and makes review output easier to trust.
Use the first answer to sharpen the second
If the first pass is too broad, narrow the scope by module, workflow step, or ownership boundary. If the answer is too shallow, ask for the missing contract, the likely drift dimension, or the canonical pre-task query that best fits the task. Iterating this way usually improves signal more than asking for a longer response.
Keep the prompt aligned with the skill’s design
The icpg skill is strongest when you ask for reason tracking, drift detection, and pre-task analysis, not just code explanation. If you want better icpg usage, include what “done” means, what kind of change you are considering, and which part of the codebase is in scope.
