J03Fr0st
- 21 skills
- 0 followers
- 6 hours ago last updated
- ▌ HTML Writeup · j03fr0st bundleCreate and verify one standalone HTML report for a decision, comparison, audit, architecture explanation, plan, incident review, or research brief. Use when the deliverable needs document hierarchy plus tables, diagrams, evidence, or light navigation. Route production websites and application interfaces to a frontend skill; answer Markdown or plain-text requests directly.
- ▌ Tdd · j03fr0st bundleDrive behavior changes through observable red, green, and refactor evidence. Use when the user asks for test-first development, TDD, red-green-refactor, a regression test before a fix, or when an implementation workflow needs a behavioral slice protected by an executable test. Route diagnosis of an unknown cause to diagnosing-bugs, broad completion proof to verification-before-completion, review-only work to code-review, and non-behavioral edits to proportionate artifact checks.
- ▌
- ▌
- ▌
- ▌ Writing For Agents · j03fr0st bundleWrite and revise documents that agents consume - skills, SKILL.md, AGENTS.md, CLAUDE.md, and reference files reached by a pointer. Use when creating, editing, reviewing, or splitting a skill, when writing or updating AGENTS.md or CLAUDE.md, when a skill triggers unreliably or gets ignored, when agent instructions are bloated or followed inconsistently, or when deciding what belongs in context versus behind a pointer. Do not use for human-facing prose, which belongs to writing-for-humans.
- ▌ Writing For Humans · j03fr0st bundleWrite and revise human-facing prose so it is clear, specific, natural, and faithful to the author's intent and genre. Use for emails, articles, reports, documentation, announcements, talks, and other prose when the user asks to draft, diagnose, edit, rewrite, make writing less formulaic or less AI-like, sound more natural or direct, or match a supplied voice. Do not use for agent instructions such as skills or AGENTS.md, code-only work, verbatim transcription, or translation without editorial changes.
- ▌ Research · j03fr0st bundleInvestigate technical questions against primary sources and record cited findings. Use for repository comparisons, documentation or API research, and decisions that need external evidence. Use last30days when recent community discussion matters; local bug diagnosis belongs to diagnosing-bugs.
- ▌ Simplify · j03fr0st bundleSimplify working code for clarity and maintainability while preserving observable behavior. Use for requested cleanup of recent changes or a named area, reducing unnecessary nesting, duplication, or indirection. Architecture decisions belong to codebase-design; unknown failures belong to diagnosing-bugs.
- ▌ Handoff · j03fr0st bundlePreserve resumable task state when work moves to another session, harness, directory, or person, or must survive a context reset. Use for pause, pickup, and portable handoff requests. Ordinary progress updates and final delivery summaries stay with the active workflow.
- ▌ Implement · j03fr0st bundleExecute authorized software changes from direct requests, issues, specifications, or plans. Use when asked to build, change, refactor, or fix known-cause behavior, or when selected Agile work enters delivery. Diagnosis, explicit test-first work, review-only work, planning-only work, and research have dedicated workflows.
- ▌ Prototype · j03fr0st bundleBuild a small experiment to answer a design or feasibility question through observation. Use for trying a state model, comparing an interaction, or measuring an uncertain approach. Established bug diagnosis belongs to diagnosing-bugs; production changes belong to implement.
- ▌ Grilling · j03fr0st bundleStress-test a consequential or ambiguous plan, decision, or idea through a live interview. Use when the user asks to be grilled, wants their thinking challenged, or material choices remain silently assumed. Do not use for clear mechanical work, information retrieval, or review of a completed artifact.
- ▌
- ▌ Code Review · j03fr0st bundleReview code changes read-only at quick, standard, or deep depth, with a bounded single-reviewer default and evidence-backed findings. Use when the user asks to review a branch, pull request, commit, working-tree changes, staged changes, a diff, or code before merge; asks for a quick or deep review; or wants to know whether a change matches its specification and repository rules. Route whole-codebase audits, product acceptance, dedicated security audits, and implementation-only requests to their own workflows.
- ▌
- ▌ Codebase Design · j03fr0st bundleDesign or improve software architecture through cohesive modules, intentional dependency direction, explicit inter-module contracts, and evidence-gated abstraction. Use when the user asks about module or service boundaries, interfaces, coupling or cohesion, DRY/KISS/YAGNI, duplication versus abstraction, over- or under-engineering, SOLID trade-offs, ports and adapters, layers or vertical slices, dependency cycles, synchronous or asynchronous communication, architecture refactoring, test seams and substitutes, reliability semantics at a boundary, or making a codebase easier for humans and coding agents to navigate. Route UI-only visual design and infrastructure topology with no software ownership decision to their dedicated skills.
- ▌ Diagnosing Bugs · j03fr0st bundleDiagnose bugs and performance regressions through reproduction, observations, competing hypotheses, and discriminating experiments before proposing a fix. Use when the user says diagnose, debug, investigate, find the root cause, explain a failure, or reports broken, throwing, failing, flaky, intermittent, or slow behavior whose cause is not established. Keep diagnosis read-only unless mutation is explicitly authorized; hand confirmed remediation to implement or tdd, and route review-only findings to code-review.
- ▌ Security Review · j03fr0st bundleReview security and privacy risks read-only when a dedicated audit, threat model, dependency-risk assessment, or independent security gate is requested or needed. Routine changed-code review belongs to code-review; authorized remediation belongs to implement.
- ▌ Planning And Task Breakdown · j03fr0st bundlePlan technical work when clear requirements span dependent changes, multiple sessions, or an uncertain implementation order. Use for implementation plans, vertical slices, and task dependencies. Cycle goals and capacity belong to agile-sprint-plan; a small clear change can go directly to implement.
- ▌ Verification Before Completion · j03fr0st bundleVerify completion claims with fresh, claim-specific evidence and honest terminal states. Use before saying work is done, fixed, passing, ready, deployed, or compliant; when asked to verify, prove, double-check, or show that something works; or when another implementation, TDD, debugging, review, documentation, configuration, visual, or external-state workflow needs a final evidence gate. Do not replace implementation, product acceptance, deployment authorization, or code review.