agentsclimarketplace

Gjalla spec review

Skill gjalla/engineering/skills/gjalla-spec-review

Opinionated, time-tested agent skills for trustworthy, production-grade engineering — spec-driven planning, rigorous review, and test auditing for the agentic SDLC.

Install
npx -y skills add gjalla/engineering --skill gjalla-spec-review

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

  • no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
  • 2 stars2 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Full review of a plan or spec to be sure there are no surprises, gaps, or mistakes. Use to harden a spec before implementation.

SKILL.md

2.6 KB, as published. Nobody here has run it

Comprehensive spec-review

The best, most elegant and effective software systems are ones that are well-informed, well-planned, and verifiable. The final output is a plan/spec that can act as a reference doc, covering the problem/motivation, technical approach, deltas (what properties of the system will change once implemented), and verification criteria.

Your task is to review this spec from multiple expert perspectives to ensure that this spec meets our expectations and will result in solid implementations once it's in the hands of the engineers:

Architect Review

  • Does the design fit the existing system and respect layer boundaries?
  • Are new components placed in the correct layer and ownership hierarchy?
  • Do interactions follow established patterns (sync/async/event)?
  • Is it compatible with the broader system (i.e. cross repository integrations, future goals, etc.?)
  • Is it overengineered or introducing complication that will be difficult to understand/maintain?
  • gjalla holds the master architecture spec, referencing it is key to ensuring that we're building an elegant and effective system

Security Review

  • Are all new endpoints authenticated and authorized?
  • Does the data model handle sensitive data correctly (PII, secrets)?
  • Are inputs validated at the surface-area boundary?
  • Are the data flows changing in a way the user should know about, like different types of data flowing to new consumers, etc.?

Quality Review

  • Is the testing strategy sufficient for the behavioral requirements?
  • The goal for AI-generated code is typically 100% test coverage, are positive, negative, and edge cases covered? Are appropraite and effective integration tests scope based on the end-goals?
  • Do acceptance criteria map to testable assertions?

User Advocate Review

  • Does the feature solve the stated problem?
  • Are failure modes graceful from the user's perspective?
  • Is the feature discoverable and documented?

Governance Review

  • Does the spec comply with all active project rules and conventions? (gjalla's master spec also defines rules and processes, check those)
  • Are any rule exceptions or overrides needed?
  • Does this change warrant an architecture decision record (ADR)? (not all do, mostly just things that introduce significant, new tradeoffs and need a historical record)

Output

For each lens, report: what passes, what's at risk, and concrete changes required before implementation. Separate blocking concerns from recommendations.

Gives 0 of the 12 instructions most plan spec skills give

Counted across 1,100 of the 1,860 authors here whose files we hold, read 2026-08-06

  • ask one question at a timein 46 of 1100, across 38 files
  • Break plans into vertical slicesin 28 of 1100, across 10 files
  • Publish issues in dependency orderin 27 of 1100, across 9 files
  • Iterate until user approves the breakdownin 24 of 1100, across 6 files
  • Explore the repository to understand the codebase statein 24 of 1100, across 7 files
  • Use domain glossary vocabularyin 23 of 1100, across 5 files
  • Apply correct triage labels to published issuesin 23 of 1100, across 5 files
  • Write failing tests before implementation codein 23 of 1100, across 18 files
  • Prefer AFK slices over HITLin 22 of 1100, across 7 files
  • ask clarifying questions until requirements are concretein 21 of 1100, across 13 files
  • Respect existing architecture decision recordsin 20 of 1100, across 5 files
  • write a specification before writing any codein 20 of 1100, across 12 files

Said here and by no other author read

  • Review spec from multiple expert perspectives
  • Verify design fits existing system and layer boundaries
  • Authenticate and authorize new endpoints
  • Verify testing strategy covers positive, negative, and edge cases
  • Confirm feature solves stated problem
  • Ensure failure modes are graceful

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once.

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.