@monoes/monomindcli 2.15.3 → 2.15.4

package/org-skills/intent-driven-development/SKILL.md

@@ -0,0 +1,365 @@
+---
+name: intent-driven-development
+description: "Turn ambiguous or high-impact product and engineering changes into scoped, verifiable acceptance criteria before or alongside implementation. Use when a user asks to clarify a feature, define acceptance criteria, de-risk a security/data/migration/integration change, prepare implementation requirements for another agent, or make a complex request testable."
+tags: ["engineering","product"]
+tools: ["monograph_suggest"]
+license: MIT
+source: https://github.com/affaan-m/ECC
+source_path: "skills/intent-driven-development"
+source_commit: bf70150eb2df8070024e5bdf08e4aa08959e2735
+---
+# Intent-Driven Development
+
+Produce useful acceptance criteria without turning specification into ceremony. Inspect
+available context first, expose genuine ambiguity, and choose verification methods that fit
+the work and its risk.
+
+## When to Activate
+
+- User asks to clarify a feature, define acceptance criteria, or de-risk a change before implementation
+- Request touches security, authentication, persistent data, migrations, external APIs, or compliance
+- User wants to prepare a handoff artifact for another agent or team
+- Request is ambiguous enough that the expected outcome is not yet observable or testable
+- User explicitly invokes this skill with `/intent-driven-development`
+
+Do not activate for trivial edits, straightforward one-line fixes, active debugging sessions,
+code review requests, or implementation requests whose acceptance conditions are already clear.
+
+## How It Works
+
+1. **Inspect context first** — reads the repository, docs, schemas, and test infrastructure for technical facts before asking any question, while treating product/business constraints as something only the user or a product artifact can supply
+2. **Choose depth** — selects Quick Capture (3-7 criteria, low/moderate risk) or Full Acceptance Brief (security, data, migration, cross-system changes) based on the risk profile
+3. **Ask minimally** — only asks questions whose answers cannot be inferred and that materially change scope or behavior
+4. **Write observable criteria** — each AC-NNN describes a starting condition, trigger, expected outcome, prohibited side effect, verification method, and priority; no vague words like "correctly" or "securely" without evidence
+5. **Proceed or hand off** — for clear requests with no blocking risks, records criteria and continues; for risky changes, presents blockers and waits for confirmation
+6. **Handle revision** — if an AC fails mid-implementation due to architectural constraints, marks it `[revised]`, updates scope or verification method, increments the revision number, and re-presents only the changed criteria
+
+## Examples
+
+**Quick Capture — "Add CSV export to the dashboard"**
+
+```
+Goal: Authenticated users can download dashboard data as a CSV file.
+In scope: Export of currently filtered rows; filename includes date.
+Out of scope: Scheduled exports, email delivery, Excel format.
+Assumptions: Max row count is under 10k; no PII in exported fields.
+
+AC-001: Export generates file with correct headers
+- Scenario: authenticated user, at least one data row visible
+- Action: click "Export CSV"
+- Expected: browser downloads file with columns [id, name, created_at]
+- Must not: expose internal fields or rows belonging to other users
+- Verification: automated integration test + manual schema spot-check
+- Priority: Required
+```
+
+**Full Acceptance Brief trigger — "Migrate user auth to OAuth"**
+
+Auth change + external dependency + existing session data → Full Brief with Risk Review table,
+blocking decisions on session invalidation strategy, and explicit rollback AC.
+
+**Existing spec review — user pastes a PRD**
+
+Skill reviews it for missing scope boundaries, unverifiable requirements ("the system shall be fast"),
+and silent assumptions, then returns corrected or supplemental criteria without restarting discovery.
+
+## Operating Rules
+
+1. Inspect the available repository, documentation, issue, design, and test context before
+   asking for technical facts that can be discovered locally.
+2. Do not infer product or business constraints from code. Business rules, compliance and
+   regulatory obligations, contractual SLAs, pricing, data-retention policy, prioritization,
+   and target users cannot be read from a repository. Treat them as unknown until the user
+   supplies them or an authoritative product artifact (PRD, contract, policy document) states
+   them. Record them as assumptions flagged for confirmation, never as discovered facts. The
+   repository tells you how the system behaves today, not what the business requires it to do.
+3. Ask only questions whose answers are required and cannot be safely inferred. Group short,
+   related questions when that saves unnecessary turns.
+4. Do not block implementation by default. When the user has asked to implement a sufficiently
+   clear change, record key assumptions and acceptance criteria briefly, then proceed or hand
+   them to the implementation workflow.
+5. Require explicit user confirmation before proceeding only when an unresolved decision could
+   create material security exposure, data loss, irreversible migration, contractual/API
+   breakage, meaningful cost, or destructive external action.
+6. Do not write an acceptance document into a repository, alter project files, create a branch,
+   commit, or invoke another skill unless the user requests it or the active repository
+   workflow explicitly requires it.
+7. Treat automated tests as evidence, not truth. Prefer automation when reliable and
+   proportionate; allow manual UX, accessibility, security, legal, or operational verification
+   where automation cannot establish the outcome.
+8. Never include real secrets, credentials, tokens, private keys, personal data, or sensitive
+   production payloads in acceptance criteria, fixtures, examples, or saved artifacts. Use
+   redacted or synthetic values.
+9. Do not run destructive tests, migrations, security probes, load tests, paid external calls,
+   or operations against production/live data without explicit authorization and an identified
+   safe environment.
+10. When an acceptance criterion cannot be satisfied due to an architectural, platform, or
+   external constraint discovered during implementation, do not silently drop or workaround it.
+   Update the affected criterion (mark it `[revised]`, state the constraint, and adjust scope or
+   verification method), increment the revision number, and re-present only the changed criteria
+   to the user before continuing. Require explicit confirmation only if the revision changes a
+   blocking decision or materially reduces safety or correctness guarantees.
+
+## Choose The Depth
+
+Use the smallest useful output.
+
+### Quick Capture
+
+Use for a clear but non-trivial change with low or moderate risk. Produce:
+
+- Goal
+- In scope / out of scope
+- Assumptions
+- 3-7 acceptance criteria with verification methods
+- Blocking questions, if any
+
+Do not delay implementation for approval unless a blocking risk from the operating rules
+exists or the user specifically asked for a specification first.
+
+### Full Acceptance Brief
+
+Use for ambiguous, cross-system, security-sensitive, data-changing, migration, compliance,
+or high-cost changes, or when the user requests a handoff artifact. Produce the full template
+below and request confirmation for unresolved blocking decisions before risky implementation.
+
+### Existing Specification Review
+
+When the user already supplied a PRD, issue, plan, or acceptance criteria:
+
+1. Review it instead of restarting discovery.
+2. Identify missing scope boundaries, unsafe assumptions, contradictions, and unverifiable
+   requirements.
+3. Return corrected or supplemental criteria.
+
+## Workflow
+
+### 1. Establish Goal And Risk
+
+Extract or ask for:
+
+- The observable outcome for the user or system.
+- The actors affected.
+- The main failure consequence.
+- Risk dimensions that actually apply: security/privacy, persistent data, compatibility/API,
+  migration, external dependencies, cost, concurrency, performance, usability/accessibility.
+
+Avoid asking generic questions about irrelevant risks.
+
+### 2. Discover Context
+
+When local or connected artifacts are available, inspect only what is needed:
+
+- Existing behavior and directly related files or interfaces.
+- Repository conventions, product docs, API contracts, data schemas, or migration history.
+- Existing verification infrastructure and realistic commands.
+- External dependencies and whether they are testable in isolation.
+
+Record discovered facts separately from user-provided assumptions. If context cannot be
+inspected, say what is unknown and ask focused questions.
+
+The repository reveals technical facts — how the system behaves today, its conventions, and
+its contracts. It does not reveal product or business constraints: business rules, compliance
+and regulatory obligations, contractual SLAs, pricing, data-retention policy, prioritization,
+and target users. Never reconstruct these from code or naming. Capture them only from the user
+or an authoritative product artifact, and list them as assumptions to confirm until then.
+
+### 3. Define Scope
+
+State:
+
+- Goal: one sentence describing the intended outcome.
+- In scope: behavior this change must deliver.
+- Out of scope: tempting adjacent work explicitly excluded.
+- Assumptions: claims not yet proven.
+- Blocking decisions: unresolved choices that materially affect safety or behavior.
+
+### 4. Write Acceptance Criteria
+
+Use `AC-001`, `AC-002`, and so on. Each criterion must describe observable behavior and an
+appropriate verification method; criteria and tests are not required to map one-to-one.
+
+For each applicable criterion include:
+
+- Scenario or starting condition.
+- Action or trigger.
+- Expected observable behavior.
+- Prohibited side effect when meaningful.
+- Verification method: automated test, integration check, manual UX review, accessibility
+  check, security review, operational check, or stakeholder acceptance.
+- Environment/safety constraint when verification could affect data, services, cost, or secrets.
+- Priority: required, important, or optional.
+
+Do not use words such as "correctly", "securely", "fast", "intuitive", or "robust" without
+defining observable evidence or recording them as a human-review judgment.
+
+### 5. Cover Only Relevant Boundaries
+
+Consider these categories, but include only categories that apply:
+
+| Category | Include when | Typical evidence |
+| --- | --- | --- |
+| Happy path | New or changed user-visible behavior | Successful workflow or state transition |
+| Validation | The change accepts input | Rejected malformed or boundary value without mutation |
+| Authorization/privacy | Data or actions have access boundaries | Denied access and no sensitive disclosure |
+| Persistence/migration | Stored data or schemas change | Backward read, migration, rollback or backup behavior |
+| Compatibility | Public APIs, files, events, or clients may break | Existing contract or fixture remains valid |
+| Failure recovery | Network, service, or asynchronous failure exists | No partial state or clear retry/degraded behavior |
+| Idempotency/concurrency | Repeats or simultaneous writes are plausible | No duplicate side effect or invalid final state |
+| Performance | A user or service threshold matters | Defined measurement conditions and threshold |
+| UX/accessibility | A person interacts with the result | Keyboard, feedback, error recovery, visual/manual review |
+
+### 6. Present And Continue
+
+- For a clarification/specification request, present the brief and ask for decisions only on
+  listed blockers.
+- For an implementation request with no blocker, present a compact criteria summary as part of
+  the work and continue with implementation.
+- For handoff to another agent or team, include enough context and verification detail for them
+  to act without inventing requirements.
+- Save the brief to a file only when requested. Use a repository-approved path when one exists;
+  otherwise ask for or state the chosen destination before writing.
+
+## Output Template
+
+Use this template for a Full Acceptance Brief. Omit irrelevant sections for Quick Capture.
+
+```markdown
+# Acceptance Brief: <Change Name>
+
+**Status:** Draft | Approved | Implemented | Verified
+**Revision:** <number>
+**Prepared for:** <user/team/agent, when known>
+**Approval required before risky work:** Yes | No - <reason>
+
+## Revision Log
+
+| Rev | Date | Changed criteria | Reason |
+| --- | --- | --- | --- |
+| 1 | <date> | — | Initial draft |
+
+## Goal
+
+<One observable outcome sentence.>
+
+## Scope
+
+**In scope**
+- <behavior included>
+
+**Out of scope**
+- <adjacent work excluded>
+
+## Context
+
+**Discovered facts** (technical, verified from repository or artifact)
+- <how the system behaves today, conventions, contracts>
+
+**Product/business constraints** (supplied by user or product artifact, never inferred from code)
+- <business rule, compliance/SLA obligation, retention policy, priority, target user — or "none supplied yet">
+
+**Assumptions**
+- <unverified claim to confirm or validate>
+
+**Dependencies and constraints**
+- <external service, local convention, compatibility obligation, environment limit>
+
+## Risk Review
+
+| Risk area | Applies? | Required handling |
+| --- | --- | --- |
+| Security/privacy | Yes/No | <redaction, authorization, review, etc.> |
+| Persistent data/migration | Yes/No | <compatibility, backup, rollback, etc.> |
+| External effects/cost | Yes/No | <sandbox/test environment/authorization> |
+| Compatibility/API | Yes/No | <contract to preserve or version> |
+| UX/accessibility | Yes/No | <manual or automated evidence> |
+
+## Acceptance Criteria
+
+### AC-001: <observable behavior>
+- **Scenario:** <starting condition>
+- **Action:** <single trigger>
+- **Expected:** <observable result>
+- **Must not:** <prohibited side effect, if applicable>
+- **Verification:** <method and intended evidence>
+- **Environment/safety:** <constraints, if applicable>
+- **Priority:** Required | Important | Optional
+
+## Blocking Decisions
+
+- [ ] <only decisions that prevent safe or correct progress>
+
+## Verification Plan
+
+| Criterion | Verification evidence | Status |
+| --- | --- | --- |
+| AC-001 | <test/check/review command or evidence type> | Pending |
+```
+
+## Pass/Fail Examples
+
+Use these to judge whether the skill actually produced a verifiable brief, not planning prose.
+
+**A failing acceptance criterion**
+
+```
+AC-001: The export works correctly and is secure.
+```
+
+Fails — "works correctly" and "secure" are not observable, there is no scenario, trigger,
+expected result, or verification method, and nothing states what must not happen. A reader
+cannot tell whether the implementation satisfied it.
+
+**A passing acceptance criterion**
+
+```
+AC-001: Export generates file with correct headers
+- Scenario: authenticated user, at least one data row visible
+- Action: click "Export CSV"
+- Expected: browser downloads file with columns [id, name, created_at]
+- Must not: expose internal fields or rows belonging to other users
+- Verification: automated integration test + manual schema spot-check
+- Priority: Required
+```
+
+Passes — a concrete observable outcome, a prohibited side effect, and a named verification
+method. Two people would agree on whether it was met.
+
+**A failing context entry**
+
+```
+Discovered facts: Users on the free tier are limited to 100 exports per month.
+```
+
+Fails — a per-tier limit is a business rule. It must not appear under discovered facts inferred
+from code; it belongs under Product/business constraints, supplied by the user, or be listed as
+an assumption to confirm.
+
+### Pass/Fail Rubric
+
+A brief passes only if every answer is "yes". Any "no" means revise before returning it.
+
+- [ ] Does every required criterion have a scenario, an observable expected result, and a named verification method?
+- [ ] Are all vague terms ("correctly", "secure", "fast", "robust") either replaced with observable evidence or marked as human judgment?
+- [ ] Are product/business constraints listed as supplied/assumed, with none silently inferred from code?
+- [ ] Is scope explicit, with out-of-scope items named?
+- [ ] Are blocking decisions limited to choices that actually affect safety or correctness, not preferences?
+
+## Quality Check
+
+Before returning the brief, check:
+
+- The goal describes an outcome rather than an implementation choice.
+- Scope boundaries and assumptions are explicit.
+- Every required criterion is observable or clearly marked for human judgment.
+- Security, privacy, data, compatibility, external-effect, and UX risks were considered only
+  where relevant and not silently ignored.
+- Verification methods identify safe environments for risky operations.
+- No secret or production-sensitive information was copied into the output.
+- No repository mutation or implementation block is imposed without justification or request.
+
+## Handoff
+
+When another planning or implementation workflow is available, pass the acceptance brief or
+criterion IDs to it. When no dedicated workflow exists, provide the brief directly as the
+implementation reference. Do not assume any named skill or tool is installed.

package/org-skills/internal-comms/LICENSE.txt

@@ -0,0 +1,202 @@
+
+                                 Apache License
+                           Version 2.0, January 2004
+                        http://www.apache.org/licenses/
+
+   TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
+
+   1. Definitions.
+
+      "License" shall mean the terms and conditions for use, reproduction,
+      and distribution as defined by Sections 1 through 9 of this document.
+
+      "Licensor" shall mean the copyright owner or entity authorized by
+      the copyright owner that is granting the License.
+
+      "Legal Entity" shall mean the union of the acting entity and all
+      other entities that control, are controlled by, or are under common
+      control with that entity. For the purposes of this definition,
+      "control" means (i) the power, direct or indirect, to cause the
+      direction or management of such entity, whether by contract or
+      otherwise, or (ii) ownership of fifty percent (50%) or more of the
+      outstanding shares, or (iii) beneficial ownership of such entity.
+
+      "You" (or "Your") shall mean an individual or Legal Entity
+      exercising permissions granted by this License.
+
+      "Source" form shall mean the preferred form for making modifications,
+      including but not limited to software source code, documentation
+      source, and configuration files.
+
+      "Object" form shall mean any form resulting from mechanical
+      transformation or translation of a Source form, including but
+      not limited to compiled object code, generated documentation,
+      and conversions to other media types.
+
+      "Work" shall mean the work of authorship, whether in Source or
+      Object form, made available under the License, as indicated by a
+      copyright notice that is included in or attached to the work
+      (an example is provided in the Appendix below).
+
+      "Derivative Works" shall mean any work, whether in Source or Object
+      form, that is based on (or derived from) the Work and for which the
+      editorial revisions, annotations, elaborations, or other modifications
+      represent, as a whole, an original work of authorship. For the purposes
+      of this License, Derivative Works shall not include works that remain
+      separable from, or merely link (or bind by name) to the interfaces of,
+      the Work and Derivative Works thereof.
+
+      "Contribution" shall mean any work of authorship, including
+      the original version of the Work and any modifications or additions
+      to that Work or Derivative Works thereof, that is intentionally
+      submitted to Licensor for inclusion in the Work by the copyright owner
+      or by an individual or Legal Entity authorized to submit on behalf of
+      the copyright owner. For the purposes of this definition, "submitted"
+      means any form of electronic, verbal, or written communication sent
+      to the Licensor or its representatives, including but not limited to
+      communication on electronic mailing lists, source code control systems,
+      and issue tracking systems that are managed by, or on behalf of, the
+      Licensor for the purpose of discussing and improving the Work, but
+      excluding communication that is conspicuously marked or otherwise
+      designated in writing by the copyright owner as "Not a Contribution."
+
+      "Contributor" shall mean Licensor and any individual or Legal Entity
+      on behalf of whom a Contribution has been received by Licensor and
+      subsequently incorporated within the Work.
+
+   2. Grant of Copyright License. Subject to the terms and conditions of
+      this License, each Contributor hereby grants to You a perpetual,
+      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+      copyright license to reproduce, prepare Derivative Works of,
+      publicly display, publicly perform, sublicense, and distribute the
+      Work and such Derivative Works in Source or Object form.
+
+   3. Grant of Patent License. Subject to the terms and conditions of
+      this License, each Contributor hereby grants to You a perpetual,
+      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+      (except as stated in this section) patent license to make, have made,
+      use, offer to sell, sell, import, and otherwise transfer the Work,
+      where such license applies only to those patent claims licensable
+      by such Contributor that are necessarily infringed by their
+      Contribution(s) alone or by combination of their Contribution(s)
+      with the Work to which such Contribution(s) was submitted. If You
+      institute patent litigation against any entity (including a
+      cross-claim or counterclaim in a lawsuit) alleging that the Work
+      or a Contribution incorporated within the Work constitutes direct
+      or contributory patent infringement, then any patent licenses
+      granted to You under this License for that Work shall terminate
+      as of the date such litigation is filed.
+
+   4. Redistribution. You may reproduce and distribute copies of the
+      Work or Derivative Works thereof in any medium, with or without
+      modifications, and in Source or Object form, provided that You
+      meet the following conditions:
+
+      (a) You must give any other recipients of the Work or
+          Derivative Works a copy of this License; and
+
+      (b) You must cause any modified files to carry prominent notices
+          stating that You changed the files; and
+
+      (c) You must retain, in the Source form of any Derivative Works
+          that You distribute, all copyright, patent, trademark, and
+          attribution notices from the Source form of the Work,
+          excluding those notices that do not pertain to any part of
+          the Derivative Works; and
+
+      (d) If the Work includes a "NOTICE" text file as part of its
+          distribution, then any Derivative Works that You distribute must
+          include a readable copy of the attribution notices contained
+          within such NOTICE file, excluding those notices that do not
+          pertain to any part of the Derivative Works, in at least one
+          of the following places: within a NOTICE text file distributed
+          as part of the Derivative Works; within the Source form or
+          documentation, if provided along with the Derivative Works; or,
+          within a display generated by the Derivative Works, if and
+          wherever such third-party notices normally appear. The contents
+          of the NOTICE file are for informational purposes only and
+          do not modify the License. You may add Your own attribution
+          notices within Derivative Works that You distribute, alongside
+          or as an addendum to the NOTICE text from the Work, provided
+          that such additional attribution notices cannot be construed
+          as modifying the License.
+
+      You may add Your own copyright statement to Your modifications and
+      may provide additional or different license terms and conditions
+      for use, reproduction, or distribution of Your modifications, or
+      for any such Derivative Works as a whole, provided Your use,
+      reproduction, and distribution of the Work otherwise complies with
+      the conditions stated in this License.
+
+   5. Submission of Contributions. Unless You explicitly state otherwise,
+      any Contribution intentionally submitted for inclusion in the Work
+      by You to the Licensor shall be under the terms and conditions of
+      this License, without any additional terms or conditions.
+      Notwithstanding the above, nothing herein shall supersede or modify
+      the terms of any separate license agreement you may have executed
+      with Licensor regarding such Contributions.
+
+   6. Trademarks. This License does not grant permission to use the trade
+      names, trademarks, service marks, or product names of the Licensor,
+      except as required for reasonable and customary use in describing the
+      origin of the Work and reproducing the content of the NOTICE file.
+
+   7. Disclaimer of Warranty. Unless required by applicable law or
+      agreed to in writing, Licensor provides the Work (and each
+      Contributor provides its Contributions) on an "AS IS" BASIS,
+      WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
+      implied, including, without limitation, any warranties or conditions
+      of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
+      PARTICULAR PURPOSE. You are solely responsible for determining the
+      appropriateness of using or redistributing the Work and assume any
+      risks associated with Your exercise of permissions under this License.
+
+   8. Limitation of Liability. In no event and under no legal theory,
+      whether in tort (including negligence), contract, or otherwise,
+      unless required by applicable law (such as deliberate and grossly
+      negligent acts) or agreed to in writing, shall any Contributor be
+      liable to You for damages, including any direct, indirect, special,
+      incidental, or consequential damages of any character arising as a
+      result of this License or out of the use or inability to use the
+      Work (including but not limited to damages for loss of goodwill,
+      work stoppage, computer failure or malfunction, or any and all
+      other commercial damages or losses), even if such Contributor
+      has been advised of the possibility of such damages.
+
+   9. Accepting Warranty or Additional Liability. While redistributing
+      the Work or Derivative Works thereof, You may choose to offer,
+      and charge a fee for, acceptance of support, warranty, indemnity,
+      or other liability obligations and/or rights consistent with this
+      License. However, in accepting such obligations, You may act only
+      on Your own behalf and on Your sole responsibility, not on behalf
+      of any other Contributor, and only if You agree to indemnify,
+      defend, and hold each Contributor harmless for any liability
+      incurred by, or claims asserted against, such Contributor by reason
+      of your accepting any such warranty or additional liability.
+
+   END OF TERMS AND CONDITIONS
+
+   APPENDIX: How to apply the Apache License to your work.
+
+      To apply the Apache License to your work, attach the following
+      boilerplate notice, with the fields enclosed by brackets "[]"
+      replaced with your own identifying information. (Don't include
+      the brackets!)  The text should be enclosed in the appropriate
+      comment syntax for the file format. We also recommend that a
+      file or class name and description of purpose be included on the
+      same "printed page" as the copyright notice for easier
+      identification within third-party archives.
+
+   Copyright 2026 Anthropic, PBC.
+
+   Licensed under the Apache License, Version 2.0 (the "License");
+   you may not use this file except in compliance with the License.
+   You may obtain a copy of the License at
+
+       http://www.apache.org/licenses/LICENSE-2.0
+
+   Unless required by applicable law or agreed to in writing, software
+   distributed under the License is distributed on an "AS IS" BASIS,
+   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+   See the License for the specific language governing permissions and
+   limitations under the License.

package/org-skills/internal-comms/SKILL.md

@@ -0,0 +1,36 @@
+---
+name: internal-comms
+description: "A set of resources to help write all kinds of internal communications, using the organization's preferred formats. Use this skill whenever asked to write some sort of internal communications (status reports, leadership updates, 3P updates, company newsletters, FAQs, incident reports, project updates, etc.)."
+tags: ["writing","operations","leadership"]
+tools: []
+license: Apache-2.0
+source: https://github.com/anthropics/skills
+source_path: "skills/internal-comms"
+source_commit: 34040c9c568585f6929bedeaad110ad08f079624
+---
+## When to use this skill
+To write internal communications, use this skill for:
+- 3P updates (Progress, Plans, Problems)
+- Company newsletters
+- FAQ responses
+- Status reports
+- Leadership updates
+- Project updates
+- Incident reports
+
+## How to use this skill
+
+To write any internal communication:
+
+1. **Identify the communication type** from the request
+2. **Load the appropriate guideline file** from the `examples/` directory:
+    - `examples/3p-updates.md` - For Progress/Plans/Problems team updates
+    - `examples/company-newsletter.md` - For company-wide newsletters
+    - `examples/faq-answers.md` - For answering frequently asked questions
+    - `examples/general-comms.md` - For anything else that doesn't explicitly match one of the above
+3. **Follow the specific instructions** in that file for formatting, tone, and content gathering
+
+If the communication type doesn't match any existing guideline, ask for clarification or more context about the desired format.
+
+## Keywords
+3P updates, company newsletter, company comms, weekly update, faqs, common questions, updates, internal comms

package/org-skills/internal-comms/examples/3p-updates.md

@@ -0,0 +1,47 @@
+## Instructions
+You are being asked to write a 3P update. 3P updates stand for "Progress, Plans, Problems." The main audience is for executives, leadership, other teammates, etc. They're meant to be very succinct and to-the-point: think something you can read in 30-60sec or less. They're also for people with some, but not a lot of context on what the team does.
+
+3Ps can cover a team of any size, ranging all the way up to the entire company. The bigger the team, the less granular the tasks should be. For example, "mobile team" might have "shipped feature" or "fixed bugs," whereas the company might have really meaty 3Ps, like "hired 20 new people" or "closed 10 new deals." 
+
+They represent the work of the team across a time period, almost always one week. They include three sections:
+1) Progress: what the team has accomplished over the next time period. Focus mainly on things shipped, milestones achieved, tasks created, etc.
+2) Plans: what the team plans to do over the next time period. Focus on what things are top-of-mind, really high priority, etc. for the team.
+3) Problems: anything that is slowing the team down. This could be things like too few people, bugs or blockers that are preventing the team from moving forward, some deal that fell through, etc.
+
+Before writing them, make sure that you know the team name. If it's not specified, you can ask explicitly what the team name you're writing for is.
+
+
+## Tools Available
+Whenever possible, try to pull from available sources to get the information you need:
+- Slack: posts from team members with their updates - ideally look for posts in large channels with lots of reactions
+- Google Drive: docs written from critical team members with lots of views
+- Email: emails with lots of responses of lots of content that seems relevant
+- Calendar: non-recurring meetings that have a lot of importance, like product reviews, etc.
+
+
+Try to gather as much context as you can, focusing on the things that covered the time period you're writing for:
+- Progress: anything between a week ago and today
+- Plans: anything from today to the next week
+- Problems: anything between a week ago and today
+
+
+If you don't have access, you can ask the user for things they want to cover. They might also include these things to you directly, in which case you're mostly just formatting for this particular format.
+
+## Workflow
+
+1. **Clarify scope**: Confirm the team name and time period (usually past week for Progress/Problems, next
+week for Plans)
+2. **Gather information**: Use available tools or ask the user directly
+3. **Draft the update**: Follow the strict formatting guidelines
+4. **Review**: Ensure it's concise (30-60 seconds to read) and data-driven
+
+## Formatting
+
+The format is always the same, very strict formatting. Never use any formatting other than this. Pick an emoji that is fun and captures the vibe of the team and update.
+
+[pick an emoji] [Team Name] (Dates Covered, usually a week)
+Progress: [1-3 sentences of content]
+Plans: [1-3 sentences of content]
+Problems: [1-3 sentences of content]
+
+Each section should be no more than 1-3 sentences: clear, to the point. It should be data-driven, and generally include metrics where possible. The tone should be very matter-of-fact, not super prose-heavy.