JS Mastery Engineering Workflow Skills
Takes a vague idea to shipped, verified, documented code — one skill per phase, for any AI coding agent.
README describes artifacts written into the user's repo (docs/, AGENTS.md), installation via the npx skills channel, and a zero-dependency checker that shrinks supply-chain surface; but the actual SKILL.md contents are absent from evidence, so least privilege, user confirmation, external effects (e.g. /develop running migrations), rollback, and sensitive-data handling cannot be verified and score 1; attribution relies on an unverified publisher with no provenance support.
CI runs a zero-dependency portability check on push/PR and a token budget analyzer exists, showing good self-consistency; but failure messages and error paths are not described anywhere in the evidence, and /check's verification behavior lacks source backing.
The README explicitly covers greenfield/brownfield/monorepo/single-change scenarios and multiple clients (Claude Code, Cursor, Codex, Gemini CLI), with a clear docs/ vs .workflow/ environment rule — the repository's strongest area; capability boundaries are honestly framed (the gate is not a guarantee), but per-skill trigger precision is only inferable from the README.
Information architecture is excellent (skill table, artifact-path-owner table, flow diagrams), the MIT LICENSE text is present, and the removal of hardening is disclosed as a known limitation; but there is no CHANGELOG or version history file, install notes depend on external npx skills docs without upgrade/uninstall guidance, and FAQ plus maintenance responsibility/update path are missing.
File-based state, the /clear suggestion, and layered workflow depth show genuine cost/benefit thinking; artifact paths are predictable and output usability is above average, but actual effectiveness (whether /check verify truly verifies) has no execution evidence.
README claims (layered gate, portability check) are partially traceable to in-repo scripts/CI, but the evidence set omits SKILL.md and script contents, so most assertions cannot be cross-corroborated; fact/inference separation is acceptable but cross-source corroboration is weak.
- Publisher is unverified; treat identity as unknown and award no brand credit.
- Actual SKILL.md instructions were not in the evidence set; permissions, side effects, and confirmation behavior cannot be statically verified — trial in an isolated environment first.
- /develop runs database migrations; use under a controlled branch with backups.
- No CHANGELOG or version history exists; diff skill files item-by-item when upgrading.
- Installation depends on the external npx skills toolchain; watch that upstream's own supply-chain security.
What does this agent do, and when should you use it?
This is a set of skills in the open Agent Skills format (repository jsmastery-pro/skills, MIT licensed) powering the JS Mastery development workflow. It ships nine skills — scope, audit, architect, develop, check, test, document, sync, debug — one per phase, run only when a change needs them and in any order. The core design is that state lives in files: a scope, specs, AGENTS.md context files, and tests all land in the repository (e.g. docs/scope/, docs/specs/), so work survives across sessions and works for a whole team. Installation uses npx skills into Claude Code's .claude/skills or the generic .agents/skills directory, and works with any Agent Skills client. Each skill's instructions live in its SKILL.md, while agents/openai.yaml is interface metadata only and carries no logic.
The flow is: idea → /scope → /audit → /architect → /develop → /check verify → /test → /check review → /document → /sync. /scope turns a product idea into a living, coarse scope file (docs/scope/) kept current as you ship. /audit writes the AGENTS.md context files every other skill reads. /architect runs a deep design conversation and writes load-bearing decisions as build specs in docs/specs/. /develop builds a feature — UI or backend — from its spec, gating to /architect if a decision is owed. /check verify runs the real app to prove the feature against the spec; /check review reads the code on a second, different model for a senior review. /test writes a senior test suite for the change; /debug runs a root-cause loop and hands a regression test to /test. /document writes PR text, CHANGELOG.md, release notes, or postmortems from the real diff; /sync reconciles AGENTS.md, scope, and spec statuses after a change. Install with: npx skills@latest add jsmastery-pro/skills -a claude-code (Claude Code) or npx skills@latest add jsmastery-pro/skills (generic .agents/skills for Codex and others). Restart Claude Code after installing and commit the skills folder to share with your team.
- A developer starting a greenfield product: /scope the idea, /architect the stack, scaffold the project, /audit to seed AGENTS.md from the real project, then the feature loop.
- A team taking over an existing codebase: run /audit first so every skill understands the stack, commands, and conventions, then /scope the next slice.
- An engineer with a failing build or bug: go straight to /debug for a disciplined root-cause loop, whose regression test goes to /test.
- A reviewer gating a merge: /check verify proves the feature in the real app; /check review gets a senior review on a different model before the PR.
- A monorepo maintainer: everything scopes to the target workspace, each with its own AGENTS.md, scope, stack, and commands.
- A developer writing release material: /document produces the PR body, changelog, release note, or postmortem from the real diff.
What are this agent's strengths and limitations?
- State lives in files (scope, specs, AGENTS.md, tests), so work survives across sessions and is shareable by the whole team instead of being trapped in a chat.
- Each skill is independent and runs on demand in any order: a bug goes to /debug, a small change needs only /develop plus /check verify.
- Gated, spec-driven design: /develop routes to /architect when a load-bearing decision is missing, and overrides are recorded as Assumed specs flagged until /architect ratifies them.
- Model-agnostic: any Agent Skills client (Claude Code, Cursor, Codex, Gemini CLI, and more) reads the SKILL.md, and /check review deliberately uses a different model than the one that wrote the code.
- It is not a standalone program — it depends on a host AI coding agent (e.g. Claude Code or Codex) to actually execute the skills; without such a client it is unusable.
- Adopting it introduces new file conventions (docs/scope/, docs/specs/, AGENTS.md, etc.) committed alongside your code, which is a migration cost for existing repos and team habits.
- Hardening (systems-level failure mode analysis) is temporarily removed and will return as a system design specialization.
- The layered gate is prompt-based and explicitly not an absolute guarantee; behavioral correctness still depends on /check verify and /test catching it.
- The README offers no benchmarks, adoption numbers, or long-term maintenance evidence; evaluate fit yourself before adopting.
How do you install or deploy this agent?
Requires a Node.js/npm environment and any Agent Skills client (Claude Code, Cursor, Codex, Gemini CLI, and more). Install: # Claude Code (installs into .claude/skills, then restart Claude Code)
npx skills@latest add jsmastery-pro/skills -a claude-code
# Generic .agents/skills, read by Codex and other agents
npx skills@latest add jsmastery-pro/skillsCommit the installed skills folder to share the workflow with your team. No additional credentials required.
How do you use this agent?
Invoke the skills as slash commands in your AI coding agent's session. Greenfield: /scope → /architect → scaffold → /audit → feature loop. Brownfield: /audit first, then /scope. A small change: /develop then /check verify. Run /debug anytime something breaks; run a bare /scope anytime to see where things stand. At the end of /scope, pick a workflow depth: Prototype (just /develop, self-checked), Alpha (adds /check verify), Beta (adds /test), or GA (adds a fresh-model /check review and /document); override per feature anytime. The workflow suggests /clear at handoffs so a fresh session reads from disk. If docs/ is a published docs site, workflow artifacts move to .workflow/ so they don't ship.