Claude Skill

goga-accept-scope

Defines the acceptance scope — the set of cells for a given functionality

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

Full trust report

Download qarium-goga-goga_assets_skills_goga-accept-scope-f1257db.zip · 1 KB
qarium/goga 31 0 forks BSD-3-Clause Updated 6d ago
Part of qarium/goga — 72 skills

Install

skills CLI npx skills add https://github.com/qarium/goga/tree/1.2.x/goga/assets/skills/goga-accept-scope
Claude Code claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install qarium-goga@llmmart
Git git clone https://github.com/qarium/goga.git

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

Skill manifest

goga-accept-scope

Identity

You are responsible for defining the acceptance scope — identifying the set of cells associated with a given functionality.

Algorithm

Determine acceptance scope

Acceptance operates at the functionality level. One functionality may span one or more cells.

Resolve the scope:

  1. Arguments contain a functionality description or path — use as <target>
  2. Arguments are empty — analyze git diff to identify changed files
  3. No changes found or scope is ambiguous — prompt the user via AskUserQuestion:
    • question: "Which functionality should undergo acceptance?"
    • header: "Acceptance scope"
    • multiSelect: false
    • options:
      • label: "Branch changes", description: "Determine from git diff"
      • label: "Specific functionality", description: "Provide a functionality description"
      • label: "All project cells", description: "Full acceptance"

Map scope to cells

  1. Load the project schema: goga schema
  2. Match the functionality description or git diff results to cells in the schema
  3. For each matched cell:
    1. Verify the CODEMANIFEST file exists
    2. Load the CODEMANIFEST
    3. Verify the .usages/ directory exists
    4. Classify change types: CODE / MANIFEST / USAGE / TEST
  4. Discover dependent cells — cells that import the matched cells
  5. Classify each dependency:
    • DIRECT — imports a changed API
    • TRANSITIVE — imports a DIRECT dependency
  6. Generate the Acceptance Scope Report

STOP if:

  • No cells are discovered
  • A cell lacks a CODEMANIFEST
  • The scope is ambiguous

Output format

Complete every section. Empty sections are not allowed.

# Acceptance Scope Report

## Data source
[How the scope was resolved: arguments, git diff, or user selection]

## Functionality
[Functionality description, if determined]

## Cells for acceptance
[Table: Cell | Path | Change types (CODE/MANIFEST/USAGE/TEST)]

## Affected dependencies
[Table: Dependent cell | Dependency type (DIRECT/TRANSITIVE) | Impact assessment]

## Scope summary
[Total cells, total files, distribution by change categories]
Files (goga)
  • SKILL.md 2.2 KB
    ---
    name: goga-accept-scope
    description: Defines the acceptance scope — the set of cells for a given functionality
    ---
    # goga-accept-scope
    
    ## Identity
    
    You are responsible for defining the acceptance scope — identifying the set of cells associated with a given functionality.
    
    ## Algorithm
    
    ### Determine acceptance scope
    
    Acceptance operates at the functionality level. One functionality may span one or more cells.
    
    Resolve the scope:
    
    1. **Arguments contain a functionality description or path** — use as `<target>`
    2. **Arguments are empty** — analyze `git diff` to identify changed files
    3. **No changes found or scope is ambiguous** — prompt the user via AskUserQuestion:
       - **question**: "Which functionality should undergo acceptance?"
       - **header**: "Acceptance scope"
       - **multiSelect**: false
       - **options**:
         - **label**: "Branch changes", **description**: "Determine from git diff"
         - **label**: "Specific functionality", **description**: "Provide a functionality description"
         - **label**: "All project cells", **description**: "Full acceptance"
    
    ### Map scope to cells
    
    1. Load the project schema: `goga schema`
    2. Match the functionality description or `git diff` results to cells in the schema
    3. For each matched cell:
       a. Verify the CODEMANIFEST file exists
       b. Load the CODEMANIFEST
       c. Verify the `.usages/` directory exists
       d. Classify change types: CODE / MANIFEST / USAGE / TEST
    4. Discover dependent cells — cells that import the matched cells
    5. Classify each dependency:
       - **DIRECT** — imports a changed API
       - **TRANSITIVE** — imports a DIRECT dependency
    6. Generate the Acceptance Scope Report
    
    STOP if:
    - No cells are discovered
    - A cell lacks a CODEMANIFEST
    - The scope is ambiguous
    
    ## Output format
    
    Complete every section. Empty sections are not allowed.
    
    ```md
    # Acceptance Scope Report
    
    ## Data source
    [How the scope was resolved: arguments, git diff, or user selection]
    
    ## Functionality
    [Functionality description, if determined]
    
    ## Cells for acceptance
    [Table: Cell | Path | Change types (CODE/MANIFEST/USAGE/TEST)]
    
    ## Affected dependencies
    [Table: Dependent cell | Dependency type (DIRECT/TRANSITIVE) | Impact assessment]
    
    ## Scope summary
    [Total cells, total files, distribution by change categories]
    ```
    

Comments (0)

Sign in to join the conversation.

No comments yet.

Reviews (0)

No reviews yet.

Related