Bicrement

Plugin bicrement in zhuochun/skills. Commands read from the repo's manifest — 1 month ago.

Skills (36)

• agentic-repo-environment

  Diagnose, bootstrap, retrofit, or renew the repository-local environment for coding-agent work across the software lifecycle. Use read-only diagnosis for task-path gaps, Bootstrap for minimum working paths, Retrofit for observed friction, and Renew for accepted corrections. Improve discovery, execut

• architecture-assessment

  Discover and rank architecture improvement opportunities across an existing software scope before one redesign target is selected. Use for portfolio health checks, accumulated architecture drift, fresh-eye reassessment, modernization priorities, fragile hotspots, testing difficulty, or ownership fri

• architecture-risk-evaluation

  Evaluate software architecture by translating business drivers and quality goals into prioritized, falsifiable scenarios and tracing them through components, data, deployment, dependencies, and operating procedures. Use for architecture proposals, design reviews, modernization programs, major techno

• architecture-surface-mapping

  Orient across multiple architecture surfaces of unfamiliar software or trace one bounded end-to-end journey across experience, operations, domain state, systems, data, interfaces, and owners. Use when a decision depends on cross-surface relationships or expected and observed paths disagree. Keep sim

• autonomous-delivery

  Complete an authorized software change while detecting, applying, and integrating the specialist judgments it needs. Use for requests such as go fix it or take this through completion. Own continuity and verification; keep routine choices moving, and pause dependent work for unresolved consequential

• behavior-preserving-refactoring

  Improve software structure while preserving supported observable behavior, compatibility, and operational semantics. Use for an authorized module redesign, legacy seam, abstraction extraction or collapse, ownership move, coupling reduction, or learned-architecture consolidation without intended beha

• code-review

  Review a proposed or completed software change against its intent, constraints, supported behavior, evidence, and future change cost without modifying it. Use for working-tree, commit, branch, pull-request, generated-code, migration, or configuration review before merge or release. Route whole-archi

• controlled-release-design

  Design controlled exposure for changing behavior through flags, dark launches, canaries, cohorts, kill switches, and release evidence. Use when deployment must be separated from exposure or promotion, abort, mixed states, ownership, and cleanup need explicit control. Use migration-planning as the en

• decision-facilitation

  Facilitate a consequential or contested decision from unclear intent to explicit authority, alternatives, evidence, assumptions, tradeoffs, closure, and follow-through. Use for organizational, product, operational, or technical choices, recurring reopening, proposal preparation, or requests to grill

• deep-module-design

  Decide whether to retain or redesign a software module or interface before implementation. Use when a request asks where a seam belongs, whether duplication should gain one owner, how to deepen a shallow abstraction, make dependencies testable, or add a new variant without leaking policy. Do not use

• domain-modeling

  Discover, compare, and evolve selective software domain models and bounded contexts around an important problem. Use when solution-shaped requirements, conflicting language, repeated exceptions, disputed concepts, classifications, or invariants, unclear translations, or hidden historical state make

• experience-design-specification

  Design a reviewable user experience for an intended outcome through user-facing concepts, task flows, information hierarchy, interaction states, feedback, and recovery. Use before implementation when people would otherwise invent consequential UX choices. Route opportunity validation to product disc

• incident-learning

  Facilitate or analyze incidents, outages, near misses, and operational surprises as system-learning reviews. Use for postmortems, debriefs, recurring failures, weak-signal analysis, or follow-up quality reviews. Reconstruct timelines and local reasoning, expose model and control gaps, preserve succe

• incident-response-coordination

  Coordinate live software incident response through accountable command, customer-impact stabilization, delegated workstreams, communications, evidence preservation, and deliberate recovery handoff. Use during outages, severe degradation, multi-service incidents, escalation, or response confusion. Su

• migration-planning

  Plan a survivable technical migration from an established state to an accepted replacement while supported obligations continue. Use when state, traffic, consumers, execution, infrastructure, or authority must move and the old state must become retireable. Own transition states, authority transfer,

• observability-design

  Design or audit decision-oriented observability across outcomes, behavior, dependencies, infrastructure, ownership, and control paths. Use before rollout for signals, dashboards, alerts, SLOs, correlation, or release evidence, and after representative operation to test whether telemetry supports ori

• platform-capability-design

  Design or review internal platform capabilities that turn repeated engineering work into honest, self-service, supportable paths with useful defaults, guardrails, and escape hatches. Use for developer platforms, paved roads, service templates, platform APIs, ticket-heavy services, or duplicated tool

• product-opportunity-discovery

  Discover and test which customer opportunity and solution direction merits investment before heavy implementation. Use for solution-shaped feature requests, conflicting customer evidence, opportunity models, assumption mapping, prototypes, experiments, or comparisons among solutions. Produce an evid

• product-opportunity-prioritization

  Prioritize product opportunities and bets against explicit outcomes, strategy, customer evidence, obligations, capacity, dependencies, risk, and learning horizon. Use for outcome roadmaps, reframing feature backlogs, choosing among customer problems, balancing near-term and uncertain bets, or review

• prototype-to-learn

  Build a disposable, runnable software prototype that answers one explicit behavior, state, UI, or interaction design question before maintained implementation. Use when users want to compare runnable candidates, exercise an interaction direction before choosing maintained behavior, or drive candidat

• research-synthesis

  Produce a bounded cross-source synthesis of what high-trust evidence supports, contradicts, or leaves unresolved, with claim provenance, applicability, confidence, and gaps. Use for literature reviews and comparisons across papers, standards, reports, guidance, or datasets. Exclude one-source summar

• retrospective-architecture-review

  Reconsider one completed software design after implementation, repeated change, operation, incidents, support, or ownership creates a material knowledge delta. Recover commitments, compare alternatives, and recommend retain, quarantine, prune, reshape, or rebuild without modification. Exclude portfo

• scoped-change-implementation

  Implement a ready, authorized, bounded feature, enhancement, integration, configuration change, or causally supported fix in coherent vertical slices while preserving conventions, unrelated work, behavior, and controls. Fix authority does not establish cause; route unexplained failures to software-f

• service-boundary-design

  Decide whether deployable service boundaries should be kept, split, merged, strengthened, or replaced by an in-process module boundary. Use for microservice proposals, modular-monolith reviews, service sprawl, unclear data ownership, cross-service pain, incidents, or ownership realignment. Ground re

• service-capacity-engineering

  Model, design, or review end-to-end service capacity and behavior near or beyond saturation across online, asynchronous, batch, storage, or shared workloads. Use for peak readiness, nonlinear latency, queue growth, retries, fan-out, noisy neighbors, failover headroom, load tests, admission control,

• service-ownership-design

  Design or assess whether a team and its enabling environment can sustainably own a production service across delivery, operation, support, improvement, and retirement. Use before ownership transfer, expanded full-cycle responsibility, reduced handoffs, on-call change, or review of nominal ownership.

• software-change-specification

  Specify an accepted but ambiguous software change before implementation by recovering current and desired behavior, scope, invariants, affected surfaces, acceptance claims, and unresolved decisions. Use when implementers would otherwise invent consequential behavior. Do not use to review a fixed can

• software-contract-evolution

  Design how software contracts evolve while independently changing producers, consumers, and stored state coexist. Use for APIs, events, schemas, protocols, libraries, commands, or integrations involving compatibility, versioning, deprecation, translation, mixed versions, or retirement. Recover the a

• software-failure-diagnosis

  Diagnose bugs, regressions, intermittent failures, incorrect results, crashes, and performance degradation by turning symptoms into discriminating evidence and a supported cause. Use first whenever a newly reported symptom remains unexplained, even when the user also authorizes a fix. After causal s

• software-security-design

  Design or revise a change-level secure-by-design contract across delivery. Use for threat modeling or when attacker-controlled inputs, protected data or effects, identity, secrets, dependencies, tenant boundaries, privilege, AI agents, or unsafe defaults create material security decisions. Produce p

• software-system-design

  Design a coherent technical solution for a bounded software capability or system when responsibilities, state ownership, interfaces, and execution must be resolved together across an end-to-end path. Use for new capabilities, application architecture, or integrations with unsettled structure. Keep s

• software-verification

  Design or execute risk-proportionate software verification by binding engineering claims to fixed methods, oracles, environments, and inspectable evidence. Use for architecture testing, undefined coverage, stale or missing evidence, named claims that must run, or an independent final check. Keep inn

• specification-review

  Independently review a specification, RFC, requirements set, behavioral contract, or decision-bearing proposal for contradictions, ambiguity, hidden decisions, unsupported claims, missing boundaries or failure behavior, and wording loopholes before implementation or adoption. Work read-only and retu

• technical-growth-coaching

  Help an engineer, technical lead, or team improve judgment by diagnosing the learning gap, adapting explanation or practice, and using feedback to test transfer. Use for technical misconceptions, mentorship, onboarding, stretch assignments, or stalled expertise. Keep bounded explanations compact; ex

• technical-program-orchestration

  Orchestrate one accepted technical outcome across concurrent or interdependent workstreams, vertical increments, integration, evidence, replanning, and closure. Use only when distinct drivers need shared steering across dependencies, integration points, decisions, or constraints. Do not use for gene

• technical-writing

  Write or revise task-fit technical documentation and evidence-grounded articles from supplied sources, code, and observed behavior. Use for tutorials, how-to guides, durable explanations, reference, runbooks, procedures, technical blogs, AI-slop audits, or humanizing and voice-preserving edits. Rout

Similar plugins