メニュー
Use when recording a canonical decision, fact, or preference in the shared Papyrus workspace with automatic dedup on (type, canonical_name). Returns {action: wrote|duplicate, papyrus_id}. Generalizes pharaoh-finding-record beyond audit findings.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Use when a developer wants to add a feature, capability, or behaviour change to a project that uses sphinx-needs and a V-model artefact structure, before any requirement or code is written. Triggers on "add a feature", "implement X", "let's build Y", or "do spec-driven development" in a project with .pharaoh/project/ tailoring.
Use when analyzing the impact of changing a requirement, specification, or any sphinx-needs item, including traceability to code via codelinks
Use when recording a design decision as a traceable sphinx-needs object with alternatives, rationale, and links to affected requirements
Use when checking for gaps, redundancies, and inconsistencies in sphinx-needs requirements, or validating traceability completeness
Use when preparing a release, generating changelogs from requirements, or summarizing requirement changes for version management
Use when reading one source file and emitting one or more requirement RST directives (typed by `target_level`) describing the observable behavior in that file. Queries shared Papyrus for canonical terms before naming concepts; writes newly surfaced concepts back. Does not draft architecture, plans, or FMEA.
| name | pharaoh-decision-record |
| description | Use when recording a canonical decision, fact, or preference in the shared Papyrus workspace with automatic dedup on (type, canonical_name). Returns {action: wrote|duplicate, papyrus_id}. Generalizes pharaoh-finding-record beyond audit findings. |
Invoke from any authoring or multi-agent coordination workflow that needs to record a canonical named item (architecture decision, domain fact, style preference) in a way that survives concurrent writers without duplication. Typical callers: pharaoh-req-from-code (when a type or concept is first surfaced), pharaoh-decide chains, multi-agent reverse-engineering fan-out.
Do NOT invoke for informational or non-canonical observations, and do NOT invoke when pharaoh-finding-record is a better fit (audit-finding category + subject_id tuple).
{type: "dec"|"fact"|"pref", canonical_name: str, body: str, tags?: list[str], reporter_id: str}. Output: {action: "wrote"|"duplicate"|"error", papyrus_id: str, dup_of?: str, message?: str}.(type, canonical_name) must produce exactly 1 "wrote" + 1 "duplicate"; measured via fixture.type: one of dec (decision), fact (domain fact), pref (preference). Controls the Papyrus need type.canonical_name: canonical identifier for the subject. Style (snake_case, CamelCase, etc.) MUST match the frozen vocabulary if one exists for the project. If the caller is unsure, it MUST first invoke pharaoh-context-gather and reuse an existing canonical before coining a new one.body: 1-3 sentence description. Stored verbatim as the Papyrus need body.tags: optional list of free-form tags.reporter_id: caller identifier (e.g. req-from-code:health_monitor.cpp). Stored in the Papyrus need source field for traceability.Exactly one single-line JSON object, no prose:
{"action": "wrote", "papyrus_id": "FACT_HealthMonitor"}
or:
{"action": "duplicate", "papyrus_id": "FACT_HealthMonitor", "dup_of": "FACT_HealthMonitor"}
or, on subprocess failure:
{"action": "error", "papyrus_id": "FACT_HealthMonitor", "message": "<stderr-first-line>"}
papyrus_id = uppercase(type) + "_" + sanitize(canonical_name)
sanitize replaces non-alphanumeric characters with underscores, collapses consecutive underscores, strips leading/trailing underscores. Case is PRESERVED (do not lowercase).
Examples:
("fact", "HealthMonitor") → FACT_HealthMonitor("fact", "heartbeat_timeout") → FACT_heartbeat_timeout("dec", "use thread pool for monitors") → DEC_use_thread_pool_for_monitorspapyrus addpapyrus --workspace .papyrus add <papyrus_need_type> \
"<canonical_name>" \
--id <papyrus_id> \
--body "<body>" \
--tags "canonical:<canonical_name>,<joined_tags>" \
--source "<reporter_id>" \
--scope local
The <papyrus_need_type> argument maps as: dec → decision, fact → fact, pref → preference.
{"action": "wrote", "papyrus_id": "<id>"}."already exists" → emit {"action": "duplicate", "papyrus_id": "<id>", "dup_of": "<id>"}.{"action": "error", "papyrus_id": "<id>", "message": "<stderr-first-line>"} and return; the caller must not retry.No surrounding prose. Emit exactly one JSON object per invocation.
(type, canonical_name). Body and tag differences do NOT suppress dedup — first writer wins and sets canonical body.reporter_id difference does NOT suppress dedup — two callers arriving at the same concept from different files still collapse to one record.papyrus_id are serialized by the Papyrus FileLock; only one succeeds, the others get "duplicate".FACT_HealthMonitor and FACT_healthmonitor do NOT dedup. The caller is responsible for consistent casing (via pharaoh-context-gather lookup before coining).papyrus binary missing → emit {"action": "error", "message": "papyrus CLI not found"}..papyrus/ workspace missing → emit {"action": "error", "message": "no .papyrus/ workspace in cwd"}.{"action": "error", "message": "<stderr-first-line>"}.pharaoh-finding-recordpharaoh-finding-record is the audit-specialized sibling: it constrains category to a known enum and derives IDs from (category, subject_id). pharaoh-decision-record accepts any (type, canonical_name) pair. Existing Phase 4b audit fan-out continues to use pharaoh-finding-record; Phase 4c's reverse-engineering fan-out uses pharaoh-decision-record.
A future cleanup may reimplement pharaoh-finding-record as a thin wrapper over pharaoh-decision-record; that refactor is out of scope for Phase 4c.
After emitting the artefact, invoke pharaoh-decision-review on it. Pass the emitted artefact (or its need_id) as target. Attach the returned review JSON to the skill's output under the key review. If the review emits any axis with score: 0 or severity: critical, return a non-success status with the review findings verbatim and do NOT finalize the artefact — the caller must regenerate (via pharaoh-decision-regenerate if available, or by re-invoking this skill with the findings as input).
See shared/self-review-invariant.md for the rationale and enforcement mechanism. Coverage is mechanically enforced by pharaoh-self-review-coverage-check in pharaoh-quality-gate.
Each caller invokes this skill once per canonical subject surfaced. The orchestrator or harness then reads the final Papyrus workspace via papyrus recall for the aggregated vocabulary.