docs(skills): autonomous dev skills

skills/build/spec-implementation/SKILL.md

@@ -0,0 +1,53 @@
+---
+name: spec-implementation
+description: >
+  GitHub Issue to Specification Workflow
+---
+
+# Workflow
+
+GitHub issue to specification workflow.
+
+## Input
+
+```text
+$GITHUB_ISSUE_URL [--dry-run]
+```
+
+Supported arguments:
+- GITHUB_ISSUE_URL -- execute against the provided GitHub issue.
+- --dry-run -- [Optional] Execute the workflow, but without any WRITE actions.
+
+## Workflow
+
+### Step 1: Read Issue
+
+Using the GitHub API, fetch the issue title & body of `$GITHUB_ISSUE_URL`.
+Identify whether there is an existing pull request associated with this issue, 
+and whether a Jira issue is mentioned in the issue body or title (eg. HYPERSHELL-000).
+
+Output: (`$ISSUE_CONTENT`, `$ISSUE_NUMBER`, `$EXISTING_PR`[NULL or string], `$JIRA_ISSUE`[NULL or string])
+
+### Step 2: Write and/or Update Specifications
+
+Read the [spec skill](skills/plan/spec/SKILL.md). 
+
+In a new work tree (in a new directory), follow its workflow to codify the intent of `$ISSUE_CONTENT` in specifications.
+
+### Step 3: Commit and Push
+
+Commit the specification changes.
+
+IF `$EXISTING_PR` IS NOT NULL:
+- Push to existing PR's branch
+- Update PR body to match actual diff, if necessary.
+
+ELSE:
+- Create a new branch for the issue of form `agent/work/issue/($JIRA_ISSUE ?? $ISSUE_NUMBER)`
+- Push to branch
+- Open Pull Request, link it to the issue
+- PR Body must conform to SIMPLIFIED TECHNICAL ENGLISH STANDARD.
+
+### Step 4: Update Issue State
+
+Place label `agent/reviewable-spec` on `$GITHUB_ISSUE_URL`.

skills/build/spec-review/SKILL.md

@@ -0,0 +1,52 @@
+---
+name: spec-review
+description: >
+  Specification Review Workflow
+---
+
+# Workflow
+
+Specification Review Workflow that assess a spec to be considered one of: 
+
+- `agent/review-spec-rejected`
+- `agent/review-spec-approved`
+
+## Input
+
+```text
+$GITHUB_PR_URL $GITHUB_ISSUE_URL [--dry-run]
+```
+
+Supported arguments:
+- GITHUB_PR_URL -- execute against the provided GitHub pull request.
+- GITHUB_ISSUE_URL -- the GitHub issue the PR is addressing.
+- --dry-run -- [Optional] Execute the workflow, but without any WRITE actions.
+
+## Workflow
+
+### Step 1: Read Pull Request
+
+Clone the repo at the state of `$GITHUB_PR_URL` and familiarize yourself
+with the specification changes made in the PR.
+
+### Step 2: Review the Specification Changes
+
+Read the [spec skill](skills/plan/spec/SKILL.md). 
+
+Assess the specifications according to:
+- the rules in the skill
+- faithfulness to the intent found in `$GITHUB_ISSUE_URL`
+- consistency with established design, architecture, and general project direction patterns.
+
+Output: `$REVIEW_VERDICT` - One of  
+- `agent/review-spec-rejected`
+- `agent/review-spec-approved`
+
+### Step 3: Update Issue State
+
+_Note: Create `$REVIEW_VERDICT` label if not exist._
+
+Place label `$REVIEW_VERDICT` on `$GITHUB_ISSUE_URL` and `$GITHUB_PR_URL`
+
+IF `$REVIEW_VERDICT`  == `agent/review-spec-rejected`:
+- Write rejection rationale as a comment on the PR. Use simplified technical english, and inline code review comments if applicable.

skills/build/triage/SKILL.md

@@ -0,0 +1,65 @@
+---
+name: triage
+description: >
+  GitHub Issue Triage Workflow.
+---
+
+# Workflow
+
+GitHub issue triage workflow that classifies issues as:
+- `agent/deferred`
+- `agent/workable`
+- `agent/duplicate`
+
+## Input
+
+```text
+$GITHUB_REPO_URL [--dry-run]
+```
+
+Supported arguments:
+- GITHUB_REPO_URL -- execute triage against the provided GitHub repository.
+- --dry-run -- [Optional] Execute the workflow, but without any WRITE actions.
+
+## Workflow
+
+### Step 1: Read Issues
+
+Using the GitHub API, fetch the issues in `$GITHUB_REPO_URL` that have the
+label `agent/allowed`. You MUST NOT read any issue that does not have the `agent/allowed` label.
+
+Output: `$LIST_OF_ISSUES`
+
+### Step 2: Classify Issues
+
+According to the criteria listed below, determine the classification each issue in `$LIST_OF_ISSUES`.
+It MUST be one of the following: 
+
+- `agent/duplicate`
+Definition: This issue is duplicated by an issue in `$LIST_OF_ISSUES` and contains equal or lesser clarity of intent. This issue will be closed.
+
+- `agent/deferred`
+Definition: This issue requires additional human input due to ambiguous intent,
+conflicting intent [with other issues], or the issue appears to be misaligned with the overall project direction.
+
+- `agent/workable`
+Definition: This issue contains clear intent, does not conflict with other issues, and is aligned with the overall project direction.
+
+
+Output: `$ISSUE_TO_CLASSIFICATION_MAP`
+
+### Step 3: Map Actions to Classification
+
+For each issue in `$ISSUE_TO_CLASSIFICATION_MAP`, execute actions according to the label:
+
+_Note: If the label does not exist, create it._
+
+- `agent/duplicate`
+Action: Label the issue as `agent/duplicate`. Then, close the label.
+
+- `agent/deferred`
+Action: Label the issue as `agent/deferred`.
+
+- `agent/workable`
+Action: Label the issue as `agent/workable`.
+

skills/plan/spec/SKILL.md

@@ -12,6 +12,12 @@ description: >
 
 Help the user create or change a spec that describes desired system behavior.
 
+Note: Specifications are not purely additive. They codify _repository intent_ and
+therefore must necessarily be utterly coherent and consistent always. More concretely,
+most spec additions are accompanied by deletions & modifications in other specs. To that end, be
+extremely thorough to understand the entire specification landscape when executing this
+workflow.
+
 ## User Input
 
 ```text