Claude Skill

atelier-setup

Configure a repository for Atelier's development workflow. Use only when explicitly invoked; inspect existing guidance, issue-tracker and domain-document conventions, preview the proposed configuration, and write only after approval. It does not install Atelier or initialize exte

LLM Mart · 0 points · 0 views 0 listing impressions 0 install-command copies
Virus-scanned Reviewed automatically before listing.

Full trust report

Download martinffx-atelier-skills_atelier-setup-3339609.zip · 3 KB
Part of martinffx/atelier — 14 skills

Install

skills CLI npx skills add https://github.com/martinffx/atelier/tree/main/skills/atelier-setup
Claude Code claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install martinffx-atelier@llmmart
Git git clone https://github.com/martinffx/atelier.git

The skills CLI installs just this skill, for any of its supported agents. Claude Code installs the whole martinffx/atelier collection as a plugin from our marketplace. Git is the plain clone.

Skill manifest

Atelier Setup

Set up repository guidance that Atelier skills need without taking ownership of the developer's installation, harness configuration, or project structure. Explore first, present every proposed edit exactly, and write only after the developer approves it.

1. Explore

Read the repository before proposing any change:

  • Root AGENTS.md and CLAUDE.md, if present. Note whether either already has an ## Agent skills heading.
  • Root CONTEXT.md and CONTEXT-MAP.md.
  • docs/adr/ and any context-local docs/adr/ directories.
  • docs/agents/, including existing issue-tracker.md and domain.md.
  • Existing issue-tracker conventions: remotes, issue links in documentation, local issue directories, and project guidance.
  • Genuine monorepo signals: a workspace manifest, or multiple independently deployable packages with their own source directories.

Do not create, install, configure, or modify anything during exploration.

2. Present Findings

Summarize what exists and recommend a domain-document layout:

  • Single-context is the default: domain language belongs in root CONTEXT.md; architectural decisions belong in root docs/adr/.
  • Multi-context is appropriate only when the repository has genuinely separate bounded contexts. CONTEXT-MAP.md belongs at the root and points to each context's CONTEXT.md and docs/adr/ directory.

Explain that domain documents remain lazy: do not create CONTEXT.md, CONTEXT-MAP.md, or an ADR directory until another Atelier skill has resolved terminology or made a decision worth recording.

Select or confirm the issue tracker:

  1. If docs/agents/issue-tracker.md already defines one, preserve it unless the developer asks to change it.
  2. Otherwise recommend the tracker indicated by existing repository practice, then ask the developer to confirm or describe their tracker.
  3. Accept GitHub, GitLab, local Markdown, another tracker described by the developer, or none.
  4. Record the chosen workflow in docs/agents/issue-tracker.md; do not install, initialize, or create external tracker resources.

Select the instruction file to edit:

  1. If both files exist, ask which file should own the agent guidance; do not duplicate it.
  2. Otherwise use root AGENTS.md when it exists.
  3. Otherwise use root CLAUDE.md when it exists.
  4. If neither exists, ask which instruction file to create; do not choose on the developer's behalf.

Show the developer the selected file, domain layout, and exact contents for:

  • the ## Agent skills block;
  • docs/agents/issue-tracker.md using references/issue-tracker.md;
  • docs/agents/domain.md using references/domain.md.

Stop and wait for explicit approval.

3. Write After Approval

Add the following block to the selected instruction file:

## Agent skills

### Planning and implementation

Use `atelier-orchestrator` at the start of development work. It selects an Inline Plan for bounded
changes or a Spec-backed Plan when durable design and coordination artifacts are warranted.

### Issue tracking

Read `docs/agents/issue-tracker.md` when issue tracking is relevant. It defines this repository's
tracker workflow; `plan.json` remains authoritative for Spec-backed task details and dependencies.

### Domain documentation

Read `docs/agents/domain.md` before working in a domain area. It defines how to locate and use this
repository's context documents and ADRs.

If an ## Agent skills section already exists, update the ### Planning and implementation, ### Issue tracking, and ### Domain documentation subsections in place rather than appending duplicates. Preserve other subsections and all content outside the section, including user edits.

Create docs/agents/ when needed, then write the approved tracker and domain documents. Do not create any other files or directories.

4. Report

State which instruction file and agent documents changed, the selected tracker, and the chosen domain-document layout. Remind the developer that the layout is a convention only: the first domain-modelling or architectural-decision task creates the relevant documents when it has substantive content.

Files (atelier)
  • references
    • domain.md 736 B
      # Domain Documentation
      
      ## Layout
      
      - **Mode:** [single-context or multi-context]
      - **Context map:** [path or not used]
      - **System ADRs:** [path]
      - **Context ADRs:** [path pattern or not used]
      
      ## Before Domain Work
      
      1. Read the context map when configured, then select the relevant context.
      2. Read that context's `CONTEXT.md` when it exists.
      3. Read ADRs relevant to the work.
      4. Proceed silently when these documents do not yet exist.
      
      ## Ownership
      
      - `CONTEXT.md` records domain language, distinctions, and business invariants.
      - `CONTEXT-MAP.md` maps bounded contexts to their context documents and ADRs.
      - ADRs record architectural decisions and trade-offs.
      - This file only tells agents how to locate and consume those documents.
      
    • issue-tracker.md 1 KB
      # Issue Tracker
      
      ## Tracker
      
      - **Provider:** [GitHub, GitLab, local Markdown, another tracker, or none]
      - **Location:** [repository, project, URL, or local directory]
      - **Tool or procedure:** [CLI, web workflow, or local-file convention]
      - **Mirror Spec-backed tasks:** [yes or no]
      
      ## Authority
      
      `plan.json` is the source of truth for Spec-backed task descriptions, dependencies, and
      validation. Tracker entries only mirror execution state when mirroring is enabled.
      
      ## Operations
      
      - **Create:** [how to create an issue or task]
      - **Read:** [how to retrieve it]
      - **Update:** [how to change status or add a note]
      - **Complete:** [how to close it]
      - **Dependencies:** [how blockers are represented]
      
      ## Status Mapping
      
      | Plan state | Tracker state |
      |------------|---------------|
      | Ready | [state] |
      | In progress | [state] |
      | Blocked | [state] |
      | Complete | [state] |
      
      ## Constraints
      
      - [Required approvals, project conventions, or known limitations]
      - Do not store credentials, tokens, or other secrets in this document.
      
  • SKILL.md 4.5 KB
    ---
    name: atelier-setup
    description: Configure a repository for Atelier's development workflow. Use only when explicitly invoked; inspect existing guidance, issue-tracker and domain-document conventions, preview the proposed configuration, and write only after approval. It does not install Atelier or initialize external tooling.
    user-invocable: true
    disable-model-invocation: true
    ---
    
    # Atelier Setup
    
    Set up repository guidance that Atelier skills need without taking ownership of the developer's
    installation, harness configuration, or project structure. Explore first, present every proposed
    edit exactly, and write only after the developer approves it.
    
    ## 1. Explore
    
    Read the repository before proposing any change:
    
    - Root `AGENTS.md` and `CLAUDE.md`, if present. Note whether either already has an `## Agent skills`
      heading.
    - Root `CONTEXT.md` and `CONTEXT-MAP.md`.
    - `docs/adr/` and any context-local `docs/adr/` directories.
    - `docs/agents/`, including existing `issue-tracker.md` and `domain.md`.
    - Existing issue-tracker conventions: remotes, issue links in documentation, local issue
      directories, and project guidance.
    - Genuine monorepo signals: a workspace manifest, or multiple independently deployable packages
      with their own source directories.
    
    Do not create, install, configure, or modify anything during exploration.
    
    ## 2. Present Findings
    
    Summarize what exists and recommend a domain-document layout:
    
    - **Single-context** is the default: domain language belongs in root `CONTEXT.md`; architectural
      decisions belong in root `docs/adr/`.
    - **Multi-context** is appropriate only when the repository has genuinely separate bounded
      contexts. `CONTEXT-MAP.md` belongs at the root and points to each context's `CONTEXT.md` and
      `docs/adr/` directory.
    
    Explain that domain documents remain lazy: do not create `CONTEXT.md`, `CONTEXT-MAP.md`, or an ADR
    directory until another Atelier skill has resolved terminology or made a decision worth recording.
    
    Select or confirm the issue tracker:
    
    1. If `docs/agents/issue-tracker.md` already defines one, preserve it unless the developer asks to
       change it.
    2. Otherwise recommend the tracker indicated by existing repository practice, then ask the
       developer to confirm or describe their tracker.
    3. Accept GitHub, GitLab, local Markdown, another tracker described by the developer, or `none`.
    4. Record the chosen workflow in `docs/agents/issue-tracker.md`; do not install, initialize, or
       create external tracker resources.
    
    Select the instruction file to edit:
    
    1. If both files exist, ask which file should own the agent guidance; do not duplicate it.
    2. Otherwise use root `AGENTS.md` when it exists.
    3. Otherwise use root `CLAUDE.md` when it exists.
    4. If neither exists, ask which instruction file to create; do not choose on the developer's behalf.
    
    Show the developer the selected file, domain layout, and exact contents for:
    
    - the `## Agent skills` block;
    - `docs/agents/issue-tracker.md` using `references/issue-tracker.md`;
    - `docs/agents/domain.md` using `references/domain.md`.
    
    Stop and wait for explicit approval.
    
    ## 3. Write After Approval
    
    Add the following block to the selected instruction file:
    
    ```markdown
    ## Agent skills
    
    ### Planning and implementation
    
    Use `atelier-orchestrator` at the start of development work. It selects an Inline Plan for bounded
    changes or a Spec-backed Plan when durable design and coordination artifacts are warranted.
    
    ### Issue tracking
    
    Read `docs/agents/issue-tracker.md` when issue tracking is relevant. It defines this repository's
    tracker workflow; `plan.json` remains authoritative for Spec-backed task details and dependencies.
    
    ### Domain documentation
    
    Read `docs/agents/domain.md` before working in a domain area. It defines how to locate and use this
    repository's context documents and ADRs.
    ```
    
    If an `## Agent skills` section already exists, update the `### Planning and implementation`,
    `### Issue tracking`, and `### Domain documentation` subsections in place rather than appending
    duplicates. Preserve other subsections and all content outside the section, including user edits.
    
    Create `docs/agents/` when needed, then write the approved tracker and domain documents. Do not
    create any other files or directories.
    
    ## 4. Report
    
    State which instruction file and agent documents changed, the selected tracker, and the chosen
    domain-document layout. Remind the developer that the layout is a convention only: the first
    domain-modelling or architectural-decision task creates the relevant documents when it has
    substantive content.
    

Comments (0)

Sign in to join the conversation.

No comments yet.

Reviews (0)

No reviews yet.

Related