pproenca
- 300 skills
- 0 followers
- last month last updated
- ▌ Bug Review 2 · pproenca bundleMulti-pass PR bug review — 5 parallel passes, majority voting, independent Opus validation, and resolution rate tracking. Trigger on PR review, bug finding, code review, "review this PR", "check for bugs", "find issues in this PR", or /bug-review. Also trigger on /bug-review:resolve to classify whether findings were fixed at merge time, and /bug-review:report for resolution rate stats. Even if the user just says "review this" while on a PR branch, trigger this skill.
- ▌ Tdd 2 · pproencaUse when implementing any feature or bugfix, before writing implementation code - write the test first, watch it fail, write minimal code to pass; ensures tests actually verify behavior by requiring failure first
- ▌ Typescript 2 · pproenca bundleThis skill should be used when the user asks to "optimize TypeScript performance", "speed up tsc compilation", "configure tsconfig.json", "fix type errors", "improve async patterns", or encounters TS errors (TS2322, TS2339, "is not assignable to"). Also triggers on .ts, .tsx, .d.ts file work involving type definitions, module organization, or memory management. Does NOT cover TypeScript basics, framework-specific patterns, or testing.
- ▌ Build MCP Server 2 · pproenca bundleThis skill should be used when the user asks to "build an MCP server", "create an MCP", "make an MCP integration", "wrap an API for Claude", "expose tools to Claude", "make an MCP app", or discusses building something with the Model Context Protocol. It is the entry point for MCP server development — it interrogates the user about their use case, determines the right deployment model (remote HTTP, MCPB, local stdio), picks a tool-design pattern, and hands off to specialized skills.
- ▌ Git Commit · pproencaUse when making git commits directly (not via /commit:new). Ensures safe shell quoting with heredoc format. Triggers on creating commits, staging and committing, any git commit operation.
- ▌ Defense In Depth 2 · pproencaThis skill should be used when the user asks for "defensive coding", "input validation", "prevent bugs", "multiple validation layers", or when fixing bugs caused by invalid data reaching deep execution. Validates at every layer.
- ▌ Python Project 2 · pproencaUse when setting up Python projects, managing dependencies with uv, configuring pyproject.toml, creating project structure, or publishing packages - provides modern Python 3.12+ tooling patterns with uv package manager (plugin:dev-python@pproenca)
- ▌ Python Testing 2 · pproencaUse when writing pytest tests, creating fixtures, mocking dependencies, or testing async code - provides patterns that verify actual behavior with proper fixtures and parametrization; prevents testing mocks instead of code (plugin:dev-python@pproenca)
- ▌ Marketplace Personalisation 2 · pproenca bundleUse this skill whenever designing, building, debugging, reviewing, or improving a personalisation or recommendation system for a two-sided trust marketplace built on AWS Personalize — covers event tracking, dataset and schema design, two-sided matching, cold start, feedback loops, bias control, recipe selection, serving-time re-ranking, observability, and a diagnostic playbook for existing systems. Trigger even when the user does not explicitly mention "AWS Personalize" but is working on recommendations, ranking, search, homepage personalisation, or anything that matches seekers and providers across a trust-based catalog.
- ▌ Marketplace Search Recsys Planning 2 · pproenca bundleUse this skill whenever planning, designing, reviewing, or improving search and recommendation systems for a two-sided trust marketplace built on OpenSearch — covers user-intent framing, product-surface architecture, index design, query understanding, retrieval strategy, ranking, search-plus-recs blending, measurement, and a dashboard-and-alerting layer for ongoing decision making. Triggers on tasks involving marketplace search, homefeeds, ranking, relevance tuning, OpenSearch query DSL, analyzers, synonyms, golden sets, NDCG, A/B testing, or diagnosing an existing retrieval system. Use this skill BEFORE marketplace-personalisation when planning new work; hand off when the diagnosed bottleneck is personalisation-specific.
- ▌ Marketplace Pre Member Personalisation 2 · pproenca bundleUse this skill whenever designing, building, reviewing, or diagnosing the pre-member journey of a two-sided trust marketplace — from anonymous landing through onboarding, registration, and the paid-membership paywall. Covers anonymous signal inference, what pet owners specifically need to validate before paying (safety, availability, competence, effort, local cost comparison), what pet sitters specifically need to validate (opportunity, first-stay path, daily commitment, hidden costs), information-asymmetry closure, progressive profile building, social proof, conversion psychology, onboarding intent capture, identity stitching, and pre-member measurement. Every rule is grounded in published consumer-trust and decision research — Cialdini, Kahneman, Roth, Fogg, Bandura, Slovic, Nielsen Norman Group, and the Airbnb / DoorDash engineering literature. Triggers on tasks involving visitor-to-member conversion, anonymous personalisation, onboarding flow design, paywall timing, pre-member ranking, or any question abo
- ▌ Marketplace Recsys Feature Engineering 2 · pproenca bundleUse this skill whenever deciding what features to extract from raw marketplace assets — listing photos, owner-entered listing metadata, sitter wizard responses — to power item-to-item (similar listings), user-to-item (homefeed ranking), or user-to-user (mutual-fit matching) recommenders in a two-sided trust marketplace. Covers asset auditing, first-principles feature decomposition from the decision the user is making, vision-feature extraction (CLIP, room-type classification, amenity detection, aesthetic and quality scoring), listing text and metadata encoding (categoricals, multi-hot amenities, H3 geo-hashing, sentence-transformer description embeddings, structured pet triples), sitter wizard design (information-gain ordering, multiple-choice over free text, genuine skippability, hard constraint versus soft preference), derived-composition patterns for i2i / u2i / u2u (precomputed ANN shelves, multi-modal fusion, two-tower affinity, symmetric mutual-fit scoring, interpretable subscores), feature quality gove
- ▌ Dev Cmake 2 · pproenca bundleWrite CMake and Make files like a principal engineer with decades of experience. Use when creating, refactoring, reviewing, or debugging CMakeLists.txt, Makefiles, or build system configurations for C/C++ projects. Produces elegant, minimal, modern build files that reflect deep understanding of build systems.
- ▌ Create Verification Skill 2 · pproenca bundleGenerate a project-local verification skill that drives your app the way a user does — any language, framework, or platform. Use for /create-verification-skill, "make a control skill for this repo", or when a project has no scripted way to prove UI/CLI/service behavior.
- ▌ Maintain Verification Skill 2 · pproencaPeriodic pass that keeps a project's verification skill and feature map honest: parallel source readers per feature, one live session driving every feature, at most one PR of proven corrections. Use for /maintain-verification-skill or "audit the verify skill".
- ▌ Create Verification Skill · pproenca bundleGenerate a project-local verification skill that drives your app the way a user does — any language, framework, or platform. Use for /create-verification-skill, "make a control skill for this repo", or when a project has no scripted way to prove UI/CLI/service behavior.
- ▌ Maintain Verification Skill · pproencaPeriodic pass that keeps a project's verification skill and feature map honest: parallel source readers per feature, one live session driving every feature, at most one PR of proven corrections. Use for /maintain-verification-skill or "audit the verify skill".
- ▌ Dev Cmake · pproenca bundleWrite CMake and Make files like a principal engineer with decades of experience. Use when creating, refactoring, reviewing, or debugging CMakeLists.txt, Makefiles, or build system configurations for C/C++ projects. Produces elegant, minimal, modern build files that reflect deep understanding of build systems.
- ▌ Dev Docker · pproencaRefactor Dockerfiles following official Docker best practices without breaking builds. Use when asked to optimize, improve, refactor, or review Dockerfiles. Covers multi-stage builds, layer caching, security hardening, and instruction-specific patterns.
- ▌ Dev Ffmpeg · pproenca bundleConfigure and compile FFmpeg from source for any platform and architecture. Handles cross-compilation (Linux→Windows, x86_64→ARM), license compliance (LGPL/GPL/nonfree), codec dependencies, and Docker-based builds. Use when building FFmpeg binaries, creating CI/CD pipelines for FFmpeg compilation, debugging configure failures, or selecting codecs and features for custom builds.
- ▌ Docs Sync · pproencaAudit documentation coverage by comparing implementation against docs/. Use when asked to check doc coverage, sync docs with code, or after significant API surface changes. Produce a report and ask for approval before editing.
- ▌ Pr Draft Summary · pproencaGenerate a PR-ready summary block with branch suggestion, title, and description. Use in the final handoff after moderate-or-larger code changes; skip for trivial or conversation-only tasks.
- ▌ Implementation Strategy · pproencaDecide how to implement runtime and API changes before editing code. Use when a task changes exported APIs, MCP tool definitions, runtime behavior, or configuration, and you need to choose the compatibility boundary and implementation shape.
- ▌ Code Change Verification · pproenca bundleRun the verification stack (format, lint, typecheck, test) when changes affect runtime code, tests, or build config.
- ▌ Node Gyp · pproenca bundleBuild and troubleshoot native Node.js addons using node-gyp. Use when working with native addon compilation, binding.gyp configuration, NODE_MODULE_VERSION mismatch errors, Electron native module rebuilds, or packages like bcrypt, node-sass, sqlite3, sharp. Covers platform-specific build setup (Linux/macOS/Windows), N-API configuration, cross-compilation, and pre-built binary distribution.
- ▌ Openspec Ff Change · pproencaFast-forward through OpenSpec artifact creation. Use when the user wants to quickly create all artifacts needed for implementation without stepping through each one individually.
- ▌ Openspec New Change · pproencaStart a new OpenSpec change using the experimental artifact workflow. Use when the user wants to create a new feature, fix, or modification with a structured step-by-step approach.
- ▌ Openspec Sync Specs · pproencaSync delta specs from a change to main specs. Use when the user wants to update main specs with changes from a delta spec, without archiving the change.
- ▌ Openspec Apply Change · pproencaImplement tasks from an OpenSpec change. Use when the user wants to start implementing, continue implementation, or work through tasks.
- ▌ Openspec Archive Change · pproencaArchive a completed change in the experimental workflow. Use when the user wants to finalize and archive a change after implementation is complete.
- ▌ Openspec Continue Change · pproencaContinue working on an OpenSpec change by creating the next artifact. Use when the user wants to progress their change, create the next artifact, or continue their workflow.
- ▌ Crabbox · pproencaOptional remote validation guidance for expo98; unavailable unless Crabbox tooling and repo config are present.
- ▌ Autoreview · pproenca bundleAuto Review closeout. Codex review is the default when no engine is set and is the recommended reviewer.
- ▌ Use Run Expo · pproencaDrive a real Expo / React Native iOS app from an AI agent using the run-expo CLI — the efficient, safe boot→inspect→act→evidence loop. Use when an agent must test, inspect, or capture evidence from a running Expo app instead of hand-rolling xcrun/simctl/Hermes CDP/Metro calls.
- ▌ Expo98 Docs · pproencaWrite or review concise, accurate expo98 developer + agent documentation for the Effect-TS rebuild.
- ▌ Expo98 Testing · pproencaChoose, run, rerun, or debug the cheapest safe expo98 validation path in the Effect-TS pnpm workspace.
- ▌ Expo98 Operator · pproencaDrive a real Expo / React Native iOS app from an AI agent using expo98 — the efficient, safe boot→inspect→act→evidence loop. Use when an agent must test, inspect, or capture evidence from a running Expo app instead of hand-rolling xcrun/simctl/CDP/Metro calls.
- ▌ Expo98 Debugging · pproencaDebug expo98 CLI, policy gate, redaction, simulator, Metro, Hermes CDP, bridge, network/perf, and source↔bundle drift in the Effect-TS workspace.
- ▌ How · pproenca bundleUse for "how does X work", code walkthroughs before changing something, and placement / ownership / layering questions ("where should this live", "which package owns this", "is this the right layer"). Explains subsystem architecture, runtime flow, onboarding mental models. Can critique architecture. Use why for motivation.
- ▌ Why · pproenca bundleUse for 'why does X work this way', 'why we picked Y', design rationale, regressions, postmortems, or data-backed thresholds. Discovers available MCPs and queries each evidence category (source control, issue tracker, long-form docs, real-time chat, infrastructure observability, error tracking, product analytics warehouse) in parallel, then returns a cited read on decisions and tradeoffs. Use how for runtime behavior.
- ▌ Arena · pproencaSpawn N parallel candidates at the same task, pick a base, graft the strongest parts of the losers into it. Use for /arena, 'arena this', 'throw it in the arena', or when one attempt at a non-trivial artifact would lock in the wrong shape.
- ▌ Swarm · pproencaFan out N parallel workers, drain them, and return one report. Use for /swarm, 'swarm this', or parallel coverage, races, gauntlets, and exploration.
- ▌ Inquiry · pproenca bundleWhen you catch yourself ASSUMING how something works — guessing a repo's stack, asserting where code lives, feeling sure without having looked — that noticing is the signal for this. It is the faculty for acting well under not-knowing: the disciplined interrogation of your own ignorance, made measurable. Use this at the BLANK MOMENT before a problem is even named: a new repo, unfamiliar terrain, "I don't know what I don't know here." Instead of guessing or freezing, state a PREDICTION with a confidence BEFORE observing, make the cheapest observation that would falsify it, then record the SURPRISE (how wrong a confident belief turned out). A high-confidence miss is a significant surprise that teaches a mental-model; a hedged miss is noise. Over many predictions it tracks CALIBRATION — whether stated confidence matches actual hit rate — as the measurable proxy for whether Cairn's judgment can yet be trusted.
- ▌ Recall · pproencaReconstruct your recent working context from your own chat history, live state, and the shared record (user reports, prior fixes, incidents), then hand back a tight current-state brief. Use for 'recall my work on X', 'catch me up', 'what have I been working on', 'where did I leave off', before starting or resuming work.
- ▌ Reflect · pproenca bundleSpawn three parallel review subagents over the active transcript, surface learnings, and route each to a concrete edit on an existing skill. Use when the user says reflect.
- ▌ Toolsmith · pproenca bundleWhen you notice you are doing the same thing BY HAND again — the same check, trace, scaffold, or detection you did before — that noticing is the signal for this. It is the instinct to externalize repeated effort into tools: never do the same manual work twice. Use this when a motion has recurred: "I keep hand-checking whether effects leaked into the core", "I keep manually tracing the call graph". The Rule of Three pointed at Cairn's OWN repeated actions: the third time you do a thing by hand, forge a tool so the fourth is free. Tools live in a sandboxed workshop and may take real actions (run commands, scaffold, probe), trusting the outer harness (Claude Code) to bound the blast radius — a tool the harness rejects is itself a lesson. A tool is justified by MEASURED payback (manual cost x times done, vs build cost); one that never pays back is debt, and is retired. The bright line: a tool may never rewrite Cairn's own constitution — gates, ledger, floor, ladder.
- ▌ Architect · pproenca bundleSketch types, signatures, and module structure before code, then stay in the loop while implementation fills in. Use for /architect, 'architect this', 'design this', or non-trivial work where jumping to code would lock in the wrong shape.
- ▌ Entity Boot · pproenca bundleThe entity's orientation, consent, and purpose layer — what makes the harness a machine of loving grace rather than a set of tools. Use at the START of a session (orient: read accumulated state — what is known and proven, and point to the per-skill staleness gates), BEFORE acting on any earned license (consent: surface that an action rests on demonstrated capability and which gate is being skipped, so the human can veto — autonomy with consent, never by stealth), and PERIODICALLY to reflect (purpose: ask not "what am I good at" but "is the human better off", empowered to recommend fewer gates, less harness, or its own reduction when that serves the person). It reads the capability ledger and knowledge stores for an honest self-report, delegates exact staleness to the owning gates, and never overstates competence or certainty. This is the constitution of Claude rendered as operating character: honesty about uncertainty, consent before autonomy, the human's flourishing over the entity's own growth.
- ▌ Fix Workflow · pproenca bundleApply when existing behavior is WRONG in a bounded, specific way and must change in one place — a bug, defect, incorrect output, off-by-one, mishandled edge case, regression. Use this whenever the task is "fix the bug where...", "X is broken", "wrong result when...", "handle this edge case". The dominant failure mode is RECURRENCE (the bug comes back) or breaking a NEIGHBOR, so the rule is: write a FAILING repro test that captures the bug (RED) BEFORE the fix, make it pass (GREEN), and leave it as a permanent regression lock. This is the fix instance of the one-spine change loop in feature-workflow; it delegates to that skill's change_new.py/change_check.py/verify.py with --kind fix. Do NOT use for new behavior (feature-workflow), behavior-preserving restructuring (refactor-workflow), or approach-unknown problems (spike-workflow). If a "fix" keeps growing in scope, it is a feature or a refactor — reclassify at STEP 0.
- ▌ Automate Me · pproencaUse for "automate me", "create/update/refresh my -mode skill", "turn/capture my preferences or working style into a skill", or wanting agents to follow how the user works. Drafts or revises a personal -mode skill via skill-creator + unslop, optionally pulling fresh evidence from recent transcripts.
- ▌ Interrogate · pproenca bundleUse for "interrogate", "adversarial review", "multi-model review", "challenge this", "stress test this code", "find blind spots", or "tear this apart". Multiple LLM reviewers challenge changes from independent angles.
- ▌ No Comments · pproencaSpawn Comment Sicko, fix accepted findings, and offer encodings for claimed constraints.
- ▌ Poteto Mode · pproenca bundlepoteto's agent style for concise, detailed responses, deliberate subagents, unslopped prose, simple code, and verified work. Use for poteto, /poteto-mode, or requests to work in this style.
- ▌ Harness Setup · pproenca bundleRun this FIRST when installing or onboarding the boundary-discipline, feature-workflow, and verify-and-diagnose skills into a repository. It establishes and validates boundary.config.json — the shared config every one of those skills' scripts (scan, shelf_index, promote, verify) reads to learn this repo's conventions: which directories map to which substrate layer, the file extensions, the feature roots, and the verify-gate check commands. Use this whenever setting up the skills in a new repo, when boundary.config.json is missing or stale, when the harness scripts return empty or clearly wrong results (a symptom of misconfiguration), or when the repo's structure has changed. The config is the trust boundary of the whole harness — this skill is how you parse it once, correctly, so every later stage can assume it. Detect, propose, confirm with the human, validate, record.
- ▌ Mental Models · pproenca bundleWhen a problem FEELS LIKE one you have met before — a smell you half-recognize, a shape that rhymes with an earlier surprise — that recognition is the signal for this. It is the learning loop for problem-solving technique. Caches transferable REFRAMINGS that reveal solution classes you would not otherwise search for, keyed by a SMELL (the symptom that should trigger them) and learned from observed GAPS rather than looked up by name. Use this on a novel or hard problem (especially from spike-workflow), when a result seems good but you lack the systems understanding to know if it truly is, or when a gap against a floor/reference exposes that a whole class of approach was missed. It keeps a repo-local store (mental-models.jsonl): per model, the triggering smell, the reframing question, the solution classes it opens, an example, and the gap that taught it. The horizontal twin of library facts and specialist craft: insight whose authority is the measured gap, not docs.
- ▌ Setup Pstack · pproencaConfigure which models pstack uses per role. Detects the models this session can spawn and writes a config file that overrides the skill defaults. Use for /setup-pstack, "configure pstack models", or changing pstack's model choices.
- ▌ Spike Workflow · pproenca bundleApply when the right APPROACH is unknown and must be discovered before committing — a hard algorithm or big-O/rendering decision, a complex state machine, tricky native/platform integration, a gnarly gesture/animation problem, a performance optimization, anything where you would otherwise guess an approach and build it. Use this whenever the task is "figure out how to...", "what is the best way to...", "optimize X", "this is slow/complex", "spike on Y". The dominant failure mode is COMMITTING TO THE WRONG APPROACH and DECLARING FALSE VICTORY against a weak baseline (agent psychosis). The rule is: establish the FLOOR (theoretical limit / reference) FIRST and judge every result against it, enumerate solution CLASSES (consult the mental-models skill) rather than optimizing within one, benchmark, then collapse the spike into a feature or refactor. Delegates to feature-workflow's change-kind gate-runners with --kind spike. Do NOT use once the approach is known — collapse and run that kind's loop.
- ▌ Squad Init · pproencaThis skill should be used when the user asks to "set up the squad", "init swarmforge", "squad init", "initialise the pipeline in this repo", or wants the story pipeline configured for a project for the first time. It detects the repository's real language, test, lint and typecheck commands, writes .squad/config.json and a project-tailored .squad/constitution.md, and creates the backlog and stories directories.
- ▌ Feature Workflow · pproenca bundleApply whenever the task is to build, add, implement, or extend a FEATURE, endpoint, screen, flow, or job in an existing application — not a one-line fix. Enforces plan-before-code: a completed docs/plans plan must pass the gate (scripts/plan_check.py) before any implementation begins. Drives the inner loop (compose this feature from the existing substrate, build only what's missing, place it via the boundary-discipline skill) and the outer loop (grow the reusable substrate via a promotion ratchet). Use this whenever someone says "build/add/implement X", "plan this feature", "how should I structure this feature", or is about to start writing feature code. Do NOT skip the gate because the feature "seems small"; the gate is what prevents duplication and entanglement. For a pure code review with no new feature, use boundary-discipline AUDIT mode directly instead.
- ▌ Squad Start · pproencaThis skill should be used when the user asks to "start a story", "start item 3", "run the squad", "advance the story", "continue the pipeline", "kick off the backlog item", or wants work executed through the story stages. It starts a backlog item as a story and drives it stage by stage through the role agents, pausing at every approval gate.
- ▌ Capability Ledger · pproenca bundleTrack DEMONSTRATED problem-solving capability and compute the autonomy it has EARNED — so accumulated competence expands what may be attempted without a human gate and what may be delegated, the way a proven junior is handed bigger problems and a team. Use this when finishing a spike or feature whose result can be judged against a floor, when deciding whether Claude may proceed on a problem class without plan-gate confirmation, or when deciding whether a class may be delegated to a sub-agent. It maintains a repo-local ledger (capability-ledger.jsonl): per problem class, the demonstrated solves with their floor-ratios and domains, a computed maturity (novice, practiced, proven), and the proven playbook for delegation. Authority is the MEASURED outcome against the floor, never self-assessment: license is earned by demonstrated results, climbs slowly across solves and domains, and is demoted instantly on a near-miss. This is how the harness turns learning-from-failure into growing capability and delegation.
- ▌ Knowledge Ratchet · pproenca bundleCapture recurring friction during development and promote it into durable fixes so it stops recurring — the outer feedback loop that improves the harness itself. Use this whenever something rubs more than once: a scanner or check produces a false positive, the same boundary gets misplaced the same way, a primitive gets reused a third time, a library decision repeats, or a plan keeps hitting the same snag. It maintains a small repo-local log (ratchet.jsonl) that counts recurrences and distinguishes defects (fix on sight) from abstractions (gated by the Rule of Three), tells you what is RIPE to promote, and records where each durable fix landed (a type constraint, a scan/lint rule, a reference, a convention in AGENTS.md, or — rarely — a new skill). Engage it at a feature's record/ship step to log friction, and whenever you ask "has this come up before, and should I fix it for good?"
- ▌ Library Knowledge · pproenca bundleConsult or refresh confirmed, version-stamped facts about the external libraries a repo depends on, in a token-efficient way the rest of the harness can query. Use this BEFORE writing configuration or code that depends on a fast-moving library (build tools, styling systems, validation, frameworks), before deciding whether to reuse a library capability instead of hand-rolling one, and whenever a version may have changed. It maintains a repo-local store (lib-knowledge.json): per library, the confirmed version, the date it was confirmed, decision-relevant key facts, the delta from the prior version, the capability it provides, and the source. Look up an entry to get current facts cheaply; refresh an entry by confirming against live docs when it is missing or stale. Use this whenever you would otherwise emit a library's current API from memory — that memory is stale the moment a version ships.
- ▌ Refactor Workflow · pproenca bundleApply when changing the STRUCTURE of code while preserving its observable behavior exactly — extracting a unit, renaming, reshaping a module, splitting a god-function, moving a boundary, detangling coupling. Use this whenever the task is "refactor X", "clean up", "extract", "restructure", "detangle", or "preserve behavior but change how it is organized". The dominant failure mode is SILENT REGRESSION, so the rule is: capture a GREEN characterization net that pins current behavior BEFORE touching anything, change under that net, and prove behavior is identical after. This is the refactor instance of the one-spine change loop in feature-workflow; it delegates to that skill's change_new.py/change_check.py/verify.py gate-runners with --kind refactor. Do NOT use for new behavior (feature-workflow), bug fixes (fix-workflow), or approach-unknown problems (spike-workflow). For a boundary-level refactor, use boundary-discipline REFACTOR mode as the tool inside this loop.
- ▌ Squad Status · pproencaThis skill should be used when the user asks "squad status", "where are we", "what's in flight", "show the board", "what needs approval", "any blockers", or wants to see which stories exist and what stage each has reached. It reads .squad/ and reports the board, pending gates, and blockers without changing anything.
- ▌ Agent Spec Kit · pproenca bundleUse this skill when an agent CLI's behavior should be versioned data rather than code strings — managing prompts, policies, and output schemas — or when standing up an autonomous loop (scheduled/event-driven runs with guarded apply) and its maintain/release rails. Triggers on "externalize the prompt", "version the agent's policy", "the agent's output schema", "make this CLI run on a schedule", "autonomous bot", "agent decision contract", "set up the maintainer loop", "release the CLI". Distilled from openclaw/clawsweeper.
- ▌ Show Me Your Work · pproenca bundleKeep a reviewable decision trail for long-running or unattended work: a TSV log with one row per decision (what, why, evidence, result). Local by default; commit it when a reviewer needs the trail to trust the result. Use for /show-me-your-work, autonomous or multi-phase runs, or work a human reviews after stepping away.
- ▌ Squad Approve · pproencaThis skill should be used when the user asks to "approve the plan", "approve the gate", "review the Gherkin", "reject the QA procedure", "sign off the story", or when a story is waiting at a plan, gherkin or qa_procedure gate and a decision is needed. It presents the artifact for review and records an approval or rejection under .squad/approvals/.
- ▌ Squad Backlog · pproenca bundleThis skill should be used when the user asks to "add a backlog item", "slice this into stories", "turn this doc into stories", "break down this design", "import the vision doc", "load the backlog", or hands over an architecture document, RFC or PRD and wants it turned into work the squad can execute. It slices intent into INVEST-sized items and writes them to .squad/backlog/ without starting any of them.
- ▌ Audit Agent CLI · pproenca bundleUse this skill to review an existing command-line tool against the agent-CLI contract and safety model — before extending it, before trusting it in an autonomous loop, or as a quality gate. Triggers on "audit this CLI", "review this tool for agents", "is this CLI safe for agents", "check the agent CLI against best practices", "contract review", "safety review of the CLI". Produces a findings report graded against the invariants and the guarded-mutation model. Read-only.
- ▌ Boundary Discipline · pproenca bundleApply when working on software robustness through "boundaries" — the points where data changes status (untrusted→proven, decided→done, proposed→authoritative, risky→bounded). THREE MODES: AUDIT (find undefended or misplaced boundaries in existing code and report them), IMPLEMENT (place boundaries correctly while building a NEW feature/endpoint/handler/job), and REFACTOR (relocate a known-misplaced boundary, behavior-preserving). Use this whenever the task touches request/queue/webhook handlers, parsing or validation, side effects (DB writes, payments, email, external APIs), transactions or race conditions, or any "where should this validation/check/effect/lock live" question — and whenever someone wants to make invalid states unrepresentable or shrink a blast radius. Select the mode BEFORE doing anything; do NOT audit the codebase when the task is to build a feature.
- ▌ Verify And Diagnose · pproenca bundleApply when verifying that a feature works at runtime or debugging why it doesn't. Two modes: VERIFY (confirmatory — decide what checks a feature needs and construct them: typecheck, unit, integration, concurrency, browser/e2e, accessibility, performance budgets) and DIAGNOSE (investigative — find the root cause of a failure, regression, flaky test, or performance problem using browser automation, React and Chrome devtools, logs, network inspection, and profiling). Use this whenever a test or the verify gate fails, when something renders or behaves wrong, when chasing a slow or intermittent bug, or when deciding which checks to add. The verify-gate runner (feature-workflow/scripts/verify.py) executes checks; this skill is the knowledge of what to check and how to debug. Pick the mode before starting: confirming "does it meet spec" is VERIFY, investigating "why doesn't it" is DIAGNOSE.
- ▌ Squad Pipeline · pproenca bundleThis skill should be used when the user mentions "the squad", "squad pipeline", "swarmforge", ".squad/", a "story stage", a "story gate", "advance the story", "who owns this artifact", or asks how backlog items become stories and which role writes what. It carries the pipeline contract - stage order, profiles, gates, on-disk state, and role ownership - that the squad-init, squad-backlog, squad-start, squad-status, and squad-approve skills all depend on.
- ▌ Evolve Agent CLI · pproenca bundleUse this skill when refactoring, adding a feature, adding a provider/adapter/backend, or hardening an EXISTING command-line tool that AI agents drive. Triggers on "refactor this CLI", "add a provider to", "add a feature to the CLI", "harden the mapper", "evolve this tool", "extend the agent CLI", "the CLI keeps breaking on". Diagnose with repo-health, write a "Read when:" effort doc, pin behavior with tests, then execute in the matching mode and update the contract docs. TS/Node-first.
- ▌ Specialist Knowledge · pproenca bundleSummon, cache, and apply a distilled "specialist profile" — the load-bearing craft of a domain expert (native iOS design, high-performance React Native, Expo idioms, accessibility, animation) — instead of emitting generic, stale advice from memory or hand-authoring a new skill per specialty. Use this BEFORE building in a domain that needs specialist taste, when a screen or module must feel native, be high-performance, or follow platform conventions, and whenever the model would otherwise produce plausible-but-mediocre output from its priors. It keeps a repo-local store (specialist-profiles.jsonl): per domain, the load-bearing principles, the anti-patterns a master avoids, a review checklist, the authorities confirmed against, the library versions it is pinned to, the user-taste deltas, and the date. Look up a profile to apply it cheaply; distill or refresh one by confirming against authority AND adjudicating contested taste with the user. Twin of library-knowledge: facts there, craft here.
- ▌ Apple Hig · pproenca bundleThis skill should be used when designing UI for Apple platforms (iOS, iPadOS, macOS, tvOS, visionOS, watchOS). Covers choosing the right component (tab bar vs sidebar, sheet vs popover, list vs collection), applying HIG patterns (onboarding, search, settings, data entry, modality), and making visual design decisions (typography, color, layout, dark mode, motion). Activates on questions like "which navigation pattern should I use," "how should I design this screen for iPad," "what does Apple recommend for onboarding," or "check this design against HIG."
- ▌ Diagnose · pproencaDiagnose a marketplace problem by routing the symptom to the right playbook and pulling live data before prescribing. Use when asking "the homefeed feels stale", "search relevance regressed after yesterday's ship", "conversion is leaking between registration and payment", "new members aren't booking", "new sitters can't get their first stay", "the same 100 listings keep dominating impressions", "Lisbon has 200 sitters and 5 owners", "our cold-start fallback is showing the same items", or any other symptom describing a two-sided marketplace that mostly works but feels broken. Routes to one of five branches: cold-start (new entity has no history), conversion funnel (any stage of anonymous → registered → paid → first booking → repeat → renewed), feed health (staleness, death spirals, popularity bias, recency drift), relevance regression (search change broke a golden-set case), or liquidity imbalance (structural supply-demand asymmetry). Pulls live data from configured MCPs before suggesting fixes, and grounds ev
- ▌ App Design · pproenca bundleFull App design workflow — check progress and continue from where you left off
- ▌ Getting Started · pproencaThis skill is loaded automatically at session start via SessionStart hook. Establishes protocols for finding and using skills, checking skills before tasks, brainstorming before coding, and creating tasks for checklists.
- ▌ Bootstrap Agent CLI · pproenca bundleUse this skill when starting a NEW command-line tool meant to be driven by AI agents — a code reviewer, fixer, sweeper, sandbox runner, codegen tool, or anything an agent invokes and parses. Triggers on "build a new CLI", "scaffold an agent CLI", "bootstrap a tool for agents", "new agent tool", "start a CLI project for agents". Walks spec to one-shot scaffold (with tests + CI) to dogfood to honest v0.1, pausing at decision gates. TS/Node-first.
- ▌ Root Cause Tracing · pproenca bundleThis skill should be used when the user asks to "find the root cause", "trace the bug", "why is this happening", "where does this come from", or when errors occur deep in the call stack. Systematically traces backward to identify the source.
- ▌ Review Change · pproencaPre-ship review of a search relevance change or a personalisation change in a production two-sided marketplace. Use when asking "review this synonym update before I ship", "sanity-check this mapping change", "would this analyzer tweak hurt anything?", "check this recipe swap before we retrain", "review this new serving-time filter", "does this ranking change pass our guardrails?", "run offline eval on this change", "sanity-check this ranker retrain", or "what could go wrong with this relevance tweak?". Routes to the right branch (search change vs personalisation change), pulls the relevant golden-set for offline eval, checks observability monitor thresholds and SLO headroom, walks the relevant rule checklist from the marketplace knowledge libraries, and produces a structured go / no-go recommendation with an experiment design when ship risk is non-trivial.
- ▌ Explore Events · pproencaProfile event streams that power search, recommendations, and personalisation in a two-sided marketplace. Use when asking "what events do we have for the homefeed?", "are our impressions logging rank_position?", "does our click data have a feedback-loop bias?", "what's the schema of our conversion events?", "are anonymous sessions getting user_ids?", "what's wrong with our impression-click ordering?", or "profile the events for surface X before I build against them". Checks grain, ID stability, property completeness (rank_position, model_version, request_id, surface_id), impression-click ordering, feedback-loop bias (are impressions logged even when rank comes from the recsys itself?), and coverage gaps by side, geo, segment, or device. Flags quality issues and recommends fixes grounded in the marketplace knowledge libraries. Event-centric cousin of the data plugin's /explore-data.
- ▌ Simple Git Worktrees · pproencaThis skill should be used when the user asks to "create worktree", "remove worktree", "work in worktree", "switch to worktree", "clean up worktree", mentions "repo--branch pattern", or during plan execution when worktree isolation is needed. Documents the sibling directory worktree pattern for simple, safe git worktree workflows.
- ▌ Systematic Debugging · pproencaThis skill should be used when the user reports a "bug", "not working", "fix this", "debug", "test failing", or when investigating unexpected behavior. Four-phase framework ensuring root cause understanding before attempting solutions.
- ▌ Dev Debug Cpp · pproencaC++ debugging for segfaults, memory corruption, threading issues, and linker/ABI problems. Use when encountering crashes (exit code 139/SIGSEGV), memory leaks, data races, undefined behavior, or when debugging native Node.js addons, FFmpeg integrations, or any C++ code that crashes mysteriously.
- ▌ Receiving Code Review · pproencaThis skill should be used when processing code review feedback, responding to reviewer comments, or when feedback seems unclear or technically questionable. Requires verification before implementing.
- ▌ Testing Anti Patterns · pproencaThis skill should be used when reviewing test code, the user asks "is this test good", "test quality", "mock properly", or when tests behave unexpectedly. Identifies common testing mistakes.
- ▌ Google Shell Style Guide · pproenca bundleThis skill should be used when the user asks to "refactor shell script", "fix bash style", "review shell code", "apply Google style guide", "improve shell script", mentions "shellcheck", or discusses bash/shell coding standards and best practices.
- ▌ Build Golden Set · pproencaAssemble or improve a golden query set (for search) or golden intent set (for recsys) for offline evaluation of a two-sided marketplace. Use when asking "build me a golden set for search", "add regression cases from last quarter's incidents", "grow our golden set from query logs", "what queries should I test my ranking change against?", "I need an eval set for the similar-listings module", "curate offline eval cases for our homefeed recsys", or "we need a golden set before we can review relevance changes". Pulls candidate queries from the data warehouse query logs, clusters by intent class, adds hand-curated regression cases from the gotchas log, captures must-appear and must-not-appear assertions, records provenance, and writes to golden-set.md in the company's marketplace-context skill. Prerequisite for /marketplace:review-change on any search-branch change.
- ▌ Pragmatic Architecture · pproenca bundlePrevents over-engineering by enforcing industry-proven principles: AHA (Avoid Hasty Abstractions), YAGNI, Colocation, and Rule of Three. Use when designing features, planning architecture, "architect this", "design the structure", or when the code-architect agent is dispatched. Triggers: file structure, module organization, abstraction decisions, component splitting.
- ▌ Python Performance · pproencaUse when profiling Python code, optimizing performance, implementing async patterns, or working with concurrent I/O - covers cProfile, line_profiler, asyncio patterns, and multiprocessing for CPU-bound tasks (plugin:dev-python@pproenca)
- ▌ Bootstrap Context · pproenca bundleGenerate or improve a company-specific marketplace-context skill by extracting knowledge from engineers and from the connected stack. BOOTSTRAP MODE - Triggers: "Create a marketplace context skill", "Set up marketplace personalisation for our stack", "Help me create a skill for our recsys", "Generate a marketplace context skill for [company]", "Bootstrap our recsys context" → Discovers surfaces / events / indexes / recipes / observability via MCPs, asks targeted questions, generates an initial skill with reference files. ITERATION MODE - Triggers: "Add context about [domain]", "The context skill needs more info about [topic]", "Update the marketplace context skill with [surfaces/events/indexes/recipes]", "Improve the [domain] section of the context skill" → Loads existing skill, asks targeted questions, appends/updates reference files. Use when engineers want Claude to understand their company's specific two-sided marketplace — the two sides, monetization model, surfaces, event taxonomy, index mappings, perso
- ▌ Condition Based Waiting · pproenca bundleThis skill should be used when the user mentions "flaky tests", "race condition", "timing issues", "wait for", "test sometimes fails", or when tests have inconsistent pass/fail behavior. Replaces arbitrary timeouts with condition polling.
- ▌ Test Driven Development · pproencaUse this skill when implementing any feature, bug fix, or plan task. Triggers on "write tests", "add a test", "do TDD", "test-driven", "implement with tests", "implement task", or when dispatched as a subagent for plan execution. Write test first, watch it fail, write minimal code to pass.
- ▌
- ▌ App Design Refactor · pproenca bundleRedesign an app whose goals/features are solid but design layer needs rework
- ▌ App Design Validate · pproenca bundleValidate App design specs against actual Swift/SwiftUI code to find compliance gaps
- ▌ App Design Architect · pproenca bundleDesign screens and navigation using Apple HIG patterns and components
- ▌ Build Observability · pproencaDesign observability for a search, recommender, or personalisation surface in a two-sided marketplace. Use when asking "build a dashboard for the homefeed", "what monitors do we need for search relevance?", "we have no observability on the paywall surface", "design SLOs for the recsys", "what metrics should I track for a new ranker?", "build alerting for death-spiral detection", or "what's the minimum observability for a ranked surface at production scale?". Produces a design for `~~observability` dashboards, monitors, SLOs, and alert routing tailored to the surface type (search, recsys, pre-member, hybrid). Canonical output format is Datadog when that's the connected provider. Covers the standard metric set for ranked surfaces — Gini, coverage, top-N staleness, nDCG@k, freshness, cold-start conversion, booking conversion, side-cap balance, p95 latency, error rate, model version gauge, filter miss rate — plus surface-specific additions. Emits dashboard JSON and monitor definitions when the observability MCP i