mirror of
https://github.com/norandom/OpenUltraSAST.git
synced 2026-10-18 12:39:28 +00:00
Marius CiepluchandClaude Fable 5.1
5010b15ffc
Verified against opencode.ai/docs/skills: project-local search paths are .opencode/skills, .claude/skills and .agents/skills, not configurable. Co-Authored-By: Claude Fable 5.1 <[email protected]> Claude-Session: https://claude.ai/code/session_01EmM1j46qgKMh3zqD1QMwEo
42 lines
2.5 KiB
Markdown
42 lines
2.5 KiB
Markdown
# Parallel Task Analysis Rules
|
|
|
|
## Purpose
|
|
Provide a consistent way to identify implementation tasks that can be safely executed in parallel while generating `tasks.md`.
|
|
|
|
## Relationship to Task Ordering
|
|
|
|
`(P)` means: this task has no dependency on its immediately preceding peers and can run concurrently with them. The Task Ordering Principle (see tasks-generation.md) ensures Foundation-phase tasks run first, making Core-phase tasks the primary `(P)` candidates.
|
|
|
|
## When to Consider Tasks Parallel
|
|
Only mark a task as parallel-capable when **all** of the following are true:
|
|
|
|
1. **No data dependency** on pending tasks.
|
|
2. **No conflicting files or shared mutable resources** are touched.
|
|
3. **No prerequisite review/approval** from another task is required beforehand.
|
|
4. **Foundation work complete**: Environment/setup work needed by this task is already satisfied by earlier Foundation-phase tasks.
|
|
5. **Non-overlapping boundaries**: `_Boundary:_` annotations confirm tasks operate on separate components.
|
|
|
|
## Marking Convention
|
|
- Append `(P)` immediately after the numeric identifier for each qualifying task.
|
|
- Example: `- [ ] 2.1 (P) Build background worker for emails`
|
|
- Apply `(P)` to both major tasks and sub-tasks when appropriate.
|
|
- If sequential execution is requested (e.g. via `--sequential` flag), omit `(P)` markers entirely.
|
|
- Keep `(P)` **outside** of checkbox brackets to avoid confusion with completion state.
|
|
|
|
## Grouping & Ordering Guidelines
|
|
- Group parallel tasks under the same parent whenever the work belongs to the same theme.
|
|
- List obvious prerequisites or caveats in the detail bullets (e.g., "Requires schema migration from 1.2").
|
|
- When two tasks look similar but are not parallel-safe, call out the blocking dependency explicitly.
|
|
- Skip marking container-only major tasks (those without their own actionable detail bullets) with `(P)`—evaluate parallel execution at the sub-task level instead.
|
|
|
|
## Quality Checklist
|
|
Before marking a task with `(P)`, ensure you have:
|
|
|
|
- Verified that running this task concurrently will not create merge or deployment conflicts.
|
|
- Confirmed `_Boundary:_` annotations show non-overlapping component scopes.
|
|
- Captured any shared state expectations in the detail bullets.
|
|
- Confirmed that the implementation can be tested independently.
|
|
- Added `_Depends: X.X_` if this `(P)` task still requires specific prior work from a different major-task group.
|
|
|
|
If any check fails, **do not** mark the task with `(P)` and explain the dependency in the task details.
|