credo

credo - Initialize session with main agent workflow instructions

credo - Migrate an existing repo into the .credo/ structure

credo - Pin the target repo for credo's project layer (hub-aware), or show the resolved target

credo - Interactive guide to available topics and workflows

credo - Set the session mode to active (intensive live collaboration, no keep-alive)

Use when the user wants to triage GitHub issues - decide whether an issue is still relevant, reproducible, closeable, a duplicate, or what concretely needs doing. Selects and prioritizes first (never dumps all issues at once), then deep-triages the chosen issues via parallel subagents, recommends actions for the owner to approve, and can optionally kick off a reviewed fix. Works for any repo; produces no sensitive or personal data.

The credo work-item model, where the FOLDER an item file lives in is the single source of truth for its status, gated by a hard Definition of Done. Use whenever you create, update, or track a work item; whenever you decide whether something is "done" and may move to 2_done/; whenever you move an item between status folders (clarify, go, done, archived, parked); whenever new code might be unwired; or when someone asks where a task stands. This is the credo task system: .credo/items/ replaces ad-hoc task lists. Applies inside subagents too - if you build or complete work, record and gate it as an item.

Read-only quality gate that audits already-built work against its stated requirement and Definition of Done before it is allowed to move to 2_done/. Produces a severity-ranked decision proposal (BLOCKER/MAJOR/MINOR/NIT) with evidence, never a fix. Use when an item is claimed complete, before moving anything to 2_done/, when asked to audit or review finished work for completeness against requirements, or when acting as the dedicated post-completion review subagent. This gate is mandatory in every session mode. Not for diagnosing why something is broken (use diag) and not for verifying rendered UI behavior (use verify).

The single source for all API budget cap and reset rules - how much of the 5-hour and weekly API limits may be spent, when to throttle, pause, wake up, or hibernate, and the commit-identity gate that runs before any commit. Use whenever you are about to start or continue autonomous work, before spawning or stopping subagents, when deciding how large a task chunk to take on, when a limit is near a cap, before a commit, or whenever someone asks "how much budget is left" or "can I keep going". Works standalone (no session skill required) and applies inside subagents too: any agent that spends API budget or commits must apply these rules.

Secure everything the user approved before a context compaction so a later /compact can never lose or alter it. Writes verbatim intent and handoff state to disk and commits plus pushes the tracked work product in the correct repository, then reports whether it is safe to compact. It does NOT run /compact itself - it makes a later compact safe. Run this only when the limit plugin's injected ACTION line names it (session-context fill crossed a configured threshold) or when the user invokes it manually. Never self-trigger it proactively - that only wastes tokens. Accepts extra trailing instructions to perform in addition to the securing checklist.

4 hooks across 3 events