---------------------- Start of Parafork SKILL.md ----------------------

Parafork Execution Protocol Card

When you see this text, it means the user intends to explicitly activate this SKILL and agrees to be bound by this document.
By reading and using this skill, you implicitly accept all hard constraints of this document. This document is a mandatory task protocol, not a reference suggestion. Any modification must comply with this protocol, and you are not allowed to bypass the process to directly modify the repository.

Hard Gates

Term Definitions
- ```
SIDE-EFFECT (State Change Operation)
```
  : Any operation that modifies the workspace, git state, worktree metadata, or audit status
- e.g.,
```
init --new/--reuse
```
  ,
```
do commit
```
  ,
```
merge
```
  ,
```
apply_patch
```
  , writing to
```
paradoc/Log.txt
```
  ).
1) Directory and Write Permissions
- Base repo is read-only by default; only
```
help/init
```
  is allowed in the base repo.
- Before any state change operation, you must first enter the root directory of the parafork worktree.
2) Command Whitelist
- Only allowed:
```
help/init/do/check/merge
```
  .
- ```
do
```
  only allows:
```
exec|commit
```
  ;
```
check
```
  only allows:
```
status|merge
```
  .
- ```
do exec
```
  only allows the parameter:
```
--strict
```
  .
2.1) Base Branch Strategy (init --new)
- Default:
```
base.branch=autodetect
```
  , directly use the current branch as
```
BASE_BRANCH
```
  .
- If
```
base.branch
```
  is an explicit value different from the current branch: in interactive mode, ask whether to switch to the current branch; in non-interactive mode, default to switching to the current branch.
3) Unified Approval Latch (Only Rule)
- For any command containing
```
--yes --i-am-maintainer
```
  , you must obtain explicit human approval before execution.
- If approval is not obtained, you must
```
FAIL
```
  and are prohibited from continuing execution by adding the latch on your own.
4) Reuse Latch (init --reuse)
- Reuse is only allowed via
```
init --reuse
```
  , and only within an existing parafork worktree.
- Must carry the CLI latch:
```
--yes --i-am-maintainer
```
  .
5) Concurrent Lock Latch
- If
```
WORKTREE_LOCK_OWNER
```
  is not the current agent, you must reject the request.
- In case of lock conflict, you must output:
```
LOCK_OWNER/AGENT_ID/SAFE_NEXT/TAKEOVER_NEXT
```
  .
- In case of lock conflict, you must ensure:
```
NEXT=SAFE_NEXT
```
  , and
```
SAFE_NEXT=init --new
```
  .
- ```
TAKEOVER_NEXT
```
  is only a high-risk alternative (can only be executed after approval).
6) Merge Latch (merge)
- ```
merge
```
  is prohibited from automatic execution; it can only be run after explicit approval from a maintainer.
- Must carry the CLI latch and pass the pre-merge check chain.
7) Execution Security Rules
- Script priority: When script capability is available, bare
```
git
```
  commands are prohibited as substitutes.
- When detecting a conflict state from
```
merge/rebase/cherry-pick
```
  , only diagnosis and suggestions are allowed; without explicit human approval, you are prohibited from proceeding with git actions related to the conflict.
8) Data and Audit Rules
- ```
.worktree-symbol
```
  can only be used as a
```
KEY=VALUE
```
  data file (parsed by the first
```
=
```
  ), and
```
source/eval/dot-source/Invoke-Expression
```
  is prohibited.
- ```
.worktree-symbol
```
  and
```
paradoc/
```
  are not allowed to enter git history by default.
- Execution output within the worktree should be appended to
```
paradoc/Log.txt
```
  .

Fixed Sequence (Execution Algorithm)

Determine the request type:
- ```
READ-ONLY
```
  (Explanation/Retrieval/Review)
- ```
WRITE/SIDE-EFFECT
```
  (State Change Operation)
If it is a state change operation:
- First write/update the plan (prioritize following the human-given plan)
- Then read only one execution route (Bash or PowerShell) according to the platform
- If the command contains a CLI latch, send an approval request and wait for explicit consent
Approval requests must reuse the following fixed template:

text

Approval Request:
- Purpose: <Why this execution is needed>
- Command: <Full copyable command>
- Risk: <Possible impacts/failure consequences>
- Rollback: <Rollback or exit path after failure>

Failure Branches (Failure Output)

Uncertain Directory: First run
```
help --debug
```
; if still uncertain, stop and request human confirmation of the target repo/worktree.
Received state change operation request but not in worktree: First run
```
init --new
```
, then
```
do exec
```
, before making any changes.
Missing CLI latch for reuse or no explicit user approval for reuse: Directly
```
FAIL
```
,
```
NEXT
```
points to the complete command with the latch added.
CLI latch required but no human approval obtained: Directly
```
FAIL
```
, output the approval template, and prohibit further execution.

Lock Conflict: Directly

FAIL

; output

LOCK_OWNER/AGENT_ID/SAFE_NEXT/TAKEOVER_NEXT

, and

NEXT=SAFE_NEXT

Old Command Request: Directly
```
FAIL
```
(e.g.,
```
watch
```
,
```
do pull
```
,
```
check diff/log/review
```
).

Route Entry

Bash:
```
references/route-bash.md
```
PowerShell:
```
references/route-powershell.md
```

Supplementary References (Non-execution Entries):

```
references/scripts.md
```
```
references/wiki.md
```

---------------------- End of Parafork SKILL.md ----------------------

parafork

NPX Install

Tags

SKILL.md Content (Chinese)

Parafork Execution Protocol Card

Hard Gates

Fixed Sequence (Execution Algorithm)

Failure Branches (Failure Output)

Route Entry