mit einem Klick
deployment-agent
deployment-agent enthält 18 gesammelte Skills von wwa-lab, mit Repository-Berufsabdeckung und Skill-Detailseiten auf SkillsMP.
Skills in diesem Repository
Use this skill when checking whether the global Agentic SDLC setup is healthy across Codex, shared agents, Claude Code, OpenCode, GitHub Copilot, project-local skills, OpenCode /sdd routing, ADR indexes, SDD profile, and sync script configuration.
Use this skill when a user wants the full predictable AI engineering workflow, especially propose/apply/verify/archive, OpenSpec-like change lifecycle, Superpowers-style execution rhythm, Agent Skills-style discipline, or an end-to-end Agentic SDLC flow across Codex, Claude Code, OpenCode, or other IDE agents.
Generates a full design artifact set from a spec.md (primary source) and optional architecture.md (secondary source). Produces three outputs: architecture.md (system architecture), data-model.md (persistent/domain data model), and API_IMPLEMENTATION_GUIDE.md (API contract). Use this skill whenever a user provides a spec, architecture, or requirements document and asks for a design, detailed design, solution design, module design, or implementation design. Also trigger when the user says "convert architecture to design", "create design from architecture", "write a design document", "I need a design doc before we start coding", "break down this architecture for engineers", or "generate design artifacts". If the user uploads or pastes an architecture or spec document and wants to move toward implementation, this skill should always be used — even if they don't use the exact words "design document".
Use this skill when a task changes architecture, cross-project conventions, AI-agent working context, platform boundaries, integration rules, security posture, data ownership, or any decision that future maintainers and coding agents should remember. Also use when the user asks for context engineering, ADRs, decision records, durable project knowledge, or shared instructions for Codex, Claude Code, or OpenCode.
Use this skill when making Codex, Claude Code, OpenCode, GitHub Copilot, Gemini, or other coding agents share the same workflow skills. Creates or updates tool-specific instruction files, skill indexes, command shims, and global skill sync rules without duplicating workflow content.
Converts a detailed design document (design.md) into a structured implementation task breakdown (tasks.md) suitable for engineering execution, Jira decomposition, sprint planning, and handoff to coding agents. Use this skill whenever the user provides or references a design document and asks for implementation tasks, engineering breakdown, Jira tasks, sprint planning, delivery planning, or a work breakdown structure. Also trigger when the user says things like "convert this design into tasks", "break this down for engineering", "create an implementation plan from this design", "generate tasks from design", or "I want to hand this off to developers". Even if the user just uploads a design.md or pastes a design and says "what do I do next?" — use this skill.
Use this skill when preparing work for a coding agent, remote agent, automation, CI workflow, or tool handoff. Creates a pinned execution manifest so agents consume explicit context instead of guessing latest sources, branches, documents, constraints, outputs, and verification commands.
Use this skill when checking whether requirements, SDD documents, ADRs, code, tests, approvals, or deployment evidence are stale relative to their source references. Applies before implementation, review, approval, release, or when a user asks if docs/code/tests are up to date.
Reviews repository code changes against an intended design and implementation plan to evaluate whether the implementation is aligned with the source design, tasks, and architectural intent. Use this skill whenever the user wants to compare implemented code against a design.md or tasks.md, verify that a coding agent's output matches the planned solution, or perform a design-compliance review before a merge, test handoff, or next implementation phase. Also trigger when the user says things like "does the code match the design", "check implementation fidelity", "review code against the plan", "was the design followed", or "is the generated code aligned". Always use this skill when both a design artifact and code are in scope — even if the user doesn't use the word "skill" or "review".
Reviews engineering documents produced during the SDLC workflow and evaluates whether they are complete, coherent, traceable, and good enough to move to the next stage. Use this skill whenever the user asks to review a spec, architecture, design, tasks doc, or user story set — even if they phrase it as "check this", "is this good enough", "find the gaps", "review what I wrote", or "give me a go/no-go". Also trigger when a document is about to be handed off downstream and should be verified first. Applies to: user stories, spec.md, architecture.md, design.md, tasks.md, and any SDLC artifact that gates a transition between phases.
Use this skill when a project needs to define, choose, migrate, or review a Spec Driven Development profile. Applies when SDD should not be hard-coded to one Java-oriented document chain, when a repo needs project-specific document stages, review gates, traceability rules, skill routing, or cross-tool SDD conventions for Codex, Claude Code, OpenCode, or similar IDE agents.
Use this skill when starting a new feature slice, module, workspace, agent, product area, or SDLC capability that needs a complete Spec Driven Development document set before implementation. Creates or verifies the standard slice documents, traceability index, and minimum gates before coding.
Converts a structured engineering specification document (spec.md) into a high-level system architecture document (architecture.md) suitable for implementation planning, technical review, and downstream task breakdown. Use this skill whenever a user provides a spec.md or requirements document and asks for system architecture, technical design, architecture proposal, or solution outline. Also trigger when the user asks to "turn this spec into architecture", "generate an architecture doc", "create a technical design from this", "produce architecture from requirements", or when the input describes a workflow platform, DevOps platform, backend system, orchestration engine, or multi-stage application needing structured architecture. Even if the user just says "architect this" or "design this system", use this skill.
Converts one or more Agile user stories, Jira stories, or capability-domain stories into a structured engineering specification document (spec.md) suitable for architecture design, task breakdown, and implementation planning. Use this skill whenever a user provides user stories and asks to generate a spec, engineering requirements document, or feature specification. Also trigger when the user says "convert these stories to a spec", "write a spec from these stories", "consolidate these stories into a spec", "turn this into an engineering spec", or "I need a spec doc from my user stories". Trigger even if the user just pastes multiple user stories or Jira tickets without explicit instructions — generating a consolidated spec is almost certainly what they need. This skill is especially important for workflow platforms, DevOps systems, multi-stage features, or any scenario where multiple stories describe the same underlying platform.
Converts a structured implementation task breakdown (tasks.md) into working code changes, tests, and supporting artifacts directly in an already-populated repository. Use this skill whenever the user provides a tasks.md or similar task list and wants incremental feature work implemented in the current codebase — even if they phrase it as "start building this", "implement these tasks", "code from this plan", "turn this into working code", "execute this engineering plan", or "help me build this". Do not use this skill for new-project bootstrapping, empty-repo scaffolding, or migration/porting work; use `tasks-to-implementation` for those cases instead.
Produces working implementation code from a tasks.md (and optional design.md / architecture.md / spec.md) in one of three explicit modes — **greenfield** (new empty project, needs scaffolding), **brownfield** (existing populated project, needs feature additions that follow existing conventions), or **migration** (port/rewrite from a source stack or schema to a target). Use this skill whenever the user asks to "scaffold a new project from this plan", "bootstrap this repo", "port this service to X", "migrate this module to Y", "rewrite this in Z", or explicitly wants the implementation mode determined before coding. Prefer this skill over `tasks-to-code` when the project is empty, when a migration is involved, or when the user explicitly mentions new-project bootstrapping or porting. If the user only wants incremental feature work on an already-populated repo with no migration or scaffolding involved, `tasks-to-code` remains the default.
Reviews repository documentation against the actual codebase to detect stale docs, broken setup steps, invalid file or path references, unsupported architectural claims, API mismatches, and other documentation drift. Use this skill whenever the user asks whether README files, docs/, runbooks, onboarding guides, AGENTS.md, CLAUDE.md, or in-repo documentation is accurate, current, consistent with code, or free of errors. Also trigger when the user says things like "check docs against code", "is the README up to date", "find doc drift", "verify repository documentation", "文档和代码一致吗", "检查 repo 文档", or "有没有文档错误".
Transforms raw business, product, platform, or DevOps requirements into Jira-ready Agile user stories with clear acceptance criteria, assumptions, dependencies, and open questions. Use this skill whenever a user provides natural language requirements, feature ideas, meeting notes, solution descriptions, or asks to convert requirements into structured user stories. Also use it when the input may represent a larger feature or epic that needs to be split into multiple implementable stories. When the requirement describes a workflow platform or system with multiple lifecycle stages, prefer splitting stories by end-to-end capability domains such as template management, instance generation, configuration, execution, and monitoring, rather than by isolated UI actions only.