Menú
Create/update a requirements document (requirements.md) inside WORK_PATH capturing technical requirements, constraints, and scope. Does NOT publish to /docs. No writes without APPROVE.
Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
Basado en la clasificación ocupacional SOC
| name | requirements-authoring |
| description | Create/update a requirements document (requirements.md) inside WORK_PATH capturing technical requirements, constraints, and scope. Does NOT publish to /docs. No writes without APPROVE. |
Create or update a requirements document inside the current WORK_PATH. This document captures technical requirements (constraints, scope, MUST/SHOULD/MAY rules) — what the system must do, without designing the solution.
This skill must NOT write to /docs/**.
requirements.md)requirements.md (or user-chosen name)contracts.md, models.md, verify.md, evidence.md
(create only if user explicitly requests)/docs/** relevant to this task, link to it instead of duplicating it.requirements.md (update instead of recreating).Follow the suggested structure below. Keep it concise and pack-friendly.
contracts.md)models.md)verify.md if it exists)requirements.md exists in WORK_PATH and captures scope, constraints, and acceptance criteriaReturn control to Fabricator.
Use after git-tooling push to create or manage a PR on Bitbucket Server. Composes PR description, creates PR via API, handles review comments. Terminal delivery step. (5 supporting files)
Use at session start to pull Jira issue details into context, or post-delivery to create/update issues. Integrates with task-authoring (issue → task.md) and git-tooling (commit links). (2 supporting files)
Select the minimal sufficient artifact set (task/requirements/tech-spec/contracts/models/verify/evidence) for the current change, and recommend the next skills. Use after task intake or when scope/risk changes.
Promote a task artifact pack into a canonical spec under /docs/specs or /docs/architecture/specs, following /docs/spec-guide.md lifecycle (active-only, delete replaced). No writes without APPROVE.
Define interface/persistence contracts (APIs, schemas, deeplinks, storage formats) + compatibility rules. Use when public surfaces or stable formats are involved.
Implement changes guided by existing artifacts and repo conventions (AGENTS/README/DEVELOPMENT + WORK_PATH). Make small diffs, follow coherence gate, and optionally trigger verification-run.