request-skill

Request New Skill

Submit a request for a new skill to be created by the CEO/admin. The request is sent via email to the admin with your description, use case, and workspace context.

Variables

• $ARGUMENTS -- Description of the skill needed

Workflow

1. If $ARGUMENTS is empty or too vague, ask:

   • "What should the skill do?" (one sentence)
   • "Give me an example of when you'd use it" (one scenario)
   • "What output do you expect?" (format/action)

2. Read .workspace-identity.json to get the requester's name and role.

3. Read personal/context/personal-info.md to get the requester's title and email.

4. Compose the request email:

Subject: HEADING OS Skill Request from {exec_name} ({exec_title})

Body (HTML):
<h2>New Skill Request</h2>
<p><strong>From:</strong> {exec_name} ({exec_title})</p>
<p><strong>Date:</strong> {today}</p>
<p><strong>Workspace:</strong> {exec_slug}</p>

<h3>Skill Description</h3>
<p>{description from $ARGUMENTS}</p>

<h3>Use Case</h3>
<p>{example scenario}</p>

<h3>Expected Output</h3>
<p>{expected output/action}</p>

<h3>Priority</h3>
<p>{requester's assessment: nice-to-have / would-help-daily / urgent-need}</p>

1. Resolve the recipient from the instance config, never from a literal address:

   ADMIN="$(python3 -c "import sys; sys.path.insert(0,'.'); from scripts.utils.operator_identity import admin_email, get_operator; print(admin_email() or get_operator()['email'])")"
   

   The value is admin_email in operator.yaml, read through the operator identity seam in scripts/utils/operator_identity.py, falling back to email.

   The order matters and is not cosmetic. email is whoever runs THIS clone, and this skill runs on an executive's workspace, so email alone mails the executive their own request. admin_email is the person who acts on it. On the operator's own workspace the two are the same address and the order never shows.

   An empty result means neither key is set. Report that, name admin_email, and send nothing.