--- name: pm-feature-fb4c1e1b2bd7 description: | Create or manage a feature workflow packet. Use when the user wants to add new user-visible functionality and needs a tracked workflow with acceptance criteria, scope boundaries, and a verification strategy. --- # pm-feature ## Purpose Create or manage a feature workflow packet. Features add new user-visible behavior. This skill emphasizes clear acceptance criteria, user-facing behavior definitions, and release risk awareness. ## Required Reads 1. `.agents/workflows/INDEX.md` -- understand lifecycle states and packet structure. 2. `.agents/workflows/dossier-template.md` -- the dossier format to follow. 3. `.agents/pm/pm-current-state.md` -- check for active workflows and current project state. 4. The PM units for areas the feature will touch (via pm-load). ## Procedure ### Creating a new feature packet 1. **Choose the workflow ID.** Use the prefix `ft_` followed by a short descriptive slug. Example: `ft_user_export_csv`. 2. **Create the packet directory.** Path: `.agents/workflows/draft/ft_/`. 3. **Write `dossier.md`.** Copy the structure from `dossier-template.md` and fill in: - Metadata: set Workflow Type to "feature", Lifecycle State to "draft". - Objective: describe the user-visible behavior being added. Write from the user's perspective: "Users will be able to ..." - Background/Context: explain why this feature is needed and any prior discussion. - Contract: define what "done" looks like in observable terms. - Acceptance Criteria: list specific, testable conditions. Each criterion should be verifiable by running a test or manually exercising the feature. Include both happy-path and error-path criteria. - Failure Policy: define conditions that mean the feature cannot ship. Default: "If the feature cannot meet acceptance criteria without breaking existing tests, stop and report." - Scope: list the files, modules, and UI surfaces that will be created or modified. - Non-Goals: state adjacent features or enhancements that are explicitly excluded. - Dependencies: list external services, libraries, or other workflows this feature depends on. - Plan of Record: break the work into ordered steps. Each step should be small enough to verify independently. - Verification Strategy: specify how each acceptance criterion will be tested (unit test, integration test, manual check). Include the commands to run. 4. **Write `run-log.md`.** Initialize from `run-log-template.md`. 5. **Write `handoff.md`.** Initialize from `handoff-template.md`. Set "Next Exact Step" to the first planned action. 6. **Write `artifacts.md`.** Initialize from `artifacts-template.md`. 7. **Add a row to `.agents/state/active-workflows.md`.** That file is the workflow tracking table, and it is preserved across upgrades. Do not open a second table in `.agents/workflows/INDEX.md`: that file is framework reference content, an upgrade refreshes it, and anything recorded there is lost. ### Managing an existing feature packet 1. **After each step**, append a run-log entry covering: action taken, files touched, test results, and which acceptance criteria are now met. 2. **Update `handoff.md`** after every step with current status and next action. 3. **Track acceptance criteria progress** in the dossier or run-log -- mark each criterion as met or unmet. 4. **Move the packet between lifecycle directories** when state changes. Draft to active requires user approval. Active to done requires all acceptance criteria met. ## Output - `.agents/workflows/draft/ft_/dossier.md` - `.agents/workflows/draft/ft_/run-log.md` - `.agents/workflows/draft/ft_/handoff.md` - `.agents/workflows/draft/ft_/artifacts.md` ## Completion Criteria - All four packet files exist and follow their respective templates. - Acceptance criteria are specific and testable (no vague language like "works well"). - The plan of record has at least two discrete steps. - The verification strategy names specific test commands or manual steps for each criterion. - Non-goals are stated to prevent scope creep. ## Error Handling - If acceptance criteria are unclear or missing from the user's request, draft best-guess criteria and flag them for user review before moving to active. - If the feature scope overlaps with an active workflow, note the conflict in Dependencies and flag it to the user. - If a dependency (external service, library) is unavailable, set the packet state to blocked, document the blocker in `handoff.md`, and stop. --- Source attribution: AMDResearch Original project: https://github.com/AMDResearch/omniprobe/blob/913ae319f727f8014e4db442a80e84915c8cf3a0/.agents/skills/pm-feature/SKILL.md License: MIT License information: https://opensource.org/license/mit Original upstream instructions; downloaded from Mega AI Hub. ## Upstream license notice ------------------------------------------------------------------------------- MIT License Copyright (c) 2026 Advanced Micro Devices, Inc. All Rights Reserved. Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. ------------------------------------------------------------------------------- # Mega AI Hub resource metadata Creator / publisher: AMDResearch Original project: https://github.com/AMDResearch/omniprobe/blob/913ae319f727f8014e4db442a80e84915c8cf3a0/.agents/skills/pm-feature/SKILL.md Attribution basis: Source repository record Fields of work: Operations, Product Management, Project & Program Management Roles: Business Process Analyst, Product Manager, Project Manager Specialties: Specialty not specified Tools: Tool not specified Country applicability: Country not specified Classification basis: Source catalog labels Instruction SHA-256: 282bda9cd9b2eade97096b11c6bd42f855f72bef0b67097488534b246f436cfc