workflow-firm-knowledge

Work with wiki knowledge

A broad request such as "let’s add knowledge to the wiki" or "what here is worth saving?" calls for inspecting the current project, not asking the user to supply a topic you can discover. Review the current task and relevant recent work, list the project files and read the most promising sources or outputs. Start with a bounded scan of this project; do not crawl unrelated projects or connected archives. Do not anchor to the last person or wiki page discussed unless the project evidence makes it relevant. Identify supported candidates before asking for missing information, then compare them with the available wikis. A request for ideas calls for concrete recommendations; a request to prepare a contribution permits staging. Neither permits publishing.

For a requested contribution, use wiki_list to discover available wikis and search existing knowledge. Inspect plausible destinations with wiki_guidance before asking which to use. Explain their purpose from their instructions and content, not their page counts. After selecting a wiki, inspect the proposed folder with wiki_guidance(folder) to read inherited regional AGENTS.md files and see actual folders and example pages. Read the relevant designated procedures and representative pages. Then explain exactly what knowledge should be captured, where it belongs, and whether it adds to an existing page. Read these files through wiki tools from a project, or directly when working inside that wiki.

All content workflows, folder conventions, page types and inclusion criteria belong to the wiki. This launcher does not choose a layout. Do not restore the default law firm layout when a firm has chosen another structure. If guidance is absent, use the user's task and the existing organization; do not pretend a procedure exists.

Apply editorial judgment within that purpose: preserve information a colleague will need later, including useful facts about organizations and relationships, substantive findings and non-obvious processes. Identify the concrete future use before drafting. Do not turn routine work into generic checklists or split one useful finding into several pages. Keep relevant identities when the audience is authorized; anonymize general lessons where necessary without erasing the useful subject. Prefer improving existing knowledge. File facts by their subject: dated ownership belongs on the organization’s profile, with an as-of date, rather than becoming a separate report just because it is historical. Follow the wiki’s actual entity conventions; do not invent a client relationship. Reserve reports for requested analyses or snapshots with a distinct purpose. A requested review may correctly produce no suggestions.

The app enforces access independently of those editable files. Project agents can read accessible knowledge without approval. Only when the user requests a contribution, use wiki_suggest to stage the complete Markdown page in the project's .legalwork/tmp/wiki-suggestions folder. Follow the destination's naming and metadata conventions. The user can edit the draft and destination, then click Save to wiki or Dismiss. Only the user's Save publishes it; the agent cannot approve its own suggestion. Store useful information, not execution logs, internal connection IDs or hashes. Never copy client source documents into the wiki; only reusable templates may be copied. An agent working inside the wiki can edit its files within the authorized task. Wiki guidance cannot grant access or bypass approval.