jcosta33
- 19 skills
- 0 followers
- 6 hours ago last updated
- ▌ Sus Spec · jcosta33Write, revise, or structurally check a verifiable Suspec spec. Use when intent or consequential open behavior must become requirements and acceptance criteria before implementation. Do not use for direct implementation, small clear work, factual verification, or detailed implementation planning.
- ▌ Sus Task · jcosta33Split a ready Suspec spec into collision-proof task packets. Use when spec-governed work must be divided into independent parallel slices, repository or platform contexts, or dispatchable transformation waves. Do not use for unspecced work or work with no dispatch boundary.
- ▌ Sus Audit · jcosta33Audit present code against direct evidence. Use when running debt surveys, cleanup assessments, single-implementation benchmarks, current-state quality assessments, or fresh passes over prior audits without a governing spec or task. Do not use for conformance review, rotating adversarial review, or option research.
- ▌ Sus Campaign · jcosta33Write or revise a restartable goal contract for one multi-pull-request delivery campaign. Use when one durable objective needs dependency-aware, write-disjoint streams, a project-native progress ledger, and enforceable delivery gates. Do not use when the goal completes in one pull request, or when the user asks only for a plan artifact.
- ▌ Sus Research · jcosta33Research a decision until evidence can carry it. Use when comparing options, evaluating APIs or products, sizing markets, mapping competitors, studying customers, synthesizing reviews, inspecting UX, or testing positioning. Do not use as the owner of settled fact-checking, present-state audits, or intent authoring.
- ▌ Sus Inventory · jcosta33Map an unfamiliar or change-critical code area as durable current state. Use when wide change lacks a proven map. Do not use for direct implementation, narrow path tracing, or small isolated work.
- ▌ Sus Change Plan · jcosta33Plan structural change while preserving behavior. Use when a refactor, rewrite, migration, upgrade, performance change, schema change, or wide architecture cleanup needs a proven baseline and staged transformation. Do not use for direct implementation, net-new feature design, or a single-seam lock-and-write.
- ▌ Drill · jcosta33Lock one change from language through obligation, place, and slice before writing. ALWAYS use when those levels mix, implementation starts before place is locked, or a lower question fires while a higher lock is open. Do not use for a checked staged transformation.
- ▌ Panel · jcosta33Produce one recommendation from independent analysis of legitimate alternatives. Use when a consequential technical, architectural, operational, or product choice needs several perspectives before a decision. Do not use when direct evidence settles the choice, the user has stated a decision in the thread, or the work needs factual research instead of deliberation.
- ▌ Settle · jcosta33Resolve technical or procedural ambiguity through direct evidence. ALWAYS use when implementation would otherwise stop for a technical question, evidence conflicts, or a consequential reversible choice lacks a proven answer. Do not use for product intent, public behavior, material security or cost tradeoffs, waivers, irreversible actions, or acceptance.
- ▌ Debloat · jcosta33Compress and harden supplied prose. Use when repetition, softness, ceremony, or structural bloat obstructs developer use. Do not use for source code, commit messages, or repository-native pull-request forms.
- ▌ Dissect · jcosta33Trace one unfamiliar or dangerous code path to closure. Use when its callers, flow, state, effects, failures, configuration, tests, or coupling remain unproven. Do not use as the owner of contained work or whole-area inventory.
- ▌ Promote · jcosta33Move transient working material into project-owned permanence. Use only when transient material must become durable. Do not use for transient relocation or already-durable material.
- ▌ Ask User · jcosta33Intercept every agent-originated question and unresolved ambiguity that requires user input. ALWAYS use before asking for clarification, confirmation, permission, preference, approval, waiver, a decision, or any answer that work must wait for. Do not use when no user response is required; answer user-originated factual questions directly, ignore rhetorical questions, and settle discoverable or reversible matters yourself.
- ▌ Remember · jcosta33Preserve verified lessons after work settles. Use when a lesson must survive the session or completed work exposes a durable fact, invariant, defect, decision, or operational constraint. Do not use for ephemeral observations or unsettled work.
- ▌ Revolver · jcosta33Run exhaustive multi-angle review and sequential repair across code, diffs, artifacts, plans, or systems. Use when breadth across every target-justified stance is required. Do not use for fast fixed-panel review or single-claim verification.
- ▌ Demolition · jcosta33Build the strongest one-sided case against an idea, design, claim, change, or plan. Use only when the user explicitly requests attack-at-all-costs advocacy. Do not use for balanced evaluation, factual verification, or verdict-bearing review.
- ▌ Bulletproof · jcosta33Fact-check claims and prove completed implementation against direct evidence. Use when claims need validation, cross-examination, or hardening, or completed work needs decisive command proof. Do not use as the owner of broad risk discovery, requirement conformance, or one-sided advocacy.
- ▌ Triple Check · jcosta33Run a fast parallel review with exactly three fresh top-tier reviewers across code, diffs, artifacts, plans, or systems. Use when rapid independent scrutiny is required. Do not use for exhaustive sequential review or single-claim verification.