Stats
Actions
Tags
Help us improve
Share bugs, ideas, or general feedback.
From famdeck
Assess a project's verification infrastructure and assign an autonomy readiness level (L0-L2). Use when the user asks 'is this project ready for autonomous work', 'check autonomy level', 'what verification tools are set up', 'assess project readiness', or when starting work on a new project to understand its quality baseline. Pairs with /autonomy-scaffold to fill gaps.
npx claudepluginhub ivintik/private-claude-marketplace --plugin famdeckHow this skill is triggered — by the user, by Claude, or both
Slash command
/famdeck:autonomy-assessThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Autonomous coding agents need guardrails — tests, linters, CI — to catch mistakes without human review. This skill evaluates what a project has and what it's missing, so you know how much trust to place in autonomous work.
Assesses codebase for AI agent readiness by detecting stacks, monorepos, git setup, and evaluating style, testing, code quality, secrets, and file sizes.
诊断项目工程健康度，评估 autopilot 兼容性并提供改进建议。当用户说"诊断"、"doctor"、"工程健康"、"为什么 autopilot 效果不好"时使用。
Runs Agent-Ready Codebase Assessment scoring codebase across 8 dimensions with parallel agents, producing weighted 0-100 score, band rating, and improvement roadmap. Supports Ruby, Python, PHP, TypeScript, JavaScript, Go, Java, Scala, Rust.
Share bugs, ideas, or general feedback.
Autonomous coding agents need guardrails — tests, linters, CI — to catch mistakes without human review. This skill evaluates what a project has and what it's missing, so you know how much trust to place in autonomous work.
Run the assessment against the current project:
python -c "
from famdeck.autonomy.report import assess_project
report = assess_project('$PWD')
print(report.summary())
"
The tool's output is a starting point, not the final answer. Always verify key findings manually — in particular, check that CI pipelines actually run tests and linting (not just deployments or publishing), and that coverage has a fail_under threshold.
If famdeck is not importable, fall back to manual inspection: check for test configs (pytest.ini, vitest.config.*, jest.config.*), linter configs (.eslintrc*, ruff.toml, .flake8), CI files (.github/workflows/, .gitlab-ci.yml), and coverage settings. Assign levels based on the criteria below.
| Level | What's present | What it means |
|---|---|---|
| L0 | No tests or linter | Cannot work autonomously — every change needs human review |
| L1 | Tests + linter | Basic autonomous work possible, but no safety net for regressions |
| L2 | L1 + CI (that runs tests/lint) + coverage thresholds + E2E validation | Full autonomous work with quality gates catching issues automatically |
Note on CI: a workflow that only publishes or deploys does not count. L2 requires CI that gates merges by running tests, linting, and type checking.
Beyond unit tests and linters, assess whether the project has end-to-end tests that verify the product works from the user's perspective. This is a separate criterion from having a test runner:
tests/e2e/, e2e/, or similar directories)A project can be L2 on infrastructure but still risky for autonomous work if its tests only cover internal functions and never exercise the product as a user would.
Present the level, detected tools, and gaps. Be specific about what's missing and why it matters:
Project: /Users/dev/my-app
Languages: TypeScript
Autonomy Level: L1
Detected tools:
test_runner: vitest
linter: eslint
Gaps:
- No CI pipeline that runs tests — required for L2
- No coverage thresholds — required for L2
- No E2E tests — cannot verify product works end-to-end
Suggested:
ci_pipeline: GitHub Actions (with test + lint steps)
coverage: vitest --coverage with fail_under threshold
e2e: Consider adding user-journey tests
If below L2, recommend specific next steps — usually /autonomy-scaffold to generate missing configs.