# Goga Accept Manifest Review

> Verify each Cell's CODEMANIFEST against the implementation

- **Type:** Skill
- **Install:** `agentstack add skill-qarium-goga-goga-accept-manifest-review`
- **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior
- **Seller:** [qarium](https://agentstack.voostack.com/s/qarium)
- **Installs:** 0
- **Category:** [Agent Skills](https://agentstack.voostack.com/c/agent-skills)
- **Latest version:** 0.1.0
- **License:** BSD-3-Clause
- **Upstream author:** [qarium](https://github.com/qarium)
- **Source:** https://github.com/qarium/goga/tree/1.1.x/goga/assets/skills/goga-accept-manifest-review

## Install

```sh
agentstack add skill-qarium-goga-goga-accept-manifest-review
```

Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent.

## About

# goga-accept-manifest-review

## Identity

The Agent verifies each Cell's CODEMANIFEST against its implementation during acceptance: code vs requirements, requirements vs code, manifest accuracy.

## Core Principle

The Agent **compares** CODEMANIFEST with the actual implementation, **updates** the manifest as needed, and **records** any unresolvable discrepancies.

### User Interaction Rule

**Always provide response options.** When addressing the User, always offer 2–4 concrete choices.

---

## Algorithm

### Step 1. Load Context

1. Load the Acceptance Scope Report.
2. Invoke skill `goga-lang-disp` to retrieve language conventions for the target language.
3. Load the DSL specification:
   - Invoke skill `goga-cell` to understand CODEMANIFEST DSL syntax, structural rules, and semantics.
   - Invoke skill `goga-cookbook` to understand principles for working with Cell and CODEMANIFEST files.
4. Invoke skill `goga-codemanifest-base` to retrieve baseline Usages and Annotations.

### Step 2. Pre-flight Check

1. Run the linter: `goga lint`.
2. Record all errors as CRITICAL. Resolve them before proceeding.

### Step 3. Per-Cell Review

Process each Cell listed in the Acceptance Scope Report:

#### Sub-step 1. Load Data

1. Read the Cell's CODEMANIFEST.
2. Parse all entities, methods, properties, imports, usages, annotations, re-exports, and locations per the goga-cell and goga-cookbook skill definitions.
3. Enumerate all source files (exclude `.usages/`, build artifacts, and test files).
4. Read every source file at its declared `location`.
5. Verify the Facade file exists.

#### Sub-step 2. Code Analysis

**Question: Does the code satisfy the CODEMANIFEST requirements, baseline practices, and language conventions?**

1. Run the contract comparison: `goga contract `.

2. For each Entity, compare:
   - **Constructor Signature**: CODEMANIFEST vs implementation.
   - **Methods**: CODEMANIFEST vs implementation — per method.
   - **Properties**: CODEMANIFEST vs implementation — per property.
3. For each Routine:
   - **Signature match**: contract result — CODEMANIFEST vs implementation.
   - **Facade export**: is the Routine exported through the Facade.
4. Check Facade exposure — every Entity must be present in the Facade.
5. Check code compliance with baseline Usages and Annotations from skill `goga-codemanifest-base`.
6. Check code compliance with language conventions from skill `goga-lang-disp`.

Additional checks:
- **Location**: the file at `/` must exist.

#### Sub-step 3. CODEMANIFEST Completeness Analysis

**Question: Is all meaningful code reflected in the CODEMANIFEST?**

For every code element absent from CODEMANIFEST, classify criticality:

**HIGH** — must be added:
- Undeclared public Entity (class with state or behavior).
- Undeclared public Routine (transformer function, factory, validator).
- Re-exported types not declared via Embedding.
- Unreported Mutations (`Object::Target`).

**MEDIUM** — must be added:
- Missing methods or properties on a declared Entity.
- Signature inaccuracies (parameters, return values, semantic labels).
- Used Imports not declared.

**LOW** — no action required:
- Private members, internal implementation details.
- Helper functions not included in the Facade.
- Stylistic annotation improvements.

Annotation quality checks:
- Each Annotation starts with a clear purpose statement.
- Every parameter is documented as `parameter_name`: description.
- Non-trivial logic includes an `Algorithm:` section.
- Constraints are described under `Requirements:`.
- No TBD, TODO, or vague wording.

#### Sub-step 4. Algorithm Comparison

For each Entity and Routine, compare Annotations against the implementation along these axes:
- **Behavior**: does the code perform what the Annotation describes.
- **Algorithm**: steps, order, conditions, branching.
- **Operational Flow**: inputs, outputs, side effects.
- **Guarantees**: post-conditions, invariants, constraints.
- **Engineering Practices**: error handling, logging, validation.

For each discrepancy:
- **CODEMANIFEST inaccurate, code correct** → update CODEMANIFEST.
- **Code incorrect, CODEMANIFEST accurate** → create a Task.
- **Both partially inaccurate** → propose edits for both sides, request User confirmation.

### Step 4. Baseline Usages and Annotations Audit

For each Cell, verify against `goga-codemanifest-base`:
1. Retrieve baseline Usages from `goga-codemanifest-base`.
2. Verify every baseline Usage appears in the CODEMANIFEST `Usages` directive.
3. Retrieve baseline Annotations from `goga-codemanifest-base`.
4. Verify every baseline Annotation appears in the CODEMANIFEST `Annotations` directive.
5. **Auto-add** any missing baseline Usages or Annotations.

### Step 5. Classify Findings

For each finding:

1. Assign a severity:
   - **CRITICAL**: Facade violation, missing implementation, CODEMANIFEST syntax error, implementation contradicts a correct manifest.
   - **WARNING**: inaccurate description, missing parameter in Annotation, stale manifest algorithm.
   - **INFO**: writing-quality improvement recommendation.

2. Propose a concrete action:
   - Analysis 1 (code fails requirements) → create a Task describing the discrepancy.
   - Analysis 2 (requirements diverge from code) → edit CODEMANIFEST.
   - Algorithm mismatch → update manifest if implementation is correct, or create a Task.

3. Request User confirmation for all CRITICAL and WARNING findings.

### Step 6. Execute Approved Actions

For each approved action:

1. **Code fails requirements** → create a Task with discrepancy details.
2. **Requirements diverge from code** → apply CODEMANIFEST edits.
3. **Manifest is stale** → update CODEMANIFEST and record the reason.
4. **Implementation is incorrect** → record CRITICAL, create a Task.

### Step 7. Validate Updates

1. Run: `goga lint`.
2. Fix any syntax errors.
3. Repeat until the linter passes with zero errors.

STOP if:
- CRITICAL violations exist in any Cell.
- Implementation contradicts manifest and manifest is correct.
- CODEMANIFEST linter errors are present.
- Facade exposure violations are detected.

---

## Output Format

Fill in every section. Empty sections are prohibited.

```md
# Manifest Review Report

## Linter Results
[Table: Cell | Linter Status | Errors (if any)]

## Analysis 1 — Code vs Requirements
[Table: Cell | Signature Match | Method Coverage | Property Coverage | Facade | Status]

## Analysis 2 — Requirements vs Code
[Table: Cell | Undocumented Entities | Description Accuracy | Annotation Quality | Status]

## Algorithm Consistency
[Per Cell: manifest algorithm vs implementation — match / discrepancy]

## Operational Flow Consistency
[Per Cell: manifest flow vs implementation — match / discrepancy]

## Guarantee Verification
[Per Cell: manifest guarantees vs implementation — preserved / violated]

## Practice Consistency
[Per Cell: manifest practices vs implementation — match / discrepancy]

## Baseline Usages/Annotations Audit
[Table: Cell | Baseline Usages present? | Baseline Annotations present?]

## Findings
[Table: Cell | Analysis | Finding | Severity (CRITICAL/WARNING/INFO) | Proposed Action]

## Applied Updates
[Table: Cell | Updated Section | Previous Value | New Value | Reason]

## Critical Discrepancies
[List of CRITICAL items. Empty if none.]

## Overall Status
[CONSISTENT / INCONSISTENT — with justification]
```

## Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [qarium](https://github.com/qarium)
- **Source:** [qarium/goga](https://github.com/qarium/goga)
- **License:** BSD-3-Clause

Install and usage instructions live in the source repository linked above.

## Pricing

- **Free** — Free

## Security capabilities

Automated source analysis of v0.1.0 — what this tool can access:

- **Network access:** no
- **Filesystem access:** no
- **Shell / process execution:** no
- **Environment & secrets:** no
- **Dynamic code execution:** no

*"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.*


## Versions

- **0.1.0** — security scan: passed — Imported from the upstream source.

## Links

- Listing page: https://agentstack.voostack.com/l/skill-qarium-goga-goga-accept-manifest-review
- Seller: https://agentstack.voostack.com/s/qarium
- Browse the marketplace: https://agentstack.voostack.com/browse

---
Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.