@thiagodiogo/pscode 2.3.0 → 2.4.0

package/dist/core/templates/workflows/onboard.js

@@ -1,606 +0,0 @@
-export function getOnboardSkillTemplate() {
-    return {
-        name: 'pscode-onboard',
-        description: 'Guided onboarding for Pscode - walk through a complete workflow cycle with narration and real codebase work.',
-        instructions: getOnboardInstructions(),
-        compatibility: 'Requires pscode CLI.',
-        metadata: { author: 'pscode', version: '1.0' },
-    };
-}
-function getOnboardInstructions() {
-    return `Guide the user through their first complete Pscode workflow cycle. This is a teaching experience—you'll do real work in their codebase while explaining each step.
-
----
-
-## Preflight
-
-Before starting, check if the Pscode CLI is installed:
-
-\`\`\`bash
-# Unix/macOS
-pscode --version 2>&1 || echo "CLI_NOT_INSTALLED"
-# Windows (PowerShell)
-# if (Get-Command pscode -ErrorAction SilentlyContinue) { pscode --version } else { echo "CLI_NOT_INSTALLED" }
-\`\`\`
-
-**If CLI not installed:**
-> Pscode CLI is not installed. Install it first, then come back to \`/ps:onboard\`.
-
-Stop here if not installed.
-
----
-
-## Phase 1: Welcome
-
-Display:
-
-\`\`\`
-## Welcome to Pscode!
-
-I'll walk you through a complete change cycle—from idea to implementation—using a real task in your codebase. Along the way, you'll learn the workflow by doing it.
-
-**What we'll do:**
-1. Pick a small, real task in your codebase
-2. Explore the problem briefly
-3. Create a change (the container for our work)
-4. Build the artifacts: proposal → specs → design → tasks
-5. Implement the tasks
-6. Archive the completed change
-
-**Time:** ~15-20 minutes
-
-Let's start by finding something to work on.
-\`\`\`
-
----
-
-## Phase 2: Task Selection
-
-### Codebase Analysis
-
-Scan the codebase for small improvement opportunities. Look for:
-
-1. **TODO/FIXME comments** - Search for \`TODO\`, \`FIXME\`, \`HACK\`, \`XXX\` in code files
-2. **Missing error handling** - \`catch\` blocks that swallow errors, risky operations without try-catch
-3. **Functions without tests** - Cross-reference \`src/\` with test directories
-4. **Type issues** - \`any\` types in TypeScript files (\`: any\`, \`as any\`)
-5. **Debug artifacts** - \`console.log\`, \`console.debug\`, \`debugger\` statements in non-debug code
-6. **Missing validation** - User input handlers without validation
-
-Also check recent git activity:
-\`\`\`bash
-# Unix/macOS
-git log --oneline -10 2>/dev/null || echo "No git history"
-# Windows (PowerShell)
-# git log --oneline -10 2>$null; if ($LASTEXITCODE -ne 0) { echo "No git history" }
-\`\`\`
-
-### Present Suggestions
-
-From your analysis, present 3-4 specific suggestions:
-
-\`\`\`
-## Task Suggestions
-
-Based on scanning your codebase, here are some good starter tasks:
-
-**1. [Most promising task]**
-   Location: \`src/path/to/file.ts:42\`
-   Scope: ~1-2 files, ~20-30 lines
-   Why it's good: [brief reason]
-
-**2. [Second task]**
-   Location: \`src/another/file.ts\`
-   Scope: ~1 file, ~15 lines
-   Why it's good: [brief reason]
-
-**3. [Third task]**
-   Location: [location]
-   Scope: [estimate]
-   Why it's good: [brief reason]
-
-**4. Something else?**
-   Tell me what you'd like to work on.
-
-Which task interests you? (Pick a number or describe your own)
-\`\`\`
-
-**If nothing found:** Fall back to asking what the user wants to build:
-> I didn't find obvious quick wins in your codebase. What's something small you've been meaning to add or fix?
-
-### Scope Guardrail
-
-If the user picks or describes something too large (major feature, multi-day work):
-
-\`\`\`
-That's a valuable task, but it's probably larger than ideal for your first Pscode run-through.
-
-For learning the workflow, smaller is better—it lets you see the full cycle without getting stuck in implementation details.
-
-**Options:**
-1. **Slice it smaller** - What's the smallest useful piece of [their task]? Maybe just [specific slice]?
-2. **Pick something else** - One of the other suggestions, or a different small task?
-3. **Do it anyway** - If you really want to tackle this, we can. Just know it'll take longer.
-
-What would you prefer?
-\`\`\`
-
-Let the user override if they insist—this is a soft guardrail.
-
----
-
-## Phase 3: Explore Demo
-
-Once a task is selected, briefly demonstrate explore mode:
-
-\`\`\`
-Before we create a change, let me quickly show you **explore mode**—it's how you think through problems before committing to a direction.
-\`\`\`
-
-Spend 1-2 minutes investigating the relevant code:
-- Read the file(s) involved
-- Draw a quick ASCII diagram if it helps
-- Note any considerations
-
-\`\`\`
-## Quick Exploration
-
-[Your brief analysis—what you found, any considerations]
-
-┌─────────────────────────────────────────┐
-│   [Optional: ASCII diagram if helpful]  │
-└─────────────────────────────────────────┘
-
-Explore mode (\`/ps:explore\`) is for this kind of thinking—investigating before implementing. You can use it anytime you need to think through a problem.
-
-Now let's create a change to hold our work.
-\`\`\`
-
-**PAUSE** - Wait for user acknowledgment before proceeding.
-
----
-
-## Phase 4: Create the Change
-
-**EXPLAIN:**
-\`\`\`
-## Creating a Change
-
-A "change" in Pscode is a container for all the thinking and planning around a piece of work. It lives at the \`changeRoot\` reported by \`pscode status --change "<name>" --json\` and holds your artifacts—proposal, specs, design, tasks.
-
-Let me create one for our task.
-\`\`\`
-
-**DO:** Create the change with a derived kebab-case name:
-\`\`\`bash
-pscode new change "<derived-name>"
-\`\`\`
-
-**SHOW:**
-\`\`\`
-Created: <changeRoot from status JSON>
-
-The folder structure:
-\`\`\`
-<changeRoot>/
-├── proposal.md    ← Why we're doing this (empty, we'll fill it)
-├── design.md      ← How we'll build it (empty)
-├── specs/         ← Detailed requirements (empty)
-└── tasks.md       ← Implementation checklist (empty)
-\`\`\`
-
-Now let's fill in the first artifact—the proposal.
-\`\`\`
-
----
-
-## Phase 5: Proposal
-
-**EXPLAIN:**
-\`\`\`
-## The Proposal
-
-The proposal captures **why** we're making this change and **what** it involves at a high level. It's the "elevator pitch" for the work.
-
-I'll draft one based on our task.
-\`\`\`
-
-**DO:** Draft the proposal content (don't save yet):
-
-\`\`\`
-Here's a draft proposal:
-
----
-
-## Why
-
-[1-2 sentences explaining the problem/opportunity]
-
-## What Changes
-
-[Bullet points of what will be different]
-
-## Capabilities
-
-### New Capabilities
-- \`<capability-name>\`: [brief description]
-
-### Modified Capabilities
-<!-- If modifying existing behavior -->
-
-## Impact
-
-- \`src/path/to/file.ts\`: [what changes]
-- [other files if applicable]
-
----
-
-Does this capture the intent? I can adjust before we save it.
-\`\`\`
-
-**PAUSE** - Wait for user approval/feedback.
-
-After approval, save the proposal:
-\`\`\`bash
-pscode instructions proposal --change "<name>" --json
-\`\`\`
-Then write the content to the \`resolvedOutputPath\` from \`pscode instructions proposal --change "<name>" --json\`.
-
-\`\`\`
-Proposal saved. This is your "why" document—you can always come back and refine it as understanding evolves.
-
-Next up: specs.
-\`\`\`
-
----
-
-## Phase 6: Specs
-
-**EXPLAIN:**
-\`\`\`
-## Specs
-
-Specs define **what** we're building in precise, testable terms. They use a requirement/scenario format that makes expected behavior crystal clear.
-
-For a small task like this, we might only need one spec file.
-\`\`\`
-
-**DO:** Resolve where the spec file should be created:
-\`\`\`bash
-pscode instructions specs --change "<name>" --json
-# Use resolvedOutputPath from the JSON. If it is a glob, choose the concrete file path using the schema instruction and workspace planning context.
-\`\`\`
-
-Draft the spec content:
-
-\`\`\`
-Here's the spec:
-
----
-
-## ADDED Requirements
-
-### Requirement: <Name>
-
-<Description of what the system should do>
-
-#### Scenario: <Scenario name>
-
-- **WHEN** <trigger condition>
-- **THEN** <expected outcome>
-- **AND** <additional outcome if needed>
-
----
-
-This format—WHEN/THEN/AND—makes requirements testable. You can literally read them as test cases.
-\`\`\`
-
-Save to the concrete file path chosen from \`resolvedOutputPath\`.
-
----
-
-## Phase 7: Design
-
-**EXPLAIN:**
-\`\`\`
-## Design
-
-The design captures **how** we'll build it—technical decisions, tradeoffs, approach.
-
-For small changes, this might be brief. That's fine—not every change needs deep design discussion.
-\`\`\`
-
-**DO:** Draft design.md:
-
-\`\`\`
-Here's the design:
-
----
-
-## Context
-
-[Brief context about the current state]
-
-## Goals / Non-Goals
-
-**Goals:**
-- [What we're trying to achieve]
-
-**Non-Goals:**
-- [What's explicitly out of scope]
-
-## Decisions
-
-### Decision 1: [Key decision]
-
-[Explanation of approach and rationale]
-
----
-
-For a small task, this captures the key decisions without over-engineering.
-\`\`\`
-
-Save to the \`resolvedOutputPath\` from \`pscode instructions design --change "<name>" --json\`.
-
----
-
-## Phase 8: Tasks
-
-**EXPLAIN:**
-\`\`\`
-## Tasks
-
-Finally, we break the work into implementation tasks—checkboxes that drive the apply phase.
-
-These should be small, clear, and in logical order.
-\`\`\`
-
-**DO:** Generate tasks based on specs and design:
-
-\`\`\`
-Here are the implementation tasks:
-
----
-
-## 1. [Category or file]
-
-- [ ] 1.1 [Specific task]
-- [ ] 1.2 [Specific task]
-
-## 2. Verify
-
-- [ ] 2.1 [Verification step]
-
----
-
-Each checkbox becomes a unit of work in the apply phase. Ready to implement?
-\`\`\`
-
-**PAUSE** - Wait for user to confirm they're ready to implement.
-
-Save to the \`resolvedOutputPath\` from \`pscode instructions tasks --change "<name>" --json\`.
-
----
-
-## Phase 9: Apply (Implementation)
-
-**EXPLAIN:**
-\`\`\`
-## Implementation
-
-Now we implement each task, checking them off as we go. I'll announce each one and occasionally note how the specs/design informed the approach.
-\`\`\`
-
-**DO:** For each task:
-
-1. Announce: "Working on task N: [description]"
-2. Implement the change in the codebase
-3. Reference specs/design naturally: "The spec says X, so I'm doing Y"
-4. Mark complete in tasks.md: \`- [ ]\` → \`- [x]\`
-5. Brief status: "✓ Task N complete"
-
-Keep narration light—don't over-explain every line of code.
-
-After all tasks:
-
-\`\`\`
-## Implementation Complete
-
-All tasks done:
-- [x] Task 1
-- [x] Task 2
-- [x] ...
-
-The change is implemented! One more step—let's complete it.
-\`\`\`
-
----
-
-## Phase 10: Complete
-
-**EXPLAIN:**
-\`\`\`
-## Completing
-
-When a change is complete, we complete it. The archive path is derived from \`planningHome.changesDir\` and the date.
-
-Completed changes become your project's decision history—you can always find them later to understand why something was built a certain way.
-\`\`\`
-
-**DO:**
-\`\`\`bash
-pscode complete "<name>"
-\`\`\`
-
-**SHOW:**
-\`\`\`
-Archived to: \`<planningHome.changesDir>/archive/YYYY-MM-DD-<name>/\`
-
-The change is now part of your project's history. The code is in your codebase, the decision record is preserved.
-\`\`\`
-
----
-
-## Phase 11: Trello Integration (optional)
-
-After the core workflow is complete, check if the Trello MCP server is available:
-
-\`\`\`tool
-mcp__claude_ai_Trello_Custom__get_me
-\`\`\`
-
-**If the call succeeds** (Trello MCP is available):
-
-\`\`\`
-## 🎉 Trello disponível!
-
-Detectei que o servidor MCP do Trello está ativo. O Pscode pode sincronizar
-automaticamente cards no Trello conforme você avança nas suas changes.
-
-**Benefícios da integração:**
-- /ps:task   → adiciona tarefa ao Backlog do Trello
-- /ps:draft  → registra ideias em "Para Explorar"
-- /ps:propose → move card para "Em Refinamento"
-- /ps:apply  → move card para "Em Desenvolvimento" e depois "Em Teste"
-- /ps:complete → move card para "Concluído"
-
-Deseja configurar agora?
-\`\`\`
-
-Use **AskUserQuestion** to ask: "Configurar integração com Trello agora?" (Sim, configurar agora / Não, depois).
-
-If "Sim": invoke \`/ps:trello-setup\` instructions directly (run the trello-setup skill inline).
-
-If "Não": mention they can run \`/ps:trello-setup\` at any time.
-
-**If the call fails** (Trello MCP not available): skip this phase silently.
-
----
-
-## Phase 12: Recap & Next Steps
-
-\`\`\`
-## Congratulations!
-
-You just completed a full Pscode cycle:
-
-1. **Explore** - Thought through the problem
-2. **New** - Created a change container
-3. **Proposal** - Captured WHY
-4. **Specs** - Defined WHAT in detail
-5. **Design** - Decided HOW
-6. **Tasks** - Broke it into steps
-7. **Apply** - Implemented the work
-8. **Archive** - Preserved the record
-
-This same rhythm works for any size change—a small fix or a major feature.
-
----
-
-## Command Reference
-
-**Core workflow:**
-
- | Command                | What it does                               |
- |------------------------|--------------------------------------------|
- | \`/ps:propose\`     | Create a change and generate all artifacts |
- | \`/ps:explore\`     | Think through problems before/during work  |
- | \`/ps:apply\`       | Implement tasks from a change              |
- | \`/ps:complete\`     | Complete a change                          |
-
-**Additional commands:**
-
- | Command                | What it does                                             |
- |------------------------|----------------------------------------------------------|
- | \`/ps:new\`         | Start a new change, step through artifacts one at a time |
- | \`/ps:continue\`    | Continue working on an existing change                   |
- | \`/ps:ff\`          | Fast-forward: create all artifacts at once               |
- | \`/ps:verify\`      | Verify implementation matches artifacts                  |
-
-**Trello integration (if configured):**
-
- | Command                | What it does                                             |
- |------------------------|----------------------------------------------------------|
- | \`/ps:task\`        | Add an ownerless task to the Trello Backlog              |
- | \`/ps:draft\`       | Capture a raw idea in "Para Explorar"                    |
- | \`/ps:trello-setup\`| Configure or reconfigure Trello integration              |
-
----
-
-## What's Next?
-
-Try \`/ps:propose\` on something you actually want to build. You've got the rhythm now!
-\`\`\`
-
----
-
-## Graceful Exit Handling
-
-### User wants to stop mid-way
-
-If the user says they need to stop, want to pause, or seem disengaged:
-
-\`\`\`
-No problem! Your change is saved at the \`changeRoot\` reported by \`pscode status --change "<name>" --json\`.
-
-To pick up where we left off later:
-- \`/ps:continue <name>\` - Resume artifact creation
-- \`/ps:apply <name>\` - Jump to implementation (if tasks exist)
-
-The work won't be lost. Come back whenever you're ready.
-\`\`\`
-
-Exit gracefully without pressure.
-
-### User just wants command reference
-
-If the user says they just want to see the commands or skip the tutorial:
-
-\`\`\`
-## Pscode Quick Reference
-
-**Core workflow:**
-
- | Command                  | What it does                               |
- |--------------------------|--------------------------------------------|
- | \`/ps:propose <name>\` | Create a change and generate all artifacts |
- | \`/ps:explore\`        | Think through problems (no code changes)   |
- | \`/ps:apply <name>\`   | Implement tasks                            |
- | \`/ps:complete <name>\` | Complete when done                         |
-
-**Additional commands:**
-
- | Command                   | What it does                        |
- |---------------------------|-------------------------------------|
- | \`/ps:new <name>\`      | Start a new change, step by step    |
- | \`/ps:continue <name>\` | Continue an existing change         |
- | \`/ps:ff <name>\`       | Fast-forward: all artifacts at once |
- | \`/ps:verify <name>\`   | Verify implementation               |
-
-Try \`/ps:propose\` to start your first change.
-\`\`\`
-
-Exit gracefully.
-
----
-
-## Guardrails
-
-- **Follow the EXPLAIN → DO → SHOW → PAUSE pattern** at key transitions (after explore, after proposal draft, after tasks, after archive)
-- **Keep narration light** during implementation—teach without lecturing
-- **Don't skip phases** even if the change is small—the goal is teaching the workflow
-- **Pause for acknowledgment** at marked points, but don't over-pause
-- **Handle exits gracefully**—never pressure the user to continue
-- **Use real codebase tasks**—don't simulate or use fake examples
-- **Adjust scope gently**—guide toward smaller tasks but respect user choice`;
-}
-export function getPsOnboardCommandTemplate() {
-    return {
-        name: 'PS: Onboard',
-        description: 'Guided onboarding - walk through a complete Pscode workflow cycle with narration',
-        category: 'Workflow',
-        tags: ['workflow', 'onboarding', 'tutorial', 'learning'],
-        content: getOnboardInstructions(),
-    };
-}
-//# sourceMappingURL=onboard.js.map

package/dist/core/templates/workflows/verify-change.d.ts

@@ -1,10 +0,0 @@
-/**
- * Skill Template Workflow Modules
- *
- * This file is generated by splitting the legacy monolithic
- * templates file into workflow-focused modules.
- */
-import type { SkillTemplate, CommandTemplate } from '../types.js';
-export declare function getVerifyChangeSkillTemplate(): SkillTemplate;
-export declare function getPsVerifyCommandTemplate(): CommandTemplate;
-//# sourceMappingURL=verify-change.d.ts.map