Run agentready assessment and submit to leaderboard

[ralphbean]

What should happen

We should run agentready assess against this repo to evaluate how well it's set up for autonomous agent contribution. The results should be submitted to the agentready leaderboard.

Context

Fullsend is a project about autonomous agentic development — our repo should score well on tooling that measures agent-readiness. Running the assessment serves two purposes:

1. Visibility — getting our results on the public leaderboard.
2. Actionable improvements — if the assessment surfaces gaps in our repo setup (e.g., missing CONTRIBUTING.md, unclear build instructions, insufficient CLAUDE.md guidance), we should address those as part of this chore.

[Dharit13]

🤖 AgentReady Assessment Report

Repository: fullsend
Path: /private/tmp/fullsend
Branch: main | Commit: cba01190
Assessed: April 29, 2026 at 3:45 PM
AgentReady Version: 2.31.2
Run by: dhshah@dhshah-mac

---

📊 Summary

Metric	Value
Overall Score	51.3/100 🥉 Bronze (Tier Definitions)
Attributes Assessed	21/29
Attributes Not Assessed	8
Assessment Duration	0.3s

Languages Detected

• Go: 89 files
• Markdown: 86 files
• YAML: 29 files
• Shell: 16 files
• Python: 9 files
• JSON: 5 files

Repository Stats

• Total Files: 268
• Total Lines: 59,544

⚖️ Reviewer Notes on Assessor Limitations

Added by the human reviewer after the auto-generated run. Not produced by the AgentReady tool.

Of the 8 attributes the tool did not assess, only 4 are genuinely inapplicable

#	Attribute	Tier	Tool's reason	Applicable to fullsend?
1	dbt_project_config	T1	Not a dbt project	No — correctly skipped
2	dbt_model_documentation	T1	Not a dbt project	No — correctly skipped
3	dbt_data_tests	T2	Not a dbt project	No — correctly skipped
4	dbt_project_structure	T2	Not a dbt project	No — correctly skipped
5	test_coverage	T2	"Not applicable to YAML/Markdown/Go/JSON/Shell/Python"	Yes — make go-test runs go test -race -cover. Tool only recognises Python/JS coverage formats.
6	structured_logging	T3	"No Python dependency files found"	Yes — Go uses slog natively. The check is Python-only.
7	branch_protection	T4	"Requires GitHub API integration"	Yes — fullsend has branch protection on main. CLI can't query without a token.
8	container_setup	T4	Language list excludes Go	Borderline — no top-level Containerfile, but the agent stack uses containerised GHA actions.

Realistic count: 24/29 assessable for this repo, not 21/29. The three Go-applicable skips above (test_coverage, structured_logging, branch_protection) would almost certainly pass, which would lift the headline score above 51.3.

Several FAILed checks reflect the same Python/JS bias rather than real gaps

Failed check	Score	What's actually true on fullsend
architecture_decisions	0/100	Tool checks docs/adr/, .adr/, adr/, docs/decisions/ — case-sensitive miss. Fullsend has docs/ADRs/ (capital) with 11+ ADRs.
type_annotations	24.6%	Measures Python type hints / TS strict-mode. Fullsend is 89 Go files / 9 Python — Go types are part of the language, not annotations.
inline_documentation	12.3%	Python docstring / JSDoc measure. Doesn't recognise Go's // doc-comment convention.
standard_layout	0/2	Looks for src/ and tests/. Go's standard layout is cmd/ + internal/ (reference).
openapi_specs	0/100	Fullsend is a CLI + design-doc repo, not an HTTP API service.

The genuine, language-neutral gaps worth addressing are: missing .github/ISSUE_TEMPLATE/ and PULL_REQUEST_TEMPLATE.md; README missing Installation/Usage sections (or a Quick Start block); .gitignore only 3/16 standard patterns; conventional-commit style used in git log but not gated by commitlint or pre-commit; CI lacks actions/cache; and internal/cli/run.go at 1,167 lines.

🎯 Priority Improvements

Focus on these high-impact fixes first:

1. Standard Project Layouts (Tier 1) - +10.0 points potential
   • Organize code into standard directories
2. Type Annotations (Tier 1) - +10.0 points potential
   • Add type annotations to function signatures
3. README Structure (Tier 1) - +10.0 points potential
   • Create or enhance README.md with essential sections
4. Conventional Commit Messages (Tier 2) - +3.0 points potential
   • Configure conventional commits with commitlint
5. Inline Documentation (Tier 2) - +3.0 points potential
   • Add docstrings to public functions and classes

📋 Detailed Findings

Findings sorted by priority (Tier 1 failures first, then Tier 2, etc.)

Standard Project Layouts ❌ 0/100

📝 Remediation Steps

Measured: 0/2 directories (Threshold: 2/2 directories)

Evidence:

• Found 0/2 standard directories
• source directory: ✗ (no src/ or project-named dir)
• tests/: ✗

Organize code into standard directories

1. Create a source directory for your code
2. Option A: Use src/ layout (recommended for packages)
3. Option B: Use project-named directory (e.g., mypackage/)
4. Ensure your package has init.py
5. Create tests/ directory for test files
6. Add at least one test file

Commands:

# Option A: src layout
mkdir -p src/mypackage
touch src/mypackage/__init__.py
# ---
# Option B: flat layout (project-named)
mkdir -p mypackage
touch mypackage/__init__.py
# Create tests directory
mkdir -p tests
touch tests/__init__.py
touch tests/test_example.py

Examples:

# src layout (recommended for distributable packages)
project/
├── src/
│   └── mypackage/
│       ├── __init__.py
│       └── module.py
├── tests/
│   └── test_module.py
└── pyproject.toml

# flat layout (common in major projects like pandas, numpy)
project/
├── mypackage/
│   ├── __init__.py
│   └── module.py
├── tests/
│   └── test_module.py
└── pyproject.toml

Type Annotations ❌ 31/100

📝 Remediation Steps

Measured: 24.6% (Threshold: ≥80%)

Evidence:

• Typed functions: 31/126
• Coverage: 24.6%

Add type annotations to function signatures

1. For Python: Add type hints to function parameters and return types
2. For TypeScript: Enable strict mode in tsconfig.json
3. Use mypy or pyright for Python type checking
4. Use tsc --strict for TypeScript
5. Add type annotations gradually to existing code

Commands:

# Python
pip install mypy
mypy --strict src/

# TypeScript
npm install --save-dev typescript
echo '{"compilerOptions": {"strict": true}}' > tsconfig.json

Examples:

# Python - Before
def calculate(x, y):
    return x + y

# Python - After
def calculate(x: float, y: float) -> float:
    return x + y

// TypeScript - tsconfig.json
{
  "compilerOptions": {
    "strict": true,
    "noImplicitAny": true,
    "strictNullChecks": true
  }
}

README Structure ❌ 33/100

📝 Remediation Steps

Measured: 1/3 sections (Threshold: 3/3 sections)

Evidence:

• Found 1/3 essential sections
• Installation: ✗
• Usage: ✗
• Development: ✓

Create or enhance README.md with essential sections

1. Add project overview and description
2. Include installation/setup instructions
3. Document basic usage with examples
4. Add development/contributing guidelines
5. Include build and test commands

Examples:

# Project Name

## Overview
What this project does and why it exists.

## Installation
```bash
pip install -e .

Usage

myproject --help

Development

# Run tests
pytest

# Format code
black .

</details>

![T1](https://img.shields.io/badge/T1-Dependency_Security_%26_Vulnerability_Scanning_55--100-green) **Dependency Security & Vulnerability Scanning** ✅ 55/100

![T1](https://img.shields.io/badge/T1-CLAUDE.md_Configuration_Files_100--100-green) **CLAUDE.md Configuration Files** ✅ 100/100

![T1](https://img.shields.io/badge/T1-Dependency_Pinning_for_Reproducibility_100--100-green) **Dependency Pinning for Reproducibility** ✅ 100/100

![T1](https://img.shields.io/badge/T1-dbt_Project_Configuration_N--A-lightgray) **dbt Project Configuration** ⊘ 

![T1](https://img.shields.io/badge/T1-dbt_Model_Documentation_N--A-lightgray) **dbt Model Documentation** ⊘ 

![T2](https://img.shields.io/badge/T2-Conventional_Commit_Messages_0--100-red) **Conventional Commit Messages** ❌ 0/100
<details>
<summary>📝 Remediation Steps</summary>

**Measured**: not configured (Threshold: configured)

**Evidence**:
- No commitlint configuration found (.commitlintrc.json, package.json, husky, or pre-commit)

Configure conventional commits with commitlint

1. Option A (Python/pre-commit): Add conventional-pre-commit to .pre-commit-config.yaml
2. Option B (JS/commitlint): Install commitlint and configure husky for commit-msg hook

**Commands**:
```bash
# Python (pre-commit):
pip install pre-commit && pre-commit install --hook-type commit-msg
# JS (commitlint + husky):
npm install --save-dev @commitlint/cli @commitlint/config-conventional husky

Inline Documentation ❌ 15/100

📝 Remediation Steps

Measured: 12.3% (Threshold: ≥80%)

Evidence:

• Documented items: 20/162
• Coverage: 12.3%
• Many public functions/classes lack docstrings

Add docstrings to public functions and classes

1. Identify functions/classes without docstrings
2. Add PEP 257 compliant docstrings for Python
3. Add JSDoc comments for JavaScript/TypeScript
4. Include: description, parameters, return values, exceptions
5. Add examples for complex functions
6. Run pydocstyle to validate docstring format

Commands:

# Install pydocstyle
pip install pydocstyle

# Check docstring coverage
pydocstyle src/

# Generate documentation
pip install sphinx
sphinx-apidoc -o docs/ src/

Examples:

# Python - Good docstring
def calculate_discount(price: float, discount_percent: float) -> float:
    """Calculate discounted price.

    Args:
        price: Original price in USD
        discount_percent: Discount percentage (0-100)

    Returns:
        Discounted price

    Raises:
        ValueError: If discount_percent not in 0-100 range

    Example:
        >>> calculate_discount(100.0, 20.0)
        80.0
    """
    if not 0 <= discount_percent <= 100:
        raise ValueError("Discount must be 0-100")
    return price * (1 - discount_percent / 100)

// JavaScript - Good JSDoc
/**
 * Calculate discounted price
 *
 * @param {number} price - Original price in USD
 * @param {number} discountPercent - Discount percentage (0-100)
 * @returns {number} Discounted price
 * @throws {Error} If discountPercent not in 0-100 range
 * @example
 * calculateDiscount(100.0, 20.0)
 * // Returns: 80.0
 */
function calculateDiscount(price, discountPercent) {
    if (discountPercent < 0 || discountPercent > 100) {
        throw new Error("Discount must be 0-100");
    }
    return price * (1 - discountPercent / 100);
}

.gitignore Completeness ❌ 19/100

📝 Remediation Steps

Measured: 3/16 patterns (Threshold: ≥70% of language-specific patterns)

Evidence:

• .gitignore found (76 bytes)
• Pattern coverage: 3/16 (19%)
• Missing 13 recommended patterns

Add missing language-specific ignore patterns

1. Review GitHub's gitignore templates for your language
2. Add the 13 missing patterns
3. Ensure editor/IDE patterns are included

Examples:

# Missing patterns:
.idea/
*.test
*.py[cod]
.pytest_cache/
.vscode/

One-Command Build/Setup ❌ 30/100

📝 Remediation Steps

Measured: multi-step setup (Threshold: single command)

Evidence:

• No clear setup command found in README
• Setup automation found: Makefile
• Setup instructions not in first 3 sections

Create single-command setup for development environment

1. Choose setup automation tool (Makefile, setup script, or package manager)
2. Create setup command that handles all dependencies
3. Document setup command prominently in README (Quick Start section)
4. Ensure setup is idempotent (safe to run multiple times)
5. Test setup on fresh clone to verify it works

Commands:

# Example Makefile
cat > Makefile << 'EOF'
.PHONY: setup
setup:
	python -m venv venv
	. venv/bin/activate && pip install -r requirements.txt
	pre-commit install
	cp .env.example .env
	@echo 'Setup complete! Run make test to verify.'
EOF

Examples:

# Quick Start section in README

## Quick Start

```bash
make setup  # One command to set up development environment
make test   # Run tests to verify setup

</details>

![T2](https://img.shields.io/badge/T2-File_Size_Limits_50--100-red) **File Size Limits** ❌ 50/100
<details>
<summary>📝 Remediation Steps</summary>

**Measured**: 2 huge, 7 large out of 99 (Threshold: <5% files >500 lines, 0 files >1000 lines)

**Evidence**:
- Found 2 files >1000 lines (2.0% of 99 files)
- Largest: internal/cli/run.go (1167 lines)

Refactor large files into smaller, focused modules

1. Identify files >1000 lines
2. Split into logical submodules
3. Extract classes/functions into separate files
4. Maintain single responsibility principle

**Examples**:

Split large file:

models.py (1500 lines) → models/user.py, models/product.py, models/order.py

</details>

![T2](https://img.shields.io/badge/T2-Concise_Documentation_75--100-green) **Concise Documentation** ✅ 75/100

![T2](https://img.shields.io/badge/T2-Pre-commit_Hooks_%26_CI%2FCD_Linting_100--100-green) **Pre-commit Hooks & CI/CD Linting** ✅ 100/100

![T2](https://img.shields.io/badge/T2-Separation_of_Concerns_100--100-green) **Separation of Concerns** ✅ 100/100

![T2](https://img.shields.io/badge/T2-Test_Coverage_Requirements_N--A-lightgray) **Test Coverage Requirements** ⊘ 

![T2](https://img.shields.io/badge/T2-dbt_Data_Tests_N--A-lightgray) **dbt Data Tests** ⊘ 

![T2](https://img.shields.io/badge/T2-dbt_Project_Structure_N--A-lightgray) **dbt Project Structure** ⊘ 

![T3](https://img.shields.io/badge/T3-Architecture_Decision_Records_%28ADRs%29_0--100-red) **Architecture Decision Records (ADRs)** ❌ 0/100
<details>
<summary>📝 Remediation Steps</summary>

**Measured**: no ADR directory (Threshold: ADR directory with decisions)

**Evidence**:
- No ADR directory found (checked docs/adr/, .adr/, adr/, docs/decisions/)

Create Architecture Decision Records (ADRs) directory and document key decisions

1. Create docs/adr/ directory in repository root
2. Use Michael Nygard ADR template or MADR format
3. Document each significant architectural decision
4. Number ADRs sequentially (0001-*.md, 0002-*.md)
5. Include Status, Context, Decision, and Consequences sections
6. Update ADR status when decisions are revised (Superseded, Deprecated)

**Commands**:
```bash
# Create ADR directory
mkdir -p docs/adr

# Create first ADR using template
cat > docs/adr/0001-use-architecture-decision-records.md << 'EOF'
# 1. Use Architecture Decision Records

Date: 2025-11-22

## Status
Accepted

## Context
We need to record architectural decisions made in this project.

## Decision
We will use Architecture Decision Records (ADRs) as described by Michael Nygard.

## Consequences
- Decisions are documented with context
- Future contributors understand rationale
- ADRs are lightweight and version-controlled
EOF

Examples:

# Example ADR Structure

```markdown
# 2. Use PostgreSQL for Database

Date: 2025-11-22

## Status
Accepted

## Context
We need a relational database for complex queries and ACID transactions.
Team has PostgreSQL experience. Need full-text search capabilities.

## Decision
Use PostgreSQL 15+ as primary database.

## Consequences
- Positive: Robust ACID, full-text search, team familiarity
- Negative: Higher resource usage than SQLite
- Neutral: Need to manage migrations, backups

</details>

![T3](https://img.shields.io/badge/T3-Issue_%26_Pull_Request_Templates_0--100-red) **Issue & Pull Request Templates** ❌ 0/100
<details>
<summary>📝 Remediation Steps</summary>

**Measured**: PR:False, Issues:0 (Threshold: PR template + ≥2 issue templates)

**Evidence**:
- No PR template found
- No issue template directory found

Create GitHub issue and PR templates in .github/ directory

1. Create .github/ directory if it doesn't exist
2. Add PULL_REQUEST_TEMPLATE.md for PRs
3. Create .github/ISSUE_TEMPLATE/ directory
4. Add bug_report.md for bug reports
5. Add feature_request.md for feature requests
6. Optionally add config.yml to configure template chooser

**Commands**:
```bash
# Create directories
mkdir -p .github/ISSUE_TEMPLATE

# Create PR template
cat > .github/PULL_REQUEST_TEMPLATE.md << 'EOF'
## Summary
<!-- Describe the changes in this PR -->

## Related Issues
Fixes #

## Testing
- [ ] Tests added/updated
- [ ] All tests pass

## Checklist
- [ ] Documentation updated
- [ ] CHANGELOG.md updated
EOF

Examples:

# Bug Report Template (.github/ISSUE_TEMPLATE/bug_report.md)

```markdown
---
name: Bug Report
about: Create a report to help us improve
title: '[BUG] '
labels: bug
assignees: ''
---

**Describe the bug**
A clear description of what the bug is.

**To Reproduce**
Steps to reproduce:
1. Go to '...'
2. Click on '....'
3. See error

**Expected behavior**
What you expected to happen.

**Environment**
- OS: [e.g. macOS 13.0]
- Version: [e.g. 1.0.0]

</details>

![T3](https://img.shields.io/badge/T3-OpenAPI%2FSwagger_Specifications_0--100-red) **OpenAPI/Swagger Specifications** ❌ 0/100
<details>
<summary>📝 Remediation Steps</summary>

**Measured**: no OpenAPI spec (Threshold: OpenAPI 3.x spec present)

**Evidence**:
- No OpenAPI specification found
- Searched recursively for: openapi.yaml, openapi.yml, openapi.json, swagger.yaml, swagger.yml, swagger.json

Create OpenAPI specification for API endpoints

1. Create openapi.yaml in repository root
2. Define OpenAPI version 3.x
3. Document all API endpoints with full schemas
4. Add request/response examples
5. Define security schemes (API keys, OAuth, etc.)
6. Validate spec with Swagger Editor or Spectral
7. Generate API documentation with Swagger UI or ReDoc

**Commands**:
```bash
# Install OpenAPI validator
npm install -g @stoplight/spectral-cli

# Validate spec
spectral lint openapi.yaml

# Generate client SDK
npx @openapitools/openapi-generator-cli generate \
  -i openapi.yaml \
  -g python \
  -o client/

Examples:

# openapi.yaml - Minimal example
openapi: 3.1.0
info:
  title: My API
  version: 1.0.0
  description: API for managing users

servers:
  - url: https://api.example.com/v1

paths:
  /users/{userId}:
    get:
      summary: Get user by ID
      parameters:
        - name: userId
          in: path
          required: true
          schema:
            type: string
      responses:
        '200':
          description: User found
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/User'
        '404':
          description: User not found

components:
  schemas:
    User:
      type: object
      required:
        - id
        - email
      properties:
        id:
          type: string
          example: "user_123"
        email:
          type: string
          format: email
          example: "user@example.com"
        name:
          type: string
          example: "John Doe"

CI/CD Pipeline Visibility ❌ 70/100

📝 Remediation Steps

Measured: basic config (Threshold: CI with best practices)

Evidence:

• CI config found: .github/workflows/release.yml, .github/workflows/lint.yml, .github/workflows/notify-adr-slack.yml, .github/workflows/sandbox-images.yml, .github/workflows/site-deploy.yml, .github/workflows/stale.yml, .github/workflows/site-build.yml, .github/workflows/branch-cleanup.yml, .github/workflows/e2e.yml, .github/workflows/fullsend.yaml
• Descriptive job/step names found
• No caching detected
• Parallel job execution detected

Add or improve CI/CD pipeline configuration

1. Create CI config for your platform (GitHub Actions, GitLab CI, etc.)
2. Define jobs: lint, test, build
3. Use descriptive job and step names
4. Configure dependency caching
5. Enable parallel job execution
6. Upload artifacts: test results, coverage reports
7. Add status badge to README

Commands:

# Create GitHub Actions workflow
mkdir -p .github/workflows
touch .github/workflows/ci.yml

# Validate workflow
gh workflow view ci.yml

Examples:

# .github/workflows/ci.yml - Good example

name: CI Pipeline

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  lint:
    name: Lint Code
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Set up Python
        uses: actions/setup-python@v5
        with:
          python-version: '3.11'
          cache: 'pip'  # Caching

      - name: Install dependencies
        run: pip install -r requirements.txt

      - name: Run linters
        run: |
          black --check .
          isort --check .
          ruff check .

  test:
    name: Run Tests
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Set up Python
        uses: actions/setup-python@v5
        with:
          python-version: '3.11'
          cache: 'pip'

      - name: Install dependencies
        run: pip install -r requirements.txt

      - name: Run tests with coverage
        run: pytest --cov --cov-report=xml

      - name: Upload coverage reports
        uses: codecov/codecov-action@v3
        with:
          files: ./coverage.xml

  build:
    name: Build Package
    runs-on: ubuntu-latest
    needs: [lint, test]  # Runs after lint/test pass
    steps:
      - uses: actions/checkout@v4

      - name: Build package
        run: python -m build

      - name: Upload build artifacts
        uses: actions/upload-artifact@v3
        with:
          name: dist
          path: dist/

Cyclomatic Complexity Thresholds ✅ 100/100

Semantic Naming ✅ 100/100

Structured Logging ⊘

Code Smell Elimination ✅ 62/100

Branch Protection Rules ⊘

Container/Virtualization Setup ⊘

---

📝 Assessment Metadata

• AgentReady Version: v2.31.2
• Research Version: v1.0.1
• Repository Snapshot: cba0119
• Assessment Duration: 0.3s
• Assessed By: dhshah@dhshah-mac
• Assessment Date: April 29, 2026 at 3:45 PM

🤖 Generated with Claude Code

[Dharit13]

@ralphbean before submitting to the leaderboard - do we want to address some issues first?

[ralphbean]

Yes please! We don't need to fix every one, but if there are straightforward ones, let's do it.

[fullsend-ai-triage]

RICE Priority Score: 0.23

Score breakdown

Dimension	Score	Reasoning
Reach	0.5	This is an internal repo hygiene chore that primarily benefits the fullsend-ai team and future contributors. It does not directly affect any of the three strategic customers (konflux-ci, openkaiden, guacsec) or their workflows. The leaderboard submission provides some external visibility but is not customer-facing.
Impact	0.5	The improvements (README sections, issue/PR templates, .gitignore, ADR directory fix, CI caching) are incremental quality-of-life enhancements. For a project about autonomous agentic development, scoring well on agent-readiness has credibility value, but the gaps identified are mostly cosmetic or tooling-bias artifacts rather than real blockers. The reviewer notes confirm several 'failures' are false negatives from the tool's Python/JS bias.
Confidence	0.9	Very high confidence. The assessment has already been run with detailed results posted in a comment, the reviewer has annotated which failures are genuine vs. tool bias, and the scope of work is clearly enumerated. Ralph confirmed only straightforward fixes are needed.
Effort	1	Multiple small, well-scoped changes across different files: adding issue/PR templates, enhancing README with Installation/Usage sections, expanding .gitignore, renaming docs/ADRs to docs/adr, adding CI caching. Each is trivial individually but there are roughly 5-7 distinct items to address, putting this at medium effort.

Formula: (0.5 × 0.5 × 0.9) / 1 = 0.23

[dhshah13]

Waiting for this pull request to be merged. Will run again after that. Hope it will improve the score.

ambient-code/agentready#412

[dhshah13]

🤖 AgentReady Assessment Report

Repository: fullsend
Path: /Users/dhshah/fullsend/repo
Branch: docs/686-forge-landscape | Commit: 04646f66
Assessed: May 12, 2026 at 1:32 PM
AgentReady Version: 2.36.1
Run by: dhshah@dhshah-mac

---

📊 Summary

Metric	Value
Overall Score	68.2/100 🥈 Silver (Tier Definitions)
Attributes Assessed	26/33
Attributes Not Assessed	7
Assessment Duration	2.2s

Languages Detected

• Markdown: 118 files
• Go: 91 files
• TypeScript: 90 files
• YAML: 40 files
• Shell: 24 files
• Python: 16 files
• JSON: 11 files
• JavaScript: 3 files
• TOML: 3 files

Repository Stats

• Total Files: 446
• Total Lines: 92,263

⚖️ Reviewer Notes on Assessor Limitations

Added by the human reviewer after the auto-generated run. Not produced by the AgentReady tool.

Score change since last run: 51.3 → 68.2 (+16.9 points, Bronze → Silver)

The previous assessment was run on Apr 29 with AgentReady v2.31.2 on commit cba01190 (main). This re-run uses v2.36.1, which incorporates fixes from agentready#412 and agentready#423. Most of the score improvement comes from the tool now correctly handling Go repos rather than changes to the fullsend codebase itself.

Of the 7 attributes the tool did not assess, only 4 are genuinely inapplicable

#	Attribute	Tier	Tool's reason	Applicable to fullsend?
1	dbt_project_config	T1	Not a dbt project	No — correctly skipped
2	dbt_model_documentation	T1	Not a dbt project	No — correctly skipped
3	dbt_data_tests	T2	Not a dbt project	No — correctly skipped
4	dbt_project_structure	T2	Not a dbt project	No — correctly skipped
5	cyclomatic_complexity	T3	Missing tool: gocyclo	Yes — would pass if the tool were installed. Not a repo issue.
6	branch_protection	T4	Requires GitHub API integration	Yes — fullsend has branch protection on main. CLI can't query without a token.
7	container_setup	T4	Language list excludes Go	Borderline — no top-level Containerfile, but the agent stack uses containerised GHA actions.

Realistic count: 28/33 assessable for this repo, not 26/33. The two applicable skips (cyclomatic_complexity, branch_protection) would likely pass, which would lift the score a few more points.

Improvements the tool now correctly recognizes (fixed since v2.31.2)

These were false negatives in the Apr 29 run due to Python/JS bias:

Attribute	v2.31.2 (Apr 29)	v2.36.1 (May 12)	What changed
standard_layout	❌ 0/100	✅ 100/100	Now recognizes Go's cmd/ + internal/ layout
type_annotations	❌ 31/100	✅ 95/100	Now recognizes Go's native type system
inline_documentation	❌ 15/100	✅ 100/100	Now recognizes Go // doc comments
architecture_decisions	❌ 0/100	✅ 100/100	Case-insensitive ADR directory detection (#423) — now finds docs/ADRs/
test_execution	not assessed	✅ 100/100	Now evaluates Go test setup
lock_files	not assessed	✅ 100/100	New attribute, correctly passes
separation_of_concerns	not assessed	✅ 100/100	New attribute, correctly passes

Remaining tool limitations (false negatives)

Failed check	Score	What's actually true on fullsend	Upstream issue
structured_logging	0/100	Tool checks go.mod for third-party libraries. Fullsend uses Go stdlib log/slog (available since Go 1.21), which doesn't appear in go.mod.	#390
openapi_specs	0/100	Fullsend is a CLI + design-doc repo, not an HTTP API service. Should be N/A.	#386

Genuine gaps worth addressing

The remaining failures that represent real, actionable improvements:

Attribute	Score	Gap
single_file_verification	30/100	Linter configs exist but single-file commands not documented in CLAUDE.md
readme_structure	33/100	README missing Installation and Usage sections
ci_quality_gates	88/100	Lint + test gates present, but no type-check gate in CI
conventional_commits	0/100	Conventional style used in practice but not enforced with commitlint/pre-commit
one_command_setup	30/100	Makefile and package.json exist but no single make setup documented in README Quick Start
gitignore_completeness	32/100	Only 8/25 recommended patterns
file_size_limits	50/100	4 files >1000 lines (largest: internal/cli/admin.go at 1568 lines)
issue_pr_templates	0/100	No .github/ISSUE_TEMPLATE/ or PULL_REQUEST_TEMPLATE.md
code_smells	50/100	3 linters configured (ruff, golangci-lint, actionlint), tool expects more (eslint, markdownlint, pylint)
repomix_config	0/100	Not configured

🎯 Priority Improvements

Focus on these high-impact fixes first:

1. Single-File Verification (Tier 1) - +5.0 points potential
   • Document single-file lint and type-check commands in CLAUDE.md/AGENTS.md
2. README Structure (Tier 1) - +5.0 points potential
   • Create or enhance README.md with essential sections
3. CI Quality Gates (Tier 1) - +5.0 points potential
   • Add or improve CI/CD pipeline configuration
4. Conventional Commit Messages (Tier 2) - +3.0 points potential
   • Configure conventional commits with commitlint
5. One-Command Build/Setup (Tier 2) - +3.0 points potential
   • Create single-command setup for development environment

📋 Detailed Findings

Findings sorted by priority (Tier 1 failures first, then Tier 2, etc.)

Single-File Verification ❌ 30/100

📝 Remediation Steps

Measured: partially documented (Threshold: single-file lint + type-check commands documented)

Evidence:

• Linter configs found (Ruff) but no documented single-file commands

Document single-file lint and type-check commands in CLAUDE.md/AGENTS.md

1. Add single-file lint command to context file (e.g., 'ruff check path/to/file.py')
2. Add single-file type-check command (e.g., 'mypy path/to/file.py')
3. Ensure these commands work without a full build step
4. Target <5 seconds execution per file

Commands:

# Python
ruff check path/to/file.py
mypy path/to/file.py

# JavaScript/TypeScript
npx eslint path/to/file.ts
npx tsc --noEmit path/to/file.ts

README Structure ❌ 33/100

📝 Remediation Steps

Measured: 1/3 sections (Threshold: 3/3 sections)

Evidence:

• Found 1/3 essential sections
• Installation: ✗
• Usage: ✗
• Development: ✓

Create or enhance README.md with essential sections

1. Add project overview and description
2. Include installation/setup instructions
3. Document basic usage with examples
4. Add development/contributing guidelines
5. Include build and test commands

CI Quality Gates ❌ 88/100

📝 Remediation Steps

Measured: missing quality gates (Threshold: CI with lint + test + type-check gates on PRs)

Evidence:

• CI config found: .github/workflows/release.yml, .github/workflows/lint.yml, .github/workflows/notify-adr-slack.yml, .github/workflows/sandbox-images.yml, .github/workflows/site-deploy.yml, .github/workflows/stale.yml, .github/workflows/site-build.yml, .github/workflows/branch-cleanup.yml, .github/workflows/e2e.yml, .github/workflows/fullsend.yaml
• Lint gate detected in CI
• Test gate detected in CI
• No type-check gate found in CI
• Descriptive job/step names found
• Caching configured
• Parallel job execution detected
• Config includes comments

Dependency Security & Vulnerability Scanning ✅ 55/100

Type Annotations ✅ 95/100

Test Execution & Coverage ✅ 100/100

CLAUDE.md Configuration Files ✅ 100/100

Standard Project Layouts ✅ 100/100

Dependency Pinning for Reproducibility ✅ 100/100

dbt Project Configuration ⊘

dbt Model Documentation ⊘

Conventional Commit Messages ❌ 0/100

📝 Remediation Steps

Measured: not configured (Threshold: configured)

Evidence:

• No commitlint configuration found (.commitlintrc.json, package.json, husky, or pre-commit)

One-Command Build/Setup ❌ 30/100

📝 Remediation Steps

Measured: multi-step setup (Threshold: single command)

Evidence:

• No clear setup command found in README
• Setup automation found: Makefile, makefile, package.json
• Setup instructions not in first 3 sections

.gitignore Completeness ❌ 32/100

📝 Remediation Steps

Measured: 8/25 patterns (Threshold: ≥70% of language-specific patterns)

Evidence:

• .gitignore found (216 bytes)
• Pattern coverage: 8/25 (32%)
• Missing 17 recommended patterns

File Size Limits ❌ 50/100

📝 Remediation Steps

Measured: 4 huge, 13 large out of 199 (Threshold: <5% files >500 lines, 0 files >1000 lines)

Evidence:

• Found 4 files >1000 lines (2.0% of 199 files)
• Largest: internal/cli/admin.go (1568 lines)

Deterministic Enforcement (Hooks & Lint Rules) ✅ 60/100

Pattern References for Common Changes ✅ 60/100

Concise Documentation ✅ 75/100

Separation of Concerns ✅ 100/100

Inline Documentation ✅ 100/100

dbt Data Tests ⊘

dbt Project Structure ⊘

Repomix AI Context Generation ❌ 0/100

📝 Remediation Steps

Measured: not configured (Threshold: configured)

Evidence:

• Repomix configuration not found
• Missing repomix.config.json

Structured Logging ❌ 0/100

📝 Remediation Steps

Measured: not configured (Threshold: structured logging library)

Evidence:

• No structured logging library found in go.mod
• Go stdlib log package produces unstructured output

OpenAPI/Swagger Specifications ❌ 0/100

📝 Remediation Steps

Measured: no OpenAPI spec (Threshold: OpenAPI 3.x spec present)

Evidence:

• No OpenAPI specification found
• Searched recursively for: openapi.yaml, openapi.yml, openapi.json, swagger.yaml, swagger.yml, swagger.json

Design Intent Documentation ✅ 90/100

Architecture Decision Records (ADRs) ✅ 100/100

Cyclomatic Complexity Thresholds ⊘

Issue & Pull Request Templates ❌ 0/100

📝 Remediation Steps

Measured: PR:False, Issues:0 (Threshold: PR template + ≥2 issue templates)

Evidence:

• No PR template found
• No issue template directory found

Code Smell Elimination ❌ 50/100

📝 Remediation Steps

Measured: ruff, golangci-lint, actionlint (Threshold: ≥60% of applicable linters configured)

Evidence:

• Linters configured: ruff, golangci-lint, actionlint
• Coverage: 50/100 points (50%)

Progressive Disclosure ✅ 70/100

Branch Protection Rules ⊘

Container/Virtualization Setup ⊘

---

📝 Assessment Metadata

• AgentReady Version: v2.36.1
• Research Version: v2.0.0
• Repository Snapshot: 04646f6
• Assessment Duration: 2.2s
• Assessed By: dhshah@dhshah-mac
• Assessment Date: May 12, 2026 at 1:32 PM

🤖 Generated with Claude Code