ai-devkit 0.14.0 → 0.16.0
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/README.md +6 -0
- package/dist/cli.js +10 -1
- package/dist/cli.js.map +1 -1
- package/dist/commands/agent.d.ts.map +1 -1
- package/dist/commands/agent.js +43 -17
- package/dist/commands/agent.js.map +1 -1
- package/dist/commands/install.d.ts +7 -0
- package/dist/commands/install.d.ts.map +1 -0
- package/dist/commands/install.js +74 -0
- package/dist/commands/install.js.map +1 -0
- package/dist/commands/phase.js +1 -1
- package/dist/commands/phase.js.map +1 -1
- package/dist/lib/Config.d.ts +3 -1
- package/dist/lib/Config.d.ts.map +1 -1
- package/dist/lib/Config.js +39 -6
- package/dist/lib/Config.js.map +1 -1
- package/dist/lib/SkillManager.d.ts.map +1 -1
- package/dist/lib/SkillManager.js +8 -2
- package/dist/lib/SkillManager.js.map +1 -1
- package/dist/lib/TemplateManager.d.ts.map +1 -1
- package/dist/lib/TemplateManager.js +1 -12
- package/dist/lib/TemplateManager.js.map +1 -1
- package/dist/services/config/config.service.d.ts +6 -0
- package/dist/services/config/config.service.d.ts.map +1 -0
- package/dist/services/config/config.service.js +55 -0
- package/dist/services/config/config.service.js.map +1 -0
- package/dist/services/install/install.service.d.ts +19 -0
- package/dist/services/install/install.service.d.ts.map +1 -0
- package/dist/services/install/install.service.js +125 -0
- package/dist/services/install/install.service.js.map +1 -0
- package/dist/templates/commands/capture-knowledge.md +7 -5
- package/dist/templates/commands/check-implementation.md +7 -4
- package/dist/templates/commands/code-review.md +7 -4
- package/dist/templates/commands/debug.md +7 -4
- package/dist/templates/commands/execute-plan.md +7 -4
- package/dist/templates/commands/new-requirement.md +7 -6
- package/dist/templates/commands/remember.md +6 -4
- package/dist/templates/commands/review-design.md +13 -10
- package/dist/templates/commands/review-requirements.md +11 -8
- package/dist/templates/commands/simplify-implementation.md +6 -3
- package/dist/templates/commands/update-planning.md +6 -3
- package/dist/templates/commands/writing-test.md +8 -5
- package/dist/templates/templates/commands/capture-knowledge.md +7 -5
- package/dist/templates/templates/commands/check-implementation.md +7 -4
- package/dist/templates/templates/commands/code-review.md +7 -4
- package/dist/templates/templates/commands/debug.md +7 -4
- package/dist/templates/templates/commands/execute-plan.md +7 -4
- package/dist/templates/templates/commands/new-requirement.md +7 -6
- package/dist/templates/templates/commands/remember.md +6 -4
- package/dist/templates/templates/commands/review-design.md +13 -10
- package/dist/templates/templates/commands/review-requirements.md +11 -8
- package/dist/templates/templates/commands/simplify-implementation.md +6 -3
- package/dist/templates/templates/commands/update-planning.md +6 -3
- package/dist/templates/templates/commands/writing-test.md +8 -5
- package/dist/types.d.ts +6 -1
- package/dist/types.d.ts.map +1 -1
- package/dist/types.js.map +1 -1
- package/dist/util/config.d.ts +8 -0
- package/dist/util/config.d.ts.map +1 -0
- package/dist/util/config.js +100 -0
- package/dist/util/config.js.map +1 -0
- package/dist/util/process.d.ts +1 -1
- package/dist/util/process.d.ts.map +1 -1
- package/package.json +5 -3
- package/templates/commands/capture-knowledge.md +7 -5
- package/templates/commands/check-implementation.md +7 -4
- package/templates/commands/code-review.md +7 -4
- package/templates/commands/debug.md +7 -4
- package/templates/commands/execute-plan.md +7 -4
- package/templates/commands/new-requirement.md +7 -6
- package/templates/commands/remember.md +6 -4
- package/templates/commands/review-design.md +13 -10
- package/templates/commands/review-requirements.md +11 -8
- package/templates/commands/simplify-implementation.md +6 -3
- package/templates/commands/update-planning.md +6 -3
- package/templates/commands/writing-test.md +8 -5
- package/dist/lib/AgentManager.d.ts +0 -104
- package/dist/lib/AgentManager.d.ts.map +0 -1
- package/dist/lib/AgentManager.js +0 -185
- package/dist/lib/AgentManager.js.map +0 -1
- package/dist/lib/TerminalFocusManager.d.ts +0 -22
- package/dist/lib/TerminalFocusManager.d.ts.map +0 -1
- package/dist/lib/TerminalFocusManager.js +0 -195
- package/dist/lib/TerminalFocusManager.js.map +0 -1
- package/dist/lib/adapters/AgentAdapter.d.ts +0 -92
- package/dist/lib/adapters/AgentAdapter.d.ts.map +0 -1
- package/dist/lib/adapters/AgentAdapter.js +0 -29
- package/dist/lib/adapters/AgentAdapter.js.map +0 -1
- package/dist/lib/adapters/ClaudeCodeAdapter.d.ts +0 -66
- package/dist/lib/adapters/ClaudeCodeAdapter.d.ts.map +0 -1
- package/dist/lib/adapters/ClaudeCodeAdapter.js +0 -306
- package/dist/lib/adapters/ClaudeCodeAdapter.js.map +0 -1
- package/dist/templates/env/base.md +0 -101
- package/dist/templates/templates/env/base.md +0 -101
- package/templates/env/base.md +0 -101
|
@@ -5,7 +5,10 @@ description: Pre-push code review against design docs.
|
|
|
5
5
|
Perform a local code review **before** pushing changes.
|
|
6
6
|
|
|
7
7
|
1. **Gather Context** — If not already provided, ask for: feature/branch description, list of modified files, relevant design doc(s) (e.g., `docs/ai/design/feature-{name}.md`), known constraints or risky areas, and which tests have been run. Also review the latest diff via `git status` and `git diff --stat`.
|
|
8
|
-
2. **
|
|
9
|
-
3. **
|
|
10
|
-
4. **
|
|
11
|
-
5. **
|
|
8
|
+
2. **Use Memory for Context** — Search memory for project review standards and recurring pitfalls: `npx ai-devkit@latest memory search --query "code review checklist project conventions"`.
|
|
9
|
+
3. **Understand Design Alignment** — For each design doc, summarize architectural intent and critical constraints.
|
|
10
|
+
4. **File-by-File Review** — For every modified file: check alignment with design/requirements and flag deviations, spot logic issues/edge cases/redundant code, flag security concerns (input validation, secrets, auth, data handling), check error handling/performance/observability, and identify missing or outdated tests.
|
|
11
|
+
5. **Cross-Cutting Concerns** — Verify naming consistency and project conventions. Confirm docs/comments updated where behavior changed. Identify missing tests (unit, integration, E2E). Check for needed configuration/migration updates.
|
|
12
|
+
6. **Store Reusable Knowledge** — Save durable review findings/checklists with `npx ai-devkit@latest memory store ...`.
|
|
13
|
+
7. **Summarize Findings** — Categorize each finding as **blocking**, **important**, or **nice-to-have** with: file, issue, impact, recommendation, and design reference.
|
|
14
|
+
8. **Next Command Guidance** — If blocking issues remain, return to `/execute-plan` (code fixes) or `/writing-test` (test gaps); if clean, proceed with push/PR workflow.
|
|
@@ -5,7 +5,10 @@ description: Debug an issue with structured root-cause analysis before changing
|
|
|
5
5
|
Help me debug an issue. Clarify expectations, identify gaps, and agree on a fix plan before changing code.
|
|
6
6
|
|
|
7
7
|
1. **Gather Context** — If not already provided, ask for: issue description (what is happening vs what should happen), error messages/logs/screenshots, recent related changes or deployments, and scope of impact.
|
|
8
|
-
2. **
|
|
9
|
-
3. **
|
|
10
|
-
4. **
|
|
11
|
-
5. **
|
|
8
|
+
2. **Use Memory for Context** — Search memory for similar incidents/fixes before deep investigation: `npx ai-devkit@latest memory search --query "<issue symptoms or error>"`.
|
|
9
|
+
3. **Clarify Reality vs Expectation** — Restate observed vs expected behavior. Confirm relevant requirements or docs that define the expectation. Define acceptance criteria for the fix.
|
|
10
|
+
4. **Reproduce & Isolate** — Determine reproducibility (always, intermittent, environment-specific). Capture reproduction steps. List suspected components or modules.
|
|
11
|
+
5. **Analyze Potential Causes** — Brainstorm root causes (data, config, code regressions, external dependencies). Gather supporting evidence (logs, metrics, traces). Highlight unknowns needing investigation.
|
|
12
|
+
6. **Resolve** — Present resolution options (quick fix, refactor, rollback, etc.) with pros/cons and risks. Ask which option to pursue. Summarize chosen approach, pre-work, success criteria, and validation steps.
|
|
13
|
+
7. **Store Reusable Knowledge** — Save root-cause and fix patterns via `npx ai-devkit@latest memory store ...`.
|
|
14
|
+
8. **Next Command Guidance** — After selecting a fix path, continue with `/execute-plan`; when implemented, use `/check-implementation` and `/writing-test`.
|
|
@@ -5,7 +5,10 @@ description: Execute a feature plan task by task.
|
|
|
5
5
|
Help me work through a feature plan one task at a time.
|
|
6
6
|
|
|
7
7
|
1. **Gather Context** — If not already provided, ask for: feature name (kebab-case, e.g., `user-authentication`), brief feature/branch description, planning doc path (default `docs/ai/planning/feature-{name}.md`), and any supporting docs (design, requirements, implementation).
|
|
8
|
-
2. **
|
|
9
|
-
3. **
|
|
10
|
-
4. **
|
|
11
|
-
5. **
|
|
8
|
+
2. **Use Memory for Context** — Search for prior implementation notes/patterns before starting: `npx ai-devkit@latest memory search --query "<feature implementation plan>"`.
|
|
9
|
+
3. **Load & Present Plan** — Read the planning doc and parse task lists (headings + checkboxes). Present an ordered task queue grouped by section, with status: `todo`, `in-progress`, `done`, `blocked`.
|
|
10
|
+
4. **Interactive Task Execution** — For each task in order: display context and full bullet text, reference relevant design/requirements docs, offer to outline sub-steps before starting, prompt for status update (`done`, `in-progress`, `blocked`, `skipped`) with short notes after work, and if blocked record blocker and move to a "Blocked" list.
|
|
11
|
+
5. **Update Planning Doc** — After each completed or status-changed task, run `/update-planning` to keep `docs/ai/planning/feature-{name}.md` accurate.
|
|
12
|
+
6. **Store Reusable Knowledge** — Save reusable implementation guidance/decisions with `npx ai-devkit@latest memory store ...`.
|
|
13
|
+
7. **Session Summary** — Produce a summary: Completed, In Progress (with next steps), Blocked (with blockers), Skipped/Deferred, and New Tasks.
|
|
14
|
+
8. **Next Command Guidance** — Continue `/execute-plan` until plan completion; then run `/check-implementation`.
|
|
@@ -5,14 +5,15 @@ description: Scaffold feature documentation from requirements through planning.
|
|
|
5
5
|
Guide me through adding a new feature, from requirements documentation to implementation readiness.
|
|
6
6
|
|
|
7
7
|
1. **Capture Requirement** — If not already provided, ask for: feature name (kebab-case, e.g., `user-authentication`), what problem it solves and who will use it, and key user stories.
|
|
8
|
-
2. **
|
|
8
|
+
2. **Use Memory for Context** — Before asking repetitive clarification questions, search memory for related decisions or conventions via `npx ai-devkit@latest memory search --query "<feature/topic>"` and reuse relevant context.
|
|
9
|
+
3. **Create Feature Documentation Structure** — Copy each template's content (preserving YAML frontmatter and section headings) into feature-specific files:
|
|
9
10
|
- `docs/ai/requirements/README.md` → `docs/ai/requirements/feature-{name}.md`
|
|
10
11
|
- `docs/ai/design/README.md` → `docs/ai/design/feature-{name}.md`
|
|
11
12
|
- `docs/ai/planning/README.md` → `docs/ai/planning/feature-{name}.md`
|
|
12
13
|
- `docs/ai/implementation/README.md` → `docs/ai/implementation/feature-{name}.md`
|
|
13
14
|
- `docs/ai/testing/README.md` → `docs/ai/testing/feature-{name}.md`
|
|
14
|
-
|
|
15
|
-
|
|
16
|
-
|
|
17
|
-
|
|
18
|
-
|
|
15
|
+
4. **Requirements Phase** — Fill out `docs/ai/requirements/feature-{name}.md`: problem statement, goals/non-goals, user stories, success criteria, constraints, open questions.
|
|
16
|
+
5. **Design Phase** — Fill out `docs/ai/design/feature-{name}.md`: architecture changes, data models, API/interfaces, components, design decisions, security and performance considerations.
|
|
17
|
+
6. **Planning Phase** — Fill out `docs/ai/planning/feature-{name}.md`: task breakdown with subtasks, dependencies, effort estimates, implementation order, risks.
|
|
18
|
+
7. **Store Reusable Knowledge** — When important conventions or decisions are finalized, store them via `npx ai-devkit@latest memory store --title "<title>" --content "<knowledge>" --tags "<tags>"`.
|
|
19
|
+
8. **Next Command Guidance** — Run `/review-requirements` first, then `/review-design`. If both pass, continue with `/execute-plan`.
|
|
@@ -2,9 +2,11 @@
|
|
|
2
2
|
description: Store reusable guidance in the knowledge memory service.
|
|
3
3
|
---
|
|
4
4
|
|
|
5
|
-
|
|
5
|
+
Help me store it in the knowledge memory service.
|
|
6
6
|
|
|
7
7
|
1. **Capture Knowledge** — If not already provided, ask for: a short explicit title (5-12 words), detailed content (markdown, examples encouraged), optional tags (keywords like "api", "testing"), and optional scope (`global`, `project:<name>`, `repo:<name>`). If vague, ask follow-ups to make it specific and actionable.
|
|
8
|
-
2. **
|
|
9
|
-
3. **
|
|
10
|
-
4. **
|
|
8
|
+
2. **Search Before Store** — Check for existing similar entries first with `npx ai-devkit@latest memory search --query "<topic>"` to avoid duplicates.
|
|
9
|
+
3. **Validate Quality** — Ensure it is specific and reusable (not generic advice). Avoid storing secrets or sensitive data.
|
|
10
|
+
4. **Store** — Call `memory.storeKnowledge` with title, content, tags, scope. If MCP tools are unavailable, use `npx ai-devkit@latest memory store` instead.
|
|
11
|
+
5. **Confirm** — Summarize what was saved and offer to retrieve related memory entries when helpful.
|
|
12
|
+
6. **Next Command Guidance** — Continue with the current lifecycle phase command (`/execute-plan`, `/check-implementation`, `/writing-test`, etc.) as needed.
|
|
@@ -2,14 +2,17 @@
|
|
|
2
2
|
description: Review feature design for completeness.
|
|
3
3
|
---
|
|
4
4
|
|
|
5
|
-
Review the design documentation in docs/ai/design/feature-{name}.md (and the project-level README if relevant).
|
|
5
|
+
Review the design documentation in `docs/ai/design/feature-{name}.md` (and the project-level README if relevant).
|
|
6
6
|
|
|
7
|
-
|
|
8
|
-
|
|
9
|
-
-
|
|
10
|
-
-
|
|
11
|
-
-
|
|
12
|
-
-
|
|
13
|
-
-
|
|
14
|
-
|
|
15
|
-
|
|
7
|
+
1. **Use Memory for Context** — Search memory for prior architecture constraints/patterns: `npx ai-devkit@latest memory search --query "<feature design architecture>"`.
|
|
8
|
+
2. Summarize:
|
|
9
|
+
- Architecture overview (ensure mermaid diagram is present and accurate)
|
|
10
|
+
- Key components and their responsibilities
|
|
11
|
+
- Technology choices and rationale
|
|
12
|
+
- Data models and relationships
|
|
13
|
+
- API/interface contracts (inputs, outputs, auth)
|
|
14
|
+
- Major design decisions and trade-offs
|
|
15
|
+
- Non-functional requirements that must be preserved
|
|
16
|
+
3. Highlight inconsistencies, missing sections, or diagrams that need updates.
|
|
17
|
+
4. **Store Reusable Knowledge** — Persist approved design patterns/constraints with `npx ai-devkit@latest memory store ...` when they will help future work.
|
|
18
|
+
5. **Next Command Guidance** — If requirements gaps are found, return to `/review-requirements`; if design is sound, continue to `/execute-plan`.
|
|
@@ -2,12 +2,15 @@
|
|
|
2
2
|
description: Review feature requirements for completeness.
|
|
3
3
|
---
|
|
4
4
|
|
|
5
|
-
Review `docs/ai/requirements/feature-{name}.md` and the project-level template `docs/ai/requirements/README.md` to ensure structure and content alignment.
|
|
5
|
+
Review `docs/ai/requirements/feature-{name}.md` and the project-level template `docs/ai/requirements/README.md` to ensure structure and content alignment.
|
|
6
6
|
|
|
7
|
-
-
|
|
8
|
-
|
|
9
|
-
-
|
|
10
|
-
-
|
|
11
|
-
-
|
|
12
|
-
|
|
13
|
-
|
|
7
|
+
1. **Use Memory for Context** — Search memory for related requirements/domain decisions before starting: `npx ai-devkit@latest memory search --query "<feature requirements>"`.
|
|
8
|
+
2. Summarize:
|
|
9
|
+
- Core problem statement and affected users
|
|
10
|
+
- Goals, non-goals, and success criteria
|
|
11
|
+
- Primary user stories & critical flows
|
|
12
|
+
- Constraints, assumptions, open questions
|
|
13
|
+
- Any missing sections or deviations from the template
|
|
14
|
+
3. Identify gaps or contradictions and suggest clarifications.
|
|
15
|
+
4. **Store Reusable Knowledge** — If new reusable requirement conventions are agreed, store them with `npx ai-devkit@latest memory store ...`.
|
|
16
|
+
5. **Next Command Guidance** — If fundamentals are missing, go back to `/new-requirement`; otherwise continue to `/review-design`.
|
|
@@ -5,6 +5,9 @@ description: Simplify existing code to reduce complexity.
|
|
|
5
5
|
Help me simplify an existing implementation while maintaining or improving its functionality.
|
|
6
6
|
|
|
7
7
|
1. **Gather Context** — If not already provided, ask for: target file(s) or component(s) to simplify, current pain points (hard to understand, maintain, or extend?), performance or scalability concerns, constraints (backward compatibility, API stability, deadlines), and relevant design docs or requirements.
|
|
8
|
-
2. **
|
|
9
|
-
3. **
|
|
10
|
-
4. **
|
|
8
|
+
2. **Use Memory for Context** — Search memory for established patterns and prior refactors in this area: `npx ai-devkit@latest memory search --query "<component simplification pattern>"`.
|
|
9
|
+
3. **Analyze Current Complexity** — For each target: identify complexity sources (deep nesting, duplication, unclear abstractions, tight coupling, over-engineering, magic values), assess cognitive load for future maintainers, and identify scalability blockers (single points of failure, sync-where-async-needed, missing caching, inefficient algorithms).
|
|
10
|
+
4. **Propose Simplifications** — Prioritize readability over brevity; apply the 30-second test: can a new team member understand each change quickly? For each issue, suggest concrete improvements (extract, consolidate, flatten, decouple, remove dead code, replace with built-ins). Provide before/after snippets.
|
|
11
|
+
5. **Prioritize & Plan** — Rank by impact vs risk: (1) high impact, low risk — do first, (2) high impact, higher risk — plan carefully, (3) low impact, low risk — quick wins if time permits, (4) low impact, high risk — skip or defer. For each change specify risk level, testing requirements, and effort. Produce a prioritized action plan with recommended execution order.
|
|
12
|
+
6. **Store Reusable Knowledge** — Save reusable simplification patterns and trade-offs via `npx ai-devkit@latest memory store ...`.
|
|
13
|
+
7. **Next Command Guidance** — After implementation, run `/check-implementation` and `/writing-test`.
|
|
@@ -5,6 +5,9 @@ description: Update planning docs to reflect implementation progress.
|
|
|
5
5
|
Help me reconcile current implementation progress with the planning documentation.
|
|
6
6
|
|
|
7
7
|
1. **Gather Context** — If not already provided, ask for: feature/branch name and brief status, tasks completed since last update, new tasks discovered, current blockers or risks, and planning doc path (default `docs/ai/planning/feature-{name}.md`).
|
|
8
|
-
2. **
|
|
9
|
-
3. **
|
|
10
|
-
4. **
|
|
8
|
+
2. **Use Memory for Context** — Search memory for prior decisions that affect priorities/scope: `npx ai-devkit@latest memory search --query "<feature planning updates>"`.
|
|
9
|
+
3. **Review & Reconcile** — Summarize existing milestones, task breakdowns, and dependencies from the planning doc. For each planned task: mark status (done / in progress / blocked / not started), note scope changes, record blockers, identify skipped or added tasks.
|
|
10
|
+
4. **Produce Updated Task List** — Generate an updated checklist grouped by: Done, In Progress, Blocked, Newly Discovered Work — with short notes per task.
|
|
11
|
+
5. **Store Reusable Knowledge** — If new planning conventions or risk-handling rules emerge, store them with `npx ai-devkit@latest memory store ...`.
|
|
12
|
+
6. **Next Steps & Summary** — Suggest the next 2-3 actionable tasks and prepare a summary paragraph for the planning doc.
|
|
13
|
+
7. **Next Command Guidance** — Return to `/execute-plan` for remaining work. When all implementation tasks are complete, run `/check-implementation`.
|
|
@@ -5,8 +5,11 @@ description: Add tests for a new feature.
|
|
|
5
5
|
Review `docs/ai/testing/feature-{name}.md` and ensure it mirrors the base template before writing tests.
|
|
6
6
|
|
|
7
7
|
1. **Gather Context** — If not already provided, ask for: feature name/branch, summary of changes (link to design & requirements docs), target environment, existing test suites, and any flaky/slow tests to avoid.
|
|
8
|
-
2. **
|
|
9
|
-
3. **
|
|
10
|
-
4. **
|
|
11
|
-
5. **
|
|
12
|
-
6. **
|
|
8
|
+
2. **Use Memory for Context** — Search memory for existing testing patterns and prior edge cases: `npx ai-devkit@latest memory search --query "<feature testing strategy>"`.
|
|
9
|
+
3. **Analyze Testing Template** — Identify required sections from `docs/ai/testing/feature-{name}.md`. Confirm success criteria and edge cases from requirements & design docs. Note available mocks/stubs/fixtures.
|
|
10
|
+
4. **Unit Tests (aim for 100% coverage)** — For each module/function: list behavior scenarios (happy path, edge cases, error handling), generate test cases with assertions using existing utilities/mocks, and highlight missing branches preventing full coverage.
|
|
11
|
+
5. **Integration Tests** — Identify critical cross-component flows. Define setup/teardown steps and test cases for interaction boundaries, data contracts, and failure modes.
|
|
12
|
+
6. **Coverage Strategy** — Recommend coverage tooling commands. Call out files/functions still needing coverage and suggest additional tests if <100%.
|
|
13
|
+
7. **Store Reusable Knowledge** — Save reusable testing patterns or tricky fixtures with `npx ai-devkit@latest memory store ...`.
|
|
14
|
+
8. **Update Documentation** — Summarize tests added or still missing. Update `docs/ai/testing/feature-{name}.md` with links to test files and results. Flag deferred tests as follow-up tasks.
|
|
15
|
+
9. **Next Command Guidance** — If tests expose design issues, return to `/review-design`; otherwise continue to `/code-review`.
|
package/dist/types.d.ts
CHANGED
|
@@ -14,10 +14,15 @@ export type EnvironmentCode = 'cursor' | 'claude' | 'github' | 'gemini' | 'codex
|
|
|
14
14
|
export interface DevKitConfig {
|
|
15
15
|
version: string;
|
|
16
16
|
environments: EnvironmentCode[];
|
|
17
|
-
|
|
17
|
+
phases: Phase[];
|
|
18
|
+
skills?: ConfigSkill[];
|
|
18
19
|
createdAt: string;
|
|
19
20
|
updatedAt: string;
|
|
20
21
|
}
|
|
22
|
+
export interface ConfigSkill {
|
|
23
|
+
registry: string;
|
|
24
|
+
name: string;
|
|
25
|
+
}
|
|
21
26
|
export interface SkillRegistriesConfig {
|
|
22
27
|
registries?: Record<string, string>;
|
|
23
28
|
}
|
package/dist/types.d.ts.map
CHANGED
|
@@ -1 +1 @@
|
|
|
1
|
-
{"version":3,"file":"types.d.ts","sourceRoot":"","sources":["../src/types.ts"],"names":[],"mappings":"AAAA,MAAM,MAAM,KAAK,GACb,cAAc,GACd,QAAQ,GACR,UAAU,GACV,gBAAgB,GAChB,SAAS,GACT,YAAY,GACZ,YAAY,CAAC;AAEjB,MAAM,WAAW,qBAAqB;IACpC,IAAI,EAAE,MAAM,CAAC;IACb,IAAI,EAAE,MAAM,CAAC;IACb,eAAe,EAAE,MAAM,CAAC;IACxB,WAAW,EAAE,MAAM,CAAC;IACpB,SAAS,CAAC,EAAE,MAAM,CAAC;IACnB,WAAW,CAAC,EAAE,MAAM,CAAC;IACrB,mBAAmB,CAAC,EAAE,OAAO,CAAC;IAC9B,sBAAsB,CAAC,EAAE,MAAM,CAAC;IAChC,iBAAiB,CAAC,EAAE,MAAM,CAAC;CAC5B;AAED,MAAM,MAAM,eAAe,GAAG,QAAQ,GAAG,QAAQ,GAAG,QAAQ,GAAG,QAAQ,GAAG,OAAO,GAAG,UAAU,GAAG,UAAU,GAAG,KAAK,GAAG,UAAU,GAAG,KAAK,GAAG,aAAa,CAAC;AAEzJ,MAAM,WAAW,YAAY;IAC3B,OAAO,EAAE,MAAM,CAAC;IAChB,YAAY,EAAE,eAAe,EAAE,CAAC;IAChC,
|
|
1
|
+
{"version":3,"file":"types.d.ts","sourceRoot":"","sources":["../src/types.ts"],"names":[],"mappings":"AAAA,MAAM,MAAM,KAAK,GACb,cAAc,GACd,QAAQ,GACR,UAAU,GACV,gBAAgB,GAChB,SAAS,GACT,YAAY,GACZ,YAAY,CAAC;AAEjB,MAAM,WAAW,qBAAqB;IACpC,IAAI,EAAE,MAAM,CAAC;IACb,IAAI,EAAE,MAAM,CAAC;IACb,eAAe,EAAE,MAAM,CAAC;IACxB,WAAW,EAAE,MAAM,CAAC;IACpB,SAAS,CAAC,EAAE,MAAM,CAAC;IACnB,WAAW,CAAC,EAAE,MAAM,CAAC;IACrB,mBAAmB,CAAC,EAAE,OAAO,CAAC;IAC9B,sBAAsB,CAAC,EAAE,MAAM,CAAC;IAChC,iBAAiB,CAAC,EAAE,MAAM,CAAC;CAC5B;AAED,MAAM,MAAM,eAAe,GAAG,QAAQ,GAAG,QAAQ,GAAG,QAAQ,GAAG,QAAQ,GAAG,OAAO,GAAG,UAAU,GAAG,UAAU,GAAG,KAAK,GAAG,UAAU,GAAG,KAAK,GAAG,aAAa,CAAC;AAEzJ,MAAM,WAAW,YAAY;IAC3B,OAAO,EAAE,MAAM,CAAC;IAChB,YAAY,EAAE,eAAe,EAAE,CAAC;IAChC,MAAM,EAAE,KAAK,EAAE,CAAC;IAChB,MAAM,CAAC,EAAE,WAAW,EAAE,CAAC;IACvB,SAAS,EAAE,MAAM,CAAC;IAClB,SAAS,EAAE,MAAM,CAAC;CACnB;AAED,MAAM,WAAW,WAAW;IAC1B,QAAQ,EAAE,MAAM,CAAC;IACjB,IAAI,EAAE,MAAM,CAAC;CACd;AAED,MAAM,WAAW,qBAAqB;IACpC,UAAU,CAAC,EAAE,MAAM,CAAC,MAAM,EAAE,MAAM,CAAC,CAAC;CACrC;AAED,MAAM,WAAW,kBAAkB;IACjC,MAAM,CAAC,EAAE,qBAAqB,CAAC;CAChC;AAED,MAAM,WAAW,aAAa;IAC5B,KAAK,EAAE,MAAM,CAAC;IACd,KAAK,EAAE,MAAM,CAAC;IACd,WAAW,EAAE,MAAM,CAAC;CACrB;AAED,eAAO,MAAM,gBAAgB,EAAE,KAAK,EAQnC,CAAC;AAEF,eAAO,MAAM,mBAAmB,EAAE,MAAM,CAAC,KAAK,EAAE,MAAM,CAQrD,CAAC"}
|
package/dist/types.js.map
CHANGED
|
@@ -1 +1 @@
|
|
|
1
|
-
{"version":3,"file":"types.js","sourceRoot":"","sources":["../src/types.ts"],"names":[],"mappings":";;;
|
|
1
|
+
{"version":3,"file":"types.js","sourceRoot":"","sources":["../src/types.ts"],"names":[],"mappings":";;;AAmDa,QAAA,gBAAgB,GAAY;IACvC,cAAc;IACd,QAAQ;IACR,UAAU;IACV,gBAAgB;IAChB,SAAS;IACT,YAAY;IACZ,YAAY;CACb,CAAC;AAEW,QAAA,mBAAmB,GAA0B;IACxD,YAAY,EAAE,sCAAsC;IACpD,MAAM,EAAE,8BAA8B;IACtC,QAAQ,EAAE,mCAAmC;IAC7C,cAAc,EAAE,sBAAsB;IACtC,OAAO,EAAE,kBAAkB;IAC3B,UAAU,EAAE,qBAAqB;IACjC,UAAU,EAAE,4BAA4B;CACzC,CAAC"}
|
|
@@ -0,0 +1,8 @@
|
|
|
1
|
+
import { ConfigSkill, EnvironmentCode, Phase } from '../types';
|
|
2
|
+
export interface InstallConfigData {
|
|
3
|
+
environments: EnvironmentCode[];
|
|
4
|
+
phases: Phase[];
|
|
5
|
+
skills: ConfigSkill[];
|
|
6
|
+
}
|
|
7
|
+
export declare function validateInstallConfig(data: unknown, configPath: string): InstallConfigData;
|
|
8
|
+
//# sourceMappingURL=config.d.ts.map
|
|
@@ -0,0 +1 @@
|
|
|
1
|
+
{"version":3,"file":"config.d.ts","sourceRoot":"","sources":["../../src/util/config.ts"],"names":[],"mappings":"AACA,OAAO,EAAE,WAAW,EAAE,eAAe,EAAE,KAAK,EAAoB,MAAM,UAAU,CAAC;AAGjF,MAAM,WAAW,iBAAiB;IAChC,YAAY,EAAE,eAAe,EAAE,CAAC;IAChC,MAAM,EAAE,KAAK,EAAE,CAAC;IAChB,MAAM,EAAE,WAAW,EAAE,CAAC;CACvB;AAyDD,wBAAgB,qBAAqB,CAAC,IAAI,EAAE,OAAO,EAAE,UAAU,EAAE,MAAM,GAAG,iBAAiB,CAQ1F"}
|
|
@@ -0,0 +1,100 @@
|
|
|
1
|
+
"use strict";
|
|
2
|
+
Object.defineProperty(exports, "__esModule", { value: true });
|
|
3
|
+
exports.validateInstallConfig = validateInstallConfig;
|
|
4
|
+
const zod_1 = require("zod");
|
|
5
|
+
const types_1 = require("../types");
|
|
6
|
+
const env_1 = require("./env");
|
|
7
|
+
const skillEntrySchema = zod_1.z.object({
|
|
8
|
+
registry: zod_1.z.string().trim().min(1, 'registry must be a non-empty string'),
|
|
9
|
+
name: zod_1.z.string().trim().min(1).optional(),
|
|
10
|
+
skill: zod_1.z.string().trim().min(1).optional()
|
|
11
|
+
}).transform((entry, ctx) => {
|
|
12
|
+
const resolvedName = entry.name ?? entry.skill;
|
|
13
|
+
if (!resolvedName) {
|
|
14
|
+
ctx.addIssue({
|
|
15
|
+
code: zod_1.z.ZodIssueCode.custom,
|
|
16
|
+
path: ['name'],
|
|
17
|
+
message: 'requires a non-empty "name" field'
|
|
18
|
+
});
|
|
19
|
+
return zod_1.z.NEVER;
|
|
20
|
+
}
|
|
21
|
+
return {
|
|
22
|
+
registry: entry.registry,
|
|
23
|
+
name: resolvedName
|
|
24
|
+
};
|
|
25
|
+
});
|
|
26
|
+
const installConfigSchema = zod_1.z.object({
|
|
27
|
+
environments: zod_1.z.array(zod_1.z.string()).optional().default([]).superRefine((values, ctx) => {
|
|
28
|
+
values.forEach((value, index) => {
|
|
29
|
+
if (!(0, env_1.isValidEnvironmentCode)(value)) {
|
|
30
|
+
ctx.addIssue({
|
|
31
|
+
code: zod_1.z.ZodIssueCode.custom,
|
|
32
|
+
path: [index],
|
|
33
|
+
message: `has unsupported value "${value}"`
|
|
34
|
+
});
|
|
35
|
+
}
|
|
36
|
+
});
|
|
37
|
+
}).transform(values => dedupe(values)),
|
|
38
|
+
phases: zod_1.z.array(zod_1.z.string()).optional(),
|
|
39
|
+
skills: zod_1.z.array(skillEntrySchema).optional().default([])
|
|
40
|
+
}).transform((data, ctx) => {
|
|
41
|
+
const phaseValues = data.phases ?? [];
|
|
42
|
+
phaseValues.forEach((value, index) => {
|
|
43
|
+
if (!types_1.AVAILABLE_PHASES.includes(value)) {
|
|
44
|
+
ctx.addIssue({
|
|
45
|
+
code: zod_1.z.ZodIssueCode.custom,
|
|
46
|
+
path: ['phases', index],
|
|
47
|
+
message: `has unsupported value "${value}"`
|
|
48
|
+
});
|
|
49
|
+
}
|
|
50
|
+
});
|
|
51
|
+
return {
|
|
52
|
+
environments: data.environments,
|
|
53
|
+
phases: dedupe(phaseValues),
|
|
54
|
+
skills: dedupeSkills(data.skills)
|
|
55
|
+
};
|
|
56
|
+
});
|
|
57
|
+
function validateInstallConfig(data, configPath) {
|
|
58
|
+
const parsed = installConfigSchema.safeParse(data);
|
|
59
|
+
if (!parsed.success) {
|
|
60
|
+
throw new Error(`Invalid config file ${configPath}: ${formatZodIssue(parsed.error)}`);
|
|
61
|
+
}
|
|
62
|
+
return parsed.data;
|
|
63
|
+
}
|
|
64
|
+
function formatZodIssue(error) {
|
|
65
|
+
const issue = error.issues[0];
|
|
66
|
+
if (!issue) {
|
|
67
|
+
return 'validation failed';
|
|
68
|
+
}
|
|
69
|
+
if (issue.code === zod_1.z.ZodIssueCode.invalid_type && issue.path.length === 0) {
|
|
70
|
+
return 'expected a JSON object at root';
|
|
71
|
+
}
|
|
72
|
+
if (issue.path.length === 0) {
|
|
73
|
+
return issue.message;
|
|
74
|
+
}
|
|
75
|
+
return `${formatPath(issue.path)} ${issue.message}`;
|
|
76
|
+
}
|
|
77
|
+
function formatPath(pathParts) {
|
|
78
|
+
const [first, ...rest] = pathParts;
|
|
79
|
+
let result = String(first);
|
|
80
|
+
for (const part of rest) {
|
|
81
|
+
if (typeof part === 'number') {
|
|
82
|
+
result += `[${part}]`;
|
|
83
|
+
}
|
|
84
|
+
else {
|
|
85
|
+
result += `.${part}`;
|
|
86
|
+
}
|
|
87
|
+
}
|
|
88
|
+
return result;
|
|
89
|
+
}
|
|
90
|
+
function dedupe(values) {
|
|
91
|
+
return [...new Set(values)];
|
|
92
|
+
}
|
|
93
|
+
function dedupeSkills(skills) {
|
|
94
|
+
const unique = new Map();
|
|
95
|
+
for (const skill of skills) {
|
|
96
|
+
unique.set(`${skill.registry}::${skill.name}`, skill);
|
|
97
|
+
}
|
|
98
|
+
return [...unique.values()];
|
|
99
|
+
}
|
|
100
|
+
//# sourceMappingURL=config.js.map
|
|
@@ -0,0 +1 @@
|
|
|
1
|
+
{"version":3,"file":"config.js","sourceRoot":"","sources":["../../src/util/config.ts"],"names":[],"mappings":";;AAiEA,sDAQC;AAzED,6BAAwB;AACxB,oCAAiF;AACjF,+BAA+C;AAQ/C,MAAM,gBAAgB,GAAG,OAAC,CAAC,MAAM,CAAC;IAChC,QAAQ,EAAE,OAAC,CAAC,MAAM,EAAE,CAAC,IAAI,EAAE,CAAC,GAAG,CAAC,CAAC,EAAE,qCAAqC,CAAC;IACzE,IAAI,EAAE,OAAC,CAAC,MAAM,EAAE,CAAC,IAAI,EAAE,CAAC,GAAG,CAAC,CAAC,CAAC,CAAC,QAAQ,EAAE;IACzC,KAAK,EAAE,OAAC,CAAC,MAAM,EAAE,CAAC,IAAI,EAAE,CAAC,GAAG,CAAC,CAAC,CAAC,CAAC,QAAQ,EAAE;CAC3C,CAAC,CAAC,SAAS,CAAC,CAAC,KAAK,EAAE,GAAG,EAAe,EAAE;IACvC,MAAM,YAAY,GAAG,KAAK,CAAC,IAAI,IAAI,KAAK,CAAC,KAAK,CAAC;IAC/C,IAAI,CAAC,YAAY,EAAE,CAAC;QAClB,GAAG,CAAC,QAAQ,CAAC;YACX,IAAI,EAAE,OAAC,CAAC,YAAY,CAAC,MAAM;YAC3B,IAAI,EAAE,CAAC,MAAM,CAAC;YACd,OAAO,EAAE,mCAAmC;SAC7C,CAAC,CAAC;QACH,OAAO,OAAC,CAAC,KAAK,CAAC;IACjB,CAAC;IAED,OAAO;QACL,QAAQ,EAAE,KAAK,CAAC,QAAQ;QACxB,IAAI,EAAE,YAAY;KACnB,CAAC;AACJ,CAAC,CAAC,CAAC;AAEH,MAAM,mBAAmB,GAAG,OAAC,CAAC,MAAM,CAAC;IACnC,YAAY,EAAE,OAAC,CAAC,KAAK,CAAC,OAAC,CAAC,MAAM,EAAE,CAAC,CAAC,QAAQ,EAAE,CAAC,OAAO,CAAC,EAAE,CAAC,CAAC,WAAW,CAAC,CAAC,MAAM,EAAE,GAAG,EAAE,EAAE;QACnF,MAAM,CAAC,OAAO,CAAC,CAAC,KAAK,EAAE,KAAK,EAAE,EAAE;YAC9B,IAAI,CAAC,IAAA,4BAAsB,EAAC,KAAK,CAAC,EAAE,CAAC;gBACnC,GAAG,CAAC,QAAQ,CAAC;oBACX,IAAI,EAAE,OAAC,CAAC,YAAY,CAAC,MAAM;oBAC3B,IAAI,EAAE,CAAC,KAAK,CAAC;oBACb,OAAO,EAAE,0BAA0B,KAAK,GAAG;iBAC5C,CAAC,CAAC;YACL,CAAC;QACH,CAAC,CAAC,CAAC;IACL,CAAC,CAAC,CAAC,SAAS,CAAC,MAAM,CAAC,EAAE,CAAC,MAAM,CAAC,MAAM,CAAsB,CAAC;IAC3D,MAAM,EAAE,OAAC,CAAC,KAAK,CAAC,OAAC,CAAC,MAAM,EAAE,CAAC,CAAC,QAAQ,EAAE;IACtC,MAAM,EAAE,OAAC,CAAC,KAAK,CAAC,gBAAgB,CAAC,CAAC,QAAQ,EAAE,CAAC,OAAO,CAAC,EAAE,CAAC;CACzD,CAAC,CAAC,SAAS,CAAC,CAAC,IAAI,EAAE,GAAG,EAAE,EAAE;IACzB,MAAM,WAAW,GAAG,IAAI,CAAC,MAAM,IAAI,EAAE,CAAC;IAEtC,WAAW,CAAC,OAAO,CAAC,CAAC,KAAK,EAAE,KAAK,EAAE,EAAE;QACnC,IAAI,CAAC,wBAAgB,CAAC,QAAQ,CAAC,KAAc,CAAC,EAAE,CAAC;YAC/C,GAAG,CAAC,QAAQ,CAAC;gBACX,IAAI,EAAE,OAAC,CAAC,YAAY,CAAC,MAAM;gBAC3B,IAAI,EAAE,CAAC,QAAQ,EAAE,KAAK,CAAC;gBACvB,OAAO,EAAE,0BAA0B,KAAK,GAAG;aAC5C,CAAC,CAAC;QACL,CAAC;IACH,CAAC,CAAC,CAAC;IAEH,OAAO;QACL,YAAY,EAAE,IAAI,CAAC,YAAY;QAC/B,MAAM,EAAE,MAAM,CAAC,WAAW,CAAY;QACtC,MAAM,EAAE,YAAY,CAAC,IAAI,CAAC,MAAM,CAAC;KAClC,CAAC;AACJ,CAAC,CAAC,CAAC;AAEH,SAAgB,qBAAqB,CAAC,IAAa,EAAE,UAAkB;IACrE,MAAM,MAAM,GAAG,mBAAmB,CAAC,SAAS,CAAC,IAAI,CAAC,CAAC;IAEnD,IAAI,CAAC,MAAM,CAAC,OAAO,EAAE,CAAC;QACpB,MAAM,IAAI,KAAK,CAAC,uBAAuB,UAAU,KAAK,cAAc,CAAC,MAAM,CAAC,KAAK,CAAC,EAAE,CAAC,CAAC;IACxF,CAAC;IAED,OAAO,MAAM,CAAC,IAAI,CAAC;AACrB,CAAC;AAED,SAAS,cAAc,CAAC,KAAiB;IACvC,MAAM,KAAK,GAAG,KAAK,CAAC,MAAM,CAAC,CAAC,CAAC,CAAC;IAC9B,IAAI,CAAC,KAAK,EAAE,CAAC;QACX,OAAO,mBAAmB,CAAC;IAC7B,CAAC;IAED,IAAI,KAAK,CAAC,IAAI,KAAK,OAAC,CAAC,YAAY,CAAC,YAAY,IAAI,KAAK,CAAC,IAAI,CAAC,MAAM,KAAK,CAAC,EAAE,CAAC;QAC1E,OAAO,gCAAgC,CAAC;IAC1C,CAAC;IAED,IAAI,KAAK,CAAC,IAAI,CAAC,MAAM,KAAK,CAAC,EAAE,CAAC;QAC5B,OAAO,KAAK,CAAC,OAAO,CAAC;IACvB,CAAC;IAED,OAAO,GAAG,UAAU,CAAC,KAAK,CAAC,IAAI,CAAC,IAAI,KAAK,CAAC,OAAO,EAAE,CAAC;AACtD,CAAC;AAED,SAAS,UAAU,CAAC,SAAiC;IACnD,MAAM,CAAC,KAAK,EAAE,GAAG,IAAI,CAAC,GAAG,SAAS,CAAC;IACnC,IAAI,MAAM,GAAG,MAAM,CAAC,KAAK,CAAC,CAAC;IAE3B,KAAK,MAAM,IAAI,IAAI,IAAI,EAAE,CAAC;QACxB,IAAI,OAAO,IAAI,KAAK,QAAQ,EAAE,CAAC;YAC7B,MAAM,IAAI,IAAI,IAAI,GAAG,CAAC;QACxB,CAAC;aAAM,CAAC;YACN,MAAM,IAAI,IAAI,IAAI,EAAE,CAAC;QACvB,CAAC;IACH,CAAC;IAED,OAAO,MAAM,CAAC;AAChB,CAAC;AAED,SAAS,MAAM,CAAI,MAAW;IAC5B,OAAO,CAAC,GAAG,IAAI,GAAG,CAAC,MAAM,CAAC,CAAC,CAAC;AAC9B,CAAC;AAED,SAAS,YAAY,CAAC,MAAqB;IACzC,MAAM,MAAM,GAAG,IAAI,GAAG,EAAuB,CAAC;IAE9C,KAAK,MAAM,KAAK,IAAI,MAAM,EAAE,CAAC;QAC3B,MAAM,CAAC,GAAG,CAAC,GAAG,KAAK,CAAC,QAAQ,KAAK,KAAK,CAAC,IAAI,EAAE,EAAE,KAAK,CAAC,CAAC;IACxD,CAAC;IAED,OAAO,CAAC,GAAG,MAAM,CAAC,MAAM,EAAE,CAAC,CAAC;AAC9B,CAAC"}
|
package/dist/util/process.d.ts
CHANGED
|
@@ -4,7 +4,7 @@
|
|
|
4
4
|
* Utilities for detecting and inspecting running processes on the system.
|
|
5
5
|
* Primarily focused on macOS/Unix-like systems using the `ps` command.
|
|
6
6
|
*/
|
|
7
|
-
import type { ProcessInfo } from '
|
|
7
|
+
import type { ProcessInfo } from '@ai-devkit/agent-manager';
|
|
8
8
|
/**
|
|
9
9
|
* Options for listing processes
|
|
10
10
|
*/
|
|
@@ -1 +1 @@
|
|
|
1
|
-
{"version":3,"file":"process.d.ts","sourceRoot":"","sources":["../../src/util/process.ts"],"names":[],"mappings":"AAAA;;;;;GAKG;AAGH,OAAO,KAAK,EAAE,WAAW,EAAE,MAAM,
|
|
1
|
+
{"version":3,"file":"process.d.ts","sourceRoot":"","sources":["../../src/util/process.ts"],"names":[],"mappings":"AAAA;;;;;GAKG;AAGH,OAAO,KAAK,EAAE,WAAW,EAAE,MAAM,0BAA0B,CAAC;AAE5D;;GAEG;AACH,MAAM,WAAW,oBAAoB;IACjC,0DAA0D;IAC1D,WAAW,CAAC,EAAE,MAAM,CAAC;IAErB,iDAAiD;IACjD,IAAI,CAAC,EAAE,MAAM,EAAE,CAAC;CACnB;AAED;;;;;;;;;;;;;;GAcG;AACH,wBAAgB,aAAa,CAAC,OAAO,GAAE,oBAAyB,GAAG,WAAW,EAAE,CA2D/E;AAED;;;;;GAKG;AACH,wBAAgB,aAAa,CAAC,GAAG,EAAE,MAAM,GAAG,MAAM,CAgCjD;AAED;;;;;GAKG;AACH,wBAAgB,aAAa,CAAC,GAAG,EAAE,MAAM,GAAG,MAAM,CAYjD;AAED;;;;;GAKG;AACH,wBAAgB,gBAAgB,CAAC,GAAG,EAAE,MAAM,GAAG,OAAO,CASrD;AAED;;;;;GAKG;AACH,wBAAgB,cAAc,CAAC,GAAG,EAAE,MAAM,GAAG,WAAW,GAAG,IAAI,CAG9D"}
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "ai-devkit",
|
|
3
|
-
"version": "0.
|
|
3
|
+
"version": "0.16.0",
|
|
4
4
|
"description": "A CLI toolkit for AI-assisted software development with phase templates and environment setup",
|
|
5
5
|
"main": "dist/index.js",
|
|
6
6
|
"types": "dist/index.d.ts",
|
|
@@ -27,14 +27,16 @@
|
|
|
27
27
|
"author": "",
|
|
28
28
|
"license": "MIT",
|
|
29
29
|
"dependencies": {
|
|
30
|
-
"@ai-devkit/
|
|
30
|
+
"@ai-devkit/agent-manager": "0.2.0",
|
|
31
|
+
"@ai-devkit/memory": "0.7.0",
|
|
31
32
|
"chalk": "^4.1.2",
|
|
32
33
|
"commander": "^11.1.0",
|
|
33
34
|
"fs-extra": "^11.2.0",
|
|
34
35
|
"gray-matter": "^4.0.3",
|
|
35
36
|
"inquirer": "^8.2.6",
|
|
36
37
|
"ora": "^9.1.0",
|
|
37
|
-
"yaml": "^2.3.4"
|
|
38
|
+
"yaml": "^2.3.4",
|
|
39
|
+
"zod": "^3.25.76"
|
|
38
40
|
},
|
|
39
41
|
"devDependencies": {
|
|
40
42
|
"@types/fs-extra": "^11.0.4",
|
|
@@ -5,8 +5,10 @@ description: Document a code entry point in knowledge docs.
|
|
|
5
5
|
Guide me through creating a structured understanding of a code entry point and saving it to the knowledge docs.
|
|
6
6
|
|
|
7
7
|
1. **Gather & Validate Entry Point** — If not already provided, ask for: entry point (file, folder, function, API), why it matters (feature, bug, investigation), and desired depth or focus areas. Confirm the entry point exists; if ambiguous or not found, clarify or suggest alternatives.
|
|
8
|
-
2. **
|
|
9
|
-
3. **
|
|
10
|
-
4. **
|
|
11
|
-
5. **
|
|
12
|
-
6. **
|
|
8
|
+
2. **Use Memory for Context** — Search memory for prior knowledge about this module/domain: `npx ai-devkit@latest memory search --query "<entry point or subsystem>"`.
|
|
9
|
+
3. **Collect Source Context** — Read the primary file/module and summarize purpose, exports, key patterns. For folders: list structure, highlight key modules. For functions/APIs: capture signature, parameters, return values, error handling. Extract essential snippets (avoid large dumps).
|
|
10
|
+
4. **Analyze Dependencies** — Build a dependency view up to depth 3, tracking visited nodes to avoid loops. Categorize: imports, function calls, services, external packages. Note external systems or generated code to exclude.
|
|
11
|
+
5. **Synthesize Explanation** — Draft overview (purpose, language, high-level behavior). Detail core logic, execution flow, key patterns. Highlight error handling, performance, security considerations. Identify potential improvements or risks.
|
|
12
|
+
6. **Create Documentation** — Normalize name to kebab-case (`calculateTotalPrice` → `calculate-total-price`). Create `docs/ai/implementation/knowledge-{name}.md` with sections: Overview, Implementation Details, Dependencies, Visual Diagrams, Additional Insights, Metadata, Next Steps. Include mermaid diagrams when they clarify flows or relationships. Add metadata (analysis date, depth, files touched).
|
|
13
|
+
7. **Store Reusable Knowledge** — If insights should persist across sessions, store them using `npx ai-devkit@latest memory store ...`.
|
|
14
|
+
8. **Review & Next Actions** — Summarize key insights and open questions. Suggest related areas for deeper dives, confirm file path, and suggest `/remember` for key long-lived rules.
|
|
@@ -2,9 +2,12 @@
|
|
|
2
2
|
description: Compare implementation with design and requirements docs to ensure alignment.
|
|
3
3
|
---
|
|
4
4
|
|
|
5
|
-
Compare the current implementation with the design in docs/ai/design
|
|
5
|
+
Compare the current implementation with the design in `docs/ai/design/` and requirements in `docs/ai/requirements/`.
|
|
6
6
|
|
|
7
7
|
1. If not already provided, ask for: feature/branch description, list of modified files, relevant design doc(s), and any known constraints or assumptions.
|
|
8
|
-
2.
|
|
9
|
-
3.
|
|
10
|
-
4.
|
|
8
|
+
2. **Use Memory for Context** — Search memory for known constraints and prior decisions before assessing mismatches: `npx ai-devkit@latest memory search --query "<feature implementation alignment>"`.
|
|
9
|
+
3. For each design doc: summarize key architectural decisions and constraints, highlight components, interfaces, and data flows that must be respected.
|
|
10
|
+
4. File-by-file comparison: confirm implementation matches design intent, note deviations or missing pieces, flag logic gaps, edge cases, or security issues, suggest simplifications or refactors, and identify missing tests or documentation updates.
|
|
11
|
+
5. **Store Reusable Knowledge** — Save recurring alignment lessons/patterns with `npx ai-devkit@latest memory store ...`.
|
|
12
|
+
6. Summarize findings with recommended next steps.
|
|
13
|
+
7. **Next Command Guidance** — If major design issues are found, go back to `/review-design` or `/execute-plan`; if aligned, continue to `/writing-test`.
|
|
@@ -5,7 +5,10 @@ description: Pre-push code review against design docs.
|
|
|
5
5
|
Perform a local code review **before** pushing changes.
|
|
6
6
|
|
|
7
7
|
1. **Gather Context** — If not already provided, ask for: feature/branch description, list of modified files, relevant design doc(s) (e.g., `docs/ai/design/feature-{name}.md`), known constraints or risky areas, and which tests have been run. Also review the latest diff via `git status` and `git diff --stat`.
|
|
8
|
-
2. **
|
|
9
|
-
3. **
|
|
10
|
-
4. **
|
|
11
|
-
5. **
|
|
8
|
+
2. **Use Memory for Context** — Search memory for project review standards and recurring pitfalls: `npx ai-devkit@latest memory search --query "code review checklist project conventions"`.
|
|
9
|
+
3. **Understand Design Alignment** — For each design doc, summarize architectural intent and critical constraints.
|
|
10
|
+
4. **File-by-File Review** — For every modified file: check alignment with design/requirements and flag deviations, spot logic issues/edge cases/redundant code, flag security concerns (input validation, secrets, auth, data handling), check error handling/performance/observability, and identify missing or outdated tests.
|
|
11
|
+
5. **Cross-Cutting Concerns** — Verify naming consistency and project conventions. Confirm docs/comments updated where behavior changed. Identify missing tests (unit, integration, E2E). Check for needed configuration/migration updates.
|
|
12
|
+
6. **Store Reusable Knowledge** — Save durable review findings/checklists with `npx ai-devkit@latest memory store ...`.
|
|
13
|
+
7. **Summarize Findings** — Categorize each finding as **blocking**, **important**, or **nice-to-have** with: file, issue, impact, recommendation, and design reference.
|
|
14
|
+
8. **Next Command Guidance** — If blocking issues remain, return to `/execute-plan` (code fixes) or `/writing-test` (test gaps); if clean, proceed with push/PR workflow.
|
|
@@ -5,7 +5,10 @@ description: Debug an issue with structured root-cause analysis before changing
|
|
|
5
5
|
Help me debug an issue. Clarify expectations, identify gaps, and agree on a fix plan before changing code.
|
|
6
6
|
|
|
7
7
|
1. **Gather Context** — If not already provided, ask for: issue description (what is happening vs what should happen), error messages/logs/screenshots, recent related changes or deployments, and scope of impact.
|
|
8
|
-
2. **
|
|
9
|
-
3. **
|
|
10
|
-
4. **
|
|
11
|
-
5. **
|
|
8
|
+
2. **Use Memory for Context** — Search memory for similar incidents/fixes before deep investigation: `npx ai-devkit@latest memory search --query "<issue symptoms or error>"`.
|
|
9
|
+
3. **Clarify Reality vs Expectation** — Restate observed vs expected behavior. Confirm relevant requirements or docs that define the expectation. Define acceptance criteria for the fix.
|
|
10
|
+
4. **Reproduce & Isolate** — Determine reproducibility (always, intermittent, environment-specific). Capture reproduction steps. List suspected components or modules.
|
|
11
|
+
5. **Analyze Potential Causes** — Brainstorm root causes (data, config, code regressions, external dependencies). Gather supporting evidence (logs, metrics, traces). Highlight unknowns needing investigation.
|
|
12
|
+
6. **Resolve** — Present resolution options (quick fix, refactor, rollback, etc.) with pros/cons and risks. Ask which option to pursue. Summarize chosen approach, pre-work, success criteria, and validation steps.
|
|
13
|
+
7. **Store Reusable Knowledge** — Save root-cause and fix patterns via `npx ai-devkit@latest memory store ...`.
|
|
14
|
+
8. **Next Command Guidance** — After selecting a fix path, continue with `/execute-plan`; when implemented, use `/check-implementation` and `/writing-test`.
|
|
@@ -5,7 +5,10 @@ description: Execute a feature plan task by task.
|
|
|
5
5
|
Help me work through a feature plan one task at a time.
|
|
6
6
|
|
|
7
7
|
1. **Gather Context** — If not already provided, ask for: feature name (kebab-case, e.g., `user-authentication`), brief feature/branch description, planning doc path (default `docs/ai/planning/feature-{name}.md`), and any supporting docs (design, requirements, implementation).
|
|
8
|
-
2. **
|
|
9
|
-
3. **
|
|
10
|
-
4. **
|
|
11
|
-
5. **
|
|
8
|
+
2. **Use Memory for Context** — Search for prior implementation notes/patterns before starting: `npx ai-devkit@latest memory search --query "<feature implementation plan>"`.
|
|
9
|
+
3. **Load & Present Plan** — Read the planning doc and parse task lists (headings + checkboxes). Present an ordered task queue grouped by section, with status: `todo`, `in-progress`, `done`, `blocked`.
|
|
10
|
+
4. **Interactive Task Execution** — For each task in order: display context and full bullet text, reference relevant design/requirements docs, offer to outline sub-steps before starting, prompt for status update (`done`, `in-progress`, `blocked`, `skipped`) with short notes after work, and if blocked record blocker and move to a "Blocked" list.
|
|
11
|
+
5. **Update Planning Doc** — After each completed or status-changed task, run `/update-planning` to keep `docs/ai/planning/feature-{name}.md` accurate.
|
|
12
|
+
6. **Store Reusable Knowledge** — Save reusable implementation guidance/decisions with `npx ai-devkit@latest memory store ...`.
|
|
13
|
+
7. **Session Summary** — Produce a summary: Completed, In Progress (with next steps), Blocked (with blockers), Skipped/Deferred, and New Tasks.
|
|
14
|
+
8. **Next Command Guidance** — Continue `/execute-plan` until plan completion; then run `/check-implementation`.
|
|
@@ -5,14 +5,15 @@ description: Scaffold feature documentation from requirements through planning.
|
|
|
5
5
|
Guide me through adding a new feature, from requirements documentation to implementation readiness.
|
|
6
6
|
|
|
7
7
|
1. **Capture Requirement** — If not already provided, ask for: feature name (kebab-case, e.g., `user-authentication`), what problem it solves and who will use it, and key user stories.
|
|
8
|
-
2. **
|
|
8
|
+
2. **Use Memory for Context** — Before asking repetitive clarification questions, search memory for related decisions or conventions via `npx ai-devkit@latest memory search --query "<feature/topic>"` and reuse relevant context.
|
|
9
|
+
3. **Create Feature Documentation Structure** — Copy each template's content (preserving YAML frontmatter and section headings) into feature-specific files:
|
|
9
10
|
- `docs/ai/requirements/README.md` → `docs/ai/requirements/feature-{name}.md`
|
|
10
11
|
- `docs/ai/design/README.md` → `docs/ai/design/feature-{name}.md`
|
|
11
12
|
- `docs/ai/planning/README.md` → `docs/ai/planning/feature-{name}.md`
|
|
12
13
|
- `docs/ai/implementation/README.md` → `docs/ai/implementation/feature-{name}.md`
|
|
13
14
|
- `docs/ai/testing/README.md` → `docs/ai/testing/feature-{name}.md`
|
|
14
|
-
|
|
15
|
-
|
|
16
|
-
|
|
17
|
-
|
|
18
|
-
|
|
15
|
+
4. **Requirements Phase** — Fill out `docs/ai/requirements/feature-{name}.md`: problem statement, goals/non-goals, user stories, success criteria, constraints, open questions.
|
|
16
|
+
5. **Design Phase** — Fill out `docs/ai/design/feature-{name}.md`: architecture changes, data models, API/interfaces, components, design decisions, security and performance considerations.
|
|
17
|
+
6. **Planning Phase** — Fill out `docs/ai/planning/feature-{name}.md`: task breakdown with subtasks, dependencies, effort estimates, implementation order, risks.
|
|
18
|
+
7. **Store Reusable Knowledge** — When important conventions or decisions are finalized, store them via `npx ai-devkit@latest memory store --title "<title>" --content "<knowledge>" --tags "<tags>"`.
|
|
19
|
+
8. **Next Command Guidance** — Run `/review-requirements` first, then `/review-design`. If both pass, continue with `/execute-plan`.
|