philippe-ths
UserGovernance for AI coding agents: deterministic policy checks, git hooks and tool gating that enforce the rules rather than prompt them.
Categories
Indexed Skills (16)
aiw-failure-analysis
Reactive skill for when the agent has claimed a task complete and that claim is contradicted — by the user, by runtime behaviour, by manual verification, or by the agent itself. Use it whenever the user reports the behaviour is still broken, the fix didn't help, the system is doing the wrong thing, or runtime disagrees with the agent's tests or validation, with phrases like 'still broken' or 'didn't help'. Use it equally when the agent is about to supersede, replace, or redo its own recent attempt at the same defect, or to touch code its own recent change last touched for that defect, whoever noticed. Load this skill BEFORE proposing any fix. The trigger is a trust collapse: the core skills (aiw-ground-truth, aiw-testing, aiw-verification, aiw-validation, aiw-housekeeping) that should have caught the problem did not, so the agent cannot trust its oracle, tests, or verification until each is audited. It stops the agent jumping to the nearest plausible patch. It owns the structured pause after a contradicted 'd
aiw-github
Rules for every GitHub and git history action during a task: starting work on an issue, switching branches, rebasing, committing, pushing, opening a pull request, post-merge cleanup, and handling parent and sub-issue hierarchies. Use this skill whenever the agent is about to read a GitHub issue at task start, create or switch to a branch, run a rebase, create a commit, push to remote, open a pull request, or run post-merge cleanup, even if the user does not name the action explicitly. Also use when the agent encounters a parent issue with sub-issues, when a deterministic policy hook blocks a git action, or when the agent suspects new commits have landed on the target branch since the last rebase. The skill exists to keep GitHub actions traceable to an issue, taken after the done gate, safe against silent working-tree loss during branch operations, and short of the one action that stays the human's: the merge.
aiw-ground-truth
Establishes where trusted inputs and expected outputs come from during coding tasks, so the agent's tests, fixtures, and assumed-correct values have authority not invented by the agent. Use this skill before generating a test fixture, constructing expected output, mocking an external system, reusing earlier fixtures, deleting code, or assuming what 'correct' means, and at the start of every task to classify the work into one or more of the nine modalities (New, Feature, Fix, Refactor, Improve, Investigate, Migrate, Configure, Delete). It owns the trust hierarchy for ground-truth sources, the canonical modality decision procedure shared across the workflow, modality-specific oracle rules, the sourcing protocol when real ground truth is missing, storage and provenance for ground-truth artifacts, and the boundary distinguishing ground truth from test setup. It breaks the closed loop where the agent writes the code, fixtures, and tests and reads its own results with no external check.
aiw-housekeeping
Makes keeping the project clean and well organised a step in the workflow rather than something that happens when someone notices. Use this skill at the done gate, third after aiw-verification and aiw-validation, before presenting any work for the human's done decision, and on every task including one that set out to remove or move nothing. It asks whether anything the task caused should now be removed or moved: a code path the change orphaned, a file the work left behind, a thing sitting in the wrong place. Use it also on its own, over the whole repository, when the human asks what has built up, asks for a cleanup or a tidy-up or an audit of the repository, wonders what all these leftover files are, or when a session-start note reports the repository hiding paths through a local exclude rule. In that mode it examines the whole repository and hands back a ranked list for the human to approve, rather than acting on what it finds. It owns the footprint that bounds what may be acted on, the tiering that sets wha
aiw-init
User-invoked session preflight. Runs the repository's declared checks read-only and reports project state the human may not be aware of: open issues and pull requests, work left in flight, errors in recent logs, dependent services that are down, approaching expiries, and drift in the project's own documents. Use this skill when the human invokes it by name, or asks what the state of the project is, what they were in the middle of, what has changed since last session, or whether anything needs attention before they start. It maintains `project-checks.md`, the per-repository record of what is worth checking and what normal looks like for each check. It reports observations and never decides what to do about them; choosing the next task stays with the human.
aiw-issue-creation
Structured process for creating follow-up or spin-off GitHub issues during a task. Use this skill when the agent discovers work outside the current scope that should be tracked. The skill exists to prevent implementation-heavy issues that bias the implementing agent and peg to stale code.
aiw-north-star
Structured process for authoring and updating `north-star.md`, the shortest statement of what a project is trying to achieve. Use this skill when the human asks to create, scaffold, revise, or check the north-star, with phrasings like 'what is this project for', 'set up a north-star', or 'is that still the goal'. Use it also, and without being asked, when a request that has just arrived would take the project away from its stated goal, before any planning happens: that conflict means either the request is wrong or the goal has moved, and neither is the agent's call. The skill exists because a project's direction is the one thing no oracle can derive: the codebase shows what is, the spec shows what is asked, and neither says what the project is trying to achieve.
aiw-orchestration
Chooses the execution shape for a task — run it solo in the main loop, fan out read-only scouts, run an orchestrator over builders and reviewers, or relay a chain too large for one context window from agent to agent — gives its own sealed owner to a step the built system runs through a model on every use, and routes model capability and effort per role once a shape is chosen. Use this skill to decide whether to split work, before deciding rather than after: whenever a task spans many files or areas, its inputs exceed one context window, it looks like a batch of similar mechanical edits, its edits would collide in one tree, or there is any impulse to hand implementation to another agent, and whenever the deliverable includes a step a model will run on every use of the built system. Use it before handing writing work to any agent other than yourself. Deciding not to split is one of its answers and the more common one. It owns the gate that keeps multi-agent shapes off ordinary work, the per-role capability and
aiw-performance-profiling
Automated performance and UI-state-transition coverage rules. Use this skill when implementing changes to user interfaces, reactive state, heavy data loops, caching logic, or any code path where runtime speed affects usability. The skill exists to prevent the pattern where functional tests pass while real-world execution becomes sluggish or stutters.
aiw-planning
Structured planning process for producing a code-aware implementation plan before writing code, including the pre-planning codebase baseline checks (smoke tests and the global suite, test readiness, bounded-change confirmation) and the task modality classification the rest of the plan depends on. Use this skill at the start of every task before any implementation, whether the user says 'plan' or just hands the agent an issue. It owns the codebase baseline check, the modality classification step (procedure in aiw-ground-truth), the plan's structure and required content, the oracle and verification expectations the plan must state, the issue-vs-codebase priority rule, assumption classification, bounded-change confirmation, and handling human feedback at plan review. It does not own oracle definitions or the trust hierarchy (aiw-ground-truth), test mechanics (aiw-testing), evidence and sufficiency (aiw-verification), or post-failure investigation (aiw-failure-analysis).
aiw-prompt-smith
Author or repair prompting artifacts, including system prompts, CLAUDE.md, AGENTS.md/AGENT.md files, other skills, agent prompt files, and any file an agent loads at session start or opens at a step to learn what to do, whatever it is named, such as a README a mode file includes, a method page, or a reference an operator agent reads for a field. Use when writing any of these from scratch, when moving instructions from one file to another, and especially when one has produced a noticed failure and needs fixing at the cause rather than a narrow patch. Trigger whenever the user is drafting, reviewing, tightening, or debugging a system prompt, a project-instructions file, an agent-instructions file, or a skill, even if they don't say the word "prompt", e.g. "my CLAUDE.md keeps making it do X", "this skill over-triggers", "help me write instructions for the agent", "why does my agent ignore this rule". Prefer this skill over ad-hoc editing whenever the likely fix would otherwise be to just append another rule.
aiw-security-testing
Automated security testing rules for changes that touch authentication, authorisation, untrusted input, file-path or shell-command construction, secret handling, external API consumers, or data-access boundaries. Use this skill whenever the change crosses a trust boundary or processes input that could be hostile, even if the surface looks routine. The skill exists to prevent the pattern where happy-path tests pass while negative paths, boundaries, and threat-model assumptions go unchecked.
aiw-testing
Mechanical craft rules for writing tests well: choosing the right test level, consuming ground truth from aiw-ground-truth rather than fabricating it, organising tests for independence and clarity, and avoiding anti-patterns that produce green suites with no real authority. Use this skill whenever the agent is about to write or modify a test, choose a fixture, pick a test level (unit, integration, end-to-end), decide whether to mock a component, refactor test code, fill a coverage gap from aiw-verification, write a regression test, or when tempted to assert on internal calls or private state. It does not decide what counts as correct (aiw-ground-truth) or whether tests are sufficient evidence (aiw-verification). It owns test mechanics, test-level selection, modality-specific testing emphasis referencing aiw-ground-truth, the anti-patterns that produce misleading green bars, and the hygiene rules that keep a suite a reliable signal.
aiw-validation
Governs whether the finished work is the thing the human asked for, as distinct from whether the change is correct. Use this skill at the done gate alongside aiw-verification and aiw-housekeeping, before presenting any work for the human's done decision, and whenever about to say 'done', hand over a deliverable, or open a pull request. It owns the deliverable the plan must name, the questions asked of finished work (does it exist, does it do what was asked, is it the thing the project is for), the requirement to meet the artifact in the form the human will meet it rather than read the code that produces it, the one line it leaves in the pull request body, and the split between what the human judges and what the agent confirms.
aiw-verification
Governs how the agent confirms a change actually works before declaring a task complete. Use this skill at the end of every implementation pass and whenever the agent is about to say 'done', 'this works', 'tests pass', 'ready to commit', or 'ready to push'. Also use when interpreting runtime output, deciding whether to run the full system end-to-end, claiming a refactor preserves behaviour, a fix is fixed, a migration is complete, or a delete is safe. It forces the agent to justify every time that its checks cover the change and to name the unverified surface, breaking the 'all tests pass, system is broken' failure mode. It owns the required justification step before declaring done, the evidence hierarchy from static checks to end-to-end runs on real artifacts, the rules for when end-to-end execution is mandatory, reading runtime output as evidence not exit codes, modality-aware requirements referencing aiw-ground-truth, and the scoping step that names what was not checked.
rate
Record a 1-4 quality rating for the current Claude Code session (1 bad, 2 fine, 3 good, 4 excellent). Use this skill when the user invokes /rate, says 'rate this session', or otherwise wants to log how the session went. The rating is the only human quality signal in AI Workflow session observation; it is matched to the session by repo and time at collection. Installed globally so it works in every repo.
Bio shown is the top-scored skill's repo description as a fallback — real GitHub bios land in a future update.