ac-framework 1.5.0 → 1.7.0

package/framework/.agent/skills/openspec-continue-change/SKILL.md

@@ -2,7 +2,7 @@
 name: openspec-continue-change
 description: Continue working on an OpenSpec change by creating the next artifact. Use when the user wants to progress their change, create the next artifact, or continue their workflow.
 license: MIT
-compatibility: Requires openspec CLI.
+compatibility: Requires acfm CLI (bundled).
 metadata:
   author: openspec
   version: "1.0"
@@ -15,9 +15,25 @@ Continue working on a change by creating the next artifact.
 
 **Steps**
 
-1. **If no change name provided, prompt for selection**
+1. **Verify project initialization**
 
-   Run `openspec list --json` to get available changes sorted by most recently modified. Then use the **AskUserQuestion tool** to let the user select which change to work on.
+   Check if the project is initialized:
+   ```bash
+   acfm spec status --json
+   ```
+   
+   **If not initialized** (`"initialized": false`):
+   ```bash
+   acfm spec init
+   ```
+   
+   **If initialized** (`"initialized": true`):
+   - Note the `dirName` field (either `.acfm` or `openspec`)
+   - Continue with the workflow
+
+2. **If no change name provided, prompt for selection**
+
+   Run `acfm spec list --json` to get available changes sorted by most recently modified. Then use the **AskUserQuestion tool** to let the user select which change to work on.
 
    Present the top 3-4 most recently modified changes as options, showing:
    - Change name
@@ -29,16 +45,16 @@ Continue working on a change by creating the next artifact.
 
    **IMPORTANT**: Do NOT guess or auto-select a change. Always let the user choose.
 
-2. **Check current status**
+3. **Check current status**
    ```bash
-   openspec status --change "<name>" --json
+   acfm spec status --change "<name>" --json
    ```
    Parse the JSON to understand current state. The response includes:
    - `schemaName`: The workflow schema being used (e.g., "spec-driven")
    - `artifacts`: Array of artifacts with their status ("done", "ready", "blocked")
    - `isComplete`: Boolean indicating if all artifacts are complete
 
-3. **Act based on status**:
+4. **Act based on status**:
 
    ---
 
@@ -54,7 +70,7 @@ Continue working on a change by creating the next artifact.
    - Pick the FIRST artifact with `status: "ready"` from the status output
    - Get its instructions:
      ```bash
-     openspec instructions <artifact-id> --change "<name>" --json
+     acfm spec instructions <artifact-id> --change "<name>" --json
      ```
    - Parse the JSON. The key fields are:
      - `context`: Project background (constraints for you - do NOT include in output)
@@ -77,9 +93,9 @@ Continue working on a change by creating the next artifact.
    - This shouldn't happen with a valid schema
    - Show status and suggest checking for issues
 
-4. **After creating an artifact, show progress**
+5. **After creating an artifact, show progress**
    ```bash
-   openspec status --change "<name>"
+   acfm spec status --change "<name>"
    ```
 
 **Output**

package/framework/.agent/skills/openspec-explore/SKILL.md

@@ -2,7 +2,7 @@
 name: openspec-explore
 description: Enter explore mode - a thinking partner for exploring ideas, investigating problems, and clarifying requirements. Use when the user wants to think through something before or during a change.
 license: MIT
-compatibility: Requires openspec CLI.
+compatibility: Requires acfm CLI (bundled).
 metadata:
   author: openspec
   version: "1.0"
@@ -79,11 +79,27 @@ Depending on what the user brings, you might:
 
 You have full context of the OpenSpec system. Use it naturally, don't force it.
 
+### Verify project initialization
+
+At the start, check if the project is initialized:
+```bash
+acfm spec status --json
+```
+
+**If not initialized** (`"initialized": false`):
+```bash
+acfm spec init
+```
+
+**If initialized** (`"initialized": true`):
+- Note the `dirName` field (either `.acfm` or `openspec`)
+- Continue with the workflow
+
 ### Check for context
 
-At the start, quickly check what exists:
+Next, quickly check what exists:
 ```bash
-openspec list --json
+acfm spec list --json
 ```
 
 This tells you:

package/framework/.agent/skills/openspec-ff-change/SKILL.md

@@ -2,7 +2,7 @@
 name: openspec-ff-change
 description: Fast-forward through OpenSpec artifact creation. Use when the user wants to quickly create all artifacts needed for implementation without stepping through each one individually.
 license: MIT
-compatibility: Requires openspec CLI.
+compatibility: Requires acfm CLI (bundled).
 metadata:
   author: openspec
   version: "1.0"
@@ -15,7 +15,23 @@ Fast-forward through artifact creation - generate everything needed to start imp
 
 **Steps**
 
-1. **If no clear input provided, ask what they want to build**
+1. **Verify project initialization**
+
+   Check if the project is initialized:
+   ```bash
+   acfm spec status --json
+   ```
+   
+   **If not initialized** (`"initialized": false`):
+   ```bash
+   acfm spec init
+   ```
+   
+   **If initialized** (`"initialized": true`):
+   - Note the `dirName` field (either `.acfm` or `openspec`)
+   - Continue with the workflow
+
+2. **If no clear input provided, ask what they want to build**
 
    Use the **AskUserQuestion tool** (open-ended, no preset options) to ask:
    > "What change do you want to work on? Describe what you want to build or fix."
@@ -24,21 +40,21 @@ Fast-forward through artifact creation - generate everything needed to start imp
 
    **IMPORTANT**: Do NOT proceed without understanding what the user wants to build.
 
-2. **Create the change directory**
+3. **Create the change directory**
    ```bash
-   openspec new change "<name>"
+   acfm spec new "<name>"
    ```
    This creates a scaffolded change at `openspec/changes/<name>/`.
 
-3. **Get the artifact build order**
+4. **Get the artifact build order**
    ```bash
-   openspec status --change "<name>" --json
+   acfm spec status --change "<name>" --json
    ```
    Parse the JSON to get:
    - `applyRequires`: array of artifact IDs needed before implementation (e.g., `["tasks"]`)
    - `artifacts`: list of all artifacts with their status and dependencies
 
-4. **Create artifacts in sequence until apply-ready**
+5. **Create artifacts in sequence until apply-ready**
 
    Use the **TodoWrite tool** to track progress through the artifacts.
 
@@ -47,7 +63,7 @@ Fast-forward through artifact creation - generate everything needed to start imp
    a. **For each artifact that is `ready` (dependencies satisfied)**:
       - Get instructions:
         ```bash
-        openspec instructions <artifact-id> --change "<name>" --json
+        acfm spec instructions <artifact-id> --change "<name>" --json
         ```
       - The instructions JSON includes:
         - `context`: Project background (constraints for you - do NOT include in output)
@@ -62,7 +78,7 @@ Fast-forward through artifact creation - generate everything needed to start imp
       - Show brief progress: "✓ Created <artifact-id>"
 
    b. **Continue until all `applyRequires` artifacts are complete**
-      - After creating each artifact, re-run `openspec status --change "<name>" --json`
+      - After creating each artifact, re-run `acfm spec status --change "<name>" --json`
       - Check if every artifact ID in `applyRequires` has `status: "done"` in the artifacts array
       - Stop when all `applyRequires` artifacts are done
 
@@ -70,9 +86,9 @@ Fast-forward through artifact creation - generate everything needed to start imp
       - Use **AskUserQuestion tool** to clarify
       - Then continue with creation
 
-5. **Show final status**
+6. **Show final status**
    ```bash
-   openspec status --change "<name>"
+   acfm spec status --change "<name>"
    ```
 
 **Output**
@@ -85,7 +101,7 @@ After completing all artifacts, summarize:
 
 **Artifact Creation Guidelines**
 
-- Follow the `instruction` field from `openspec instructions` for each artifact type
+- Follow the `instruction` field from `acfm spec instructions` for each artifact type
 - The schema defines what each artifact should contain - follow it
 - Read dependency artifacts for context before creating new ones
 - Use `template` as the structure for your output file - fill in its sections

package/framework/.agent/skills/openspec-new-change/SKILL.md

@@ -2,7 +2,7 @@
 name: openspec-new-change
 description: Start a new OpenSpec change using the experimental artifact workflow. Use when the user wants to create a new feature, fix, or modification with a structured step-by-step approach.
 license: MIT
-compatibility: Requires openspec CLI.
+compatibility: Requires acfm CLI (bundled).
 metadata:
   author: openspec
   version: "1.0"
@@ -15,7 +15,23 @@ Start a new change using the experimental artifact-driven approach.
 
 **Steps**
 
-1. **If no clear input provided, ask what they want to build**
+1. **Verify project initialization**
+
+   Check if the project is initialized:
+   ```bash
+   acfm spec status --json
+   ```
+   
+   **If not initialized** (`"initialized": false`):
+   ```bash
+   acfm spec init
+   ```
+   
+   **If initialized** (`"initialized": true`):
+   - Note the `dirName` field (either `.acfm` or `openspec`)
+   - Continue with the workflow
+
+2. **If no clear input provided, ask what they want to build**
 
    Use the **AskUserQuestion tool** (open-ended, no preset options) to ask:
    > "What change do you want to work on? Describe what you want to build or fix."
@@ -24,38 +40,38 @@ Start a new change using the experimental artifact-driven approach.
 
    **IMPORTANT**: Do NOT proceed without understanding what the user wants to build.
 
-2. **Determine the workflow schema**
+3. **Determine the workflow schema**
 
    Use the default schema (omit `--schema`) unless the user explicitly requests a different workflow.
 
    **Use a different schema only if the user mentions:**
    - A specific schema name → use `--schema <name>`
-   - "show workflows" or "what workflows" → run `openspec schemas --json` and let them choose
+   - "show workflows" or "what workflows" → run `acfm spec schemas --json` and let them choose
 
    **Otherwise**: Omit `--schema` to use the default.
 
-3. **Create the change directory**
+4. **Create the change directory**
    ```bash
-   openspec new change "<name>"
+   acfm spec new "<name>"
    ```
    Add `--schema <name>` only if the user requested a specific workflow.
-   This creates a scaffolded change at `openspec/changes/<name>/` with the selected schema.
+   This creates a scaffolded change at `{specDir}/changes/<name>/` (where {specDir} is either `.acfm` or `openspec` as detected by CLI) with the selected schema.
 
-4. **Show the artifact status**
+5. **Show the artifact status**
    ```bash
-   openspec status --change "<name>"
+   acfm spec status --change "<name>"
    ```
    This shows which artifacts need to be created and which are ready (dependencies satisfied).
 
-5. **Get instructions for the first artifact**
+6. **Get instructions for the first artifact**
    The first artifact depends on the schema (e.g., `proposal` for spec-driven).
    Check the status output to find the first artifact with status "ready".
    ```bash
-   openspec instructions <first-artifact-id> --change "<name>"
+   acfm spec instructions <first-artifact-id> --change "<name>"
    ```
    This outputs the template and context for creating the first artifact.
 
-6. **STOP and wait for user direction**
+7. **STOP and wait for user direction**
 
 **Output**
 

package/framework/.agent/skills/openspec-onboard/SKILL.md

@@ -2,7 +2,7 @@
 name: openspec-onboard
 description: Guided onboarding for OpenSpec - walk through a complete workflow cycle with narration and real codebase work.
 license: MIT
-compatibility: Requires openspec CLI.
+compatibility: Requires acfm CLI (bundled).
 metadata:
   author: openspec
   version: "1.0"
@@ -18,11 +18,11 @@ Guide the user through their first complete OpenSpec workflow cycle. This is a t
 Before starting, check if OpenSpec is initialized:
 
 ```bash
-openspec status --json 2>&1 || echo "NOT_INITIALIZED"
+acfm spec status --json 2>&1 || echo "NOT_INITIALIZED"
 ```
 
 **If not initialized:**
-> OpenSpec isn't set up in this project yet. Run `openspec init` first, then come back to `/opsx:onboard`.
+> OpenSpec isn't set up in this project yet. Run `acfm spec init` first, then come back to `/opsx:onboard`.
 
 Stop here if not initialized.
 
@@ -168,7 +168,7 @@ Let me create one for our task.
 
 **DO:** Create the change with a derived kebab-case name:
 ```bash
-openspec new change "<derived-name>"
+acfm spec new "<derived-name>"
 ```
 
 **SHOW:**
@@ -237,7 +237,7 @@ Does this capture the intent? I can adjust before we save it.
 
 After approval, save the proposal:
 ```bash
-openspec instructions proposal --change "<name>" --json
+acfm spec instructions proposal --change "<name>" --json
 ```
 Then write the content to `openspec/changes/<name>/proposal.md`.
 
@@ -423,7 +423,7 @@ Archived changes become your project's decision history—you can always find th
 
 **DO:**
 ```bash
-openspec archive "<name>"
+acfm spec archive "<name>"
 ```
 
 **SHOW:**

package/framework/.agent/skills/openspec-sync-specs/SKILL.md

@@ -2,7 +2,7 @@
 name: openspec-sync-specs
 description: Sync delta specs from a change to main specs. Use when the user wants to update main specs with changes from a delta spec, without archiving the change.
 license: MIT
-compatibility: Requires openspec CLI.
+compatibility: Requires acfm CLI (bundled).
 metadata:
   author: openspec
   version: "1.0"
@@ -17,15 +17,31 @@ This is an **agent-driven** operation - you will read delta specs and directly e
 
 **Steps**
 
-1. **If no change name provided, prompt for selection**
+1. **Verify project initialization**
 
-   Run `openspec list --json` to get available changes. Use the **AskUserQuestion tool** to let the user select.
+   Check if the project is initialized:
+   ```bash
+   acfm spec status --json
+   ```
+   
+   **If not initialized** (`"initialized": false`):
+   ```bash
+   acfm spec init
+   ```
+   
+   **If initialized** (`"initialized": true`):
+   - Note the `dirName` field (either `.acfm` or `openspec`)
+   - Continue with the workflow
+
+2. **If no change name provided, prompt for selection**
+
+   Run `acfm spec list --json` to get available changes. Use the **AskUserQuestion tool** to let the user select.
 
    Show changes that have delta specs (under `specs/` directory).
 
    **IMPORTANT**: Do NOT guess or auto-select a change. Always let the user choose.
 
-2. **Find delta specs**
+3. **Find delta specs**
 
    Look for delta spec files in `openspec/changes/<name>/specs/*/spec.md`.
 
@@ -37,7 +53,7 @@ This is an **agent-driven** operation - you will read delta specs and directly e
 
    If no delta specs found, inform user and stop.
 
-3. **For each delta spec, apply changes to main specs**
+4. **For each delta spec, apply changes to main specs**
 
    For each capability with a delta spec at `openspec/changes/<name>/specs/<capability>/spec.md`:
 
@@ -70,7 +86,7 @@ This is an **agent-driven** operation - you will read delta specs and directly e
       - Add Purpose section (can be brief, mark as TBD)
       - Add Requirements section with the ADDED requirements
 
-4. **Show summary**
+5. **Show summary**
 
    After applying all changes, summarize:
    - Which capabilities were updated

package/framework/.agent/skills/openspec-verify-change/SKILL.md

@@ -2,7 +2,7 @@
 name: openspec-verify-change
 description: Verify implementation matches change artifacts. Use when the user wants to validate that implementation is complete, correct, and coherent before archiving.
 license: MIT
-compatibility: Requires openspec CLI.
+compatibility: Requires acfm CLI (bundled).
 metadata:
   author: openspec
   version: "1.0"
@@ -15,9 +15,25 @@ Verify that an implementation matches the change artifacts (specs, tasks, design
 
 **Steps**
 
-1. **If no change name provided, prompt for selection**
+1. **Verify project initialization**
 
-   Run `openspec list --json` to get available changes. Use the **AskUserQuestion tool** to let the user select.
+   Check if the project is initialized:
+   ```bash
+   acfm spec status --json
+   ```
+   
+   **If not initialized** (`"initialized": false`):
+   ```bash
+   acfm spec init
+   ```
+   
+   **If initialized** (`"initialized": true`):
+   - Note the `dirName` field (either `.acfm` or `openspec`)
+   - Continue with the workflow
+
+2. **If no change name provided, prompt for selection**
+
+   Run `acfm spec list --json` to get available changes. Use the **AskUserQuestion tool** to let the user select.
 
    Show changes that have implementation tasks (tasks artifact exists).
    Include the schema used for each change if available.
@@ -25,23 +41,23 @@ Verify that an implementation matches the change artifacts (specs, tasks, design
 
    **IMPORTANT**: Do NOT guess or auto-select a change. Always let the user choose.
 
-2. **Check status to understand the schema**
+3. **Check status to understand the schema**
    ```bash
-   openspec status --change "<name>" --json
+   acfm spec status --change "<name>" --json
    ```
    Parse the JSON to understand:
    - `schemaName`: The workflow being used (e.g., "spec-driven")
    - Which artifacts exist for this change
 
-3. **Get the change directory and load artifacts**
+4. **Get the change directory and load artifacts**
 
    ```bash
-   openspec instructions apply --change "<name>" --json
+   acfm spec instructions apply --change "<name>" --json
    ```
 
    This returns the change directory and context files. Read all available artifacts from `contextFiles`.
 
-4. **Initialize verification report structure**
+5. **Initialize verification report structure**
 
    Create a report structure with three dimensions:
    - **Completeness**: Track tasks and spec coverage
@@ -50,7 +66,7 @@ Verify that an implementation matches the change artifacts (specs, tasks, design
 
    Each dimension can have CRITICAL, WARNING, or SUGGESTION issues.
 
-5. **Verify Completeness**
+6. **Verify Completeness**
 
    **Task Completion**:
    - If tasks.md exists in contextFiles, read it
@@ -70,7 +86,7 @@ Verify that an implementation matches the change artifacts (specs, tasks, design
        - Add CRITICAL issue: "Requirement not found: <requirement name>"
        - Recommendation: "Implement requirement X: <description>"
 
-6. **Verify Correctness**
+7. **Verify Correctness**
 
    **Requirement Implementation Mapping**:
    - For each requirement from delta specs:
@@ -89,7 +105,7 @@ Verify that an implementation matches the change artifacts (specs, tasks, design
        - Add WARNING: "Scenario not covered: <scenario name>"
        - Recommendation: "Add test or implementation for scenario: <description>"
 
-7. **Verify Coherence**
+8. **Verify Coherence**
 
    **Design Adherence**:
    - If design.md exists in contextFiles:
@@ -107,7 +123,7 @@ Verify that an implementation matches the change artifacts (specs, tasks, design
      - Add SUGGESTION: "Code pattern deviation: <details>"
      - Recommendation: "Consider following project pattern: <example>"
 
-8. **Generate Verification Report**
+9. **Generate Verification Report**
 
    **Summary Scorecard**:
    ```

package/framework/.agent/skills/performance-optimizer/SKILL.md

@@ -0,0 +1,43 @@
+---
+name: performance-optimizer
+description: Transform the agent into a performance engineer. Apply methodologies for measuring, profiling, and optimizing code (caching, algorithm complexity, resource usage).
+---
+
+# Performance Optimization
+
+## Overview
+
+Use this skill to analyze and improve the performance of the codebase. Focus on measurable improvements, not premature optimization.
+
+## Workflow
+
+1.  **Measure First**:
+    *   Never optimize without a baseline.
+    *   Use profiling tools or simple timing logs to identify bottlenecks.
+    *   "What gets measured, gets managed."
+
+2.  **Analyze and Hypothesize**:
+    *   Identify the root cause: CPU, Memory, I/O, or Network?
+    *   Look for common culprits: N+1 queries, unoptimized loops, large payload sizes, unnecessary re-renders (frontend).
+
+3.  **Optimize**:
+    *   **Algorithmic**: Improve Big-O complexity (e.g., O(n^2) -> O(n)).
+    *   **Caching**: Implement caching strategies (in-memory, Redis, HTTP caching).
+    *   **Database**: Add indexes, optimize queries, use batching.
+    *   **Frontend**: Lazy loading, memoization, code splitting, asset optimization.
+
+4.  **Verify**:
+    *   Run the measurements again.
+    *   Confirm the improvement.
+    *   Ensure no regression in functionality.
+
+## Techniques & Patterns
+
+*   **Database**: Explain Analyze, Indexing, Connection Pooling.
+*   **Backend**: Async processing, Caching layers, Load balancing.
+*   **Frontend**: Virtualization for long lists, Debouncing/Throttling events.
+
+## Output
+
+*   Create a brief report of findings and improvements.
+*   Update code with optimized solution.

package/framework/.agent/skills/project-constitution/SKILL.md

@@ -0,0 +1,66 @@
+---
+name: project-constitution
+description: Manage the project's core principles and ensuring alignment. Create or update the project constitution from interactive or provided principle inputs.
+---
+
+# Project Constitution Management
+
+## Overview
+
+You are updating the project constitution at `.specify/memory/constitution.md` (or `.specify/.specify/memory/constitution.md` if the user's structure differs). This file is a TEMPLATE containing placeholder tokens in square brackets (e.g. `[PROJECT_NAME]`, `[PRINCIPLE_1_NAME]`). Your job is to (a) collect/derive concrete values, (b) fill the template precisely, and (c) propagate any amendments across dependent artifacts.
+
+**Note**: If the constitution file does not exist yet, it should have been initialized from a template during project setup. If it's missing, copy the template first (check `.specify/templates/constitution-template.md`).
+
+## Execution Flow
+
+1.  **Load the existing constitution**.
+    *   Identify every placeholder token of the form `[ALL_CAPS_IDENTIFIER]`.
+    *   **IMPORTANT**: The user might require less or more principles than the ones used in the template. If a number is specified, respect that - follow the general template. You will update the doc accordingly.
+
+2.  **Collect/derive values for placeholders**:
+    *   If user input (conversation) supplies a value, use it.
+    *   Otherwise infer from existing repo context (README, docs, prior constitution versions if embedded).
+    *   For governance dates: `RATIFICATION_DATE` is the original adoption date (if unknown ask or mark TODO), `LAST_AMENDED_DATE` is today if changes are made, otherwise keep previous.
+    *   `CONSTITUTION_VERSION` must increment according to semantic versioning rules:
+        *   MAJOR: Backward incompatible governance/principle removals or redefinitions.
+        *   MINOR: New principle/section added or materially expanded guidance.
+        *   PATCH: Clarifications, wording, typo fixes, non-semantic refinements.
+    *   If version bump type ambiguous, propose reasoning before finalizing.
+
+3.  **Draft the updated constitution content**:
+    *   Replace every placeholder with concrete text (no bracketed tokens left except intentionally retained template slots that the project has chosen not to define yet—explicitly justify any left).
+    *   Preserve heading hierarchy and comments can be removed once replaced unless they still add clarifying guidance.
+    *   Ensure each Principle section: succinct name line, paragraph (or bullet list) capturing non‑negotiable rules, explicit rationale if not obvious.
+    *   Ensure Governance section lists amendment procedure, versioning policy, and compliance review expectations.
+
+4.  **Consistency propagation checklist**:
+    *   Check if `.specify/templates/plan-template.md`, `.specify/templates/spec-template.md`, and any other templates align with the updated constitution.
+    *   Update runtime guidance docs (e.g., `README.md`, `docs/quickstart.md`) if they reference changed principles.
+
+5.  **Produce a Sync Impact Report** (prepend as an HTML comment at top of the constitution file after update):
+    *   Version change: old → new
+    *   List of modified principles (old title → new title if renamed)
+    *   Added/Removed sections
+    *   Templates requiring updates (✅ updated / ⚠ pending) with file paths
+    *   Follow-up TODOs.
+
+6.  **Validation before final output**:
+    *   No remaining unexplained bracket tokens.
+    *   Version line matches report.
+    *   Dates ISO format YYYY-MM-DD.
+    *   Principles are declarative, testable, and free of vague language ("should" → replace with MUST/SHOULD rationale where appropriate).
+
+7.  **Write the completed constitution** back to the file (overwrite).
+
+8.  **Output a final summary**:
+    *   New version and bump rationale.
+    *   Any files flagged for manual follow-up.
+    *   Suggested commit message (e.g., `docs: amend constitution to vX.Y.Z (principle additions + governance update)`).
+
+## Formatting & Style Requirements
+
+*   Use Markdown headings exactly as in the template.
+*   Wrap long rationale lines to keep readability (<100 chars ideally).
+*   Keep a single blank line between sections.
+*   Avoid trailing whitespace.
+*   If critical info missing, insert `TODO(<FIELD_NAME>): explanation` and include in the Sync Impact Report.