Claude Skills by romiluz13

Shared preamble loaded by all cc10x agents — memory protocol, contract format, output rules.

Greenfield architecture design: map functionality flows, draw components, design APIs, classify dependencies, plan observability. For multi-component, API, schema, auth, or integration-heavy work. For retrofitting existing code, use codebase-hygiene instead.

Implementation skill for writing production code with TDD. Covers the RED-GREEN-REFACTOR cycle, false-RED detection, vertical slicing, scope escalation, test process discipline, and code generation patterns. Loaded by component-builder and bug-investigator.

Answers questions about cc10x itself — what it is, how to install and configure it, how the router, workflows, memory, and hooks operate, and how to troubleshoot. Use this skill when: the user asks ABOUT cc10x — "what is cc10x", "how do I configure cc10x", "why isn't cc10x activating", "how do cc10x workflows work", "how does cc10x memory work", "cc10x troubleshooting". NOT for performing work: "set up cc10x for me", build, debug, review, or plan requests route to cc10x-router. "Update cc10...

THE ONLY ENTRY POINT FOR CC10X. Activate this skill for build, debug, review, and plan requests. Use when the user asks to implement, fix, review, plan, test, refactor, or continue code work. Trigger keywords: build, implement, create, write, add, review, audit, debug, fix, error, bug, broken, plan, design, architect, spec, brainstorm, test, refactor, optimize, update, change, research, cc10x, c10x. CRITICAL: Route and execute immediately. Do not stop at describing capabilities.

Two-mode skill: (1) adversarial review — spec compliance + code quality + security, confidence-scored findings with file:line evidence; (2) receiving review — verify-before- agreeing discipline for acting on external/human review feedback.

Canonical deep-module vocabulary (module, interface, depth, seam, adapter, leverage, locality) for designing a module's shape — a lot of behaviour behind a small interface at a clean seam, testable through that interface. The single source of truth for these terms; other skills (architecture, codebase-hygiene, building, planning) point here instead of restating them. Use when designing or improving a module's interface, finding deepening opportunities, deciding where a seam goes, or making co...

Two-mode skill: (1) find semantic duplicates — functions doing the same thing under different names, invisible to copy-paste detectors; (2) deepen shallow modules — thin wrappers and pass-through layers that spread complexity. Advisory and read-only; changes route through BUILD with full gates.

Debugging discipline: feedback loop FIRST, root cause before fix, blast radius after fix. Covers the 10-rung construction ladder, LSP-powered tracing, hypothesis quality criteria, and four-phase investigation. Loaded by bug-investigator.

Use when a BUILD phase completes, a commit is staged, or a PR is about to be created, and the diff has not yet been reflected in documentation. Also use when the user says "update docs", "sync docs", "document this", or asks whether documentation is up to date.

Actively build and sharpen a project's domain model — challenge terms against the glossary, sharpen fuzzy language, stress-test with edge-case scenarios, update CONTEXT.md inline, and offer ADRs sparingly. The active discipline loaded by language-shaping agents (planner, doc-syncer, exploration). Builders load a read-only/obey variant: they read CONTEXT.md and obey it, emitting a proposal on contradiction rather than resolving it. See the Active vs read-only section for which mode applies.

Two-mode exploration skill: (1) design dialogue — turn rough ideas into validated designs through collaborative interview before planning; (2) spike — throwaway code answering ONE design question, deleted or absorbed, never shipped. Router invokes mode via dispatch context.

Two-mode frontend skill: (1) authoring — accessibility, responsive layout, loading/error states, performance, DESIGN.md authoring, visual direction; (2) critique — READ-only scored review of built UI against anchored rubric, AI-slop detection, two isolated assessments. Router invokes mode via context.

Use when you need a one-off MCP server capability during research or debugging without permanently mounting it as a context-polluting integration.

Two-mode skill: (1) session memory — load/persist durable workflow state under .cc10x/ (activeContext, patterns, progress) so context survives compaction; (2) handoff package — portable, secrets-redacted export for a coworker, different tool, or fresh non-cc10x session.

Use after saving a non-trivial plan or decision RFC when a fail-closed feasibility, completeness, and alignment review must block execution.

Planning discipline for creating execution plans and decision RFCs. Covers task decomposition, context references, validation levels, risk-based testing, ADR format, plan completeness gate, and functionality flow mapping. Loaded by planner agent.

Internal skill. Synthesis guidance loaded via SKILL_HINTS by planner and bug-investigator when research files are available.

Use when a git merge or rebase reports conflicts and the operation is in progress.

Safe cc10x upgrade that preserves local modifications. Stashes diffs, pulls upstream, rebuilds cache, rebases patches. Use this skill when: updating cc10x, upgrading, pulling latest cc10x, syncing plugin, refreshing cache, or checking for new versions. Triggers: update cc10x, upgrade cc10x, pull cc10x, sync plugin, refresh cc10x, check for updates, new version, update plugin, upgrade plugin.

Verification discipline: task completion is not goal achievement. Covers the gate function, self-critique gate, validation levels, evidence array protocol, and goal-backward lens. Loaded by integration-verifier, component-builder, and bug-investigator.

Generate a "pick up where I left off" status report across all active Pi sessions. Use when the user asks for bearings, a status report, morning brief, catch-up, "where did I leave off", or "what's in the works". Reads live session state, composes a scannable 4-section digest, and writes a dated report to ~/.pi/agent/bearings/.

You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.

Review the changes since a fixed point (commit, branch, tag, or merge-base) along two axes — Standards (does the code follow this repo's documented coding standards?) and Spec (does the code match what the originating issue/spec asked for?). Runs both reviews in parallel sub-agents and reports them side by side. Use when the user wants to review a branch, a PR, work-in-progress changes, or asks to "review since X".

Find semantic duplicates (same intent, different implementation) and shallow modules (thin wrappers spreading complexity). Read-only advisory — changes route through BUILD with full gates. Use when auditing code quality, before refactoring, or when a codebase feels bloated.

Never lose an unresolved decision. Use when work discovers an open question that needs the user's input, before declaring that work complete. Persists decisions to ~/.pi/agent/decisions.json so they survive compaction and session restarts. Inspired by FirstMate's decision-hold-lifecycle.

Diagnosis loop for hard bugs and performance regressions. Use when the user says "diagnose"/"debug this", or reports something broken/throwing/failing/slow.

Treat documentation as a first-class deliverable of every BUILD phase. Classify the diff's doc impact across 3 layers (business/technical/audit) and write only the updates genuinely needed. Use after BUILD completes, before a commit/PR, or when asked "are docs up to date".

Review and sharpen persistent memory so it compounds instead of accumulating. Use when pruning pi-hermes-memory entries, doing monthly memory hygiene, or when the same lesson has been recorded multiple times.

The auto-pi workflow procedure layer. ask-matt owns semantic routing; the deterministic workflow interpreter owns state transitions, evidence gates, persistence, autonomous continuation, bounded retries, review, and ship.

Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation

Security review of the diff — the third review axis alongside Standards and Spec. Reviews for injection, auth, secrets, deserialization, SSRF, path traversal, unsafe operations, and dependency confusion. Use as a parallel sub-agent with fresh context (diff-only, anti-anchored) during the review phase.

Hand off work to another Pi session — write a handoff doc, save key decisions to memory, and notify the target session via intercom. Use when a session is getting long, when you need to continue work in a fresh context, or when transferring work between projects/sessions. Composes handoff.ts (doc writer) + memory (persistence) + pi-intercom (transport).

Maintain and improve a Pi coding agent setup over time — prevent drift AND find new leverage. Use when auditing setup health, before adding a package/extension, before publishing, or when asked "is my setup healthy" / "audit my setup" / "how do I keep this sharp".

Use when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidence before assertions always