Develoop

View saved version →

---
name: cleanup-slops
description: Find and simplify implicit state machines across a repository or a specified pull request without regressing behavior. Use for requests such as "find all of the implicit state machines in my app" or a cleanup pass that removes redundant state and consolidates scattered transitions for readability and maintenance.
license: MIT
---

# Cleanup Slops

Start from this prompt:

> find all of the implicit state machines in my app

Use it as a discovery lens for a behavior-preserving cleanup. Find lifecycle
rules hidden across mutable flags, nullable values, effects, callbacks, and
duplicated status fields. Remove unnecessary stored state and scattered
coordination; make essential transitions easier to understand and maintain.

An implicit state machine exists when the meaning or legality of an operation
depends on prior events and combinations of state, while its transitions and
invariants are distributed across the code. Multiple booleans alone are not
evidence: independent settings may legitimately vary independently.

## Establish the boundary

- For a repository-wide request, map application entry points and runtime
  modules, then track which areas were inspected. Start with first-party code;
  exclude generated, vendored, and build output unless they own relevant
  behavior. Do not claim exhaustive discovery from a few keyword searches.
- For a specified PR, resolve the target repository, base, and head. Inspect the
  merge-base-to-head diff and the full enclosing implementations, callers,
  consumers, and tests needed to understand it. Address machines introduced,
  modified, or relied on by that implementation; record unrelated discoveries
  without expanding the patch. Keep findings tied to the inspected head.
- Honor explicit inspection-only or planning requests. When cleanup is
  requested, carry supported fixes through implementation and validation.
  Local cleanup does not itself authorize remote comments, push, merge,
  deployment, or changes to external data.
- Read repository guidance and preserve unrelated working changes. For a new
  cleanup branch, use the existing checkout unless isolation is required or
  requested. Keep an existing PR's branch context when working on that PR.

## Discover and reconstruct

Trace behavior from entry points and state owners, using searches only as
leads. Inspect loading and error flags, selected IDs plus cached objects,
status enums, mirrored props or store values, subscription and connection
lifecycles, pending promises, timers, retries, queues, persistence, and cleanup
handlers. Follow reads, writes, reset paths, and async completions across
module boundaries. Include server, worker, and client paths where present.

Keep a compact inventory for each candidate:

| Evidence | What to establish |
| --- | --- |
| Owner and locations | Who owns the state, who writes it, and who observes it |
| Effective states | Reachable combinations and combinations ruled out by code or contracts |
| Events and transitions | Entry, success, failure, cancellation, retry, reset, and disposal paths |
| Invariants and effects | What must remain true, including observable output and side effects |
| Decision | Derive or remove redundant state, consolidate essential transitions, preserve, or defer with a reason |

Distinguish demonstrated behavior from inferred intent. A suspicious combination
is a candidate until its producers, consumers, and reachable transitions are
understood. Prioritize redundant sources of truth, impossible combinations,
duplicated transition logic, and effects that synchronize state with other
state. Preserve independent axes such as cached data and an in-flight refresh.

## Establish regression evidence

Before editing a candidate, identify its observable contract and run the
relevant existing checks. Record baseline failures separately. Where coverage
does not establish that contract, add focused characterization tests at the
public behavior b

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 2 — file references are metadata, not package contents.

View saved version →

---
name: gh-autoreview-resolve
description: Run a bounded GitHub automated-review and resolution loop for a specified pull request. Use when an agent must mark a PR ready for review, confirm the automated reviewer started through an eyes reaction, wait for a thumbs-up or concrete review response, validate and address review threads, request a narrowly focused `@codex review` follow-up when warranted, prevent review scope creep through PR comments or a gh-create-issue follow-up, and optionally merge with the user's preferred strategy.
license: MIT
---

# GitHub Auto Review Resolve

Move one specified pull request from draft through a conservative automated-review loop. Keep the PR's original implementation goal authoritative; do not turn review follow-up into an open-ended audit.

## Adapt to the agent host

Read [references/agent-harnesses.md](references/agent-harnesses.md) before
choosing GitHub, waiting, or user-interaction tools. The `@codex review`
mention in this workflow addresses GitHub's configured Codex reviewer; it does
not require the agent executing this skill to be Codex. Do not post the mention
unless the repository actually uses that reviewer.

## Establish the contract

1. Read repository instructions, the linked issue, PR body, changed files, current head, checks, and existing review threads.
2. Record the original goal, acceptance criteria, explicit non-goals, requested review focus, whether merge is authorized, and the user's preferred merge strategy.
3. Verify `gh auth status`, the repository, PR number, local checkout, and unrelated working-tree changes before mutations.
4. Run `scripts/inspect_review_state.py <PR> --repo OWNER/REPO` for one normalized, fully paginated baseline. Treat its GraphQL `reviewThreads` result as the source of truth for unresolved work. The inspector first reads `gh api rate_limit`, preserves 200 GraphQL points plus a five-point next-query buffer by default, and reports every query's `cost`, `remaining`, `used`, and `reset_at` values.
5. Use only one active observer for an `OWNER/REPO#PR`. When waiting is required, give the loop to one `--watch` process and let other agents or tasks reuse its result instead of polling independently. The watcher enforces this on the same host with an advisory process lock in a user-private directory; it refuses symlinks or non-regular lock files and releases ownership automatically on process exit. Operators must preserve the same single-observer contract across hosts.

Do not merge unless the user explicitly requested it. If merge was requested but the strategy is neither stated nor reliably discoverable, ask rather than guess.

## Start review

1. If the PR is a draft, record the UTC time and full head OID immediately before the ready transition. Retain the OID so the ready-triggered review can be tied to unchanged code even though GitHub does not attach a `Review head:` marker to that implicit request.
2. Then run `gh pr ready <PR> --repo OWNER/REPO` and inspect with `--after <ISO_TIME>` using the recorded transition time so old bot activity is not mistaken for the new review. If the PR is already ready, do not repeat the transition; reuse its recorded trigger evidence when available, and never substitute a later observation time for the ready time.
3. Confirm review start from an `eyes` reaction on the PR or the active `@codex review...` comment. If feedback or a pass response arrives before eyes is sampled, accept that as a completed start race.
4. If no start signal appears after a reasonable bounded wait, confirm there is no active request, then post exactly one `@codex review` comment. Include the current full head OID on its own `Review head:` line so a later reaction can be tied to that exact code. Never post another request while eyes is present.
5. When the user supplied a review target, request it narrowly and keep the head marker:

   ```text
   @codex review
   Review head: `<full head OID>`

   Focus on <specific contract, regressi

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 3 — file references are metadata, not package contents.

View saved version →

---
name: gh-create-issue
description: Create high-quality GitHub issues or issue drafts from repository evidence, user intent, and external documentation. Use when the user asks an agent to create, draft, file, open, or prepare an implementation issue, bug report, feature request, follow-up issue, or GitHub issue with researched facts, scope, non-goals, suggested direction, acceptance criteria, and validation notes.
license: MIT
---

# GH Create Issue

Create implementation-ready issues that preserve what was learned during investigation. Treat the issue as an engineering handoff: concrete enough for a future implementer to start safely, scoped enough to avoid accidental broad rewrites, and honest about uncertainties.

Creating issues directly requires GitHub CLI or an equivalent authenticated
GitHub integration. Without write access, produce a complete issue draft
instead of claiming that an issue was created.

## Adapt to the agent host

Read [references/agent-harnesses.md](references/agent-harnesses.md) before
choosing tools or invocation syntax. Treat named commands as one implementation
of a capability: use the current host's connected GitHub integration when it
offers the same read or write operation, and fall back to `gh` when it does not.

## Workflow

1. Inspect issue style before writing.
   - If the target repository or sibling repository has recent issues, read the newest relevant issues first.
   - Mirror the useful level of detail, section shape, and tone without copying irrelevant structure.
   - If there are no existing issues, use the default template in `references/issue-structure.md`.

2. Research from primary evidence.
   - Inspect the current code, docs, tests, workflows, logs, or issue/PR history that define the problem.
   - For platform, API, protocol, or framework behavior, verify against primary sources when facts may be stale or subtle.
   - Record discovered facts in the issue body, not just in the conversation.

3. Separate facts from direction.
   - Use concrete references for observed current behavior.
   - Mark recommendations as suggested direction, not as already proven design.
   - Include assumptions and open questions when they affect implementation choices.

4. Define boundaries.
   - State the goal.
   - State scope and non-goals explicitly.
   - Preserve user-specified constraints and exact nouns.
   - Avoid turning a narrow follow-up into a broad redesign.

5. Write acceptance criteria that can be verified.
   - Prefer observable behavior, commands, CI jobs, manual smoke tests, screenshots, logs, or API responses.
   - Include regression checks for existing behavior.
   - Include platform-specific validation when the issue depends on platform behavior.

6. Create the issue only after reviewing the body.
   - If the user asked to create the issue, use the repository's issue tool or `gh issue create`.
   - If the target repo is ambiguous, resolve it from cwd/remotes before creating.
   - If creation is risky or the user asked for a draft, return the issue body instead.

## Reference Files

- Read `references/issue-structure.md` when drafting any issue body.
- Read `references/research-and-evidence.md` when deciding what investigation to perform or how to word discovered facts.
- Read `references/checklist.md` before creating or returning the final issue.
- Read `references/agent-harnesses.md` before choosing host-specific tools or invocation syntax.

## Style Rules

- Write GitHub issue titles and bodies in English, even when the user request or source discussion is in another language.
- Translate user-provided requirements, examples, and context into clear English for the issue body.
- Preserve exact non-English product names, UI labels, field values, error text, commands, and quoted strings when those literals are the implementation target or evidence.
- Prefer concise section prose over long bullet piles, but use bullets for facts and criteria.
- Use exact code symbols, routes, file 

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 5 — file references are metadata, not package contents.

View saved version →

---
name: gh-implement-issue
description: Implement GitHub issues through a complete branch-to-PR workflow. Use when the user asks an agent to implement, fix, or ship a specific GitHub issue, including reading issue comments, confirming the implementation contract, creating a branch, making atomic commits, validating, pushing, opening or updating a PR, and handling issue-linked review/CI follow-up. Use related skills or integrations when available; otherwise inspect the repository, issue, PR, CI, and review context directly with the available tools.
license: MIT
---

# GH Implement Issue

## Overview

Use this when the job is not just "make a patch", but "implement the GitHub issue and carry it to a validated PR-ready state". The output should be a branch/commit/PR state that matches the issue scope and a closeout that names validation and unresolved risk.

## Adapt to the agent host

Read [references/agent-harnesses.md](references/agent-harnesses.md) before
choosing GitHub, browser, delegation, or user-interaction tools. Use equivalent
capabilities exposed by the current host; command and tool names in this skill
are examples, not hard dependencies.

## Workflow

1. Establish context before editing.
   - Read repo `AGENTS.md` / local instructions.
   - Run `git status --short --branch` and protect unrelated dirty work.
   - Fetch the issue/PR/source-of-truth first: `gh issue view`, `gh pr view`, linked comments, upstream PRs, docs, or paired repositories.
   - If the issue touches separable surfaces and the current host plus repository instructions permit delegation, use subagents for independent discovery, such as backend contract vs frontend UI vs upstream library behavior. Otherwise perform the same discovery sequentially.

2. Confirm the implementation contract.
   - Restate the concrete behavior, non-goals, and expected output.
   - Check whether the issue number is actually an issue, PR, duplicate, stale branch, or follow-up.
   - When the target is a GitHub issue you will implement, assign yourself before branch planning or code edits: `gh issue edit <issue-number-or-url> --add-assignee "@me"` (or an equivalent GitHub API/UI action). Do not remove existing assignees. If assignment is impossible because the target is not an issue or permissions are missing, stop and report the blocker before implementation.
   - For cross-repo changes, inspect the upstream contract before patching the downstream repo.

3. Plan the branch and commit slices.
   - Create or switch to the requested feature branch before editing.
   - Keep commits aligned with real task boundaries: core behavior, UI, docs, release/version, review fix.
   - If branch scope grows beyond its name or PR text, rename or update the branch/PR instead of letting metadata drift.

4. Implement narrowly.
   - Follow local patterns and repo validation style.
   - Stage only requested files; leave unrelated worktree noise unstaged.
   - Add focused regression tests when behavior is testable.
   - For user-facing UI or runtime behavior, verify with a real browser, device, deployment, or output surface when feasible.

5. Validate in layers.
   - Run the smallest focused test first.
   - Then run the repo-expected checks for the touched surface, such as typecheck, lint, build, unit tests, dry-run deploy, or package metadata checks.
   - If a command cannot run because an environment dependency is missing, record the exact blocker and continue with the strongest available narrower proof.

6. Publish.
   - Push with upstream tracking once the local branch is coherent.
   - Create a draft PR for substantial or still-reviewing work unless the user asked otherwise.
   - Write PR titles and bodies in English. The PR body must be English even when the issue or conversation is in another language.
   - Translate the implemented issue requirements into clear English in the PR body, while preserving exact non-English UI labels, product names, error text, commands, and quoted literals

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 2 — file references are metadata, not package contents.

View saved version →

---
name: writing-strategy
description: Choose writing and narrative strategies from a curated bilingual strategy set, then produce a Markdown article outline or table of contents. Use when the user asks how to structure a draft, essay, article, post, proposal, column, case study, story, marketing copy, or other writing based on a topic, material, purpose, audience/readers, tone, or language. The skill selects a best-fit strategy, avoids overusing generic problem-solution frames, keeps Korean and English strategy names as canonical references, and displays strategy names in the user's output language unless bilingual names are explicitly requested.
license: CC-BY-NC-SA-4.0
---

# Writing Strategy

## Core Workflow

Use this skill to recommend how to structure a piece of writing, not to draft the full article unless the user asks for the full draft.

1. Infer the user's input language. Output strategy names, overview, rationale, and outline in that language. Use the exact Korean strategy name for Korean input and the exact English strategy name for English input. Keep both names in references for lookup stability, but do not show bilingual paired names unless the user explicitly asks.
2. Extract the writing situation: topic, source material, purpose, intended reader, desired tone, length, and any constraints. If key details are missing, make light assumptions and proceed; ask only when the strategy choice would be genuinely risky.
3. Load [references/index.md](references/index.md) for selection cues. Shortlist 4-6 plausible strategies across different narrative modes.
4. Apply the generic-frame guard before choosing: do not default to `Problem → Solution`, `Status → Problem → Solution`, `Problem → Analysis → Solution → Outcome`, `Introduction → Body → Conclusion`, `Goal → Obstacle → Solution`, or `Need → Solution → Satisfaction` unless the user's material clearly demands a direct fix, status report, diagnostic proposal, or standard essay.
5. Choose one best strategy and 2-3 alternatives. Read only the detailed reference files for the chosen strategy and the alternatives.
6. Produce a Markdown response with the recommended strategy, a short fit rationale, and a complete article outline or table of contents adapted to the user's topic. Then show the alternative strategies in the same output language and invite the user to choose one if they want the outline reframed.

## Output Shape

For Korean input, use this order:

```markdown
## 추천 글쓰기 전략
**정확한 한국어 전략명**

선택 이유: ...

## 글의 전체 구조
1. ...
2. ...

## 대안 전략
- **정확한 한국어 전략명**: ...
- **정확한 한국어 전략명**: ...
```

For English input, use this order:

```markdown
## Recommended Writing Strategy
**Exact English Strategy Name**

Why it fits: ...

## Article Outline
1. ...
2. ...

## Alternative Strategies
- **Exact English Strategy Name**: ...
- **Exact English Strategy Name**: ...
```

Keep the outline specific to the user's material. Do not return a generic template with placeholder-only headings. If the user provides several materials, weave them into the section headings or section notes.

## Strategy Names

The exact strategy names are:

- [핵심 3가지 포인트 강조 / 3 Key Points](references/3_key_points.md)
- [5 WHY 분석 / 5 Whys Analysis](references/5_whys_analysis.md)
- [유사 사례 → 비교 분석 → 시사점 / Analogy → Comparison → Takeaway](references/analogy_comparison_takeaway.md)
- [주목 → 관심 → 욕구 → 행동 / Attention → Interest → Desire → Action (AIDA)](references/attention_interest_desire_action_aida.md)
- [변화 전 → 변화 후 구조 / Before → After](references/before_after.md)
- [변화 전 → 변화 후 → 다음 과제 / Before → After → Next Challenge](references/before_after_next_challenge.md)
- [여정 기반 구조 / Before → Journey → After](references/before_journey_after.md)
- [사례 → 분석 → 시사점 / Case → Analysis → Implication](references/case_analysis_implication.md)
- [원인 → 결과 구조 / Cause → Effect](references/cause_effect.md)
- [도전 → 전략 → 성과 / Challenge → Strategy → Result](references/challenge_strategy_result.md)
- [인물 중심 이야기 / Character-Driven Sto

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 57 — file references are metadata, not package contents.