Menu
Create or update feature context documents. Use this when asked to describe a feature, explain motivation, or provide non-normative context.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Double-check the last work, whether it be a plan, design, or implementation, ensuring all aspects have been fully considered. Use when user wants to check work, or mentions "double check".
Align source with target. Use this when asked to align, check, or verify alignment between artifacts.
Create or update ARCHITECTURE.md. Use this when asked to create, update or modify the project architecture.
Brainstorm ideas, explore solutions, and evaluate options. Use this when asked to brainstorm, explore ideas, or analyze trade-offs.
Run traceability and schema checks, then fix any errors. Use this when asked to check, validate, or fix traceability and schema issues.
Implement code and tests based on architecture, requirements, and design (or a set of tasks). Use this when asked to implement features, write code, or create tests.
| name | awa-feature |
| description | Create or update feature context documents. Use this when asked to describe a feature, explain motivation, or provide non-normative context. |
${input}
You MUST consider the user input before proceeding (if not empty).
Create or update a non-normative feature context document as specified in the instruction above, following awa conventions. Consider existing specifications before making changes.
If deriving from existing code or requirements (reverse workflow), analyze the codebase and specs to extract the problem statement, conceptual model, and usage scenarios.
You SHALL run awa spec codes to help choose the {CODE} extending existing one if logical.
You SHALL describe the problem, motivation, and conceptual model for the feature.
You SHALL provide concrete usage scenarios that illustrate the feature in action.
You SHALL mark the document as INFORMATIVE (not normative).
You SHALL NOT use normative language (SHALL/SHOULD/MAY) — that belongs in REQ documents.
You SHALL NOT define acceptance criteria or traceability IDs — that belongs in REQ documents.
You SHALL NOT describe design decisions or implementation details — that belongs in DESIGN documents.
You SHALL use clear, accessible language; define jargon in a glossary if needed.
You SHALL support reverse workflow: deriving feature context from existing code or requirements when requested.
You SHALL clarify open points with user.
You MAY include diagrams, background, and non-normative notes as needed.
You MAY use todos and tools as needed.