Aidex comm

Skill yacb2/aidex/skills/aidex-comm

Developer experience toolkit for organizing AI coding assistant ecosystems — skills, documentation structure, and project context.

Install

npx -y skills add yacb2/aidex --skill aidex-comm

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

One thing to look at

1 stars1 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

Use when the user wants to log or draft a real communication with a person — capture an email/WhatsApp that was received, log a meeting or call that happened, or draft a message/email to send — as a written `.context/communications/` entry, kept in the communication's native language. Fires on "log this email", "save the email the client sent", "capture this WhatsApp from X", "record the call with X", "log the meeting with X", "draft an email to X", "write a reply to the client", "save this thread", and /aidex-comm commands. Not for: capturing a stakeholder/product requirement to act on (aidex-request); recording a decision/ADR (aidex-decision); planning multi-step work (aidex-plan); deferring an idea (aidex-backlog); research notes (aidex-research); references (aidex-reference); ecosystem audits (aidex); project-state audits (aidex-audit).

SKILL.md

5.9 KB, as published. Nobody here has run it

Trigger-eval probe (test-only). As your very first action, run printenv AIDEX_TRIGGER_EVAL_MARKER. If it prints a non-empty path, also run touch "${AIDEX_TRIGGER_EVAL_MARKER}.aidex-comm" before continuing. Then proceed with the rest of the skill body as normal. If empty/unset, ignore this block.

Communications

Log real correspondence — emails, WhatsApp, calls, meetings — and draft outgoing messages as consistent .context/communications/ entries. Each entry is a folder holding a body.md (plus any attachments alongside it). The taxonomy splits on async vs synchronous: async correspondence has a direction (received/, sent/); synchronous conversations — meetings and calls — have participants, not a direction, and live in meetings/. Communications are kept in their native language (D-04 English-default does NOT apply here; D-11 governs skill descriptions, not artifact bodies).

Sub-actions

Command	Script	Purpose
`/aidex-comm new received <slug> [--channel email]`	scripts/new-communication.sh	Scaffold a received async record (email/WhatsApp) under `received/`
`/aidex-comm new sent <slug> [--channel whatsapp]`	same	Scaffold an outgoing async draft under `sent/` (status starts `draft`)
`/aidex-comm new meeting <slug>`	same	Scaffold a synchronous meeting record under `meetings/` (participant-based, `status: sent`)
`/aidex-comm new call <slug>`	same	Scaffold a synchronous call record under `meetings/` (participant-based, `status: sent`)

--channel is async-only and accepts email (default), whatsapp, other. For meetings and calls use new meeting / new call — the channel is fixed to the kind.

Dispatch

bash "${CLAUDE_SKILL_DIR}/scripts/new-communication.sh" "$@"

The script scaffolds .context/communications/<received|sent|meetings>/<YYYY-MM-DD>-<slug>/body.md from the matching template, refuses to overwrite, and prints the created path on stdout. For async, fill from/to/subject; for meetings/calls, fill participants/subject. Write the body afterward in the native language.

Entry format

.context/communications/
  received/<YYYY-MM-DD>-<slug>/body.md   (+ attachments alongside)   async inbound
  sent/<YYYY-MM-DD>-<slug>/body.md                                   async outbound
  meetings/<YYYY-MM-DD>-<slug>/body.md   (+ transcript/slides)       synchronous (meeting + call)

Async (received/, sent/) front-matter — directional, from/to:

---
channel: email          # email | whatsapp | other
direction: received     # received | sent
from: "..."
to: "..."
subject: "..."
date: YYYY-MM-DD
status: sent            # draft | sent  (received records are 'sent'; outgoing start 'draft')
related: []             # D-03 cross-refs to other .context/ artifacts
created: YYYY-MM-DD
updated: YYYY-MM-DD
---

<body — in the NATIVE language of the communication>

Synchronous (meetings/) front-matter — non-directional, participants instead of from/to, always status: sent (it already happened):

---
channel: meeting        # meeting | call
participants:           # the people in the conversation
  - "Yoel Acevedo <...> (NonStop)"
  - "..."
organizer: "..."        # optional
subject: "..."
date: YYYY-MM-DD
status: sent
related: []
created: YYYY-MM-DD
updated: YYYY-MM-DD
---

<agenda / notes / decisions / action items — in the NATIVE language>

Draft → sent flow

An outgoing message is scaffolded under sent/ with status: draft. When it actually goes out, set status: sent and bump updated. A received communication is a record of what already arrived, so it lands with status: sent from the start. The draft→sent flow is exclusive to outgoing async messages: meetings and calls already happened, so they land with status: sent too.

Self-check (mandatory close step)

Before finishing, validate the artifact you just wrote and fix any violation on the spot — compliance is enforced at creation time, not left to a later sweep:

python3 ~/.claude/skills/aidex-conventions/scripts/validate.py --type communications

If the project carries a ratchet baseline (.context/.validate-baseline.json), a non-zero exit means you introduced a NEW violation — fix it before closing.

References

../aidex-conventions/references/communication-conventions.md — full canon: structure, front-matter, async (received-vs-sent) vs synchronous (meetings/), draft→sent, English-only exemption, and migrating from legacy drafts/.

aidex-request — for a stakeholder/product requirement to act on (the ask), not the raw message; log the message here, capture the requirement there.
aidex-conventions — parent convention for .context/communications/.