Skip to content
Back to skills

Config

ASecurity

Use this skill to resolve auto-task settings. It owns the procedure that merges the shipped defaults file with project and local config, per-leaf, plus the resolved-block contract consumers read. Run it standalone to inspect the resolved settings and where each value came from.

  • 9 stars
  • 0 votes
  • 0 copies
  • 1 view
  • Added September 3, 2026
ai-agents

Works with

  • mcp

Security analysis

A100/100

Scanned September 20, 2026

npx -y skills add patforna/auto-task --skill config --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Config?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Config
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/patforna-config/badge)](https://www.skillsdirectory.com/skills/patforna-config)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: config
description: "Use this skill to resolve auto-task settings. It owns the procedure that merges the shipped defaults file with project and local config, per-leaf, plus the resolved-block contract consumers read. Run it standalone to inspect the resolved settings and where each value came from."
---

# Config

## Usage

`/at:config` — inspect the resolved settings for the current repo, with each value's origin (see § Inspect).

Setting-consuming skills don't call this as a command. They follow § Resolve — via their mandatory Step 0 — to obtain a **resolved block**, then read `settings.*` from it. Every setting's canonical default lives in the shipped defaults file (§ Resolve layer 1) and nowhere else, so a skill never restates a default: change it there and every consumer follows.

## Scope

`/at:config` currently resolves the settings `/at:create-task` consumes: `settings.task_store.*` and `settings.feedback_snapshots.*` — their defaults live in the shipped `auto-task.config.defaults.md` (§ Resolve layer 1). Both are static (no environment detection), so § Detection is an empty stub for now.

The other seven headings are **recognised** (see § Heading → Setting Map), so a full config raises no false warnings, but their values still live in the skills that consume them — they don't resolve to live settings yet.

## Settings

The settings `/at:config` owns. Their **default values live in the shipped `auto-task.config.defaults.md`** (§ Resolve layer 1), not here — this section maps each setting to its meaning and its override label.

| Setting                                | Meaning                                          | Resolved by | Override (heading → label)             |
| :------------------------------------- | :----------------------------------------------- | :---------- | :------------------------------------- |
| `settings.task_store.location`         | where task files live                            | static      | `## Task Store` → `location:`          |
| `settings.task_store.create`           | how a new task file is created                   | static      | `## Task Store` → `create:`            |
| `settings.task_store.status`           | how a task's status changes                      | static      | `## Task Store` → `status:`            |
| `settings.feedback_snapshots.dir`      | out-of-repo dir for post-clarify snapshots       | static      | `## Feedback Snapshots` → `dir:`       |
| `settings.feedback_snapshots.exemplar` | calibration exemplar read before writing a task  | static      | `## Feedback Snapshots` → `exemplar:`  |

A task's attachments live in `{settings.task_store.location}/attachments/{NNN}/` (derived from `location`, not a separate setting).

An override supplies only the leaves it names (e.g. a `## Task Store` giving just `location:` leaves `create` and `status` at their defaults). See § Resolve for the per-leaf merge.

## Heading → Setting Map

The nine canonical config-file headings and the settings they map to. All nine are **recognised** (never warn); only Task Store and Feedback Snapshots **resolve** to live settings — the rest are recognised but inert, their values still living in the skills that consume them.

| Config heading         | Setting(s)                                   | Live?            |
| :--------------------- | :------------------------------------------- | :--------------- |
| `## Task Store`        | `location:` / `create:` / `status:`          | yes              |
| `## Verification`      | `settings.verify`                            | no               |
| `## Worktrees`         | `path:` / `init:`                            | no               |
| `## Review`            | `settings.review_context`                    | no               |
| `## Design Review`     | `settings.design_review_server`              | no               |
| `## Models`            | `implementer:` / `adversarial:` / `panel:`   | no               |
| `## Conventions`       | `suffix:` / `merge:`                         | no               |
| `## Transcript Capture`| `settings.transcript_capture`                | no               |
| `## Feedback Snapshots`| `dir:` / `exemplar:`                         | yes              |

A heading outside this set is **unrecognised** → warn (see § Inspect). Never guess a near-miss to a canonical heading.

## Detection

**Not yet.** Nothing is detected: both live settings (`settings.task_store.*`, `settings.feedback_snapshots.*`) are static, so the resolver runs no environment probes. When detection lands (codex presence, a check recipe/script, Chrome DevTools MCP), it will resolve only leaves left at `auto` and never clobber an explicit override.

## Resolve

Produce a resolved block for the current repo. Standalone path only for now (orchestrator injection and resolve-from-primary-before-worktree are not implemented yet).

The config chain is **three files of identical format** — `## Heading` sections with labelled sub-lines — read and merged the same way at every layer:

1. Determine the repo root (the current working repo's top level).
2. **Layer 1 — defaults.** Read the shipped `auto-task.config.defaults.md` at the plugin root (`${CLAUDE_PLUGIN_ROOT}` — two levels up from this skill's `skills/config/` directory). Every setting's default value lives here.
3. **Layer 2 — project.** If `.claude/auto-task.config.md` exists at the repo root, read it. Skip silently if absent.
4. **Layer 3 — local.** If `.claude/auto-task.config.local.md` exists at the repo root, read it. Skip silently if absent.
5. **Merge per-leaf — local beats project beats defaults, each leaf independently.** Parse all three files the same way: map each `##` heading to its setting group via § Heading → Setting Map, and each labelled sub-line to a leaf. A layer supplies **only** the leaves it names; unnamed leaves keep the lower layer's value. Never replace a whole section wholesale — that would erase sub-defaults in compound settings. A leaf's provenance is the layer its final value came from: `default` (defaults file), `project`, or `local`.
6. Detection: none yet (see § Detection).
7. Emit the resolved block per § Resolved-block Grammar. The `run:` field is the passed-in task id if one was given, else `standalone`; the `source:` field is the absolute repo-root path.
8. Report the repo-root path and which of the three config files were found vs absent.

## Resolved-block Grammar

The `v1` contract. **LOCKED** — later changes reproduce it exactly; the `v1` tag gates any future format change. Do not "improve" it without bumping past `v1`.

Header line, then one entry per leaf:

````markdown
Resolved auto-task settings v1 (run: standalone; source: /abs/path/to/repo)
- settings.task_store.location: tasks/ [default]
- settings.task_store.create: [default]
  ```text
  <the create recipe from the defaults file, verbatim — elided here>
  ```
- settings.task_store.status: edit the task file's `status:` frontmatter field in place [default]
- settings.feedback_snapshots.dir: skipped [default]
- settings.feedback_snapshots.exemplar: skipped [default]
````

**Worked example — mixed provenance.** Project config sets only `dir:`, local config sets only `exemplar:`; each leaf resolves independently and carries its own tag (no wholesale replacement drops the other):

````markdown
Resolved auto-task settings v1 (run: standalone; source: /abs/path/to/repo)
- settings.task_store.location: tasks/ [default]
- settings.task_store.create: [default]
  ```text
  <the create recipe from the defaults file, verbatim — elided here>
  ```
- settings.task_store.status: edit the task file's `status:` frontmatter field in place [default]
- settings.feedback_snapshots.dir: ~/snaps/ [project]
- settings.feedback_snapshots.exemplar: ~/snaps/x-after.md [local]
````

Both examples elide the create recipe deliberately: `<…>` stands for whatever the defaults file or an override actually says. Never paste a default's real text into this skill — the copy drifts.

Rules:

- **Header:** `Resolved auto-task settings v1 (run: <task-id or standalone>; source: <abs repo-root path>)`.
- **One leaf per line** for scalars: `- settings.x: <value> [provenance]`.
- **Commands** are backticked (e.g. `` `just create-task "<title>"` ``).
- **Provenance** — every leaf carries a `[provenance]` tag from the closed vocabulary `default | detected | project | local`, naming the layer its value came from (`default` = the shipped defaults file). `detected` may append the fact (e.g. `[detected: codex on PATH]`) — unused until detection lands.
- **Single-line values** (a path, command, or short phrase) render inline: `- settings.x: <value> [provenance]`. **Multi-line / compound values** render as a fenced ` ```text ` sub-block indented under the leaf line (which ends with just its `[provenance]` tag). Today: `settings.task_store.create` fences (multi-line); `settings.task_store.status` and the two feedback-snapshot paths render inline.
- **Empty prose** renders inline as `settings.x: "" [default]` (no fenced block). No current leaf is empty-prose, but the rule is part of `v1`.
- **Skipped feedback snapshots** render inline per leaf as `settings.feedback_snapshots.dir: skipped [default]` and `settings.feedback_snapshots.exemplar: skipped [default]`.
- Only the five live leaves (`settings.task_store.location`, `settings.task_store.create`, `settings.task_store.status`, `settings.feedback_snapshots.dir`, `settings.feedback_snapshots.exemplar`) appear today.

## Inspect

Run on `/at:config` with no arguments:

1. Follow § Resolve for the current repo (`run: standalone`).
2. Print the resolved block, including the `source:` path, so each leaf shows its origin (`[default]` / `[project]` / `[local]`).
3. **Lint headings.** For each `##` heading in the project and local config files, if it is not one of the nine canonical headings (§ Heading → Setting Map), warn: `unrecognised heading "<heading>" — ignored`. A full nine-section config raises zero warnings; a heading outside the nine warns. Never guess a near-miss to a canonical heading.

Copied-default detection (warning when an override just restates today's default) needs fixtures and is not implemented yet.

## Step 0 (for Consumers)

Every setting-consuming skill embeds this block at the top of its steps:

> **Step 0 — Resolve config (mandatory).** If a `Resolved auto-task settings v1` block was passed in, use it verbatim and do NOT re-run detection. Otherwise resolve now by following `/at:config` § Resolve. Do not proceed without a resolved block. At each reference site read `settings.*` from the block; never restate a default.

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.