🎩 You're Invited:Meet the Socket team at Black Hat in Las Vegas, August 3-6.RSVP →
Sign In

ai-workflow-kit

Package Overview
Dependencies
Maintainers
1
Versions
6
Alerts
File Explorer

Advanced tools

License
Socket logo

Install Socket

Detect and block malicious and high-risk dependencies

Install

ai-workflow-kit - npm Package Compare versions

Comparing version
2.2.0
 to
2.3.0
+58
skills/handoff/SKILL.md
---
name: ak:handoff
description: Compact the current conversation into a handoff document for a fresh agent to continue the work.
disable-model-invocation: true
argument-hint: "[focus of the next session]"
---
# Skill: /handoff
Compact the current conversation into a handoff document so a fresh agent can continue without losing context.
## Focus of next session
$ARGUMENTS
## Steps
1. **Survey what exists**: Scan for artifacts already captured elsewhere — PRDs, plans, ADRs, issues, commits, diffs. Reference them by path or URL; do not duplicate their content.
2. **Write the handoff document** with these sections:
```markdown
# Handoff: [date] — [focus or "continuation"]
## Where we left off
[1-3 sentences on current state and what was just completed or decided]
## Open threads
- [Decision or task not yet resolved]
- [Blocked item and what's blocking it]
## Key decisions made this session
- [Decision] — [why, in one line]
## Artifacts to read first
- `path/to/file.md` — [what it contains]
- Issue #42 — [what it tracks]
## Suggested skills for next session
- `/ak:plan` — [why it's relevant]
- `/ak:debug` — [why it's relevant]
## Context the next agent needs but isn't in the code
[Anything non-obvious: constraints, stakeholder preferences, things tried and abandoned]
```
3. **Save to the OS temp directory** — not the current workspace.
- Windows: `%TEMP%\handoff-[timestamp].md`
- macOS/Linux: `/tmp/handoff-[timestamp].md`
4. **Report the path** to the user and optionally copy the key sections to the conversation for immediate use.
## Rules
- Do not duplicate content already in PRDs, issues, or commits. Reference them.
- Redact secrets, API keys, and PII.
- If the user passed arguments, treat them as the focus of the next session and tailor the doc accordingly.
- The document should be self-contained: a fresh agent reading only this file should know where to start.
+10
-3
CHANGELOG.md

@@ -12,2 +12,10 @@ # Changelog

## [2.3.0] - 2026-06-25
### Added
- Add /ak:handoff skill and update CLAUDE.md
### Fixed
- Update SKILL.md to clarify task execution steps
## [2.2.0] - 2026-05-24

@@ -76,5 +84,4 @@

- Spanish README (`README.es.md`)[1.1.0]: https://github.com/bezael/ai-workflow-kit/compare/...v1.1.0[2.0.0]: https://github.com/bezael/ai-workflow-kit/compare/v1.1.0...v2.0.0
[Unreleased]: https://github.com/bezael/ai-workflow-kit/compare/v2.2.0...HEAD
[2.2.0]: https://github.com/bezael/ai-workflow-kit/compare/v2.1.0...v2.2.0
[2.1.0]: https://github.com/bezael/ai-workflow-kit/compare/v2.0.0...v2.1.0
[Unreleased]: https://github.com/bezael/ai-workflow-kit/compare/v2.3.0...HEAD
[2.3.0]: https://github.com/bezael/ai-workflow-kit/compare/v2.2.0...v2.3.0
+2
-0
CLAUDE.md

@@ -18,2 +18,3 @@ # CLAUDE.md — AI Workflow Kit

| `/ak:vibe-audit` | Audit of apps generated with vibe coding |
| `/ak:handoff [focus]` | Compact the conversation for a fresh agent to continue |
| `/ak:memory save [topic]` | Persist learnings from the current session |

@@ -41,2 +42,3 @@ | `/ak:memory recall [question]` | Retrieve relevant memory before acting |

/ak:debug submit button not responding on mobile
/ak:handoff implement auth in the next session
```

@@ -43,0 +45,0 @@ 

+2
-2
package.json
{
"name": "ai-workflow-kit",
"version": "2.2.0",
"version": "2.3.0",
"description": "Skills, agents & hooks for Claude Code, Cursor, GitHub Copilot, and Google Antigravity",

@@ -34,3 +34,3 @@ "type": "module",

],
"author": "Bezael Pérez <bezael@dominicode.com>",
"author": "Bezael Pérez <me@dominicode.com>",
"license": "MIT",

@@ -37,0 +37,0 @@ "repository": {

+35
-23
skills/debug/SKILL.md

@@ -9,3 +9,3 @@ ---

Structured debugging workflow. Diagnose before proposing fixes.
Structured debugging. Build a **tight loop** before hypothesizing.

@@ -16,24 +16,28 @@ ## Problem reported

## When to use it
## Steps
When the user writes `/debug [problem description]` or reports a bug, error, or unexpected behavior.
### Phase 1: Build a feedback loop
## Steps
Before reading code or forming theories, build a **tight loop** — one command that reproduces the bug and can go **red** on it.
### Phase 1: Reproduce and understand
If **Problem reported** is empty, ask the user: what were you expecting? what are you getting? is it intermittent?
1. If **Problem reported** above is empty, ask the user:
- What behavior were you expecting?
- What behavior are you getting?
- When did it start? Does it always happen or is it intermittent?
If it's already provided, skip directly to step 2.
Try in order:
1. **Failing test** at the nearest seam (unit, integration, e2e)
2. **Script / curl** against a running server with a fixture input
3. **Console probe** — one targeted log at the failure point, tagged `[DEBUG-id]`
2. Read the files relevant to the error. If there's a stack trace, follow the trail from the error upward.
The loop is tight when it is:
- [ ] **Red-capable** — runs the actual bug path and fails on *this* bug
- [ ] **Deterministic** — same result every run
- [ ] **Fast** — seconds, not minutes
- [ ] **Agent-runnable** — no human in the loop
3. Find the exact point where behavior diverges from expected.
**Phase 1 is done when you have named this command and run it at least once.**
Do not proceed to Phase 2 without a tight loop. Reading code to build a theory before this exists is the failure mode this skill prevents.
### Phase 2: Hypotheses
Before touching code, list the most likely causes:
With the loop **red**, list the most likely causes before touching code:

@@ -47,23 +51,31 @@ ```

Always start with the highest-probability hypothesis.
Show the list to the user before testing. They often re-rank instantly from domain knowledge.
### Phase 3: Verify
For each hypothesis, propose a minimal verification (a `console.log`, a test, checking a variable's value) before proposing a full fix.
Change **one variable at a time** and run the loop after each change:
- Targeted log at the boundaries that distinguish hypotheses
- Swap a value, toggle a flag, or inline a function
The loop turns green when you've found the cause.
### Phase 4: Fix
Only when the cause is confirmed:
1. Propose the minimal fix that solves the problem
2. Explain why it works
3. Point out if the fix can have side effects
1. Write a regression test before the fix (if a clean seam exists)
2. Apply the minimal fix — the smallest change that makes the loop go **green**
3. Re-run the full test suite
4. Remove all `[DEBUG-id]` logs (grep the tag)
### Phase 5: Prevention (optional)
If the bug reveals a problematic pattern, suggest how to prevent it in the future (test, validation, stricter type, etc.).
If the bug reveals a systemic gap, suggest how to close it:
- No clean test seam → flag for `/ak:review`
- Type gap → stricter TypeScript
- Architectural issue → `/ak:plan` a refactor
## Rules
- Don't propose fixes before understanding the cause. A fix without diagnosis is another bug waiting to appear.
- The simplest fix that solves the problem is the best fix.
- If the bug is in production, prioritize the quick fix (hotfix) and document the proper fix for later.
- No Phase 2 without a tight loop. Theorizing before reproducing is the exact failure this skill prevents.
- The simplest fix that makes the loop green is the right fix.
- If in production: hotfix first, proper fix second — document the gap.
+12
-11
skills/plan/SKILL.md

@@ -16,13 +16,6 @@ ---

## When to use it
When the user writes `/plan [task]` or when the task:
- Touches more than 3 files
- Requires creating new folder structure
- Involves database or API changes
- Has dependencies between steps
## Steps
1. **Understand the goal**: Read the user's task. If ambiguous, ask ONE clarifying question before continuing.
_Done when: the goal fits in one sentence._

@@ -33,2 +26,3 @@ 2. **Explore the relevant codebase**:

- Detect dependencies and risks
_Done when: every file that will change has been read._

@@ -61,8 +55,15 @@ 3. **Propose a structured plan**:

4. **Wait for approval** before executing any changes. Don't start writing code until the user says "go ahead" or similar.
4. **Wait for approval** before executing any changes.
_Done when: user explicitly approves ("go ahead", "looks good", etc.)._
5. **Mark the ticket InProgress**: if the task is linked to an issue or ticket, mark it as `in_progress` now — before writing any code.
6. **Execute** the plan exactly as approved. If you discover something that changes the plan, stop and report.
7. **After implementation**: run `/ak:review` on the changed files before considering the task complete.
## Rules
- A plan is a contract. If the user approves, execute exactly what you said.
- If during execution you discover something that changes the plan, stop and report.
- A plan is a contract. Execute exactly what was approved.
- Prefer small iterative plans over large complete ones.
- One clarifying question max — don't interview the user.