Ejecuta cualquier Skill en Manus
con un clic

Ejecuta cualquier Skill en Manus con un clic

to-issues

Estrellas3

Forks0

Actualizado10 de junio de 2026 a las 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.

Instalación

Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.

Ejecutar en Manus

Fuente

The-Koi-Pond

The-Koi-Pond/De-Koi

Abrir repositorio de GitHub Ver repositorios del creador

Descarga

Ejecutar en Manus

Ocupaciones relacionadasSOC

Basado en la clasificación ocupacional SOC

Especialistas en gestión de proyectosOperaciones empresariales y financieras·SOC 13-1082

Explorador de archivos

2 archivos

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.

Más de este repositorio

mismo repositorio

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.