koruworks
13 skills with substantive source documentation and an official publisher or observed installation demand. Read each skill’s original documentation through its card.
koruworksbuild-feature
Build a single large feature end to end — you settle the product shape, then plan it, then code it. Use when the user asks to implement a new feature or invokes /build-feature . Settles what a person can now do that they could not before and the ladder of use cases smallest to largest, writes docs/ /PLAN.rev1.md derived from it, takes it through review to PLAN.final.md, then executes it in small, verifiable increments grounded in the project's principles.
- instalacje
- 1
- GitHub Stars
- 0
- Aktualizacja
- 14 paź
koruworksclose-plan
Close out a finished .final.md — fold what landed into the docs that already exist, carry what is still owed into -V2.rev1.md, and delete the planning artifacts the tree no longer needs. Use when the user invokes /close-plan , or asks to clean up or retire a small feature's docs after execute-plan or build-feature has finished. Reviews ACCEPTANCE.md check by check before calling anything landed, then triages every phase as landed, pending, deferred or dropped. The smaller sibling of close-roadma
- instalacje
- 1
- GitHub Stars
- 0
- Aktualizacja
- 14 paź
koruworksclose-roadmap
Close out a finished roadmap or feature execution by retiring its planning docs into canonical documentation and carrying what is still owed into the next roadmap — you are the archivist and the architect of the next round, not the coder. Use when the user invokes /close-roadmap , or asks to clean up a feature's docs, retire a roadmap, prepare for the next roadmap, or tidy docs/ / after execute-roadmap or build-feature has finished. Reviews ACCEPTANCE.md check by check, triages every item of ROA
- instalacje
- 1
- GitHub Stars
- 0
- Aktualizacja
- 13 paź
koruworkscommit-changes
Write a high-level commit summary of the current work — what changed and why the decisions were taken — show it for approval, then commit on approval without pushing. Use when the user asks to summarise, write up, or commit a batch of work, or says "commit this" / "write a commit message". Its length is proportional to the change — a one-line fix gets a sentence or two, a multi-file batch gets the full sectioned body. The summary is also read downstream by people and LLMs generating changelogs,
- instalacje
- 1
- GitHub Stars
- 0
- Aktualizacja
- 14 paź
koruworksdraft-experience
Shape a feature as a product before anyone plans how to build it — the sentence, the ladder of use cases smallest to largest, what stays hidden, and the open product questions. Use when the user invokes /draft-experience , asks what a feature should be, asks whether something is simple enough, or wants the experience document that a technical design, roadmap or plan is then written from. Also use to check an existing feature, bug or proposal against the product shape it claims to serve. Writes d
- instalacje
- 1
- GitHub Stars
- 0
- Aktualizacja
- 13 paź
koruworksdraft-technical
Design how a feature is built as an engineering conversation with the user before any plan document exists — discover the architecture together, find what the codebase already has to build on, challenge complexity, record every decision with its reason, and write docs/ /TECHNICAL.rev1.md only when the user says the design is ready. Use when the user invokes /draft-technical , or asks to design, architect, or think through how to build a feature, subsystem, integration, migration or infrastructur
- instalacje
- 1
- GitHub Stars
- 0
- Aktualizacja
- 13 paź
koruworksexecute-plan
Execute a signed-off PLAN.final.md for a single feature yourself, phase by phase, on the current branch — you are the engineer, not a delivery lead. Use when the user invokes /execute-plan, or asks to implement, build or continue an approved plan that is small enough for one person, e.g. "/execute-plan spell-check", "/execute-plan spell-check p1-p3", "build the rest of the plan while I sleep". Resolves the requested phases against the final doc, builds each as its own verified increment, runs it
- instalacje
- 1
- GitHub Stars
- 0
- Aktualizacja
- 13 paź
koruworksexecute-roadmap
Execute an approved roadmap or plan by orchestrating sub-agents — in parallel, in isolated checkouts, where the runtime allows — you are the delivery lead, not the coder. Use when the user invokes /execute-roadmap, or asks to implement, execute, or oversee an approved roadmap or plan after draft-roadmap or build-feature has produced a signed-off final doc, e.g. "/execute-roadmap implement m2, plans 3.1-3.4, parallelize" or "oversee the roadmap until it is complete". Resolves the requested scope
- instalacje
- 1
- GitHub Stars
- 0
- Aktualizacja
- 13 paź
koruworksmerge-branch
Merge changes from another branch while reviewing them against the project's principles — a merge is a review gate, not a mechanical operation. Use when the user asks to merge a branch, bring changes in from another branch, or resolve a merge. Flags unclear intent, unnecessary complexity and likely bug sources before merging, asks the user about any product decision a conflict would settle, and recommends merging the main integration branch into the other branch first when that is the easier dir
- instalacje
- 1
- GitHub Stars
- 0
- Aktualizacja
- 13 paź
koruworksresume-handoff
Pick up unfinished work from docs/ /HANDOFF.md in a fresh session — you are the agent the handoff was written for, and you verify it against the tree before you trust it. Use when the user invokes /resume-handoff , points at a HANDOFF.md, or asks to continue, resume, or pick up where the last session stopped on a plan or roadmap built by execute-plan, execute-roadmap or build-feature, e.g. "/resume-handoff cloud-sync", "/resume-handoff spell-check p4", "pick up the handoff and keep going while I
- instalacje
- 1
- GitHub Stars
- 0
- Aktualizacja
- 13 paź
koruworksreview-doc
Review an experience, technical, plan, roadmap, or implementation doc from draft-experience, draft-technical, build-feature or draft-roadmap — you are the reviewer, not the author. Use when the user asks to review a plan, roadmap, design or experience document, or invokes /review-doc . Reads docs/ / .revN.md, writes .revN.notes.md grounded in the product shape, the project's principles and the actual code, and iterates with the user until the doc is ready to become .final.md.
- instalacje
- 1
- GitHub Stars
- 0
- Aktualizacja
- 13 paź
koruworksreview-doc-loop
Run the reviewer's half of the document review loop without the user relaying each round — review the current .revN.md into .revN.notes.md, commit the closed round, wait for the author's rev(N+1), and repeat until the document is ready for final, a round cap is hit, or only the user can move it forward. Use after rev1 exists, when the user invokes /review-doc-loop [max-rounds] in a fresh session that did not write the document. Its counterpart is answer-notes-loop in the author's session.
- instalacje
- 1
- GitHub Stars
- 0
- Aktualizacja
- 14 paź
koruworkswrite-acceptance
Write docs/ /ACCEPTANCE.md — the ordered checklist a person works through by hand to deploy, test and accept finished work, because a machine could not do it. Use at the end of every implementing skill (execute-plan, execute-roadmap, build-feature), or when the user invokes /write-acceptance or asks for a test plan, an acceptance checklist, or "tell me how to verify this". Covers only what could not be automated — consoles and accounts, physical devices, GUI surfaces, two-machine and multi-user
- instalacje
- 1
- GitHub Stars
- 0
- Aktualizacja
- 13 paź