agentleFS
Sign inStart free
ulises-jeremiasulises-jeremias/agent-toolkit/skills/delivery/technical-unit-assessment/SKILL.md

technical-unit-assessment

Skill19 starsChanged 2 months agoMITView on GitHub

WHAT - Evidence-based technical unit assessment for repositories, platforms, frontend, backend,

We split this skill into the rules it gives an agent

6 rules. About 0 are common, 2 are distinctive, and 4 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈2

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 4

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Use project-assessment as the router for multi-unit assessments.

    line 14
  2. Distinctive:

    Does NOT score indicators without evidence — mark as Not assessed

    line 18
  3. Distinctive:

    Does NOT make technical decisions — scores inform, humans decide

    line 19
  4. Very specific:

    Does NOT produce final report without output-handshake

    line 20
  5. Very specific:

    Run project-assessment-evidence to build evidence map

    line 33
  6. Very specific:

    Use the 1–5 scale from references/indicator-groups.md.

    line 41

≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Technical Unit Assessment (WHAT)

Assess a technical unit: frontend app, backend API, data platform, infrastructure/IaC scope, mobile app, AI/ML pipeline, or another technical workload.

Run project-assessment-evidence first. Use project-assessment as the router for multi-unit assessments.

Out of scope

  • Does NOT score indicators without evidence — mark as Not assessed
  • Does NOT make technical decisions — scores inform, humans decide
  • Does NOT produce final report without output-handshake

Unit intake

Ask before scoring:

  • Unit name and type (frontend / backend / infra / data / mobile / AI)
  • Repositories, services, infrastructure scopes, or pipelines included
  • Technical decision ownership (team, client, shared, unknown)
  • Assessment period
  • Authoritative systems for code, docs, CI/CD, incidents, observability, security

Workflow

  1. Run project-assessment-evidence to build evidence map
  2. Select indicator groups matching the unit type (see references/indicator-groups.md)
  3. Score only indicators with evidence; mark rest as Not assessed
  4. Note confidence and missing evidence per score
  5. Apply output-handshake before final scorecard

Scoring rules

Use the 1–5 scale from references/indicator-groups.md. Do not average unrelated indicators without explaining weighting. Request validator for subjective scores.

References

  • references/indicator-groups.md — all indicator groups + scoring scale + AI-native readiness
  • references/default-template.md — technical unit scorecard template
  • references/example-frontend-assessment.md — example assessment for a frontend team

Delegates to

NeedSkill
Evidence intakeproject-assessment-evidence
Multi-unit routingproject-assessment
Deep UI/UX reviewfigma / figma-implement-design
Repo discoveryassistant
Final output gateoutput-handshake

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

Reviews can't be read right now.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free