@olegkoval/agent-skills 1.55.1 → 1.55.3
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/.github/prompts/wrap-up.prompt.md +60 -67
- package/.kiro/steering/wrap-up.md +60 -67
- package/.windsurf/rules/wrap-up.md +60 -67
- package/README.md +2 -2
- package/adapters/claude/olko-reflection/skills/wrap-up/SKILL.md +63 -72
- package/adapters/cursor/olko-reflection/skills/wrap-up/SKILL.md +63 -72
- package/adapters/grok/olko-reflection/skills/wrap-up/SKILL.md +63 -72
- package/catalog/skills.json +1 -1
- package/package.json +1 -1
- package/plugins/olko-apple-kit/.claude-plugin/plugin.json +1 -1
- package/plugins/olko-creative/.claude-plugin/plugin.json +1 -1
- package/plugins/olko-garmin-kit/.claude-plugin/plugin.json +1 -1
- package/plugins/olko-git-tools/.claude-plugin/plugin.json +1 -1
- package/plugins/olko-github-pr/.claude-plugin/plugin.json +1 -1
- package/plugins/olko-obsidian/.claude-plugin/plugin.json +1 -1
- package/plugins/olko-product/.claude-plugin/plugin.json +1 -1
- package/plugins/olko-reflection/.claude-plugin/plugin.json +1 -1
- package/plugins/olko-reflection/skills/wrap-up/SKILL.md +63 -72
- package/plugins/olko-release/.claude-plugin/plugin.json +1 -1
- package/plugins/olko-skill-meta/.claude-plugin/plugin.json +1 -1
- package/plugins/olko-web-ops/.claude-plugin/plugin.json +1 -1
|
@@ -1,12 +1,10 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: wrap-up
|
|
3
3
|
description: >
|
|
4
|
-
Close out a
|
|
5
|
-
|
|
6
|
-
|
|
7
|
-
|
|
8
|
-
before handing work off. This is the single-change axis: for a retro over repository history use
|
|
9
|
-
retro-analysis, for how the agents are being operated use agent-ops-retro.
|
|
4
|
+
Close out a small change or multi-step task by checking its original objective, running applicable
|
|
5
|
+
quality gates, auditing the diff and task-owned artifacts, and preparing an evidence-backed handoff.
|
|
6
|
+
Use when work is believed done, the user asks to wrap up or clean up, or before handing work off.
|
|
7
|
+
For a retro over repository history use retro-analysis; for agent operations use agent-ops-retro.
|
|
10
8
|
license: MIT
|
|
11
9
|
compatibility: Codex, Claude Code, Cursor, GitHub Copilot, Windsurf, Kiro, Grok, and other Agent Skills compatible tools.
|
|
12
10
|
metadata:
|
|
@@ -22,91 +20,84 @@ metadata:
|
|
|
22
20
|
|
|
23
21
|
# Wrap Up
|
|
24
22
|
|
|
25
|
-
|
|
23
|
+
Use this as a proportional end-of-task audit. Preserve pre-existing work and do not expand the task to make the report look complete.
|
|
26
24
|
|
|
27
|
-
## 1.
|
|
25
|
+
## 1. Verify the objective
|
|
28
26
|
|
|
29
|
-
-
|
|
30
|
-
-
|
|
31
|
-
-
|
|
32
|
-
- Identify the exact repositories, worktrees, branches, files, services, and temporary paths owned by this task. Preserve pre-existing user work.
|
|
27
|
+
- Restate the original request, issue, or ticket and its acceptance criteria. Compare each criterion with the actual diff and evidence, not just the implementation plan.
|
|
28
|
+
- Mark each outcome `completed`, `partially completed`, `intentionally deferred`, or `blocked`; mark unverified facts `unknown`. Give the reason and next action for anything incomplete.
|
|
29
|
+
- Set overall status to `completed` only when every required criterion and check passes. If required evidence is missing or a check fails, report `partially completed` or `blocked` as appropriate. A deliberate deferral is complete only when it was outside the agreed acceptance criteria.
|
|
33
30
|
|
|
34
|
-
## 2.
|
|
31
|
+
## 2. Run applicable quality gates
|
|
35
32
|
|
|
36
|
-
-
|
|
37
|
-
-
|
|
38
|
-
-
|
|
39
|
-
-
|
|
40
|
-
- If a check fails, determine whether it is caused by this task. Do not call the task green because an unrelated check happened to pass.
|
|
41
|
-
- For user-facing behavior, require real browser/device or human evidence when that is part of acceptance; automated tests alone are not visual acceptance.
|
|
33
|
+
- Detect the project type and configured commands from local instructions, manifests, scripts, and CI before running anything. Choose checks proportional to the change, from focused checks to broader gates when warranted.
|
|
34
|
+
- Run configured, non-destructive formatter checks, lint, typecheck, unit and integration tests, build, and project-specific validation when applicable. Distinguish a formatter check from a formatter command that rewrites files; inspect side effects before running the latter.
|
|
35
|
+
- Record each command and `pass`, `fail`, `skipped`, or `not applicable` for each gate. Explain skips. Redact secrets and personal data from commands and failing output before quoting the smallest useful excerpt; never invent a result or claim success after a required failure.
|
|
36
|
+
- Inspect each required delivery gate at its authoritative source: local commit, remote SHA, PR state and review threads, current-head CI, deployed version or endpoint, and browser, device, or human acceptance. Mark unavailable evidence `unknown`; do not infer one gate from another.
|
|
42
37
|
|
|
43
|
-
## 3.
|
|
38
|
+
## 3. Audit the diff, hygiene, and context
|
|
44
39
|
|
|
45
|
-
|
|
40
|
+
- Inspect `git status`, staged and unstaged diffs, untracked files, recent branches, and `git worktree list`. Identify task-owned worktrees, scratch branches, generated files, debug files, and local-only configuration; leave uncertain or pre-existing work untouched.
|
|
41
|
+
- Scan introduced lines for `console.log`, `print`, `dbg!`, `debugger`, equivalent debug output, commented-out code, new TODO/FIXME/HACK markers, temporary flags, and unused imports, files, dependencies, or configuration. Flag legitimate diagnostic logging for review; do not remove it automatically.
|
|
42
|
+
- Check the diff and untracked files for keys, tokens, passwords, private keys, connection strings, cookies, personal data, and credentials in logs or examples. Report locations without printing values; recommend environment variables or a secret manager where relevant.
|
|
43
|
+
- Decide from the actual change whether README, architecture or API docs, OpenAPI, CHANGELOG, CONTRIBUTING, `.env.example`, ADRs, or runbooks need an update. Name the exact change needed. Skip documentation for trivial internal changes unless it helps future maintenance.
|
|
46
44
|
|
|
47
|
-
|
|
48
|
-
- Remote: tracking branch and remote SHA, verified with Git or the existing provider CLI.
|
|
49
|
-
- PR: current title/body, merge state, review threads, and required checks, when applicable.
|
|
50
|
-
- CI: current-head status, not an old successful run.
|
|
51
|
-
- Deployment: actual deployed version or endpoint health, when applicable.
|
|
52
|
-
- Device or human QA: real acceptance evidence, when applicable.
|
|
45
|
+
## 4. Prepare safe cleanup
|
|
53
46
|
|
|
54
|
-
|
|
47
|
+
- Propose cleanup commands only. Do not remove any file, branch, or worktree automatically, including generated or temporary files. Never propose deletion of an unknown untracked file, broad directory, or unresolved glob.
|
|
48
|
+
- Before proposing worktree or branch deletion, verify a clean worktree, ownership, no unpushed commits, and that the branch is not active in another worktree. Check `git branch --merged <default-branch>` and remote/merge state where relevant. An unmerged pushed branch may be the recovery point.
|
|
49
|
+
- For confirmed safe targets, propose `git worktree remove -- 'path with spaces'` or `git branch -d -- 'topic/branch'` with the actual argument shell-quoted, including embedded quotes. Use `--` to end options; never interpolate untrusted names as raw shell text. Use `git fetch --prune` only when network access and remote cleanup are appropriate. Force deletion requires explicit approval.
|
|
50
|
+
- Read-only inspection and configured non-destructive checks may run automatically. Ask before committing, pushing, creating or updating a PR, deleting any file, branch, or worktree, or modifying external systems. Existing explicit authorization for the task still applies.
|
|
55
51
|
|
|
56
|
-
##
|
|
52
|
+
## 5. Handoff
|
|
57
53
|
|
|
58
|
-
|
|
54
|
+
Use the report below, keeping it brief for a small change and adding detail only where evidence or risk warrants it. State what was executed and what still needs confirmation. If a PR is appropriate, draft its motivation, changes, testing evidence, rollout and rollback considerations, and reviewer notes; do not publish it without authorization. Suggest a conventional commit message without committing.
|
|
59
55
|
|
|
60
|
-
|
|
61
|
-
-
|
|
62
|
-
- For dirty paths that predate this task or cannot be attributed confidently, leave them in place and report them.
|
|
63
|
-
- Check the repository’s worktree list and remove only task-owned worktrees that are clean and no longer needed. Use an exact path; never remove a worktree containing uncommitted user work.
|
|
56
|
+
```markdown
|
|
57
|
+
### Wrap-up report
|
|
64
58
|
|
|
65
|
-
|
|
59
|
+
**Objective**
|
|
60
|
+
<original task and acceptance criteria, each marked completed / partially completed / intentionally deferred / blocked / unknown; use unknown when evidence is unavailable>
|
|
66
61
|
|
|
67
|
-
|
|
68
|
-
|
|
69
|
-
- If the remote branch is pushed but unmerged, treat it as the recovery point. Delete the local branch only when the task is delivered, the remote branch is confirmed intact, the worktree is clean, and the user’s workflow permits local deletion. Otherwise preserve it and report why.
|
|
70
|
-
- Never use force branch deletion or destructive checkout/reset commands unless the user explicitly requests that exact recovery operation.
|
|
71
|
-
- Before deleting a branch, verify it is not checked out by another worktree and that no unique local commits would be lost.
|
|
62
|
+
**Status**
|
|
63
|
+
`completed | partially completed | blocked`
|
|
72
64
|
|
|
73
|
-
|
|
65
|
+
**Changes**
|
|
66
|
+
- <file or area>: <what changed and why>
|
|
74
67
|
|
|
75
|
-
|
|
76
|
-
|
|
77
|
-
|
|
78
|
-
|
|
79
|
-
|
|
80
|
-
|
|
81
|
-
|
|
82
|
-
|
|
83
|
-
using `NOT_APPLICABLE` for out-of-scope gates and `NOT_RUN` for applicable
|
|
84
|
-
checks that were not executed:
|
|
68
|
+
**Checks**
|
|
69
|
+
| Check | Result | Notes |
|
|
70
|
+
|---|---|---|
|
|
71
|
+
| Formatter | pass/fail/skipped/not applicable | <command and evidence or reason> |
|
|
72
|
+
| Lint | pass/fail/skipped/not applicable | ... |
|
|
73
|
+
| Typecheck | pass/fail/skipped/not applicable | ... |
|
|
74
|
+
| Unit / integration tests | pass/fail/skipped/not applicable | ... |
|
|
75
|
+
| Build / project validation | pass/fail/skipped/not applicable | ... |
|
|
85
76
|
|
|
86
|
-
|
|
87
|
-
|
|
77
|
+
**Delivery**
|
|
78
|
+
- Local commit: <SHA or not applicable>
|
|
79
|
+
- Remote: <verified SHA and branch, pending, or not applicable>
|
|
80
|
+
- PR and review: <state, unresolved threads, or not applicable>
|
|
81
|
+
- CI: <current-head checks and result, pending, or not applicable>
|
|
82
|
+
- Deployment: <version or endpoint evidence, unknown, or not applicable>
|
|
83
|
+
- Browser/device/human acceptance: <evidence, unknown, or not applicable>
|
|
88
84
|
|
|
89
|
-
|
|
90
|
-
|
|
91
|
-
|
|
92
|
-
|
|
85
|
+
**Cleanup**
|
|
86
|
+
- Proposed: <exact safe commands or none>
|
|
87
|
+
- Executed: <actions or none>
|
|
88
|
+
- Requires confirmation: <actions or none>
|
|
93
89
|
|
|
94
|
-
|
|
95
|
-
|
|
96
|
-
|
|
90
|
+
**Documentation**
|
|
91
|
+
- Created: <files or none>
|
|
92
|
+
- Updated: <files or none>
|
|
93
|
+
- Not needed: <reason or none>
|
|
97
94
|
|
|
98
|
-
|
|
99
|
-
|
|
95
|
+
**Risks and follow-ups**
|
|
96
|
+
- <remaining risk, blocked gate, or next action; include delivery state if relevant>
|
|
100
97
|
|
|
101
|
-
|
|
102
|
-
|
|
103
|
-
CI:
|
|
104
|
-
DEPLOYMENT:
|
|
105
|
-
DEVICE_OR_HUMAN_QA:
|
|
98
|
+
**Suggested commit**
|
|
99
|
+
`type(scope): concise imperative summary`
|
|
106
100
|
|
|
107
|
-
|
|
108
|
-
|
|
109
|
-
FINAL_STATUS:
|
|
101
|
+
**Handoff**
|
|
102
|
+
<2–5 sentences with the evidence and next step a teammate needs>
|
|
110
103
|
```
|
|
111
|
-
|
|
112
|
-
`FINAL_STATUS` must be exactly one of `DELIVERED`, `BLOCKED`, or `INTENTIONALLY_UNCHANGED`. Use `BLOCKED` when required evidence or cleanup cannot safely be completed; name the blocker and next action. Never promote a partial result to `DELIVERED`.
|