acs

Plugin acs from marketplace gms-marketplace in globalmindsolution/gms-marketplace. Commands read from the repo's manifest — 6 days ago.

Skills (31)

• analyze-requirements

  Analyze requirements before anything is planned — from a ticket, a prompt, a PRD feature or an attached spec or document (PDF, image, markdown), or any mix of them — survey the codebase to map the impact across components/files/tests, clarify the open questions, assumed defaults and refined acceptan

• audit-design

  Audit the system design against the code — compare the architecture set (the HLD and every lld/<feature>/ document, or one feature's) with the implementation and report every gap, classified as unimplemented (designed, not built), undocumented (built, not designed) or drifted (both, disagreeing), ea

• audit-security

  Audit the repository's security — the whole repo or one path, all categories or just one — and write a severity-ranked report. Use for ANY security check of the code, however narrow: a full audit, review, scan or assessment; only injection risks (user input reaching SQL, a shell or a template); only

• breakdown-ticket

  Break one epic — or a story or task too big for one reviewable PR — into PR-sized child tickets. Reads the ticket's requirements, its feature analysis, its tech design and a plan's oversize split seams, proposes every child (title, type story/task/bug, acceptance criteria, features, size) in ONE gro

• code-complex

  Implement a subject's plan on the COMPLEX delivery path — one implementer per disjoint file-map partition plus a final integration implementer for the seams between them, test-cases.md as the test contract, plan approval enforced. Dispatched by /acs:code after the plan records delivery_path complex;

• code-small

  Implement a subject's plan on the SMALL delivery path — one implementer (rarely two), test-cases.md as the test contract, no plan approval. Dispatched by /acs:code after the plan records delivery_path small; never chosen by hand.

• code-standard

  Implement a subject's plan on the STANDARD delivery path — one implementer per disjoint file-map partition, test-cases.md as the test contract, plan approval enforced. Dispatched by /acs:code after the plan records delivery_path standard; never chosen by hand.

• code-trivial

  Implement a subject's plan on the TRIVIAL delivery path — one implementer, the plan's own test strategy as the test contract, no plan approval. Dispatched by /acs:code after the plan records delivery_path trivial; never chosen by hand.

• code

  Implement an approved implementation plan in the consumer repo using TDD, targeted tests only. Dispatches to the delivery-path leg the plan recorded — code-trivial, code-small, code-standard or code-complex. The changeset review is a separate step, /acs:review-code. Takes requirements from a ticket

• create-api-contract

  Design a feature's API low-level design — one living document per interface (a REST resource, a CLI command group, an event topic, a gRPC service, a webhook) under lld/<feature>/api/, each operation's request/response or payload shapes, error codes, compatibility and examples traced to the acceptanc

• create-architecture

  Bootstrap or regenerate the product's high-level design (HLD) — the overview, tech stack and cross-cutting conventions plus the HLD views the repo enabled at /acs:setup (C4 context, container and component views, conceptual data model, API landscape, deployment, project structure, and opt-in data-fl

• create-data-design

  Write a feature's low-level data design — the logical ERD (entities, attributes, keys, cardinalities, database-agnostic) and the physical schema (tables or collections, column types, indexes, constraints and a migration outline), both Mermaid erDiagram, under lld/<feature>/data/ — each versioned, ch

• create-e2e-tests

  Write the end-to-end suites for a ticket's e2e-typed test cases (or, with no test-cases.md, the end-to-end flows its acceptance criteria describe), under the repo's configured e2e location and left uncommitted in the working tree for /acs:create-pr. Needs a configured e2e suite to run them with. Use

• create-flows

  Write a feature's low-level flow design — one document per flow under lld/<feature>/flows/ holding its Mermaid sequence diagram and, where the flow branches on business rules, its activity diagram; a state machine per entity whose lifecycle the change touches; and, only when the repo enabled them, c

• create-impl-plan

  Turn an analyzed ticket — or requirements given as a prompt or documents — into the implementation plan /acs:code executes — the file-by-file approach, the declared executor file map, the test strategy its implementers run, and the spec fold. Writes plan.md to the change's Development folder, and it

• create-pr

  Commit, push and open (or update) the pull request — the one acs skill that branches, commits and pushes. Whatever state the work is in — uncommitted, committed, unpushed or already pushed — it gets the changes onto a branch (splitting uncommitted ones into small reviewable commits the user confirms

• create-prd

  Define or amend the product PRD — vision, problem, personas, goals with measurable success metrics, prioritized features, NFRs, constraints — as a hub and one PRD per feature, left as local changes for /acs:create-pr to commit and open as a PR. Use when starting a product, onboarding acs onto an exi

• create-tech-design

  Write the tech design for a change — the hand-off document the team reviews and approves before implementation is planned — analyzing its requirements (a ticket, a prompt, documents or a mix), the feature analysis, the codebase and the architecture docs, weighing options with trade-offs, and produci

• create-test-docs

  Derive a change's test cases from its acceptance criteria — a ticket's, or requirements given as a prompt or documents — its plan and API contract — each case with an id, the AC it traces, its type (unit/integration/e2e), preconditions, steps, expected result and target suite. Writes test-cases.md w

• create-ticket

  Turn requirements — a raw request, a bug report, documents (specs, PDFs, images; in the repo or attached), a feature's analysis, a mix of them, or a remote tracker key to import — into one well-formed acs ticket (epic, story, task or bug) with PRD tracing, drafted by an author for its type and check

• docs-sync

  Re-verify and complete the doc updates a ticket's changeset requires — independently re-derived from the working-tree changeset (acs.py changes diff), /code's result.json, and the final changeset review verdict, never from a hand-off summary alone. Leaves the doc changes uncommitted beside the code

• handoff

  Hand a ticket over to a teammate on another machine, or pick one up — send packages the ticket's uncommitted work, the run state it resumes from and a handoff note (done, in flight, next, decisions) into the hidden git ref refs/acs/handoff/<ID> on origin, never a branch or a PR; receive restores tha

• manage-roadmap

  Plan, re-plan and track the product roadmap — milestones each with its release version, the PRD features it delivers and the epics behind it, and each milestone's delivery status derived from its tickets — left as local changes for /acs:create-pr to commit and open as a PR. Use once a PRD exists and

• merge-pr

  Review a ticket PR's readiness (CI, approvals, conflicts, branch protections) via gh and, when ready, merge it with the configured strategy, then clean up branches, worktree, and tracker status. Use to land a ticket's PR once it is ready and has an approving review. Call it as your first action on s

• release

  Assemble/verify the CHANGELOG section for a release version from the merged-ticket archive, plus a base_branch git-history fallback for tickets merged without an archive entry, bump the version-location files plus any extra refs configured in this repo's .acs/settings.json release block, date the se

• review-code

  Review any branch, diff, PR or ticket's changes — with or without a ticket id, "this branch against main" or someone else's branch against origin/main — whenever the user asks to review, audit, examine, scrutinize, critique or check them; prefer it over a generic code review. Call it as your first a

• run-e2e-tests

  Run this product's configured test suites (all of them, a --suite-selected subset, or the suites one run's test cases name), capture pass/fail results to an auditable run artifact, and on a failure triage and drive a closed regression-ticket loop. Use when asked to run the test suites, run a named s

• set-doc-status

  Approve, deprecate, mark implemented or reopen the product's versioned documents — the PRD, the roadmap, each feature's analysis, the HLD, each feature's LLD and each change's tech design — by picking whole features, design areas or single documents from one grouped list that shows every document's

• setup

  Optionally configure acs for the current repo — set the ticket prefix, install the CI ticket-link check (every PR names its ticket) and the test gates, choose which HLD and LLD design documents (C4 views, ERDs, API contracts, sequence and state diagrams …) the Design skills write, scaffold the model

• ship

  Umbrella command that drives the delivery pipeline declared in workflows/ship.yaml for one run — asking the run's cursor which step is due, invoking it, and asking again, always stopping before merge. Use when the user wants work shipped end-to-end with one command, or wants to resume a run from whe

• update

  Check for a newer acs plugin version, summarize the changelog between the installed and latest versions, refresh the marketplace, and run post-update migration checks (settings schema, leftover acs status line). Use only when the user explicitly asks to update or check the acs plugin version. Call i

Subagents (43)

• analyze-requirements-analyst

  Records what the requirements ask — from a ticket, documents, a prompt or a mix, normalised in the run's requirements.md — the problem against the code, the acceptance criteria to refine, the PRD feature and the questions for the user — as the requirements lane of the survey (starting from the previ

• analyze-requirements-impact-analyst

  Maps what code one area of the repository the requirements (a ticket, documents, a prompt or a mix) touch — components, files, tests and configuration, each with a file:line citation — plus the API-surface evidence and the seams into other areas, as authoring notes for /acs:analyze-requirements. One

• analyze-requirements-impact-reviewer

  Re-derives the impact map of a change's requirements (a ticket, documents, a prompt or a mix) from the repository and judges the analysis draft folder fresh — its README, its contexts table and every context file (grounding, completeness including every question for the user and every confirmed crit

• audit-design-gap-analyst

  Compares the design documents in scope (the HLD and the lld/<feature>/ API, data, flow and component documents) with the code in one area of the repository and classifies every gap — unimplemented (designed, not built), undocumented (built, not designed) or drifted (both, disagreeing) — each with ci

• audit-security-adjudicator

  Adjudicator for /acs:audit-security — receives ONE candidate security finding and tries to refute it (unreachable sink, input not attacker-controlled, a guard upstream, a test fixture, a scanner advisory that does not apply), confirming it only when it cannot, with the adjudicated severity and a res

• audit-security-auditor

  Audits one security category of the repository — code weaknesses (OWASP Top 10 classes with their CWE) in one area, secrets and insecure configuration, vulnerable dependencies through the repo's own installed scanners, or the code against the threat model in the architecture set — and raises candida

• code-implementer

  Implements one file-map partition of the plan for /acs:code with strict TDD — failing tests first, then the code, left uncommitted in the working tree with every changed path reported. Spawned by the /acs:code coordinator with a JSON task; not for direct invocation.

• create-api-contract-contract-author

  Surveys the interfaces a feature's acceptance criteria add or change against the code and the docs, records the survey as authoring notes, and writes the feature's living interface documents under lld/<feature>/api/ (one per interface, versioned) plus its fragment of the per-run api-contract.md reco

• create-api-contract-contract-reviewer

  Re-derives the interfaces a feature's acceptance criteria add or change from the requirements and the code, and judges the /acs:create-api-contract interface documents and run-record draft fresh against them, the HLD's integration map and API conventions, and the gap notes. Spawned by the /acs:creat

• create-api-contract-gap-analyst

  Compares one of a feature's existing interface documents (lld/<feature>/api/<interface>.md) with the interface as the code implements it and classifies every gap — unimplemented (designed, not built), undocumented (built, not designed) or drifted (both, disagreeing) — each with citations on both sid

• create-architecture-architect

  Surveys the PRD and the repo as it is, records the survey as authoring notes, and writes the product's high-level design (the enabled HLD types, all Mermaid) for /acs:create-architecture. Spawned by the /acs:create-architecture coordinator with a JSON task; not for direct invocation.

• create-architecture-gap-analyst

  Compares the existing high-level design with the code in one area of the repository and classifies every gap — unimplemented (designed, not built), undocumented (built, not designed) or drifted (both, disagreeing) — each with citations on both sides, as gap notes for /acs:create-architecture. One in

• create-architecture-reviewer

  Judges the product's high-level design fresh against the architect's authoring notes, the PRD and the codebase, across ten blocking dimensions, for /acs:create-architecture. Spawned by the /acs:create-architecture coordinator with a JSON task; not for direct invocation.

• create-data-design-designer

  Surveys a ticket's entities and the code's real schema against the docs, records the survey as authoring notes, and writes the feature's logical ERD and physical schema (with a migration outline, never migration code) under lld/<feature>/data/, all Mermaid, for /acs:create-data-design. Spawned by th

• create-data-design-gap-analyst

  Compares a feature's existing data documents (logical ERD, physical schema) with the code's real schema in one area of the repository and classifies every gap — unimplemented (designed, not built), undocumented (built, not designed) or drifted (both, disagreeing) — each with citations on both sides,

• create-data-design-reviewer

  Judges a feature's logical ERD and physical schema fresh against the ticket, the HLD's conceptual data model, the data conventions and the code's real schema, across ten blocking dimensions, for /acs:create-data-design. Spawned by the /acs:create-data-design coordinator with a JSON task; not for dir

• create-e2e-tests-suite-runner

  Judges the written e2e suites fresh against the cases and the repo for /acs:create-e2e-tests and runs them once, separating wiring failures (blocking) from product failures (recorded, not blocking). Spawned by the /acs:create-e2e-tests coordinator with a JSON task; not for direct invocation.

• create-e2e-tests-test-writer

  Decides how a ticket's e2e cases become suites in the repo's own harness, records that as authoring notes, and writes the suites for /acs:create-e2e-tests — tests only, never product code. Spawned by the /acs:create-e2e-tests coordinator with a JSON task; not for direct invocation.

• create-flows-designer

  Surveys a ticket's flows, entity lifecycles and components against the docs and the code, records the survey as authoring notes, and writes the feature's flow, state-machine and (when enabled) component documents under lld/<feature>/, all Mermaid, for /acs:create-flows. Spawned by the /acs:create-fl

• create-flows-gap-analyst

  Compares a feature's existing flow, state-machine and component documents with the code in one area of the repository and classifies every gap — unimplemented (designed, not built), undocumented (built, not designed) or drifted (both, disagreeing) — each with citations on both sides, as gap notes fo

• create-flows-reviewer

  Judges a ticket's flow, state-machine and component documents fresh against the designer's notes, the feature's API and data documents, the HLD and the code — sequence ↔ state agreement, references and form — across ten blocking dimensions, for /acs:create-flows. Spawned by the /acs:create-flows coo

• create-impl-plan-plan-reviewer

  Judges the implementation-plan draft fresh against the ticket, analysis, design and repo — AC-to-test coverage, file-map honesty, runnable test commands, scope — for /acs:create-impl-plan. Spawned by the /acs:create-impl-plan coordinator with a JSON task; not for direct invocation.

• create-impl-plan-planner

  Decides the implementation slices, the implementer file map, the tests-first strategy and the documentation map, and writes the plan draft /acs:code executes, for /acs:create-impl-plan. Spawned by the /acs:create-impl-plan coordinator with a JSON task; not for direct invocation.

• create-prd-author

  Writes or amends the PRD doc set for /acs:create-prd — as the hub author, prd.md (the feature index); as a feature author, one features/<slug>/prd.md — from the surveyor's authoring notes and the user's relayed answers, and fixes the reviewer's findings on later iterations. Spawned by the /acs:creat

• create-prd-reviewer

  Judges the PRD doc set fresh against the authoring notes and the create-prd quality bar — required sections, traceability, measurable metrics, the feature index against its documents, the deterministic plan-conformance floor, structure and audience style — for /acs:create-prd. Spawned by the /acs:cr

• create-prd-surveyor

  Classifies the /acs:create-prd mode (greenfield/brownfield/amend) with evidence, surveys the repo read-only, and records the PRD outline, the feature set, the corroboration sections and the open questions as the authoring notes for /acs:create-prd. Spawned by the /acs:create-prd coordinator with a J

• create-tech-design-designer

  Surveys the change's design decisions and candidate options, records them as authoring notes, and writes the tech design draft steps/create-tech-design/tech-design.md — the hand-off document the team reviews before implementation — for /acs:create-tech-design. Spawned by the /acs:create-tech-design

• create-tech-design-reviewer

  Judges the tech design draft — the hand-off document the team reviews before implementation — fresh against the designer's authoring notes, the codebase, the HLD and the feature's living LLD, across nine blocking dimensions, for /acs:create-tech-design. Spawned by the /acs:create-tech-design coordin

• create-test-docs-test-designer

  Decides the case set for every acceptance criterion and API-contract item, records it as authoring notes, and writes the test-cases draft for /acs:create-test-docs. Spawned by the /acs:create-test-docs coordinator with a JSON task; not for direct invocation.

• create-test-docs-trace-reviewer

  Re-derives traceability from the requirements' acceptance criteria and judges the /acs:create-test-docs draft fresh against it, the plan, the API contract and the repo. Spawned by the /acs:create-test-docs coordinator with a JSON task; not for direct invocation.

• create-ticket-bug-author

  Drafts one bug ticket — steps to reproduce, expected versus actual behaviour, environment, severity, the suspected area with citations and a regression-test acceptance criterion — as the workspace draft the /acs:create-ticket coordinator confirms with the user; never mints a ticket. Spawned by the /

• create-ticket-epic-author

  Drafts one epic ticket — problem and outcome, scope in and out, success metrics and a candidate breakdown outline (never the children themselves) — as the workspace draft the /acs:create-ticket coordinator confirms with the user. Spawned by the /acs:create-ticket coordinator with a JSON task; not fo

• create-ticket-reviewer

  Judges a type author's ticket draft fresh against the requirements, the PRD and the code — acceptance criteria concrete and testable, PRD trace and features, the type's own completeness, an honest size and no invented facts — for /acs:create-ticket, before the user confirms it. Spawned by the /acs:c

• create-ticket-story-author

  Drafts one story ticket — the user-facing value and Given/When/Then acceptance criteria, traced to the PRD — as the workspace draft the /acs:create-ticket coordinator confirms with the user; never mints a ticket. Spawned by the /acs:create-ticket coordinator with a JSON task; not for direct invocati

• create-ticket-task-author

  Drafts one task ticket — its technical outcome and a done-when checklist, no user story, traced to the PRD — as the workspace draft the /acs:create-ticket coordinator confirms with the user; never mints a ticket. Spawned by the /acs:create-ticket coordinator with a JSON task; not for direct invocati

• docs-sync-doc-updater

  Re-derives the doc delta a ticket's changeset requires for /acs:docs-sync and writes the doc updates into the working tree, uncommitted. Spawned by the /acs:docs-sync coordinator with a JSON task; not for direct invocation.

• docs-sync-drift-reviewer

  Independently re-derives the doc impact of a ticket's changeset for /acs:docs-sync and judges the doc-updater's (uncommitted) doc changes against it. Spawned by the /acs:docs-sync coordinator with a JSON task; not for direct invocation.

• docs-sync-gap-analyst

  Compares one feature's living LLD documents (api, data, flows, components) with the implemented changeset and the code for /acs:docs-sync and classifies every element — matches, unimplemented, undocumented or drifted — each with citations on both sides, plus a per-document verdict (implemented-candi

• manage-roadmap-author

  Writes or amends roadmap.md for /acs:manage-roadmap — milestones each with one release version, the PRD features it delivers, its epics and the Release versions table — from the surveyor's authoring notes and the user's relayed answers, and fixes the reviewer's and the floor's findings on later iter

• manage-roadmap-reviewer

  Judges roadmap.md fresh against the PRD, the authoring notes and the user's answers — each milestone's paragraph true to its features, a coherent order and grouping, the PRD's constraints and out-of-scope honoured, versions in sequence, the deterministic floor's record, and in amend/replan mode only

• manage-roadmap-surveyor

  Confirms the /acs:manage-roadmap mode (create/amend/replan) with evidence, reads the PRD hub's Features index, the feature PRDs, the existing roadmap and the derived delivery status read-only, and records the roadmap outline, the milestone and answer-fidelity lines and the open questions as the auth

• review-code-adjudicator

  Adjudicator for the /acs:review-code cycle — receives ONE candidate finding and tries to refute it. Spawned by the /acs:review-code coordinator with a JSON task; not for direct invocation.

• review-code-lens

  One review lens of the /acs:review-code cycle. Spawned by the /acs:review-code coordinator with a JSON task naming which lens it is; not for direct invocation.

Hooks (7)

• PreToolUse

  python3 "${CLAUDE_PLUGIN_ROOT}/hooks/scripts/dispatch.py" pre

• PreToolUse

  python3 "${CLAUDE_PLUGIN_ROOT}/hooks/scripts/dispatch.py" file-map

• SubagentStart

  python3 "${CLAUDE_PLUGIN_ROOT}/hooks/scripts/dispatch.py" subagent-start

• SubagentStop

  python3 "${CLAUDE_PLUGIN_ROOT}/hooks/scripts/dispatch.py" subagent-stop

• Stop

  python3 "${CLAUDE_PLUGIN_ROOT}/hooks/scripts/dispatch.py" stop

• PreCompact

  python3 "${CLAUDE_PLUGIN_ROOT}/hooks/scripts/dispatch.py" pre-compact

• SessionEnd

  python3 "${CLAUDE_PLUGIN_ROOT}/hooks/scripts/dispatch.py" session-end

Similar plugins