Menu
Create a feature document covering business context and initial architecture for a new feature using the PM and Architect workflow.
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Validate workflow markdown documents such as plans, reviews, implementation reports, and audits against the required format contract.
Master workflow orchestrating feature planning, review, implementation, audit, and retrospectives. Entry point for feature development lifecycle.
Audit a feature implementation against its approved plan and implementation report, then produce the architect verdict and follow-up direction.
Create a feature-specific context document and save it under the feature contexts directory for later planning, review, or implementation work.
Execute a review-approved feature plan and produce or refine the implementation report for that feature.
Orchestrate the full feature workflow loop by detecting artifact state and routing through review, implementation, audit, and follow-up steps.
| name | feat |
| description | Create a feature document covering business context and initial architecture for a new feature using the PM and Architect workflow. |
Purpose: Create comprehensive feature documents that define complex, multi-phase work. Features are self-contained work units with their own plans, contexts, reports, and notes - unlike simple tasks which are single files.
The skill orchestrates a two-stage process: first, the Product Manager stage enriches the feature description with business context, problem statements, objectives, scope, and success criteria. Then, the Architect stage decides whether there is enough context to propose a lightweight Draft Plans List and creates a feature document whose planning surface is ## Plans.
Choose any of the following:
/feat {description} # Provide feature description directly
/feat "{feature-title}" {description} # Feature title + description
/feat --jira TICKET-123 {description} # With Jira ticket integration
/feat --atlassian ISSUE-456 {description} # With Atlassian issue integration
/feat {description} --name {custom-slug} # Custom feature directory name
When {description} only: Use provided text + auto-generate feature slug.
When --jira or --atlassian provided: Fetch ticket data via MCP integration + enhance with ticket context.
When --name provided: Use custom slug for feature directory (e.g. feat-2026-01-custom-name).
/feat {your feature description} — skill will create feature and orchestrate PM + Architect stages./feat --jira TICKET-123 additional context (fetches ticket data)./feat --atlassian ISSUE-456 additional context (fetches issue data)./feat "My Feature" description... --name custom-slug (custom directory naming)./feat Create user authentication flow with OAuth2 and WebAuthn options/feat --jira PROJ-123 Implement role-based access control for admin panelYou are executing the /feat command. This command follows a two-stage process: first as the Product Manager, then as the Architect.
CRITICAL — Execution context: When the user invokes /feat directly (inline mode, no "loop" or "auto"), execute BOTH stages in the current context — you ARE the PM for Stage 1, then you ARE the Architect for Stage 2. Do NOT launch subagents. Subagent delegation for /feat stages happens ONLY in loop/auto mode.
Use Product Manager (product-manager.md) role with:
--jira TICKET-123 flag provided)--atlassian ISSUE-456 flag provided)The PM will:
--jira or --atlassian flag is providedThe PM outputs an enriched feature description: Summary, Problem Statement, Objectives, Context, Scope, Success Criteria, and optionally Proposed Subtasks. For internal/tooling features, PM may use Internal Value and omit User Stories.
After PM stage completes, switch to Architect (architect.md) role with:
The Architect will:
## Plans empty except for the hint when context is still insufficientThe Architect outputs a Draft Plans List only when context is sufficient. Each proposal is N-{slug} plus a one-line goal, not a phase specification.
After receiving PM-enriched content and the Architect decision about draft plans:
date +%Y-%m-%d## Plans sectionInputs integration:
sync or check returns an error, show that raw failure to the user.Output: Feature document in .pythia/workflows/features/feat-YYYY-MM-{slug}/feat-YYYY-MM-{slug}.md
See also: /plan skill, /ctx skill, /research skill, /retro skill
/feat sync is a manual reconciliation command for the user. It is not auto-triggered by /feat or /plan.
Behavior:
feat-idplans/*.plan.md files in the feature directory# Plan {slug}: {Title} and status from ## Metadata## Plans in the feature doc:
- [{slug}](plans/{slug}.plan.md) — {Title} · status: {status}Do not change frontmatter, feature status, or any sections outside ## Plans.
At the end of every /feat or /feat sync response, output a verdict/state-aware ## Next Steps block and active context footer.
/feat next stepsAfter creating or updating a feature document:
## Next Steps
Feature saved: `{feature-dir}/{feature-id}.md`
**Actions**
**[a]** Architect next plan - choose this to inspect the feature and propose the next concrete plan.
**[q]** Clarify scope - choose this to ask Product/Architect clarification questions about scope, risks, constraints, and missing context.
**[r]** Research topic - choose this to launch Researcher only after a concrete uncertainty/topic is identified.
**[s]** Sync plans - choose this to reconcile `## Plans` against existing plan files.
---
**Active context**: role: Product Manager · feat: {feat-id} · mode: create · skill: /feat
/feat sync next stepsAfter completing /feat sync:
## Next Steps
Feature sync complete: `{feature-dir}/{feature-id}.md`
**Actions**
**[a]** Architect next plan - choose this to inspect synced `## Plans` and propose the next missing, blocked, or highest-value plan.
**[q]** Clarify gaps - choose this to inspect stale scope, missing ownership, unclear plan boundaries, or context gaps.
**[p]** Plan now - choose this only after the target plan direction is clear.
---
**Active context**: role: Product Manager · feat: {feat-id} · mode: sync · skill: /feat
After emitting /feat or /feat sync response, halt and wait for user input.
When the next user input is exactly one of the offered chooser keys:
[a] / a: launch Architect subagent (architect.md) with the feature doc path and ask for next-plan proposal. Architect should not write a plan unless user confirms the proposed direction.[q] / q (/feat only): stay in current context and ask 3-5 Product/Architect clarification questions about scope, risks, constraints, and missing context. Do not edit artifacts.[q] / q (/feat sync only): stay in current context and clarify stale scope, missing ownership, unclear plan boundaries, or context gaps. Do not edit artifacts.[r] / r (/feat only): launch Researcher subagent (researcher.md) only if the user supplies or confirms a concrete research topic/uncertainty. If topic is missing, ask for it first.[s] / s (/feat only): run /feat sync {feature-dir}/{feature-id}.md in current context.[p] / p (/feat sync only): launch Architect planning only when the plan direction is already clear; otherwise ask for the missing plan direction first.Do not treat arbitrary custom user messages as chooser input. Do not provide copyable /ctx or /research commands without a concrete topic because those commands need additional user context.
Every /feat or /feat sync response must end with:
Active context: role: Product Manager · feat: {feat-id} · mode: {create|sync} · skill: /feat