From pharaoh
Breaks requirement changes into ordered actionable tasks with Pharaoh workflow enforcement and dependency ordering for sphinx-needs projects.
How this skill is triggered — by the user, by Claude, or both
Slash command
/pharaoh:pharaoh-planThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Break a set of requirement changes into ordered, actionable tasks. Each task maps
Break a set of requirement changes into ordered, actionable tasks. Each task maps
to a Pharaoh skill invocation. The plan respects pharaoh.toml workflow gates,
establishes task dependencies, and provides a roadmap for implementing changes
across the requirements hierarchy.
pharaoh:change and want to turn its impact analysis into an execution plan.pharaoh:plan has no workflow gates and runs freely in both advisory and enforcing modes.Execute the following steps in order.
Follow the instructions in skills/shared/data-access.md to:
ubproject.toml, conf.py, source directories).pharaoh.toml for strictness level, workflow gates, and traceability requirements.After completing data access, present the detection summary before proceeding:
Project: <name> (<config source>)
Types: <list of directive names>
Links: <list of link type names>
Data source: <tier used>
Needs found: <count>
Strictness: <advisory|enforcing>
If detection fails (no project found, no needs in source files), report the issue and ask the user for guidance. Do not proceed with empty data.
Determine what changes the user wants to make.
If the user provides a Change Document (output from a previous pharaoh:change invocation):
If the user describes the change in natural language (e.g., "change brake response time from 100ms to 50ms"):
Multiple matches found:
1. REQ_001 (Requirement: Brake response time) [open]
2. REQ_007 (Requirement: Brake pedal response) [approved]
Which need(s) are you changing? Enter numbers or IDs.
pharaoh:change impact analysis logic:
If the user wants to add a new feature (no existing need to change):
required_links from pharaoh.toml).Scope summary:
After determining the scope, record:
modify (changing existing needs) or create (adding new needs).modify type).Follow the instructions in skills/shared/strictness.md to determine which workflow gates apply.
Read pharaoh.toml (or use defaults if absent):
strictness: "advisory" or "enforcing".require_change_analysis: Whether authoring skills require a prior pharaoh:change.require_verification: Whether pharaoh:release requires a prior review skill.require_mece_on_release: Whether pharaoh:release requires a prior pharaoh:mece.These gates determine which tasks are mandatory in the plan versus optional.
Assemble the ordered list of tasks based on the scope and workflow gates.
When the change type is modify, use this default sequence:
Change analysis (pharaoh:change): Analyze impact of the change on the target need(s). Produces a Change Document listing all affected needs.
require_change_analysis = true, this task is mandatory before any authoring tasks.Author target need(s) (authoring skill, e.g. pharaoh:req-draft): Modify each target need with the requested change. One task per target need. Use the skill matching the need type (req-draft for requirements, arch-draft for architecture, vplan-draft for verification plans).
Author affected specifications (authoring skill): Update each specification that traces to a modified need. One task per affected specification.
Author affected implementations (authoring skill): Update each implementation that traces to a modified specification. One task per affected implementation.
Author affected test cases (authoring skill): Update each test case that traces to a modified implementation. One task per affected test case.
Verify all changes (review skill, e.g. pharaoh:req-review): Verify that all modified needs satisfy their parents and meet traceability requirements.
require_verification = true, this task is mandatory before any release task.MECE check (pharaoh:mece): Check for gaps, redundancies, or inconsistencies introduced by the changes. This task is optional by default.
require_mece_on_release = true, this task is mandatory before any release task.Release (pharaoh:release): Generate a changelog entry for the changes. Include this task only if the user indicates they are preparing a release.
Ordering within authoring tasks: Follow the hierarchy top-down. Modify needs in this order: requirements first, then specifications, then implementations, then test cases. This ensures that each level is updated before its children are modified, so authors can reference the updated parent content.
When the change type is create, use this sequence:
Author new requirement(s) (pharaoh:req-draft): Create the new top-level requirement(s). One task per requirement.
Author new specifications (authoring skill matching need type): Create specifications for each new requirement. One task per specification.
Author new implementations (authoring skill matching need type): Create implementations for each new specification. One task per implementation.
Author new test cases (authoring skill matching need type): Create test cases for each new implementation. One task per test case.
MECE check (pharaoh:mece): Verify complete coverage across the new needs. Confirm that every required_links chain is satisfied.
Verify all new needs (review skill, e.g. pharaoh:req-review): Verify that all new needs have proper links and satisfy their parents.
Note on hierarchy levels: Not every project uses all four levels (req, spec, impl, test). Only include tasks for need types that exist in the project's configuration. If the project defines only req and test, the plan should include only those levels.
pharaoh.toml is absent, include all steps as recommendations but mark none as mandatory.Format the plan as a structured document the user can review before execution.
Plan format:
## Implementation Plan
### Scope
- Change: <description of what is changing>
- Type: <modify|create>
- Target needs: <count>
- Affected needs: <count>
- Affected files: <count>
- Strictness: <advisory|enforcing>
### Tasks
| # | Task | Skill | Target | Detail | File | Required |
|----|-----------------------|------------------|------------|-------------------------------------------|--------------------------|----------|
| 1 | Analyze impact | pharaoh:change | REQ_001 | Trace downstream impact of latency change | docs/requirements.rst | yes |
| 2 | Update requirement | pharaoh:req-draft / pharaoh:req-regenerate | REQ_001 | Change latency from 100ms to 50ms | docs/requirements.rst | yes |
| 3 | Update specification | pharaoh:arch-draft | SPEC_001 | Update signal timing to match new latency | docs/specifications.rst | yes |
| 4 | Update implementation | pharaoh:arch-draft | IMPL_001 | Adjust timer configuration | docs/implementations.rst | yes |
| 5 | Update test case | pharaoh:vplan-draft | TC_001 | Update expected timing in assertions | docs/test_cases.rst | yes |
| 6 | Verify all changes | pharaoh:req-review, pharaoh:arch-review, pharaoh:vplan-review | (all) | Run the per-type review for each updated artefact | -- | yes* |
| 7 | MECE check | pharaoh:mece | (all) | Check for gaps in modified area | -- | no |
*Required in enforcing mode when require_verification = true.
### Dependencies
- Task 1 must complete before Tasks 2-5 (change analysis before authoring).
- Tasks 2-5 should execute in order (top-down through hierarchy).
- Task 6 requires Tasks 2-5 to complete (verification after all authoring).
- Task 7 can run after Task 6 or independently.
### Estimated scope
- Needs to modify: <count>
- Needs to create: <count>
- Files to touch: <count>
Presentation rules:
yes.recommended instead of yes. No task is strictly required.After presenting the plan, ask the user how they want to proceed:
Execute this plan step by step?
Options:
1. Execute all tasks in sequence
2. Execute up to task N (partial execution)
3. Modify the plan first
4. Save the plan and execute later
If the user chooses to execute:
Task 2/7 complete: Updated REQ_001 (latency changed to 50ms).
Proceeding to Task 3: Update SPEC_001...
Task 3 encountered an issue: SPEC_001 has additional links to IMPL_002
that were not in the original scope.
Options:
1. Add IMPL_002 to the plan and continue
2. Skip SPEC_001 and continue with Task 4
3. Stop execution and revise the plan
Plan paused after Task 3/7.
Completed: Tasks 1-3
Remaining: Tasks 4-7
Resume with "continue" or modify the remaining tasks.
.pharaoh/session.json as each skill completes, following the state management rules in skills/shared/strictness.md. This ensures that workflow gates are satisfied as the plan progresses.If the user chooses to modify the plan:
If the user chooses to save:
New impacts discovered mid-execution:
If authoring a need reveals additional downstream impacts not captured in the original Change Document:
Enforcing mode gate failures:
If a task cannot execute because a prerequisite gate is not satisfied:
Conflicting changes:
If two tasks in the plan modify the same need (e.g., a specification is affected by changes to two different requirements):
Update SPEC_001 (affected by REQ_001 and REQ_003).Tip: Skipping change analysis. Consider running pharaoh:change later
to document the impact of these modifications.
Blocked: Task 1 (change analysis) is required before authoring tasks
can execute. This is enforced by pharaoh.toml:
[pharaoh.workflow]
require_change_analysis = true
Run the change analysis first, or switch to advisory mode in pharaoh.toml.
require_change_analysis = true.require_verification = true.require_mece_on_release = true.Keep plans concrete. Every task must specify which need to modify or create, what the change is, and which file is involved. Vague tasks like "update related specs" are not acceptable. Name each need explicitly.
Never auto-execute without user consent. Always present the plan and wait for explicit confirmation before invoking any skill. This applies even if the plan has only one task.
Allow plan modification before and during execution. The user can add, remove, reorder, or change tasks at any point. Re-present the modified plan before resuming execution.
Respect the hierarchy. Author needs top-down: requirements before specifications, specifications before implementations, implementations before test cases. This ensures parent content is finalized before children are updated.
One skill invocation per task. Each task in the plan maps to exactly one Pharaoh skill call. Do not combine multiple skill invocations into a single task.
Handle partial execution gracefully. If execution is paused or interrupted, the plan state (which tasks are complete, which remain) must be clear to the user. Completed tasks should already be reflected in .pharaoh/session.json.
No session state changes from planning alone. Building and presenting the plan does not modify .pharaoh/session.json. State is only updated when tasks are actually executed.
No workflow gates on this skill. As noted in skills/shared/strictness.md, pharaoh:plan has no prerequisites and executes freely in both advisory and enforcing modes.
npx claudepluginhub useblocks/pharaoh --plugin pharaohAnalyzes impact of changes to sphinx-needs requirements, specs, or items by tracing links, extra_links, and codelinks to affected needs and code files.
Processes increment-request.json: orients on project state, elicits incremental EARS requirements with acceptance criteria, classifies changes, updates SRS/design docs, appends to feature-list.json.
Analyzes feature requests, maintains PRDs, and decomposes into tracks with work breakdowns and execution order. For new feature planning, architecture changes, requirements analysis, or plan adjustments.