Run any Skill in Manus with one click

to-issues

Stars3

Forks0

UpdatedJune 10, 2026 at 07:28

Break De-Koi plans, PRDs, parity targets, or feature ideas into independently verifiable GitHub issues using vertical slices. Use when the user asks to create implementation tickets, split a plan into issues, prepare ready-for-implementation work, or turn a broad feature into issue-sized slices.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

The-Koi-Pond

The-Koi-Pond/De-Koi

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Project Management SpecialistsBusiness and Financial Operations Occupations·SOC 13-1082

File Explorer

2 files

SKILL.md

readonly

name	to-issues
description	Break De-Koi plans, PRDs, parity targets, or feature ideas into independently verifiable GitHub issues using vertical slices. Use when the user asks to create implementation tickets, split a plan into issues, prepare ready-for-implementation work, or turn a broad feature into issue-sized slices.

To Issues

Use this skill to turn a plan into small De-Koi issues. Draft first unless the user clearly authorized posting.

Load First

skills/de-koi-agent-workflow/references/workflows/issue-submission.md
.github/ISSUE_TEMPLATE/issue_report.md or .github/ISSUE_TEMPLATE/feature_request.md, matching the request
skills/de-koi-architecture-guard/SKILL.md when slices cross owners, shared APIs, Rust, storage, import/export, providers, or runtime boundaries

Process

Gather the source plan, issue, PRD, screenshot facts, or parity row.
Inspect enough code to understand current owners and existing coverage.
Split into vertical slices, not layer-only tasks.
Mark each slice as Ready or Needs decision.
Show the breakdown and ask for approval before creating issues unless posting was already authorized.
Publish with gh issue create only after approval, using live templates and labels.

Vertical Slice Rules

Each slice should:

deliver one demoable or verifiable behavior
cross necessary layers end to end, such as UI, shared API, engine, Rust, storage, and proof
have a clear owner and proof target
avoid broad cleanup mixed with behavior
be small enough for one focused implementation pass

Prefer several thin slices over one large mixed issue. Keep dependency order explicit.

Issue Draft Shape

## Parent

<source issue or plan, if any>

## What to build

<end-to-end behavior, not a layer-by-layer task list>

## Acceptance criteria

- [ ] <observable criterion>
- [ ] <proof or validation criterion>

## Blocked by

<issue link or "None">

Avoid stale file-path inventories in public issue bodies. Name stable owners and contracts instead. Do not add AI/tool self-attribution or disclaimers.

More from this repository

same repository

de-koi-agent-workflow

The-Koi-Pond/De-Koi

Apply De-Koi's repo-local version of the Chai agent workflow pack for proof discipline, investigations, feature sizing, refactor handoffs, reviews, PR readiness, reviewer feedback iteration, issue drafting, UI/UX proof, security-sensitive checks, risky-work evidence, debt notes, and final status reports. Use for nontrivial coding work, ambiguous symptoms, refactors, reviews, PR/issue workflows, or any task where an agent must prove claims while preserving De-Koi's code separation and module ownership rules.

2026-06-123

de-koi-architecture-guard

The-Koi-Pond/De-Koi

Protect De-Koi's layered Tauri and hostable Rust runtime architecture, module ownership, dependency direction, explicit imports, Rust capability boundaries, shared-code placement, HTTP pipeline, and file-splitting discipline. Use when changing folders, imports, shared modules, TypeScript engine layers, Tauri/HTTP command wrappers, Rust capability crates, repositories, adapters, feature APIs, or any code structure that could widen impact area.

2026-06-113

de-koi-bugfix-discipline

The-Koi-Pond/De-Koi

Guide De-Koi bug fixes through feedback-loop-first diagnosis and root-cause repair with clear impact areas, focused validation, and no band-aid patches. Use for regressions, broken UI actions, failing checks, provider/transport bugs, storage bugs, import/export bugs, generation bugs, mode behavior bugs, performance regressions, or any change where the fix could affect dependent modules.

2026-06-103

grill-with-docs

The-Koi-Pond/De-Koi

Stress-test De-Koi plans against the current repo, product docs, architecture rules, and durable guidance, then capture only reusable decisions. Use when the user wants to be grilled on a design, sharpen fuzzy requirements, validate terminology, or update docs while a plan is clarified.

2026-06-103

improve-codebase-architecture

The-Koi-Pond/De-Koi

Find De-Koi architecture deepening opportunities that improve locality, leverage, testability, and agent navigation without violating repo boundaries. Use when the user asks to improve architecture, reduce shallow modules, plan refactors, make code more testable, or inspect module/interface design.

2026-06-103

prototype

The-Koi-Pond/De-Koi

Build throwaway De-Koi prototypes to answer logic, state-model, API-shape, or UI-layout questions before production implementation. Use when the user asks to prototype, mock up, sanity-check a state model, try UI variants, or let them play with a design.

2026-06-103

name	to-issues
description	Break De-Koi plans, PRDs, parity targets, or feature ideas into independently verifiable GitHub issues using vertical slices. Use when the user asks to create implementation tickets, split a plan into issues, prepare ready-for-implementation work, or turn a broad feature into issue-sized slices.

To Issues

Use this skill to turn a plan into small De-Koi issues. Draft first unless the user clearly authorized posting.

Load First

skills/de-koi-agent-workflow/references/workflows/issue-submission.md
.github/ISSUE_TEMPLATE/issue_report.md or .github/ISSUE_TEMPLATE/feature_request.md, matching the request
skills/de-koi-architecture-guard/SKILL.md when slices cross owners, shared APIs, Rust, storage, import/export, providers, or runtime boundaries

Process

Gather the source plan, issue, PRD, screenshot facts, or parity row.
Inspect enough code to understand current owners and existing coverage.
Split into vertical slices, not layer-only tasks.
Mark each slice as Ready or Needs decision.
Show the breakdown and ask for approval before creating issues unless posting was already authorized.
Publish with gh issue create only after approval, using live templates and labels.

Vertical Slice Rules

Each slice should:

deliver one demoable or verifiable behavior
cross necessary layers end to end, such as UI, shared API, engine, Rust, storage, and proof
have a clear owner and proof target
avoid broad cleanup mixed with behavior
be small enough for one focused implementation pass

Prefer several thin slices over one large mixed issue. Keep dependency order explicit.

Issue Draft Shape

## Parent

<source issue or plan, if any>

## What to build

<end-to-end behavior, not a layer-by-layer task list>

## Acceptance criteria

- [ ] <observable criterion>
- [ ] <proof or validation criterion>

## Blocked by

<issue link or "None">

Avoid stale file-path inventories in public issue bodies. Name stable owners and contracts instead. Do not add AI/tool self-attribution or disclaimers.