Best for
- Use when the user passes an idea, feature request, or problem description that needs scoping before building.
griffinwork40/agent-afk/src/bundled-plugins/awa-bundled/skills/spec/SKILL.md
Takes a loose idea and transforms it into a structured, actionable spec ready for implementation. Use when the user passes an idea, feature request, or problem description that needs scoping before building.
Decision brief
Before speccing, detect bug-shaped inputs: crashes, error stacks, regression reports ("worked yesterday", "used to work"), platform-specific failures ("broken on X", "doesn't work when…"), or user-report framing that implies root-cause-first (not design-first). If detected, stop…
Compatibility matrix
| Platform | Status | Evidence | What to check |
|---|---|---|---|
| Codex | Not declared | No explicit evidence | Portability before use |
| Claude Code | Not declared | No explicit evidence | Portability before use |
| Cursor | Not declared | No explicit evidence | Portability before use |
| Gemini CLI | Not declared | No explicit evidence | Portability before use |
Installation
The source command is displayed only when detected. A safe inspection prompt is always available so your agent can explain every action before execution.
npx skills add https://github.com/griffinwork40/agent-afk --skill "src/bundled-plugins/awa-bundled/skills/spec"Inspect the Agent Skill "spec" from https://github.com/griffinwork40/agent-afk/blob/803066d4f1e0cd57e983658dc670d647fcd893c9/src/bundled-plugins/awa-bundled/skills/spec/SKILL.md at commit 803066d4f1e0cd57e983658dc670d647fcd893c9. List every install step, command, network request, credential, file read/write, external action, and rollback step. Explain whether it fits my task. Do not install or execute anything until I approve.
Workflow
Before speccing, detect bug-shaped inputs: crashes, error stacks, regression reports ("worked yesterday", "used to work"), platform-specific failures ("broken on X", "doesn't work when…"), or user-report framing that implies root-cause-first (not design-first). If detected, stop…
Include an Epistemic confidence section at the end of every spec: summarize coverage gaps from research, flag claims that will be hard to verify, and note where human judgment will be needed.
Permission review
No configured static risk pattern was detected
This is not proof of safety. Runtime behavior, indirect dependencies, and hidden external systems are outside the static scan.
Evidence record
| Signal | Value | Evidence type | Meaning |
|---|---|---|---|
| Quality score | 62/100 | Computed | Documentation, specificity, maintenance, and trust rules |
| Repository stars | 45 | Source | Repository attention, not individual Skill quality |
| Compatibility | 0 platforms | Source | Declared in the catalog source record |
| Usage guide | automated source guide | Editorial | Generated or reviewed according to the visible evidence level |
Pinned source
Before speccing, detect bug-shaped inputs: crashes, error stacks, regression reports ("worked yesterday", "used to work"), platform-specific failures ("broken on X", "doesn't work when…"), or user-report framing that implies root-cause-first (not design-first). If detected, stop and redirect: "This is a debugging task, not a spec task. Route to /diagnose instead — it will isolate the root cause, then /spec can scope the fix." Do not emit a spec.
Dispatch two sub-agents in parallel. One researches the web for prior art, comparable approaches, and patterns relevant to $ARGUMENT. The other inspects the local working directory for conventions, existing artifacts, and integration points relevant to the domain. When both return, synthesize a concise spec using the domain-appropriate schema below. Present to the user for confirmation before proceeding.
Output schema by domain:
| Domain | Spec fields |
|---|---|
software | problem, goals, non-goals, approach, key decisions, interface, file plan, test plan, open questions |
research | problem, hypothesis, methodology, prior art positioning, expected results, publication plan, open questions |
design | problem, user needs, constraints, solution space, prototype plan, success metrics, open questions |
business | opportunity, risk analysis, competitive landscape, go/no-go criteria, resource plan, open questions |
| (other) | problem, goals, non-goals, approach, key decisions, deliverables, validation plan, open questions |
When domain is unspecified, infer from $ARGUMENT and the working directory. If ambiguous, use the generic (other) schema.
Include an Epistemic confidence section at the end of every spec: summarize coverage gaps from research, flag claims that will be hard to verify, and note where human judgment will be needed.