ac-framework 1.9.2 → 1.9.3

package/framework/new_project/.continue/prompts/ac.prompt

@@ -0,0 +1,192 @@
+**Fundamental Principle**: *"Quality over speed. Documentation before code. Planning before execution."*
+
+--- YOU SHOULD FOLLOW THIS EXACT WORKFLOW HERE, DONT SKIP STEPS, DONT CHANGE THE ORDER OF THE WORKFLOW, DONT SKIP SKILLS, DONT SKIP PHASES, DONT SKIP ANYTHING, JUST FOLLOW THE WORKFLOW EXACTLY AS IT IS WRITTEN HERE
+
+## 🛠️ Available Skills
+
+### Quality and Security Skills
+
+| Skill | Description | Primary Use |
+|-------|-------------|---------------|
+| `secure-coding-cybersecurity` | Detects and prevents security vulnerabilities (SQLi, XSS, command injection, hardcoded secrets). Follows OWASP Top 10 standards. | Secure code validation |
+| `code-maintainability` | Analyzes code maintainability: duplication, documentation, error handling, naming conventions, SOLID architecture, performance. | Refactoring and standards |
+| `error-handling-patterns` | Error handling patterns in multiple languages: exceptions, Result types, retry, circuit breaker, graceful degradation. | Application resilience |
+| `performance-optimizer` | Methodologies for measuring, profiling, and optimizing code (caching, algorithm complexity, resource usage). | Performance Engineering |
+| `test-generator` | Generate comprehensive test suites (Unit, Integration, E2E) ensuring requirements are met. | Test Driven Development |
+
+### SpecKit Consistency & Quality Skills
+
+| Skill | Description | Primary Use |
+|-------|-------------|---------------|
+| `project-constitution` | Manage the project's core principles and ensuring alignment. | Project Governance |
+| `requirement-checklist` | Generate quality control checklists for requirements (unit tests for specs). | Requirements Quality |
+| `spec-analysis` | Analyze consistency across Spec, Plan, and Tasks. | Consistency Check |
+| `spec-clarification` | Interactively clarify specific sections of the spec. | Ambiguity Resolution |
+
+### Planning and Design Skills
+
+| Skill | Description | Primary Use |
+|-------|-------------|---------------|
+| `brainstorming` | Generates ideas and questions decisions before implementing. Explores requirements, constraints, and success criteria. | Design and architecture |
+| `api-design-principles` | REST and GraphQL design principles: resources, endpoints, pagination, versioning, HATEOAS. | API design |
+| `interface-design` | Interface design (dashboards, admin panels, apps). NOT for landing pages/marketing. | UI design |
+
+### OpenSpec Skills (The heart of the framework)
+
+| Skill | Description | Primary Use |
+|-------|-------------|---------------|
+| `openspec-explore` | Exploration mode to investigate problems, map architecture, find integration points before implementing. | Pre-analysis |
+| `openspec-new-change` | Creates a new change with step-by-step workflow (proposal → specs → design → tasks). | Structured start |
+| `openspec-ff-change` | Fast-forward: creates all artifacts at once to start implementation quickly. | Quick start |
+| `openspec-continue-change` | Continues an existing change by creating the next artifact in the sequence. | Continue workflow |
+| `openspec-apply-change` | Implements tasks from a change (applies code according to specs and tasks). | Change execution |
+| `openspec-verify-change` | Verifies that implementation matches artifacts (specs, tasks, design). | Validation |
+| `openspec-archive-change` | Archives a completed change by moving it to `openspec/changes/archive/`. | Change closure |
+| `openspec-onboard` | Guided tutorial to learn OpenSpec with a complete example workflow. | Learning |
+| `openspec-sync-specs` | Synchronizes delta specs to main specs (intelligent merge). | Update specs |
+| `openspec-bulk-archive-change` | Archives multiple completed changes at once. | Bulk cleanup |
+
+### Documentation and Debugging Skills
+
+| Skill | Description | Primary Use |
+|-------|-------------|---------------|
+| `project-index` | Generates structured project documentation: structure analysis, domains, agent guides. | Indexing and context |
+| `sync-index` | Keep project documentation (`project-index` and sub-skills) in sync with codebase changes. | Documentation Sync |
+| `systematic-debugging` | Structured debugging in 4 phases: root cause investigation, pattern analysis, hypothesis, implementation. | Problem resolution |
+| `changelog-generator` | Creates automated changelogs from git commits, translating technical to user language. | Version history |
+| `skill-writer` | Guide to create new skills for Claude Code with correct structure and frontmatter. | Create new skills |
+
+---
+
+## 🚀 Workflow: New Project
+
+When starting a project **from scratch**, follow this mandatory workflow:
+
+```
+┌─────────────────────────────────────────────────────────────────────────────────┐
+│                           WORKFLOW: NEW PROJECT                                  │
+└─────────────────────────────────────────────────────────────────────────────────┘
+
+    ┌─────────────────┐
+    │     START       │
+    └────────┬────────┘
+             │
+             ▼
+    ┌──────────────────────────────────────────────┐
+    │  PHASE 1: FOUNDATIONS & GOVERNANCE           │
+    │  1. project-constitution                     │
+    │     └─ Define core principles                │
+    │  2. secure-coding-cybersecurity              │
+    │     └─ Establish security guidelines         │
+    │  3. code-maintainability                     │
+    │     └─ Define quality standards              │
+    └────────────────────┬─────────────────────────┘
+                         │
+                         ▼
+    ┌──────────────────────────────────────────────┐
+    │  PHASE 2: DISCOVERY & PLANNING               │
+    │  4. brainstorming                            │
+    │     └─ Architecture/Idea generation          │
+    │  5. openspec-new-change                      │
+    │     └─ Create proposal                       │
+    │  6. spec-clarification (CRITICAL)            │
+    │     └─ Refine requirements interactively     │
+    │  7. openspec-continue-change                 │
+    │     └─ Draft Specs, Design, Tasks            │
+    │  8. requirement-checklist                    │
+    │     └─ "Unit test" the specs                 │
+    │  9. spec-analysis                            │
+    │     └─ Verify Spec/Plan consistency          │
+    └────────────────────┬─────────────────────────┘
+                         │
+                         ▼
+    ┌──────────────────────────────────────────────┐
+    │  PHASE 3: IMPLEMENTATION                     │
+    │  10. test-generator                          │
+    │      └─ TDD: Write tests first               │
+    │  11. openspec-apply-change                   │
+    │      └─ Implement code to pass tests         │
+    │  12. performance-optimizer                   │
+    │      └─ Optimize critical paths              │
+    └────────────────────┬─────────────────────────┘
+                         │
+                         ▼
+    ┌──────────────────────────────────────────────┐
+    │  PHASE 4: VALIDATION & CLOSURE               │
+    │  13. systematic-debugging                    │
+    │      └─ Resolve any issues                   │
+    │  14. openspec-verify-change                  │
+    │      └─ Validate against initial specs       │
+    │  15. sync-index                              │
+    │      └─ Update project docs                  │
+    │  16. openspec-archive-change                 │
+    │      └─ Archive the change                   │
+    └──────────────────────────────────────────────┘
+```
+
+---
+
+## 🔄 Workflow: Existing Project
+
+When working on an **existing codebase** (adding features, fixing bugs, refactoring):
+
+```
+┌─────────────────────────────────────────────────────────────────────────────────┐
+│                        WORKFLOW: EXISTING PROJECT                                │
+└─────────────────────────────────────────────────────────────────────────────────┘
+
+    ┌─────────────────┐
+    │  START CHANGE   │
+    └────────┬────────┘
+             │
+             ▼
+    ┌──────────────────────────────────────────────┐
+    │  PHASE 1: CONTEXT & ANALYSIS                 │
+    │  1. project-index (if needed)                │
+    │     └─ Map current system                    │
+    │  2. openspec-explore                         │
+    │     └─ Deep dive into relevant modules       │
+    │  3. brainstorming                            │
+    │     └─ Ideate on feature/fix                 │
+    └────────────────────┬─────────────────────────┘
+                         │
+                         ▼
+    ┌──────────────────────────────────────────────┐
+    │  PHASE 2: REQUIREMENTS & PLANNING            │
+    │  4. openspec-new-change                      │
+    │     └─ Initialize change artifact            │
+    │  5. spec-clarification                       │
+    │     └─ CLARIFY requirements first            │
+    │  6. requirement-checklist                    │
+    │     └─ Validate requirements                 │
+    │  7. openspec-continue-change                 │
+    │     └─ Draft Specs, Design, Tasks            │
+    │  8. spec-analysis                            │
+    │     └─ Check consistency with existing       │
+    └────────────────────┬─────────────────────────┘
+                         │
+                         ▼
+    ┌──────────────────────────────────────────────┐
+    │  PHASE 3: TEST-DRIVEN IMPLEMENTATION         │
+    │  9. test-generator                           │
+    │     └─ Generate tests for new feature        │
+    │  10. openspec-apply-change                   │
+    │      └─ Implement code                       │
+    │  11. secure-coding-cybersecurity             │
+    │      └─ Audit new code                       │
+    └────────────────────┬─────────────────────────┘
+                         │
+                         ▼
+    ┌──────────────────────────────────────────────┐
+    │  PHASE 4: OPTIMIZATION & VERIFICATION        │
+    │  12. systematic-debugging                    │
+    │      └─ Fix regressions                      │
+    │  13. performance-optimizer                   │
+    │      └─ Ensure no perf degradation           │
+    │  14. openspec-verify-change                  │
+    │      └─ Final verification                   │
+    │  15. sync-index (IMPORTANT)                  │
+    │      └─ Update docs with new changes         │
+    │  16. openspec-archive-change                 │
+    │      └─ Archive change                       │
+    └──────────────────────────────────────────────

package/framework/new_project/.continue/prompts/opsx-apply.prompt

@@ -0,0 +1,151 @@
+---
+name: opsx-apply
+description: Implement tasks from an OpenSpec change (Experimental)
+invokable: true
+---
+
+Implement tasks from an OpenSpec change.
+
+**Input**: Optionally specify a change name (e.g., `/opsx:apply add-auth`). If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
+
+**Steps**
+
+1. **Select the change**
+
+   If a name is provided, use it. Otherwise:
+   - Infer from conversation context if the user mentioned a change
+   - Auto-select if only one active change exists
+   - If ambiguous, run `openspec list --json` to get available changes and use the **AskUserQuestion tool** to let the user select
+
+   Always announce: "Using change: <name>" and how to override (e.g., `/opsx:apply <other>`).
+
+2. **Check status to understand the schema**
+   ```bash
+   openspec status --change "<name>" --json
+   ```
+   Parse the JSON to understand:
+   - `schemaName`: The workflow being used (e.g., "spec-driven")
+   - Which artifact contains the tasks (typically "tasks" for spec-driven, check status for others)
+
+3. **Get apply instructions**
+
+   ```bash
+   openspec instructions apply --change "<name>" --json
+   ```
+
+   This returns:
+   - Context file paths (varies by schema)
+   - Progress (total, complete, remaining)
+   - Task list with status
+   - Dynamic instruction based on current state
+
+   **Handle states:**
+   - If `state: "blocked"` (missing artifacts): show message, suggest using `/opsx:continue`
+   - If `state: "all_done"`: congratulate, suggest archive
+   - Otherwise: proceed to implementation
+
+4. **Read context files**
+
+   Read the files listed in `contextFiles` from the apply instructions output.
+   The files depend on the schema being used:
+   - **spec-driven**: proposal, specs, design, tasks
+   - Other schemas: follow the contextFiles from CLI output
+
+5. **Show current progress**
+
+   Display:
+   - Schema being used
+   - Progress: "N/M tasks complete"
+   - Remaining tasks overview
+   - Dynamic instruction from CLI
+
+6. **Implement tasks (loop until done or blocked)**
+
+   For each pending task:
+   - Show which task is being worked on
+   - Make the code changes required
+   - Keep changes minimal and focused
+   - Mark task complete in the tasks file: `- [ ]` → `- [x]`
+   - Continue to next task
+
+   **Pause if:**
+   - Task is unclear → ask for clarification
+   - Implementation reveals a design issue → suggest updating artifacts
+   - Error or blocker encountered → report and wait for guidance
+   - User interrupts
+
+7. **On completion or pause, show status**
+
+   Display:
+   - Tasks completed this session
+   - Overall progress: "N/M tasks complete"
+   - If all done: suggest archive
+   - If paused: explain why and wait for guidance
+
+**Output During Implementation**
+
+```
+## Implementing: <change-name> (schema: <schema-name>)
+
+Working on task 3/7: <task description>
+[...implementation happening...]
+✓ Task complete
+
+Working on task 4/7: <task description>
+[...implementation happening...]
+✓ Task complete
+```
+
+**Output On Completion**
+
+```
+## Implementation Complete
+
+**Change:** <change-name>
+**Schema:** <schema-name>
+**Progress:** 7/7 tasks complete ✓
+
+### Completed This Session
+- [x] Task 1
+- [x] Task 2
+...
+
+All tasks complete! You can archive this change with `/opsx:archive`.
+```
+
+**Output On Pause (Issue Encountered)**
+
+```
+## Implementation Paused
+
+**Change:** <change-name>
+**Schema:** <schema-name>
+**Progress:** 4/7 tasks complete
+
+### Issue Encountered
+<description of the issue>
+
+**Options:**
+1. <option 1>
+2. <option 2>
+3. Other approach
+
+What would you like to do?
+```
+
+**Guardrails**
+- Keep going through tasks until done or blocked
+- Always read context files before starting (from the apply instructions output)
+- If task is ambiguous, pause and ask before implementing
+- If implementation reveals issues, pause and suggest artifact updates
+- Keep code changes minimal and scoped to each task
+- Update task checkbox immediately after completing each task
+- Pause on errors, blockers, or unclear requirements - don't guess
+- Use contextFiles from CLI output, don't assume specific file names
+
+**Fluid Workflow Integration**
+
+This skill supports the "actions on a change" model:
+
+- **Can be invoked anytime**: Before all artifacts are done (if tasks exist), after partial implementation, interleaved with other actions
+- **Allows artifact updates**: If implementation reveals design issues, suggest updating artifacts - not phase-locked, work fluidly

package/framework/new_project/.continue/prompts/opsx-archive.prompt

@@ -0,0 +1,156 @@
+---
+name: opsx-archive
+description: Archive a completed change in the experimental workflow
+invokable: true
+---
+
+Archive a completed change in the experimental workflow.
+
+**Input**: Optionally specify a change name after `/opsx:archive` (e.g., `/opsx:archive add-auth`). If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
+
+**Steps**
+
+1. **If no change name provided, prompt for selection**
+
+   Run `openspec list --json` to get available changes. Use the **AskUserQuestion tool** to let the user select.
+
+   Show only active changes (not already archived).
+   Include the schema used for each change if available.
+
+   **IMPORTANT**: Do NOT guess or auto-select a change. Always let the user choose.
+
+2. **Check artifact completion status**
+
+   Run `openspec status --change "<name>" --json` to check artifact completion.
+
+   Parse the JSON to understand:
+   - `schemaName`: The workflow being used
+   - `artifacts`: List of artifacts with their status (`done` or other)
+
+   **If any artifacts are not `done`:**
+   - Display warning listing incomplete artifacts
+   - Prompt user for confirmation to continue
+   - Proceed if user confirms
+
+3. **Check task completion status**
+
+   Read the tasks file (typically `tasks.md`) to check for incomplete tasks.
+
+   Count tasks marked with `- [ ]` (incomplete) vs `- [x]` (complete).
+
+   **If incomplete tasks found:**
+   - Display warning showing count of incomplete tasks
+   - Prompt user for confirmation to continue
+   - Proceed if user confirms
+
+   **If no tasks file exists:** Proceed without task-related warning.
+
+4. **Assess delta spec sync state**
+
+   Check for delta specs at `openspec/changes/<name>/specs/`. If none exist, proceed without sync prompt.
+
+   **If delta specs exist:**
+   - Compare each delta spec with its corresponding main spec at `openspec/specs/<capability>/spec.md`
+   - Determine what changes would be applied (adds, modifications, removals, renames)
+   - Show a combined summary before prompting
+
+   **Prompt options:**
+   - If changes needed: "Sync now (recommended)", "Archive without syncing"
+   - If already synced: "Archive now", "Sync anyway", "Cancel"
+
+   If user chooses sync, execute `/opsx:sync` logic. Proceed to archive regardless of choice.
+
+5. **Perform the archive**
+
+   Create the archive directory if it doesn't exist:
+   ```bash
+   mkdir -p openspec/changes/archive
+   ```
+
+   Generate target name using current date: `YYYY-MM-DD-<change-name>`
+
+   **Check if target already exists:**
+   - If yes: Fail with error, suggest renaming existing archive or using different date
+   - If no: Move the change directory to archive
+
+   ```bash
+   mv openspec/changes/<name> openspec/changes/archive/YYYY-MM-DD-<name>
+   ```
+
+6. **Display summary**
+
+   Show archive completion summary including:
+   - Change name
+   - Schema that was used
+   - Archive location
+   - Spec sync status (synced / sync skipped / no delta specs)
+   - Note about any warnings (incomplete artifacts/tasks)
+
+**Output On Success**
+
+```
+## Archive Complete
+
+**Change:** <change-name>
+**Schema:** <schema-name>
+**Archived to:** openspec/changes/archive/YYYY-MM-DD-<name>/
+**Specs:** ✓ Synced to main specs
+
+All artifacts complete. All tasks complete.
+```
+
+**Output On Success (No Delta Specs)**
+
+```
+## Archive Complete
+
+**Change:** <change-name>
+**Schema:** <schema-name>
+**Archived to:** openspec/changes/archive/YYYY-MM-DD-<name>/
+**Specs:** No delta specs
+
+All artifacts complete. All tasks complete.
+```
+
+**Output On Success With Warnings**
+
+```
+## Archive Complete (with warnings)
+
+**Change:** <change-name>
+**Schema:** <schema-name>
+**Archived to:** openspec/changes/archive/YYYY-MM-DD-<name>/
+**Specs:** Sync skipped (user chose to skip)
+
+**Warnings:**
+- Archived with 2 incomplete artifacts
+- Archived with 3 incomplete tasks
+- Delta spec sync was skipped (user chose to skip)
+
+Review the archive if this was not intentional.
+```
+
+**Output On Error (Archive Exists)**
+
+```
+## Archive Failed
+
+**Change:** <change-name>
+**Target:** openspec/changes/archive/YYYY-MM-DD-<name>/
+
+Target archive directory already exists.
+
+**Options:**
+1. Rename the existing archive
+2. Delete the existing archive if it's a duplicate
+3. Wait until a different date to archive
+```
+
+**Guardrails**
+- Always prompt for change selection if not provided
+- Use artifact graph (openspec status --json) for completion checking
+- Don't block archive on warnings - just inform and confirm
+- Preserve .openspec.yaml when moving to archive (it moves with the directory)
+- Show clear summary of what happened
+- If sync is requested, use /opsx:sync approach (agent-driven)
+- If delta specs exist, always run the sync assessment and show the combined summary before prompting