{"manifest":{"name":"Feature Spec Writer","version":"1.0.0","description":"Transform a rough feature idea into a structured engineering spec: Requirements → Design → Tasks. Produces a SPEC.md ready for team handoff.","tags":["specification","planning","product","workflow","agent","kiro"],"standard":"agentskills.io","standard_version":"1.0","content_checksum":"4811e83c38d37e6d35303816735125aeb569e870b842585166dcb9949bbe9948","bundle_checksum":null,"metadata":{},"files":[]},"files":{"SKILL.md":"# Feature Spec Writer\n\n> **Purpose:** Transform a rough feature idea into a structured implementation spec using the Kiro-style Requirements → Design → Tasks breakdown. Produces a `SPEC.md` document ready for engineering handoff — no more half-baked tickets.\n\n---\n\n## Invocation\n\n```\n/spec \n```\n\n**Example:** `/spec Add OAuth login with GitHub and Google`\n\n---\n\n## Process\n\n### Phase 1: Requirements Analysis\n\nFormalize requirements from the raw feature description.\n\n**Functional Requirements (what it MUST do)**\n- Extract concrete behaviors the feature must support\n- Write in user story format: \"As a [user], I can [action] so that [outcome]\"\n- Assign IDs: FR-1, FR-2, ...\n\n**Non-Functional Requirements**\n- Performance targets (latency, throughput, data volume)\n- Security constraints (auth model, data handling, compliance)\n- Accessibility (WCAG 2.1 AA minimum)\n- Browser / platform / device targets\n\n**Out of Scope**\n- Explicitly list what this spec does NOT cover — prevents scope creep\n\n---\n\n### Phase 2: Technical Design\n\n**Architecture Overview**\n- Which layers are touched: frontend, API, database, third-party services\n- New components vs modified existing components\n- Data flow (text-based ASCII diagram if helpful)\n\n**Data Model Changes**\n- New tables, columns, or indexes\n- Migration strategy and rollback plan\n\n**API Changes**\n- New or modified endpoints with request/response shapes\n- Auth requirement per endpoint (public / authenticated / admin)\n\n**UI/UX Changes**\n- Pages and components affected\n- New routes if applicable\n- State management implications\n\n---\n\n### Phase 3: Task Breakdown\n\nProduce a numbered task checklist in implementation order:\n\n```\nTASKS\n[ ] 1. Database: Create migration for [table/column]\n[ ] 2. API: Add POST /[resource] with [auth requirement]\n[ ] 3. Frontend: Build [Component] in [location]\n[ ] 4. Tests: Unit tests for [function/route]\n[ ] 5. Tests: E2E test for [user flow]\n[ ] 6. Docs: Update [doc] with new behavior\n[ ] 7. Deploy: Feature flag rollout or straight deploy\n```\n\nEach task must be completable in ≤ 4 hours. Break down anything larger.\n\n---\n\n## Output Format\n\nProduce a `SPEC.md` file with this structure:\n\n```markdown\n# [Feature Name] — Engineering Spec\n\n**Status:** Draft\n**Author:** @[username]\n**Date:** [today]\n**Estimated effort:** [X days / Y tasks]\n\n---\n\n## Requirements\n\n### Functional\n[FR-1 through FR-N as user stories]\n\n### Non-Functional\n[Performance, security, accessibility]\n\n### Out of Scope\n[Explicit exclusions]\n\n---\n\n## Design\n\n### Architecture\n[Overview + data flow]\n\n### Data Model\n[Schema changes + migration plan]\n\n### API\n[Endpoints + auth]\n\n### UI/UX\n[Component changes + routes]\n\n---\n\n## Tasks\n\n[Numbered, ordered checklist]\n\n---\n\n## Open Questions\n\n[Unresolved decisions — list even if none to show they were considered]\n\n---\n\n## Security Checklist\n\n- [ ] Auth required on all mutation endpoints\n- [ ] Input validation on all user-supplied fields\n- [ ] No PII in logs or error messages\n- [ ] Rate limiting on high-frequency endpoints\n```\n\n---\n\n## Rules\n\n- Requirements must be testable — if you cannot write a test for it, rewrite it\n- Every API change must state its auth requirement explicitly\n- Tasks must be ordered by dependency (no task references a later task)\n- Flag all unresolved decisions as Open Questions — never silently assume\n- If the feature touches auth, payments, or data deletion: add an explicit Security Checklist section\n- Estimate effort in tasks, not hours — estimates in hours are always wrong\n\n## Playground\n\n
Feature Spec WriterExample · SkillSlap
Input: Feature request
Feature: Users should be able to\nexport their skill collection as\na ZIP file containing all their\nSKILL.md files, one per folder.
Output: Feature spec
## Feature: Skill Collection Export\n\nUser story\nAs a skill author, I want to download\nall my skills as a ZIP so I can back\nthem up or use them offline.\n\nAcceptance criteria\n- [ ] GET /api/users/me/export returns\n      a ZIP with Content-Disposition\n- [ ] ZIP contains one folder per skill\n      named by skill slug\n- [ ] Each folder contains SKILL.md\n- [ ] Max 500 skills per export\n\nOut of scope\n- Importing from ZIP (separate ticket)\n- Including demo media files
"}}