Jeden Skill in Manus ausführen
mit einem Klick

Jeden Skill in Manus mit einem Klick ausführen

coding-process

Sterne28

Forks2

Aktualisiert30. April 2026 um 12:54

Entry point for all work. Identifies your task type and routes to the right workflow skill. Start here when beginning any task.

Installation

Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.

In Manus ausführen

Quelle

hawkyre

hawkyre/hawk-skills

GitHub-Repository öffnen Creator-Repositorys ansehen

Download

In Manus ausführen

Verwandte BerufeSOC

Basierend auf der SOC-Berufsklassifikation

SoftwareentwicklerInformatik- und Mathematikberufe·SOC 15-1252

SKILL.md

readonly

name	coding-process
description	Entry point for all work. Identifies your task type and routes to the right workflow skill. Start here when beginning any task.

Coding Process

This is the entry point for all work. It identifies the task type and routes to the appropriate workflow.

Process

Load context:
- Read relevant standards from .agents/standards/ (check index.yml first)
- Read relevant common-mistakes from .agents/common-mistakes/ (check index.yml first)
- Check .plans/ for any existing plan files related to the current work

Identify the task type from the user's description:

Task Type	Route To	Trigger
Small feature / endpoint / component / config	`/plan-small`	Self-contained, fits in one PR
Large feature / multi-system / architectural	`/plan-large`	Multi-day, multiple PRs, sequencing dependencies
Delete feature / remove dead code / drop dependency	`/remove-code`	Removing capability
Bug fix / error / crash / wrong behavior	`/fix-bug`	Something is broken
Code review / audit / PR review	`/code-audit`	Reviewing code quality
Aggressive cleanup of changes + tangibly-related code	`/code-audit-hardcore`	Same scope as code-audit, always-improve posture across related code (setup, wiring, siblings); big refactors route through plan skills
Large PR review (30+ files)	`/review-large-pr`	PR too large for single audit
Refactor / improve without behavior change	`/refactor`	Improving existing code
Understand / explore / onboard	`/learn-system`	Building mental models

Route to the appropriate skill and follow its process.

Rules

Always load standards and common-mistakes before starting any workflow
If the task type is ambiguous, ask the user to clarify
review-plan (Workflow 8) and implement-plan (Workflow 9) are invoked directly when needed — they are not routed from here
If a plan file exists in .plans/, reference it and resume from where the last session left off
Big-output discipline. Heavy command output (project check, full git diff, repo-wide search, long log, large fetch) goes to /tmp/hawk-<skill>-<step>.log, then rg -n '<pattern>' /tmp/hawk-<skill>-<step>.log | head -50 extracts what you need. Read the file only with offset/limit. See README → Big-output discipline.

Mehr aus diesem Repository

gleiches Repository

plan-large

hawkyre/hawk-skills

Plan a multi-PR feature, migration, or architectural change before writing code. Writes a `.plans/<slug>/` directory of HTML documents (with inline UI mockups and a review-tracking layer) — a 1-page `overview.html` for human review, a mandatory `data-model.html` that locks the schema before anything else, a terse `plan.html` of dependency-ordered increments, an ADR-style `decisions.html`, and a `verification.html` acceptance script. Use whenever the user says "plan this feature", "scope out the migration", "/plan-large", "architect this rollout", "I need a plan covering schema and API", "design this across multiple PRs", or "break this work up". Also use whenever the work touches a database migration, even if it's only two PRs — schema-first is the gate. Runs a blind self-review subagent before presenting. Do NOT use for single-PR changes — bail to `plan-small` at Step 0. Do NOT use to start implementing — that's `/implement-plan` after the plan is approved.

2026-06-2828

plan-small

hawkyre/hawk-skills

Plan a single-PR change end-to-end before writing code. Writes a terse `.plans/<slug>/plan.html` (HTML, with inline UI mockups where a screen changes, rendered through the shared design system) covering files to touch, data-model changes, edge cases, verification, and decisions/assumptions sourced to code or user. Use whenever the user says "plan this", "scope this out", "write up a plan for X", "/plan-small", "let's plan the new flag", or "plan before we start". Also use whenever the user describes a small feature without explicitly asking to plan — propose a plan before coding. Asks only what code can't answer (in-repo PRDs count), surfaces planned assumptions alongside questions, then runs a blind self-review subagent before presenting. Do NOT use for multi-PR work, schema migrations beyond adding a nullable column, or sequenced increments — bail to `plan-large` at Step 0. Do NOT use to start implementing — that's `/implement-plan` after the plan is approved.

2026-06-2828

code-audit-hardcore

hawkyre/hawk-skills

Aggressive cleanup audit scoped to the user's specified changes plus tangibly-relevant surrounding code. Same blind audit-* specialists as code-audit, with a maximum-improvement posture — any code in the expanded review scope that can be cleaner WILL be made cleaner. Small fixes applied inline; big fixes (>5 files, schema, public API, redesigns) routed through `/plan-small` or `/plan-large`. Plan-overrides — when the audit reveals the original plan was wrong — route through `/plan-large` by default. Always improve over preserve.

2026-06-2828

implement-plan-audited

hawkyre/hawk-skills

Execute a plan increment-by-increment with the audit-* specialists running independently at strategic checkpoints. Use whenever the user says "implement the plan with audits", "audited implementation", "run with audits", "implement with cleanup checkpoints", "audit as you go", or invokes /implement-plan-audited. Inherits the full per-increment verification loop from `implement-plan` (done-criteria evidence, layered retry ladder, file-divergence check, outcome records) and adds checkpoint annotation, blind parallel audits, audit-fix verification (each FIX closes its own loop), plan-override propagation, and BEHAVIOR_CHANGE.md artifacts. Two modes — `manual` stops between increments for user review; `auto` applies audit fixes and proceeds without interruption, designed for hours of unattended execution. Specialists are blind to the plan and the goal. Do NOT use for unaudited plan execution — use `implement-plan`. Do NOT use for one-shot audits of existing code — use `code-audit`. Do NOT use for planning or repl

2026-06-2828

implement-plan

hawkyre/hawk-skills

Execute an approved plan increment-by-increment with deterministic verification at each step. Use whenever the user says "implement the plan", "run the plan", "execute the plan", "work through the increments", "do the plan", or invokes /implement-plan. Done-criteria are checked against evidence on disk, not asserted from memory; failures escalate through a layered ladder rather than repeated identical attempts; existing code gets behavior-preservation tests before modification; file divergence (touched vs declared) is reconciled before each commit; structured outcome records land in the plan file. Designed for fresh sessions with no prior context. Do NOT use for planning itself — use `plan-small` or `plan-large`. Do NOT use for unplanned coding without a plan file — use `coding-process`. Do NOT use when the user wants audits in the loop — use `implement-plan-audited`.

2026-06-2828

review-plan

hawkyre/hawk-skills

Stress-test a plan file before committing to implementation. Catches architectural mistakes, convention violations, and missing dependencies while changes are still cheap. Invoked directly, not routed from coding-process.

2026-06-2828

Coding Process

This is the entry point for all work. It identifies the task type and routes to the appropriate workflow.

Process

Load context:

Read relevant standards from .agents/standards/ (check index.yml first)
Read relevant common-mistakes from .agents/common-mistakes/ (check index.yml first)
Check .plans/ for any existing plan files related to the current work

Identify the task type from the user's description:

Task Type	Route To	Trigger
Small feature / endpoint / component / config	`/plan-small`	Self-contained, fits in one PR
Large feature / multi-system / architectural	`/plan-large`	Multi-day, multiple PRs, sequencing dependencies
Delete feature / remove dead code / drop dependency	`/remove-code`	Removing capability
Bug fix / error / crash / wrong behavior	`/fix-bug`	Something is broken
Code review / audit / PR review	`/code-audit`	Reviewing code quality
Aggressive cleanup of changes + tangibly-related code	`/code-audit-hardcore`	Same scope as code-audit, always-improve posture across related code (setup, wiring, siblings); big refactors route through plan skills
Large PR review (30+ files)	`/review-large-pr`	PR too large for single audit
Refactor / improve without behavior change	`/refactor`	Improving existing code
Understand / explore / onboard	`/learn-system`	Building mental models

Route to the appropriate skill and follow its process.

Rules

Always load standards and common-mistakes before starting any workflow

If the task type is ambiguous, ask the user to clarify

review-plan (Workflow 8) and implement-plan (Workflow 9) are invoked directly when needed — they are not routed from here

If a plan file exists in .plans/, reference it and resume from where the last session left off

Big-output discipline. Heavy command output (project check, full git diff, repo-wide search, long log, large fetch) goes to /tmp/hawk-<skill>-<step>.log, then rg -n '<pattern>' /tmp/hawk-<skill>-<step>.log | head -50 extracts what you need. Read the file only with offset/limit. See README → Big-output discipline.