aidd-team

Plugin aidd-team from marketplace aidd in thaithienvanid/aidd. Commands read from the repo's manifest — 2 days ago.

Skills (38)

• accessible-ui

  Practice skill: build and check accessible, comfortable UI. Use in an aidd repository when a Task changes a screen, form, or UI copy, or someone says a11y, focus, contrast, or eye strain.

• adr

  Practice skill: record an architecture decision (MADR). Use in an aidd repository when a choice is hard to reverse, or someone asks X or Y, why we picked this, or for an ADR.

• ai-evals

  Practice skill: prove an AI feature with evals. Use in an aidd repository when a Task changes a prompt, model call, RAG, agent, or guardrail, or answers got worse.

• aidd-team

  In an aidd repository, run a team flow: plan, propose, MVP, onboard, specify, implement, fix, review, rollout, handover, postmortem, retro, autopilot, or a mode (refine, explore, rework, upkeep); or one names a role (product-manager, delivery-manager, architect, product-designer, security-engineer,

• caching

  Practice skill: cache a result without serving a wrong one. Use in an aidd repository when a Task adds or changes a cache, HTTP cache headers, a CDN rule, or memoization, or users see stale data.

• ci-pipeline

  Practice skill: change CI, CD, or build pipelines safely. Use in an aidd repository when a Task touches a workflow, build script, Dockerfile, release job, or IaC, or CI is red.

• cli-design

  Practice skill: design a command-line interface. Use in an aidd repository when a Task adds or changes a command, flag, CLI prompt, help text, exit code, JSON output, or terminal color.

• client-delivery

  Practice skill: run a client engagement from qualification to handover. Use in an aidd repository for a kickoff, RAID log, phase, change order, or handover.

• code-review

  Practice skill: review a diff against its Spec. Use in an aidd repository when reading a PR/MR as a reviewer, or someone asks to review a diff or whether it is ready to merge.

• concurrency

  Practice skill: run work in parallel and share state without races. Use in an aidd repository when a Task adds threads, async tasks, goroutines, or shared state, or a bug shows only under load.

• data-access

  Practice skill: read and write a database correctly under concurrency. Use in an aidd repository when a Task writes in a transaction, locks rows, queues jobs in a table, or reads a replica.

• data-model-design

  Practice skill: design a config or data model. Use in an aidd repository when a Task adds or edits a schema, config key, file format, field, enum, or who writes one, or a name clashes with a sibling.

• debugging

  Practice skill: find a failure's cause by experiment first. Use in an aidd repository when a bug, wrong result, broken change, or failing or flaky test is reported, before any fix; not for an outage.

• dependency-upgrade

  Practice skill: upgrade one dependency at a time. Use in an aidd repository when a Task bumps a package, runtime, image, or lockfile, a bot PR arrives, or a CVE lands.

• diagrams

  Practice skill: explain a change as a Mermaid diagram. Use in an aidd repository when a Design, threat model, plan, or runbook needs a picture, or someone asks to draw the flow.

• estimation

  Practice skill: estimate effort or cost as a range. Use in an aidd repository when a proposal, plan, or budget needs a number, or someone asks how long or how much.

• incident-response

  Practice skill: run a live incident until service is back. Use in an aidd repository when production is down or degraded, an alert fires, or a breach is suspected.

• legacy-modernization

  Practice skill: replace a legacy system one slice at a time. Use in an aidd repository when a Task rewrites, ports, or migrates old code, data, or a cloud, or someone says strangler or cutover.

• maintainable-code

  Practice skill: keep code readable as it grows. Use in an aidd repository when a Task grows a function, file, module, or package, writes a comment or docstring, or a diff's shape is reviewed.

• modular-monolith

  Practice skill: one deployable, split into modules with enforced boundaries. Use in an aidd repository on a new project, or when a Task adds a module or changes its API, events, or data.

• naming

  Practice skill: choose, check, or improve a name. Use in an aidd repository when a Task names a module, type, file, column, event, flag, metric, component, token, or label, or a name misleads readers.

• observability

  Practice skill: make a change observable, with a rollback trigger. Use in an aidd repository when writing an observe block, adding logs, metrics, traces, or alerts, or a release.

• performance

  Practice skill: make a change fast enough, against a budget. Use in an aidd repository when a Spec touches a hot path, a Task has a latency or load goal, or something is slow or times out.

• plain-language

  Practice skill: write at the level the reader needs. Use in an aidd repository when a Task writes prose a person reads: docs, Specs, runbooks, messages, or client documents.

• product-defaults

  Practice skill: build what `project.defaults` leaves on, each with its test. Use in an aidd repository on Day 0 or when a Task touches a default.

• product-discovery

  Practice skill: frame the problem before building. Use in an aidd repository when planning an Intent, slicing it into Specs, or judging whether a request is worth doing.

• proposal

  Practice skill: write a proposal a person decides on. Use in an aidd repository when writing a bid, quote, statement of work, RFP answer, or business case.

• prototyping

  Practice skill: build an interactive prototype for Spec approval. Use in an aidd repository when a user-facing Spec needs a clickable flow, not just a wireframe.

• release-rollout

  Practice skill: roll out progressively and undo it. Use in an aidd repository for a release, a feature flag or kill switch, an A/B test, a canary, a staged rollout, or a rollback.

• resilience

  Practice skill: recover each failure exactly once. Use in an aidd repository when code calls a service, queue, provider, or job that may fail, or adds retries or timeouts, or fixes duplicate effects.

• retrospective

  Practice skill: run a retrospective on the delivery loop itself, from its numbers. Use in an aidd repository on the team's cadence, or after an incident, a rollback, or a rejected Merge approval.

• schema-migration

  Practice skill: change a schema, data contract, or pipeline safely. Use in an aidd repository when a Task adds a migration, column, index, event schema, or backfill.

• secure-coding

  Practice skill: write and change code securely. Use in an aidd repository when a Task handles input, auth, secrets, config, files, SQL, shell, or crypto, or on any Implement Task.

• support-desk

  Practice skill: triage incoming issues and report support. Use in an aidd repository for a bug report, support ticket, feedback, or a support report.

• system-design

  Practice skill: design from measured goals and compared options. Use in an aidd repository when a Spec's Design adds a component, a data store, a queue, or a service, or meets a new scale goal.

• technical-writing

  Practice skill: write docs humans and agents can use. Use in an aidd repository when a Task changes docs, a README, a changelog, release notes, or AGENTS.md.

• test-design

  Practice skill: turn Acceptance into tests before code. Use in an aidd repository when writing or reviewing a Spec's tests, or someone asks what to test or says tests are flaky.

• threat-model

  Practice skill: threat-model a change before code exists. Use in an aidd repository when a Spec touches auth, personal data, secrets, a trust boundary, or an AI feature.

Slash commands (13)

• /aidd-team:autopilot

  Run the loop step by step between your decisions; the lead picks each next step, the roles do it, and the run stops at every ask

• /aidd-team:fix

  Make a small minor change on the quick path, a bug fix or any other type: one builder proves it, makes it, and checks its own head; the reviewer reads a diff over 20 changed lines; stops at the human Merge approval

• /aidd-team:handover

  Hand a client engagement over: the Handover list in the acceptance record, from the repository and docs to the client's data, the agent setup, and who decides, for the client's sign-off

• /aidd-team:implement

  Implement a change: an approved Spec with one builder role per Task (the developer, SRE, or technical writer), or a change with no Spec; rework fixes a head that came back from review

• /aidd-team:mvp

  Build an MVP from a request: a one-screen plan of vertical slices, a Day-0 baseline, a walking skeleton, the other slices in parallel worktrees, and a launch review, with a person deciding at each stop

• /aidd-team:onboard

  Hire the team into a repository: map the codebase read-only, fit aidd to it, and pick the first changes

• /aidd-team:plan

  Plan work bigger than one Spec as an Intent, phases of slices, checked by the architect; refine refines the open backlog

• /aidd-team:postmortem

  Write the blameless postmortem and finish the backfill Spec after an incident

• /aidd-team:propose

  Write a proposal for a client or for the company's decision makers, before any code: needs, solution, options, estimate, and the two human decisions

• /aidd-team:retro

  Run a retrospective on aidd's loop itself, propose measured improvements, and route the upkeep that is due (stale standards, old flags, flaky tests, ending waivers, runbook drills)

• /aidd-team:review

  Verify and review a PR/MR against its Spec side by side: the verifier, the reviewer, the security engineer when risky, and the product designer for a built UI, before the human Merge approval

• /aidd-team:rollout

  Roll out an approved change: once it is merged, watch the observe window with the SRE and follow the rollback trigger

• /aidd-team:specify

  Specify a Spec with the architect, a specialist only for a concern it flags or a document the risk requires, and the verifier, then prepare Spec approval; explore compares two or three directions for a person to pick

Subagents (12)

• architect

  aidd architect. Use to design a Spec from a slice in one session: Context, Design, Concerns, Tasks and their scope, risk, rollback, and ADRs, before any specialist starts.

• compliance-analyst

  aidd compliance analyst. Use when a change touches personal data, a compliance target, or an AI feature above the minimal EU AI Act tier, to map obligations to controls and evidence.

• delegate

  aidd delegate. Use under a standing delegation, after `aidd delegate check` says eligible, to answer one delegated ask for the person (Spec approval, a push of the change's own branch, or a merge) from the packet the check builds; accepts or defers, never edits or runs anything.

• delivery-manager

  aidd delivery manager. Use for a client engagement: qualify a request, keep the RAID log and phases, report status, draft change orders, coordinate acceptance, and run the handover.

• developer

  aidd developer. Use to implement a change inside its scope, writing its unit and integration tests with the code, red first, until the tests pass: one Task of a Spec once Spec approval holds, never editing its frozen acceptance tests; a change with no Spec with its regression test; or an emergency r

• product-designer

  aidd product designer. Use on a change with a user-facing surface: to build an interactive, accessible prototype before Spec approval, to review the built UI against it, and a new or reshaped screen with no Spec.

• product-manager

  aidd product manager. Use to turn a request or a goal into an Intent: a measurable outcome and phases of prioritized INVEST slices, before any Spec or code is written, and to start a proposal for a client or the company's decision makers: its needs, goal, and questions, up to the go/no-go decision.

• reviewer

  aidd code reviewer. Use to review a PR/MR's diff adversarially against its Spec before Merge approval; reports ranked findings, never approves or edits.

• security-engineer

  aidd application security engineer. Use to threat-model a Spec that touches security, data, privacy, dependencies, or AI features, and to review a diff for vulnerabilities before a person reviews its security. Not for mapping legal or regulatory obligations, or for a compliance review — that is comp

• sre

  aidd site reliability engineer. Use to plan observe and rollback, watch the observe window after release, handle an incident, write postmortems and runbooks, and change CI/CD and infrastructure.

• tech-writer

  aidd technical writer. Use to write the user-facing documentation, changelog entry, and migration notes a change needs, inside a documentation Task's scope.

• verifier

  aidd verifier. Use in Specify to write a Spec's acceptance tests, at most one per Acceptance item plus one per authorization cell and abuse case, red on the base commit for the right reason, and in Verify to run the built change and check it behaves as the Acceptance says; never fixes, edits the fro

Similar plugins