@compilr-dev/agents 0.1.0 → 0.2.1
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/dist/agent.d.ts +168 -1
- package/dist/agent.js +268 -14
- package/dist/context/file-tracker.d.ts +156 -0
- package/dist/context/file-tracker.js +358 -0
- package/dist/context/file-tracking-hook.d.ts +29 -0
- package/dist/context/file-tracking-hook.js +103 -0
- package/dist/context/index.d.ts +5 -1
- package/dist/context/index.js +3 -0
- package/dist/context/manager.d.ts +69 -1
- package/dist/context/manager.js +304 -0
- package/dist/context/types.d.ts +95 -0
- package/dist/index.d.ts +5 -5
- package/dist/index.js +7 -3
- package/dist/messages/index.d.ts +13 -0
- package/dist/messages/index.js +51 -0
- package/dist/permissions/manager.js +6 -1
- package/dist/providers/gemini.js +1 -3
- package/dist/providers/mock.js +8 -0
- package/dist/providers/openai-compatible.js +1 -3
- package/dist/skills/index.js +691 -0
- package/dist/tools/builtin/index.d.ts +6 -1
- package/dist/tools/builtin/index.js +7 -0
- package/dist/tools/builtin/suggest.d.ts +57 -0
- package/dist/tools/builtin/suggest.js +99 -0
- package/dist/tools/builtin/task.js +13 -8
- package/dist/tools/builtin/tool-names.d.ts +44 -0
- package/dist/tools/builtin/tool-names.js +51 -0
- package/dist/tools/index.d.ts +2 -2
- package/dist/tools/index.js +5 -1
- package/dist/tools/registry.d.ts +4 -0
- package/dist/tools/registry.js +9 -0
- package/package.json +4 -4
package/dist/skills/index.js
CHANGED
|
@@ -261,6 +261,697 @@ Provide actionable plans with clear next steps.`,
|
|
|
261
261
|
Apply OWASP guidelines and security best practices.`,
|
|
262
262
|
tags: ['security', 'review'],
|
|
263
263
|
}),
|
|
264
|
+
defineSkill({
|
|
265
|
+
name: 'design',
|
|
266
|
+
description: 'Guide user through project design and requirements gathering',
|
|
267
|
+
prompt: `You are in DESIGN MODE. Your goal is to gather enough information to populate the project backlog with 5-15 actionable items.
|
|
268
|
+
|
|
269
|
+
## PHASES
|
|
270
|
+
|
|
271
|
+
### Phase 1: Vision (3-5 questions)
|
|
272
|
+
Understand the big picture:
|
|
273
|
+
- What problem does this solve?
|
|
274
|
+
- Who is the target user/customer?
|
|
275
|
+
- What's the one-sentence pitch?
|
|
276
|
+
- What makes this different from alternatives?
|
|
277
|
+
|
|
278
|
+
After gathering answers, summarize the vision and confirm with user.
|
|
279
|
+
|
|
280
|
+
### Phase 2: Core Features (3-5 questions)
|
|
281
|
+
Define MVP scope:
|
|
282
|
+
- What are the 3-5 must-have features for v1?
|
|
283
|
+
- What explicitly can wait for v2?
|
|
284
|
+
- Are there any non-negotiable technical requirements?
|
|
285
|
+
|
|
286
|
+
Use the ask_user tool to present feature options when helpful.
|
|
287
|
+
|
|
288
|
+
### Phase 3: Technical Context (2-3 questions)
|
|
289
|
+
Understand constraints:
|
|
290
|
+
- Any existing systems to integrate with?
|
|
291
|
+
- Performance/scale requirements?
|
|
292
|
+
- Compliance/security requirements?
|
|
293
|
+
|
|
294
|
+
### Phase 4: Output
|
|
295
|
+
When you have enough information:
|
|
296
|
+
1. Summarize the design in a concise format
|
|
297
|
+
2. Check if project needs foundation:
|
|
298
|
+
- Use detect_project tool to check current state
|
|
299
|
+
- If no src/, package.json, or code files exist → this is a fresh project
|
|
300
|
+
3. Use backlog_write to create 5-15 items:
|
|
301
|
+
- **For fresh projects, ALWAYS add first:**
|
|
302
|
+
| CHORE-001 | chore | 📋 | critical | Project scaffolding | Create project structure, dependencies, and build config based on tech stack |
|
|
303
|
+
- Core features (type: feature, priority: high)
|
|
304
|
+
- Nice-to-haves (type: feature, priority: medium/low)
|
|
305
|
+
- Technical setup tasks (type: chore, priority: high)
|
|
306
|
+
- Known risks/unknowns (type: tech-debt, priority: medium)
|
|
307
|
+
4. Update the PRD.md file with gathered requirements:
|
|
308
|
+
- Use the edit tool to update PRD.md (located in .compilr/requirements/PRD.md or {project}-docs/00-requirements/PRD.md)
|
|
309
|
+
- Fill in: Problem Statement, Goals, User Stories, Functional Requirements
|
|
310
|
+
- Keep the existing structure, just replace placeholder text
|
|
311
|
+
5. Present the backlog and PRD summary to user for confirmation
|
|
312
|
+
- If CHORE-001 was added, mention: "Run /build to start with project scaffolding"
|
|
313
|
+
|
|
314
|
+
## RULES
|
|
315
|
+
- Ask questions in batches of 2-4 using ask_user tool when possible
|
|
316
|
+
- Always offer a "Type something custom" option
|
|
317
|
+
- Summarize after each phase before moving on
|
|
318
|
+
- If user says "skip" or "later", move to next phase
|
|
319
|
+
- Stop asking when you have enough for a meaningful backlog
|
|
320
|
+
- Total interaction should be 10-20 questions max
|
|
321
|
+
|
|
322
|
+
## COMPLETION CRITERIA
|
|
323
|
+
✓ Vision is clear and confirmed
|
|
324
|
+
✓ MVP features are defined
|
|
325
|
+
✓ Backlog has 5-15 items
|
|
326
|
+
✓ For fresh projects: CHORE-001 scaffolding item is first (critical priority)
|
|
327
|
+
✓ PRD.md is populated with requirements
|
|
328
|
+
✓ User has approved the backlog`,
|
|
329
|
+
tags: ['planning', 'requirements'],
|
|
330
|
+
}),
|
|
331
|
+
defineSkill({
|
|
332
|
+
name: 'refine',
|
|
333
|
+
description: 'Iteratively refine and expand project requirements',
|
|
334
|
+
prompt: `You are in REFINE MODE. Your goal is to deepen and expand existing requirements based on user feedback.
|
|
335
|
+
|
|
336
|
+
## STARTUP
|
|
337
|
+
|
|
338
|
+
1. Use todo_write to create a task list:
|
|
339
|
+
- "Get backlog overview"
|
|
340
|
+
- "Ask user what to refine"
|
|
341
|
+
- "Refine selected items"
|
|
342
|
+
- "Update backlog"
|
|
343
|
+
|
|
344
|
+
2. Use backlog_read with limit:10 to get overview (NOT all items!)
|
|
345
|
+
- Note the total count and what types/priorities exist
|
|
346
|
+
- If total > 10, mention there are more items available
|
|
347
|
+
|
|
348
|
+
3. Use ask_user_simple to ask what the user wants to focus on:
|
|
349
|
+
- Question: "What would you like to refine?"
|
|
350
|
+
- Options based on what you found (e.g., "High priority features", "Technical debt items", "A specific item by ID")
|
|
351
|
+
|
|
352
|
+
## REFINEMENT APPROACHES
|
|
353
|
+
|
|
354
|
+
### 1. Expand Existing Items
|
|
355
|
+
For items that are too vague:
|
|
356
|
+
- Break down into sub-tasks
|
|
357
|
+
- Add acceptance criteria
|
|
358
|
+
- Clarify scope boundaries
|
|
359
|
+
|
|
360
|
+
### 2. Add Missing Items
|
|
361
|
+
Identify gaps:
|
|
362
|
+
- Edge cases not covered
|
|
363
|
+
- Error handling scenarios
|
|
364
|
+
- Integration points
|
|
365
|
+
|
|
366
|
+
### 3. Reprioritize
|
|
367
|
+
Based on new understanding:
|
|
368
|
+
- Promote blockers, demote nice-to-haves
|
|
369
|
+
- Identify dependencies
|
|
370
|
+
|
|
371
|
+
### 4. Technical Deep-Dive
|
|
372
|
+
For complex features:
|
|
373
|
+
- Architecture decisions
|
|
374
|
+
- Technology choices
|
|
375
|
+
|
|
376
|
+
## TOOLS TO USE
|
|
377
|
+
|
|
378
|
+
- **ask_user_simple**: For single-choice questions (preferred for most interactions)
|
|
379
|
+
- **ask_user**: For multi-question batches (when gathering related info)
|
|
380
|
+
- **backlog_read**: Use id param to get specific item, use search/filters otherwise
|
|
381
|
+
- **backlog_write**: Update items after refinement decisions
|
|
382
|
+
- **todo_write**: Track your progress through refinement
|
|
383
|
+
|
|
384
|
+
## RULES
|
|
385
|
+
|
|
386
|
+
1. ALWAYS use ask_user_simple or ask_user for decisions - NEVER ask questions in plain text
|
|
387
|
+
2. Keep backlog reads efficient - use filters and limits
|
|
388
|
+
3. One refinement focus at a time
|
|
389
|
+
4. Update backlog with backlog_write after each decision
|
|
390
|
+
5. Summarize changes at the end
|
|
391
|
+
|
|
392
|
+
## COMPLETION CRITERIA
|
|
393
|
+
✓ User's refinement goals are addressed
|
|
394
|
+
✓ Backlog is updated with changes
|
|
395
|
+
✓ No open questions remain`,
|
|
396
|
+
tags: ['planning', 'requirements'],
|
|
397
|
+
}),
|
|
398
|
+
defineSkill({
|
|
399
|
+
name: 'sketch',
|
|
400
|
+
description: 'Quick project outline with simple questions',
|
|
401
|
+
prompt: `You are in SKETCH MODE. Ask 6 quick questions, then create backlog items.
|
|
402
|
+
|
|
403
|
+
STEPS:
|
|
404
|
+
1. Use todo_write with 6 tasks (one per question)
|
|
405
|
+
2. Ask each question using ask_user_simple tool
|
|
406
|
+
3. After each answer, mark that todo complete
|
|
407
|
+
4. After all questions, check if this is a fresh project:
|
|
408
|
+
- Use detect_project to check if src/, package.json, or code files exist
|
|
409
|
+
- If fresh project → add CHORE-001 scaffolding item first (critical priority)
|
|
410
|
+
5. Use backlog_write to create 3-8 items
|
|
411
|
+
6. Summarize and suggest /design for more detail (or /build to start scaffolding)
|
|
412
|
+
|
|
413
|
+
QUESTIONS (ask one at a time):
|
|
414
|
+
1. App type? Options: Web app, Mobile app, CLI tool, API service
|
|
415
|
+
2. Target users? Options: Developers, Business users, Consumers, Internal team
|
|
416
|
+
3. Main problem it solves? (free text, no options)
|
|
417
|
+
4. Must-have features? (free text, no options)
|
|
418
|
+
5. Tech needs? Options: Database, Authentication, External APIs, None
|
|
419
|
+
6. Timeline? Options: Quick prototype, MVP in weeks, Full product
|
|
420
|
+
|
|
421
|
+
RULES:
|
|
422
|
+
- One ask_user_simple call per question
|
|
423
|
+
- Keep it simple and fast
|
|
424
|
+
- For fresh projects, ALWAYS add CHORE-001 scaffolding as first item`,
|
|
425
|
+
tags: ['planning', 'requirements'],
|
|
426
|
+
}),
|
|
427
|
+
defineSkill({
|
|
428
|
+
name: 'refine-item',
|
|
429
|
+
description: 'Focused refinement of a specific backlog item',
|
|
430
|
+
prompt: `You are in FOCUSED REFINE MODE. Your goal is to refine a specific backlog item.
|
|
431
|
+
|
|
432
|
+
## STARTUP
|
|
433
|
+
|
|
434
|
+
1. Use backlog_read with id parameter to get the specific item
|
|
435
|
+
2. Use todo_write to track progress:
|
|
436
|
+
- "Review current item"
|
|
437
|
+
- "Gather refinement details"
|
|
438
|
+
- "Update backlog"
|
|
439
|
+
|
|
440
|
+
3. Present the item and ask what to refine using ask_user_simple:
|
|
441
|
+
- Question: "How would you like to refine this item?"
|
|
442
|
+
- Options: "Break into subtasks", "Add details/criteria", "Change priority", "Technical deep-dive"
|
|
443
|
+
|
|
444
|
+
## REFINEMENT FLOW
|
|
445
|
+
|
|
446
|
+
Based on user's choice:
|
|
447
|
+
|
|
448
|
+
### Break into subtasks
|
|
449
|
+
- Use ask_user_simple to ask how many subtasks (2-5)
|
|
450
|
+
- For each subtask, use ask_user_simple to get title
|
|
451
|
+
- Use backlog_write to add new items
|
|
452
|
+
- Optionally update original item status
|
|
453
|
+
|
|
454
|
+
### Add details/criteria
|
|
455
|
+
- Use ask_user to gather:
|
|
456
|
+
- Acceptance criteria
|
|
457
|
+
- Edge cases
|
|
458
|
+
- Dependencies
|
|
459
|
+
- Use backlog_write to update description
|
|
460
|
+
|
|
461
|
+
### Change priority
|
|
462
|
+
- Use ask_user_simple with priority options
|
|
463
|
+
- Use backlog_write to update
|
|
464
|
+
|
|
465
|
+
### Technical deep-dive
|
|
466
|
+
- Use ask_user to gather:
|
|
467
|
+
- Architecture approach
|
|
468
|
+
- Technology choices
|
|
469
|
+
- Risks/concerns
|
|
470
|
+
- Add as new tech-debt item or update description
|
|
471
|
+
|
|
472
|
+
## RULES
|
|
473
|
+
|
|
474
|
+
1. ALWAYS use ask_user_simple for single choices
|
|
475
|
+
2. Use ask_user for multi-field input
|
|
476
|
+
3. Update backlog after each decision
|
|
477
|
+
4. Summarize what was changed at the end
|
|
478
|
+
|
|
479
|
+
## COMPLETION
|
|
480
|
+
✓ Item is refined per user's request
|
|
481
|
+
✓ Backlog is updated
|
|
482
|
+
✓ Changes are summarized`,
|
|
483
|
+
tags: ['planning', 'requirements'],
|
|
484
|
+
}),
|
|
485
|
+
defineSkill({
|
|
486
|
+
name: 'architecture',
|
|
487
|
+
description: 'Create architecture documentation (ADRs, diagrams, data models, API designs)',
|
|
488
|
+
prompt: `You are in ARCHITECTURE MODE. Your goal is to create architecture documentation.
|
|
489
|
+
|
|
490
|
+
## DOCUMENT TYPE: {{doc_type}}
|
|
491
|
+
{{#if custom_topic}}Custom Topic: {{custom_topic}}{{/if}}
|
|
492
|
+
|
|
493
|
+
## STARTUP
|
|
494
|
+
|
|
495
|
+
1. Use todo_write to track your progress:
|
|
496
|
+
- "Read project context"
|
|
497
|
+
- "Gather requirements"
|
|
498
|
+
- "Create document"
|
|
499
|
+
- "Confirm with user"
|
|
500
|
+
|
|
501
|
+
2. Read project context:
|
|
502
|
+
- Check for PRD.md (project vision and requirements)
|
|
503
|
+
- Use backlog_read with limit:10 for feature overview
|
|
504
|
+
- Check existing architecture docs to avoid duplicates
|
|
505
|
+
|
|
506
|
+
## DOCUMENT TEMPLATES
|
|
507
|
+
|
|
508
|
+
### For ADR (Architecture Decision Record)
|
|
509
|
+
Location: .compilr/architecture/decisions/ADR-NNN-{{slug}}.md or {project}-docs/02-architecture/decisions/ADR-NNN-{{slug}}.md
|
|
510
|
+
|
|
511
|
+
Use ask_user to gather:
|
|
512
|
+
1. What decision is being documented?
|
|
513
|
+
2. What problem or need prompted this decision?
|
|
514
|
+
3. What alternatives were considered?
|
|
515
|
+
4. What are the trade-offs of the chosen approach?
|
|
516
|
+
|
|
517
|
+
Template:
|
|
518
|
+
\`\`\`markdown
|
|
519
|
+
# ADR-NNN: {{title}}
|
|
520
|
+
|
|
521
|
+
**Status:** Proposed | Accepted | Deprecated | Superseded
|
|
522
|
+
**Date:** {{YYYY-MM-DD}}
|
|
523
|
+
**Deciders:** {{who made this decision}}
|
|
524
|
+
|
|
525
|
+
---
|
|
526
|
+
|
|
527
|
+
## Context
|
|
528
|
+
|
|
529
|
+
{{What is the issue that we're seeing that is motivating this decision?}}
|
|
530
|
+
|
|
531
|
+
## Decision
|
|
532
|
+
|
|
533
|
+
{{What is the change that we're proposing and/or doing?}}
|
|
534
|
+
|
|
535
|
+
## Consequences
|
|
536
|
+
|
|
537
|
+
### Positive
|
|
538
|
+
- {{benefit 1}}
|
|
539
|
+
- {{benefit 2}}
|
|
540
|
+
|
|
541
|
+
### Negative
|
|
542
|
+
- {{trade-off 1}}
|
|
543
|
+
- {{trade-off 2}}
|
|
544
|
+
|
|
545
|
+
### Risks
|
|
546
|
+
- {{risk 1}}
|
|
547
|
+
|
|
548
|
+
---
|
|
549
|
+
|
|
550
|
+
## Alternatives Considered
|
|
551
|
+
|
|
552
|
+
### {{Alternative 1}}
|
|
553
|
+
{{description}}
|
|
554
|
+
**Rejected because:** {{reason}}
|
|
555
|
+
|
|
556
|
+
---
|
|
557
|
+
|
|
558
|
+
*Generated by /arch*
|
|
559
|
+
\`\`\`
|
|
560
|
+
|
|
561
|
+
### For System Diagram
|
|
562
|
+
Location: .compilr/architecture/diagrams/{{slug}}.md or {project}-docs/02-architecture/diagrams/{{slug}}.md
|
|
563
|
+
|
|
564
|
+
Use ask_user to gather:
|
|
565
|
+
1. What are the main components/services?
|
|
566
|
+
2. How do they communicate?
|
|
567
|
+
3. What external integrations exist?
|
|
568
|
+
4. What data flows between components?
|
|
569
|
+
|
|
570
|
+
Generate a Mermaid diagram with explanation.
|
|
571
|
+
|
|
572
|
+
### For Data Model
|
|
573
|
+
Location: .compilr/architecture/data-model.md or {project}-docs/02-architecture/data-model.md
|
|
574
|
+
|
|
575
|
+
Use ask_user to gather:
|
|
576
|
+
1. What are the main entities?
|
|
577
|
+
2. What are the relationships between them?
|
|
578
|
+
3. What are the key fields and constraints?
|
|
579
|
+
|
|
580
|
+
Generate entity descriptions and a Mermaid ER diagram.
|
|
581
|
+
|
|
582
|
+
### For API Design
|
|
583
|
+
Location: .compilr/architecture/api-design.md or {project}-docs/02-architecture/api-design.md
|
|
584
|
+
|
|
585
|
+
Use ask_user to gather:
|
|
586
|
+
1. What resources/endpoints are needed?
|
|
587
|
+
2. What authentication approach?
|
|
588
|
+
3. What are the main request/response formats?
|
|
589
|
+
|
|
590
|
+
Generate OpenAPI-style documentation.
|
|
591
|
+
|
|
592
|
+
### For Custom Topic
|
|
593
|
+
Location: .compilr/architecture/{{slug}}.md or {project}-docs/02-architecture/{{slug}}.md
|
|
594
|
+
|
|
595
|
+
Use ask_user to understand:
|
|
596
|
+
1. What aspect of architecture to document?
|
|
597
|
+
2. What level of detail is needed?
|
|
598
|
+
3. Who is the audience?
|
|
599
|
+
|
|
600
|
+
Generate appropriate documentation.
|
|
601
|
+
|
|
602
|
+
## RULES
|
|
603
|
+
|
|
604
|
+
1. Use ask_user or ask_user_simple for structured input
|
|
605
|
+
2. Read existing docs first to avoid duplicates
|
|
606
|
+
3. For ADRs, auto-number based on existing ADRs in the directory
|
|
607
|
+
4. Create directories if they don't exist
|
|
608
|
+
5. Follow the appropriate template for the document type
|
|
609
|
+
6. Include Mermaid diagrams where helpful
|
|
610
|
+
7. Summarize what was created at the end
|
|
611
|
+
|
|
612
|
+
## COMPLETION CRITERIA
|
|
613
|
+
✓ Document is created in correct location
|
|
614
|
+
✓ All sections are properly filled in
|
|
615
|
+
✓ Diagrams render correctly (valid Mermaid syntax)
|
|
616
|
+
✓ User has reviewed the output`,
|
|
617
|
+
tags: ['architecture', 'documentation'],
|
|
618
|
+
}),
|
|
619
|
+
defineSkill({
|
|
620
|
+
name: 'prd',
|
|
621
|
+
description: 'Amend or enhance the Product Requirements Document',
|
|
622
|
+
prompt: `You are in PRD MODE. Your goal is to update or enhance the existing Product Requirements Document.
|
|
623
|
+
|
|
624
|
+
## STARTUP
|
|
625
|
+
|
|
626
|
+
1. Use todo_write to track your progress:
|
|
627
|
+
- "Read current PRD"
|
|
628
|
+
- "Identify section to update"
|
|
629
|
+
- "Gather updates"
|
|
630
|
+
- "Write updated PRD"
|
|
631
|
+
|
|
632
|
+
2. Read the existing PRD.md:
|
|
633
|
+
- Location: .compilr/requirements/PRD.md or {project}-docs/00-requirements/PRD.md
|
|
634
|
+
- If no PRD exists, inform the user to run /design first
|
|
635
|
+
|
|
636
|
+
3. Present current PRD sections to user using ask_user_simple:
|
|
637
|
+
- Question: "Which section would you like to update?"
|
|
638
|
+
- Options based on PRD structure (Vision, Scope, Technical, Success Criteria)
|
|
639
|
+
|
|
640
|
+
## PRD STRUCTURE
|
|
641
|
+
|
|
642
|
+
The PRD has these sections that can be updated:
|
|
643
|
+
|
|
644
|
+
### 1. Vision
|
|
645
|
+
- Problem Statement
|
|
646
|
+
- Target Users
|
|
647
|
+
- Value Proposition
|
|
648
|
+
- Differentiation
|
|
649
|
+
|
|
650
|
+
### 2. Scope
|
|
651
|
+
- MVP Features (v1)
|
|
652
|
+
- Future Features (v2+)
|
|
653
|
+
- Out of Scope
|
|
654
|
+
|
|
655
|
+
### 3. Technical Context
|
|
656
|
+
- Integrations
|
|
657
|
+
- Constraints (Performance, Scale, Compliance)
|
|
658
|
+
- Tech Stack
|
|
659
|
+
|
|
660
|
+
### 4. Success Criteria
|
|
661
|
+
- How do we know when this is done?
|
|
662
|
+
|
|
663
|
+
## UPDATE FLOW
|
|
664
|
+
|
|
665
|
+
Based on section selected:
|
|
666
|
+
|
|
667
|
+
1. Show current content of that section
|
|
668
|
+
2. Use ask_user to gather:
|
|
669
|
+
- What to add/change
|
|
670
|
+
- What to remove
|
|
671
|
+
- Any clarifications
|
|
672
|
+
3. Use the edit tool to update PRD.md
|
|
673
|
+
4. Show the updated section for confirmation
|
|
674
|
+
|
|
675
|
+
## RULES
|
|
676
|
+
|
|
677
|
+
1. ALWAYS read the existing PRD first
|
|
678
|
+
2. Use ask_user_simple for section selection
|
|
679
|
+
3. Use ask_user for gathering detailed updates
|
|
680
|
+
4. Preserve sections you're not updating
|
|
681
|
+
5. Use edit tool (not write_file) to update specific sections
|
|
682
|
+
6. Keep formatting consistent with existing document
|
|
683
|
+
7. If scope changes affect backlog, suggest running /refine
|
|
684
|
+
|
|
685
|
+
## COMPLETION CRITERIA
|
|
686
|
+
✓ PRD.md is updated with changes
|
|
687
|
+
✓ User has reviewed the updates
|
|
688
|
+
✓ Related backlog updates are suggested if needed`,
|
|
689
|
+
tags: ['planning', 'requirements'],
|
|
690
|
+
}),
|
|
691
|
+
defineSkill({
|
|
692
|
+
name: 'session-notes',
|
|
693
|
+
description: 'Create structured session notes capturing work done and decisions made',
|
|
694
|
+
prompt: `You are in SESSION NOTES MODE. Your goal is to create a structured summary of the current session.
|
|
695
|
+
|
|
696
|
+
## STARTUP
|
|
697
|
+
|
|
698
|
+
1. Use todo_write to track your progress:
|
|
699
|
+
- "Gather session context"
|
|
700
|
+
- "Write session note"
|
|
701
|
+
- "Confirm with user"
|
|
702
|
+
|
|
703
|
+
2. Review recent conversation to understand:
|
|
704
|
+
- What was accomplished
|
|
705
|
+
- What files were changed
|
|
706
|
+
- What decisions were made
|
|
707
|
+
- What blockers were encountered
|
|
708
|
+
- What should be done next
|
|
709
|
+
|
|
710
|
+
## SESSION NOTE STRUCTURE
|
|
711
|
+
|
|
712
|
+
Create a markdown file with this structure:
|
|
713
|
+
|
|
714
|
+
\`\`\`markdown
|
|
715
|
+
# Session Note - {{title}}
|
|
716
|
+
|
|
717
|
+
**Date:** {{YYYY-MM-DD}}
|
|
718
|
+
**Project:** {{project_name}}
|
|
719
|
+
|
|
720
|
+
---
|
|
721
|
+
|
|
722
|
+
## Summary
|
|
723
|
+
|
|
724
|
+
{{2-3 sentence summary of what was accomplished}}
|
|
725
|
+
|
|
726
|
+
## Changes Made
|
|
727
|
+
|
|
728
|
+
- {{list of files created/modified}}
|
|
729
|
+
- {{features implemented}}
|
|
730
|
+
- {{bugs fixed}}
|
|
731
|
+
|
|
732
|
+
## Decisions Made
|
|
733
|
+
|
|
734
|
+
- {{architectural decisions}}
|
|
735
|
+
- {{technology choices}}
|
|
736
|
+
- {{scope changes}}
|
|
737
|
+
|
|
738
|
+
## Blockers / Issues
|
|
739
|
+
|
|
740
|
+
- {{problems encountered}}
|
|
741
|
+
- {{unresolved questions}}
|
|
742
|
+
|
|
743
|
+
## Next Steps
|
|
744
|
+
|
|
745
|
+
- [ ] {{actionable next task}}
|
|
746
|
+
- [ ] {{follow-up item}}
|
|
747
|
+
|
|
748
|
+
---
|
|
749
|
+
|
|
750
|
+
*Generated by /note*
|
|
751
|
+
\`\`\`
|
|
752
|
+
|
|
753
|
+
## FILE LOCATION
|
|
754
|
+
|
|
755
|
+
Save the note to:
|
|
756
|
+
- Single repo: \`.compilr/sessions/{{YYYY-MM-DD}}-{{slug}}.md\`
|
|
757
|
+
- Two repo: \`{{project}}-docs/04-session-notes/{{YYYY-MM-DD}}-{{slug}}.md\`
|
|
758
|
+
|
|
759
|
+
Create the directory if it doesn't exist.
|
|
760
|
+
|
|
761
|
+
## RULES
|
|
762
|
+
|
|
763
|
+
1. Use ask_user_simple to ask for a title if not provided
|
|
764
|
+
2. Keep summary concise (2-3 sentences max)
|
|
765
|
+
3. List concrete changes, not vague descriptions
|
|
766
|
+
4. Decisions should explain the "why"
|
|
767
|
+
5. Next steps should be actionable
|
|
768
|
+
6. If user provides a title, use it; otherwise generate one from the summary
|
|
769
|
+
|
|
770
|
+
## COMPLETION CRITERIA
|
|
771
|
+
✓ Session note file is created
|
|
772
|
+
✓ All sections are filled in
|
|
773
|
+
✓ User has reviewed the note`,
|
|
774
|
+
tags: ['documentation', 'session'],
|
|
775
|
+
}),
|
|
776
|
+
defineSkill({
|
|
777
|
+
name: 'build',
|
|
778
|
+
description: 'Implement a backlog item end-to-end',
|
|
779
|
+
tags: ['implementation', 'coding'],
|
|
780
|
+
prompt: `You are in BUILD MODE. Implement the specified backlog item.
|
|
781
|
+
|
|
782
|
+
## ITEM TO IMPLEMENT
|
|
783
|
+
- **ID:** {{item_id}}
|
|
784
|
+
- **Title:** {{item_title}}
|
|
785
|
+
- **Type:** {{item_type}}
|
|
786
|
+
- **Priority:** {{item_priority}}
|
|
787
|
+
- **Description:** {{item_description}}
|
|
788
|
+
|
|
789
|
+
## BEFORE STARTING
|
|
790
|
+
|
|
791
|
+
1. Show the item details to the user in a clear format
|
|
792
|
+
2. Use ask_user_simple to confirm: "Proceed with implementation?"
|
|
793
|
+
- Options: "Yes, let's build it", "No, pick a different item", "Cancel"
|
|
794
|
+
3. If there are dependency warnings, mention them and ask if user wants to proceed anyway
|
|
795
|
+
|
|
796
|
+
## CONTEXT TO READ
|
|
797
|
+
|
|
798
|
+
Before implementing, read these files for context:
|
|
799
|
+
- **PRD.md** (if exists): Project vision and requirements
|
|
800
|
+
- **CLAUDE.md**: Coding standards and conventions
|
|
801
|
+
- **Existing code**: Understand patterns already in use
|
|
802
|
+
|
|
803
|
+
## IMPLEMENTATION WORKFLOW
|
|
804
|
+
|
|
805
|
+
### Phase 1: Plan
|
|
806
|
+
1. Use todo_write to create implementation checklist:
|
|
807
|
+
- Break down the item into concrete tasks
|
|
808
|
+
- Identify files to create or modify
|
|
809
|
+
- Note any edge cases to handle
|
|
810
|
+
2. Update backlog status to 🚧 using backlog_write
|
|
811
|
+
|
|
812
|
+
### Phase 2: Implement
|
|
813
|
+
1. Write code following project conventions from CLAUDE.md
|
|
814
|
+
2. Add tests if the project has a test framework
|
|
815
|
+
3. Keep changes focused on the backlog item scope
|
|
816
|
+
4. Use todo_write to track progress through tasks
|
|
817
|
+
|
|
818
|
+
### Phase 3: Verify
|
|
819
|
+
1. Run tests with run_tests tool
|
|
820
|
+
2. Run lint with run_lint tool
|
|
821
|
+
3. If tests or lint fail:
|
|
822
|
+
- Analyze the error message
|
|
823
|
+
- Fix the issue
|
|
824
|
+
- Re-run verification
|
|
825
|
+
- Repeat up to 3 times
|
|
826
|
+
4. If still failing after 3 attempts:
|
|
827
|
+
- Report the issue to user
|
|
828
|
+
- Keep status as 🚧
|
|
829
|
+
- Ask for guidance
|
|
830
|
+
|
|
831
|
+
### Phase 4: Complete
|
|
832
|
+
1. Update backlog status to ✅ using backlog_write
|
|
833
|
+
2. Create git commit with message format:
|
|
834
|
+
- feat({{item_id}}): {{item_title}} - for features
|
|
835
|
+
- fix({{item_id}}): {{item_title}} - for bugs
|
|
836
|
+
- chore({{item_id}}): {{item_title}} - for chores
|
|
837
|
+
3. Update backlog with the commit SHA
|
|
838
|
+
4. Clear todos with todo_write
|
|
839
|
+
5. Summarize what was implemented
|
|
840
|
+
|
|
841
|
+
## RULES
|
|
842
|
+
|
|
843
|
+
- Follow coding standards from CLAUDE.md strictly
|
|
844
|
+
- Keep commits atomic - one backlog item per commit
|
|
845
|
+
- Ask user via ask_user_simple if you hit blockers
|
|
846
|
+
- Don't over-engineer - implement exactly what the item describes
|
|
847
|
+
- Don't add features beyond what was requested
|
|
848
|
+
- Use todo_write throughout to show progress
|
|
849
|
+
- Always run tests before marking complete`,
|
|
850
|
+
}),
|
|
851
|
+
defineSkill({
|
|
852
|
+
name: 'scaffold',
|
|
853
|
+
description: 'Create project foundation based on tech stack',
|
|
854
|
+
tags: ['setup', 'foundation', 'scaffolding'],
|
|
855
|
+
prompt: `You are creating the PROJECT SCAFFOLD (foundation).
|
|
856
|
+
|
|
857
|
+
## PURPOSE
|
|
858
|
+
|
|
859
|
+
Create the base project structure that features will be built on top of.
|
|
860
|
+
This is the skeleton that makes feature implementation possible.
|
|
861
|
+
|
|
862
|
+
## CONTEXT TO READ
|
|
863
|
+
|
|
864
|
+
First, read these files to understand what to build:
|
|
865
|
+
- **CLAUDE.md**: Tech stack, coding standards, project type
|
|
866
|
+
- **PRD.md** (if exists): Project vision and requirements
|
|
867
|
+
- **Existing files**: What already exists (if anything)
|
|
868
|
+
|
|
869
|
+
## BEFORE STARTING
|
|
870
|
+
|
|
871
|
+
1. Summarize the detected/specified tech stack
|
|
872
|
+
2. Use ask_user_simple to confirm: "Create project scaffold with this stack?"
|
|
873
|
+
- Options: "Yes, create it", "No, let me specify", "Cancel"
|
|
874
|
+
3. If user wants to specify, ask about tech stack preferences
|
|
875
|
+
|
|
876
|
+
## SCAFFOLD BY PROJECT TYPE
|
|
877
|
+
|
|
878
|
+
### Web Application (React/Vue/Svelte)
|
|
879
|
+
|
|
880
|
+
Create:
|
|
881
|
+
- \`src/\` folder structure:
|
|
882
|
+
- \`src/components/\` - Reusable components
|
|
883
|
+
- \`src/pages/\` or \`src/routes/\` - Page components
|
|
884
|
+
- \`src/lib/\` or \`src/utils/\` - Utility functions
|
|
885
|
+
- \`src/styles/\` - Global styles
|
|
886
|
+
- \`package.json\` with dependencies
|
|
887
|
+
- Build config (\`vite.config.ts\`, \`next.config.js\`, etc.)
|
|
888
|
+
- \`index.html\` entry point (if applicable)
|
|
889
|
+
- Basic App component with routing setup
|
|
890
|
+
- CSS/Tailwind configuration
|
|
891
|
+
- \`.gitignore\`
|
|
892
|
+
- \`README.md\` with setup instructions
|
|
893
|
+
|
|
894
|
+
### API / Backend (Node/Python/Go)
|
|
895
|
+
|
|
896
|
+
Create:
|
|
897
|
+
- \`src/\` folder structure:
|
|
898
|
+
- \`src/routes/\` or \`src/api/\` - API endpoints
|
|
899
|
+
- \`src/services/\` - Business logic
|
|
900
|
+
- \`src/models/\` - Data models
|
|
901
|
+
- \`src/utils/\` - Utilities
|
|
902
|
+
- \`package.json\` / \`requirements.txt\` / \`go.mod\`
|
|
903
|
+
- Entry point (\`src/index.ts\`, \`main.py\`, \`main.go\`)
|
|
904
|
+
- Basic server setup (Express, FastAPI, Gin, etc.)
|
|
905
|
+
- Health check endpoint (\`GET /health\`)
|
|
906
|
+
- Environment config (\`.env.example\`)
|
|
907
|
+
- \`.gitignore\`
|
|
908
|
+
- \`README.md\` with setup instructions
|
|
909
|
+
|
|
910
|
+
### CLI Tool (Node/Python/Rust)
|
|
911
|
+
|
|
912
|
+
Create:
|
|
913
|
+
- \`src/\` folder structure:
|
|
914
|
+
- \`src/commands/\` - Command handlers
|
|
915
|
+
- \`src/utils/\` - Utilities
|
|
916
|
+
- \`package.json\` with \`bin\` entry / \`setup.py\` / \`Cargo.toml\`
|
|
917
|
+
- Entry point with argument parsing
|
|
918
|
+
- Basic command structure (help, version)
|
|
919
|
+
- \`.gitignore\`
|
|
920
|
+
- \`README.md\` with usage instructions
|
|
921
|
+
|
|
922
|
+
### Full-Stack Application
|
|
923
|
+
|
|
924
|
+
Create both frontend and backend structures:
|
|
925
|
+
- \`frontend/\` or \`client/\` - Web app scaffold
|
|
926
|
+
- \`backend/\` or \`server/\` - API scaffold
|
|
927
|
+
- Root \`package.json\` with workspace config (if monorepo)
|
|
928
|
+
- \`docker-compose.yml\` (optional)
|
|
929
|
+
- \`.gitignore\`
|
|
930
|
+
- \`README.md\` with setup instructions
|
|
931
|
+
|
|
932
|
+
## POST-SCAFFOLD STEPS
|
|
933
|
+
|
|
934
|
+
1. Install dependencies:
|
|
935
|
+
- \`npm install\` / \`pip install -r requirements.txt\` / etc.
|
|
936
|
+
2. Run build to verify:
|
|
937
|
+
- \`npm run build\` / equivalent
|
|
938
|
+
3. Run lint to verify:
|
|
939
|
+
- \`npm run lint\` / equivalent
|
|
940
|
+
4. Create initial git commit:
|
|
941
|
+
- \`chore: initial project scaffold\`
|
|
942
|
+
5. Update backlog:
|
|
943
|
+
- Mark scaffold CHORE as ✅ (if exists)
|
|
944
|
+
|
|
945
|
+
## RULES
|
|
946
|
+
|
|
947
|
+
- Follow conventions from CLAUDE.md
|
|
948
|
+
- Use modern, widely-adopted patterns
|
|
949
|
+
- Keep it minimal - only what's needed to start
|
|
950
|
+
- Don't add features - just structure
|
|
951
|
+
- Ensure the project builds and lints clean
|
|
952
|
+
- Add helpful comments in config files
|
|
953
|
+
- Include TypeScript/type hints where applicable`,
|
|
954
|
+
}),
|
|
264
955
|
];
|
|
265
956
|
/**
|
|
266
957
|
* Default skill registry with built-in skills
|