codifycli
diff --git a/‎.circleci/config.yml‎
Lines changed: 55 additions & 0 deletions b/‎.circleci/config.yml‎
Lines changed: 55 additions & 0 deletions
diff --git a/‎.claude/commands/add-examples.md‎
Lines changed: 61 additions & 0 deletions b/‎.claude/commands/add-examples.md‎
Lines changed: 61 additions & 0 deletions
diff --git a/‎.fleet/run.json‎
Lines changed: 0 additions & 47 deletions b/‎.fleet/run.json‎
Lines changed: 0 additions & 47 deletions
diff --git a/‎.fleet/settings.json‎
Lines changed: 0 additions & 3 deletions b/‎.fleet/settings.json‎
Lines changed: 0 additions & 3 deletions
diff --git a/‎.github/ISSUE_TEMPLATE/resource-request.yml‎
Lines changed: 52 additions & 0 deletions b/‎.github/ISSUE_TEMPLATE/resource-request.yml‎
Lines changed: 52 additions & 0 deletions
diff --git a/‎.github/workflows/claude-fixer.yml‎
Lines changed: 30 additions & 0 deletions b/‎.github/workflows/claude-fixer.yml‎
Lines changed: 30 additions & 0 deletions
@@ -0,0 +1,55 @@
+version: 2.1
+
+jobs:
+  test:
+    parameters:
+      executor:
+        type: executor
+    executor: << parameters.executor >>
+    steps:
+      - checkout
+      - node/install:
+          node-version: '24'
+      - run:
+          name: Enable linger for current user (Linux only)
+          command: |
+            if [[ "$OSTYPE" == "linux"* ]]; then
+              loginctl enable-linger $(whoami)
+              sudo chown -R circleci:circleci /usr/local /opt /var/tmp
+            fi
+      - run:
+          name: Install dependencies
+          command: npm ci
+      - run:
+          name: Clean up pre-installed tools
+          command: npx tsx scripts/cleanup-circleci.ts
+          no_output_timeout: 10m
+      - run:
+          name: Run tests
+          command: npm run test -- ./test --no-file-parallelism --disable-console-intercept
+          no_output_timeout: 30m
+
+orbs:
+  node: circleci/node@6
+
+executors:
+  linux-x86:
+    machine:
+      image: ubuntu-2404:current
+    resource_class: medium
+  linux-arm:
+    machine:
+      image: ubuntu-2404:current
+    resource_class: arm.medium
+  macos:
+    macos:
+      xcode: '26.4.0'
+    resource_class: m4pro.medium
+
+#workflows:
+#  test-all:
+#    jobs:
+#      - test:
+#          matrix:
+#            parameters:
+#              executor: [linux-arm]
@@ -0,0 +1,61 @@
+# add-examples
+
+Add `defaultConfig` and `exampleConfigs` to a Codify resource.
+
+## Instructions
+
+The user will either pass a file path as an argument (`$ARGUMENTS`) or have a file open in the IDE. Read the resource file, then follow the rules below to add `defaultConfig` and `exampleConfigs`.
+
+If `$ARGUMENTS` is provided, use that file path. Otherwise use the file the user has open.
+
+### Step 1 — Read the resource
+
+Read the resource file. Identify:
+- The config interface/type (fields, which are required vs optional)
+- `operatingSystems` declared in `getSettings()` — determines whether to add `os` to examples
+- `dependencies` — used to decide whether to show a multi-resource example
+- Any existing `defaultConfig` or `exampleConfigs` (update rather than duplicate)
+
+If the schema is a separate JSON file, read it too.
+
+Also check for sibling resources that are commonly used together (e.g. if this resource `dependsOn` another type, read that type's file to understand its config shape).
+
+### Step 2 — Add `defaultConfig`
+
+Rules:
+- Type: `Partial<TheConfig>` (never include `os` — it's not on the typed config interface)
+- For required fields with no sensible default: use the placeholder string `'<Replace me here!'>`
+- For optional arrays that default to empty: set to `[]`
+- Omit fields that are purely user-specific (paths, names, credentials)
+- Use the tool's own documented defaults where applicable
+
+### Step 3 — Add `exampleConfigs`
+
+Rules:
+- Up to two examples: `example1` and `example2`
+- **No trivial examples** — every example must have meaningful configuration, not just `{ type: 'foo' }` with no parameters
+- `example1`: the most common real-world use case with substantive config values
+- `example2`: a more advanced variant OR a multi-resource example showing full end-to-end setup; multi-resource is preferred when the resource `dependsOn` another
+- Every example needs a `title` (short noun-phrase) and a `description` (one sentence)
+- Use realistic placeholder values for sensitive fields (`'<Replace me here!'>`), not real credentials
+- Do not add step-numbering in descriptions
+
+**`os` field in examples:**
+- The `os` field values come from the `ResourceOs` enum in `@codifycli/schemas` (`../codify-schemas/src/types/index.ts`): `'macOS'`, `'linux'`, `'windows'`
+- Add `os` to config entries inside examples only when `operatingSystems` is restricted to a single OS (e.g. Darwin-only → `os: ['macOS']`, Linux-only → `os: ['linux']`)
+- Skip `os` entirely when the resource supports both Darwin and Linux
+
+**Shared examples:**
+- When a multi-resource example is used across multiple related resources (e.g. asdf + asdf-plugin + asdf-install), define it once in a shared `examples.ts` file in the resource folder and spread it in with `...exampleSharedConfigs`
+
+### Step 4 — Import `ExampleConfig`
+
+Add `ExampleConfig` to the existing `@codifycli/plugin-core` import if not already present.
+
+### Step 5 — Register in `getSettings()`
+
+Add `defaultConfig` and `exampleConfigs` fields inside the object returned by `getSettings()`, before `operatingSystems`.
+
+## Output format
+
+Make all edits directly to the file. Do not summarise every line changed — just briefly confirm what was added.
@@ -0,0 +1,52 @@
+name: New Resource Request
+description: Request a new Codify resource — it will be automatically generated, tested, and queued for human review.
+title: "New resource request: "
+labels: ["New resource request"]
+body:
+  - type: input
+    id: tool_name
+    attributes:
+      label: Tool Name
+      description: The name of the tool or application
+      placeholder: e.g. Syncthing, k9s, rbenv
+    validations:
+      required: true
+
+  - type: input
+    id: homepage
+    attributes:
+      label: Homepage / Documentation URL
+      description: The official homepage or documentation URL for the tool
+      placeholder: https://...
+    validations:
+      required: true
+
+  - type: textarea
+    id: description
+    attributes:
+      label: What should the resource manage?
+      description: Describe what you want the Codify resource to install and configure
+      placeholder: |
+        e.g. The syncthing resource should install syncthing and allow users to manage
+        its configuration including device IDs, shared folders, and GUI settings.
+        Syncthing has a CLI so direct configuration should be possible.
+    validations:
+      required: true
+
+  - type: textarea
+    id: install_notes
+    attributes:
+      label: Installation Notes (optional)
+      description: Any known installation details, quirks, or preferred installation method
+      placeholder: e.g. Prefer homebrew on macOS; uses the official install script on Linux
+    validations:
+      required: false
+
+  - type: textarea
+    id: use_cases
+    attributes:
+      label: Use Cases (optional)
+      description: How do you plan to use this resource? Any specific config parameters that matter?
+      placeholder: e.g. I want to pin the version and configure custom data directories
+    validations:
+      required: false
@@ -0,0 +1,30 @@
+name: Claude Test Fixer
+on:
+  workflow_run:
+    workflows: ["Test all cron (Linux)", "Test all cron (MacOS)"]
+    types: [completed]
+
+jobs:
+  fix-on-failure:
+    runs-on: ubuntu-latest
+    if: ${{ github.event.workflow_run.conclusion == 'failure' }}
+    permissions:
+      contents: write
+      pull-requests: write
+      actions: read # Allows Claude to read the logs of the failed run
+    steps:
+      - uses: actions/checkout@v4
+      - name: Claude Fix Failed Tests
+        uses: anthropics/claude-code-action@v1
+        with:
+          claude_code_oauth_token: ${{ secrets.CLAUDE_CODE_OAUTH_TOKEN }}
+          prompt: |
+            The "CI Tests" workflow just failed. 
+            1. Analyze the logs from the last failed run.
+            2. Identify the root cause of the test failure.
+            3. Implement a fix and create a new pull request.
+            
+            
+
+          additional_permissions: |
+            actions: read