Autonomous Engineering Team all-in-one

About this skill

What's included (18 skills)

• acquire-project-skills

  Make a target project's own skills usable in the current session. Reads <TARGET_DIR>/.claude/skills/, symlinks each skill into ~/.claude/skills/ (so Claude Code hot-reloads them on the next turn), and records them in acquired-project-skills.json so the SessionEnd hook can remove them on exit. Invoke this at the START of working in any TARGET_DIR that ships its own .claude/skills/ — including from the project-builder, develop, revise-brief, and define-use-case entry points — or run it standalone to pull in one project's skills. Skips (never clobbers) any name already present in ~/.claude/skills/ or any name that matches a workspace skill.

• check-permissions-mode

  Check whether the current Claude session was launched with --dangerously-skip-permissions. Inspects the command line of this session's own claude process ($CLAUDE_PID) and reports yes/no via the command's exit code. Works on Windows, Linux/WSL, and macOS.

• define-architecture

  Capture the architecture of the project — platforms, service shape (monolith vs. modular vs. services), integrations, data flow, trust boundaries, and multi-tenancy. Use when the project-builder agent is gathering architecture information.

• define-deployment

  Capture deployment characteristics for both production and development — hosting, IaC, CI/CD, secrets, observability, local dev environment, containerization, hot reload, and seed data. Use when the project-builder agent is gathering deployment information.

• define-monetization

  Capture the monetization and distribution model of the project — business model, pricing tiers, target market, licensing, and any non-commercial framing. Use when the project-builder agent is gathering monetization information.

• define-overview

  Capture the high-level definition of a project — problem, target users, value proposition, scope boundaries, non-goals, and success criteria. Use when the project-builder agent is gathering overview information.

• define-quality-standards

  Capture the quality and standards baseline — linting, formatting, testing strategy, security, accessibility, performance budgets, documentation, and observability. Use when the project-builder agent is gathering quality/standards information.

• define-technologies

  Capture the technology choices for the project — languages, frameworks, data stores, auth, and key libraries. Stack-neutral; presents options with tradeoffs. Use when the project-builder agent is gathering technology information.

• define-use-case

  Capture a single use case for a target project. Collects a free-form description from the user, produces a formalized version (summary, acceptance criteria, pitfalls), runs a clarifying-question loop, and saves the result as an incrementally-numbered Markdown file in the target project's `use-cases/` folder. After saving, offers to define another use case or continue to implementation via the `develop` skill. Use when the user wants to document what the project should do, before or instead of jumping into implementation.

• develop

  Development workflow using an agent team (Analyst, Challenger, Developer, QA) to implement features, bug fixes, or refactors in a target project folder. Requires a PROJECT_BRIEF.md in the target folder; if missing, invokes project-builder first to generate one. Use BEFORE entering plan mode whenever the user asks for a code change in an external project. MUST be invoked whenever the user asks — even generically — to implement, build, add, fix, refactor, or "use the agents" / "use the team" on a target project, not only for fully detailed requests. If in doubt whether a request warrants this skill, prompt the user rather than silently proceeding solo.

• generate-release

  Generate a proper GitHub release description for a target project from the ACTUAL changes since the previous release tag — never by copying the prior release's notes. Produces a bullet-pointed "New features" section (each feature bullet up to 200 words) and a "Bugfixes" section (each bugfix bullet at most 50 words), with every bullet linking to the use case(s) it came from, then writes it to the release. Use whenever a release is cut for a target project (any release tag — a single `vX.Y.Z`, or per-component tags like `<component>-vX.Y.Z`), or standalone to (re)write the notes of an existing release.

• profile-aws-deployment

  Opt-in profile. AWS is the preferred cloud provider. Any AWS-based suggestion or solution MUST include a cost estimation table — per-service daily / monthly / yearly costs and cumulative totals that account for both newly proposed services AND pre-existing AWS services already in use by the project. Only invoke when PROJECT_BRIEF.md's `## Profiles` section lists this skill by name. Do NOT auto-invoke on arbitrary cloud or deployment discussions.

• profile-java-call-graph-tool

  Opt-in profile. Provisions the java-class-call-scanning bytecode call-graph analyzer (https://github.com/HaroldHormaechea/java-class-call-scanning) for use by the dev-team agents on a Java project. Downloads the latest release jar to a per-user cache, registers the daemon as an MCP stdio server scoped to TARGET_DIR, and documents per-role usage of the nine query operations (find-callers, find-callees, methods-in-class, methods-at-line, find-field-readers, find-field-writers, impact-of-diff, tests-for-diff, refresh-index). Only invoke when PROJECT_BRIEF.md's `## Profiles` section lists this skill by name. Do NOT auto-invoke on arbitrary Java work.

• profile-java-database-access

  Opt-in profile. Opinionated Java database-access conventions — DTO projections over entity queries, bulk retrieval over iterative round-trips, parameterized queries only (never string concatenation), and Hibernate as the JPA implementation. Only invoke when PROJECT_BRIEF.md's `## Profiles` section lists this skill by name. Do NOT auto-invoke on arbitrary Java or database-related work.

• profile-java-server-architecture

  Opt-in profile. Opinionated Java server-side architecture conventions — Gradle on its latest stable version, latest stable Spring Boot, latest Java LTS, repositories return DTOs (never JPA entities) to upper layers, internal DTOs stay internal (API layer has its own request/response DTOs), and a strict Controller/Job → Facade → Service → Repository call chain with transactions owned by the facade. Only invoke when PROJECT_BRIEF.md's `## Profiles` section lists this skill by name. Do NOT auto-invoke on arbitrary Java or Spring work.

• revise-brief

  Update one or more sections of an existing PROJECT_BRIEF.md in a target project folder without re-scaffolding. Lets the user pick which section(s) to refresh (overview, monetization, technologies, architecture, quality-and-profiles, deployment) and delegates to the project-builder subagent to re-run only those define-* skills. Keeps the YAML frontmatter in sync and preserves untouched sections. Use when the target project already has a brief and the user wants to evolve it; use `project-builder` for initial scaffolding or `develop` to build features.

• wait-and-monitor-operations

  Safely wait for and monitor any external-consequence outcome — CI runs, deploys, queue drains, container/service health, files appearing on disk — using the general "pre-flight the polled command, cap the loop, check exit code every iteration" pattern that prevents silent infinite stalls. Documents the reusable `wait_until` wrapper plus a concrete GitHub Actions instantiation (push / tag / PR-triggered runs, terminal-state field vocabularies, log-failed extraction) with every foot-gun that silently breaks polls. Use whenever a Claude run needs to wait for an asynchronous outcome before its next step.

• write-readme

  Generate or update a README.md in a target project folder. Reads PROJECT_BRIEF.md for context and produces a concise, honest README that avoids common LLM-writing pitfalls (marketing adjectives, empty badges, fake quick-start commands, emoji clutter, premature roadmap sections). Use during scaffolding once PROJECT_BRIEF.md is complete, or standalone to refresh an existing README.