ly87ing
- 7 skills
- 0 followers
- 3 hours ago last updated
- ▌ Verification · ly87ing bundleProve that a change, fix, deployment, or config edit actually works before calling it done, and decide what counts as evidence for each claim. Use when asked to verify, validate, confirm, smoke-test, or accept a change in a local, test, staging, or deployed environment; to check that a push, deploy, or applied config took effect; to compare behavior before and after a change; to prove a fix in the environment a bug names; to judge whether tests, logs, a screenshot, or a worker's report count as evidence; and for browser evidence — driving Playwright or DevTools, authenticated flows, responsive layouts, interactive HTML, dashboards, decks, fixed-frame overflow, full-screen projection, media inside overlays, a blank or error render being read as a result, a lost authenticated session, or animation timing making a capture false evidence. Not for writing or tidying Playwright test code alone with no evidence to capture, and not for deciding what to change.
- ▌ Artifact Hygiene · ly87ing bundleDecide safe locations, redaction, and cleanup rules for generated files, debug output, Playwright traces/screenshots/videos, downloads, temporary scripts, backup or timestamped copies of tracked files, reports, storage state, JSON/HTML dumps, workflow-consumed outputs, and deliverables the user asked to produce. Also covers keeping plaintext secrets and credentials out of printed command output and logs — and restoring a low-privilege credential after a temporary elevation. Use before creating or keeping such artifacts, when packaging a deliverable for handover to another person or machine, or when a requested file has no obvious home — to avoid a polluted repository, an accidental commit, personal data baked into a screenshot or recording, or a stranded deliverable. Also covers repository weight from committed binaries and media, and destructive git history rewriting.
- ▌ Solution Shaping · ly87ing bundleShape a solution before anything is built or edited — an architecture or migration scheme, a service split, merge, or retirement, an upgrade plan, a fix approach with several candidates, or a comparison of approaches. Use when asked to analyse how something should be changed, to think from zero about the right design, to compare options and say which to follow, to judge whether a scheme is complete or has gaps, or to turn a many-constraint discussion into one plan. Collects every constraint first, inventories live versus dead capabilities, names the deployment model each argument assumes, walks a blast-radius checklist, grades claims as observed, inferred, or unverified, and briefs the implementer. Not for editing the code once the scheme is agreed, nor for proving a built change works.
- ▌ Change Discipline · ly87ing bundleApplies to every edit of something that already exists, however small — an in-place bug fix, a refactor, a config or default value, a schema, a test expectation, a contract. Establish why the current behavior exists before changing it, treat a symptom or a reported root cause as a lead, not a spec, check callers and blast radius, and choose how wide a bug fix should be. Also when removing a resource, path, or symbol, when applying fixes from a review round, before a command touching login state, auth files, network egress, or a process the user is running, when an empty search or clean git status may be an ignore-rule illusion, for read-only subagent audits, when a finding would reverse the user's own call, for unexplained working-tree changes, for a file synced across repos, and for an edit's boundary or style dimension — dependency direction, public interfaces, config migrations, splitting a module that mixes responsibilities, idempotent re-runs, new abstractions, naming, input validation, comments.
- ▌ Safe Merge Review · ly87ing bundleUse when the user wants to merge a branch, a remote ref, or the corresponding branches across a set of related repos into the current working branch, or wants to review whether "is this branch ready to merge", "this merge is correct", "anything was missed", "the conflict resolution is reliable", or "it is safe to push after the merge". Applies when the user provides a branch name, remote ref, repo path, conflicted files, a merge commit, a merge request link, or a multi-repo set of branches; also when confirming a fix is really present on a parallel release line that commit-id or is-ancestor searches report as missing, and when a merge decision turns on another repo's dependency not yet on the tracked ref. Proves the merge is correct, not merely that git merge ran. Not for branch code-quality review while no merge, audit, or conflict is in play.
- ▌ Reader Facing Writing · ly87ing bundleWrite or revise reader-facing documents, plans, reports, proposals, specs, checklists, Markdown, HTML decks, dashboards, decision briefs, and agent-facing instruction files (AGENTS.md, CLAUDE.md) — and decide what each page or slide says and in what form, whether that is prose, a diagram, a screenshot, a before/after comparison, or a long screen recording trimmed and sped up into demo material an audience can actually follow. Use when content is meant for humans or agents to read, decide from, act on, review, or reuse, including compacting source material without losing its framework, when a broad rewrite is asked for with no target tone, structure, or ordering given and the target has to be agreed before executing, when a change has to land across mirrored artifacts such as a script and its rendered deck, and when turning raw captures into material that carries a point to an audience. A one-pager or dashboard counts when its job is to carry a conclusion to a named audience, charts included.
- ▌ Technical Diagramming · ly87ing bundleCreate and verify architecture, workflow, sequence, data-flow, lifecycle, deployment, and topology-comparison diagrams. Use when authoring, comparing, or semantically validating the diagram itself; not for quantitative charts, browser-only UI checks, or broader document design.