kotonoha 0.1.2 → 0.1.4

package/skills/tech-writer/references/doctypes/rfi.md

@@ -0,0 +1,43 @@
+# Request for information (RFI) type
+
+An RFI gathers market, vendor, product, feasibility, and indicative pricing
+information before requirements or procurement strategy are final. It must
+not read like an award decision or demand proposal-level effort.
+
+## Target reader
+
+Potential suppliers preparing an overview-level response, and the internal
+team using those responses to refine requirements and decide whether to
+proceed to an RFP.
+
+## Settle before writing
+
+- The unknowns the market research must resolve
+- The respondent population and distribution/confidentiality level
+- The current-environment details safe to disclose before an NDA
+- The response schedule and single source of truth for dates
+- The intended next step, while avoiding any promise to issue an RFP
+
+## Template
+
+Start from `assets/templates/rfi.md`.
+The template is the Japanese-language skeleton; translate its headings when
+the target document is English.
+
+## Recommended skeleton
+
+1. Purpose, non-procurement disclaimer, and current context
+2. Overview-level company, product, architecture, and security questions
+3. Indicative implementation, support, roadmap, and pricing information
+4. Response format, authoritative schedule, and handling conditions
+5. Respondent checklist
+
+## Checklist
+
+- [ ] Does the document state that responses are not scored or ranked?
+- [ ] Does it request overview-level information rather than detailed design?
+- [ ] Are indicative prices clearly non-binding?
+- [ ] Are roadmap, constraints, and unsupported capabilities reportable?
+- [ ] Is sensitive configuration moved to an NDA-controlled annex?
+- [ ] Is the schedule the single source of truth for dates?
+- [ ] Does the disclaimer avoid promising procurement or an RFP?

package/skills/tech-writer/references/doctypes/rfp.md

@@ -0,0 +1,46 @@
+# Request for proposal (RFP) type
+
+An RFP asks qualified suppliers for comparable, evaluable, and
+contract-ready proposals against explicit requirements, acceptance criteria,
+commercial terms, and a disclosed evaluation method.
+
+## Target reader
+
+Suppliers deciding whether and how to bid, evaluators scoring proposals, and
+procurement or legal reviewers preparing the resulting contract.
+
+## Settle before writing
+
+- Procurement scope, exclusions, budget model, and contract term
+- Must/Should/Could requirements and the consequence of failing a Must
+- Measurable acceptance criteria and payment milestones
+- Bidder eligibility, security, compliance, and subcontracting conditions
+- TCO period, price-scoring formula, category weights, and pass thresholds
+- The authoritative procurement schedule and confidentiality controls
+
+## Template
+
+Start from `assets/templates/rfp.md`.
+The template is the Japanese-language skeleton; translate its headings when
+the target document is English.
+
+## Recommended skeleton
+
+1. Procurement purpose, scope, exclusions, and current environment
+2. Functional, non-functional, security, migration, and support requirements
+3. Bidder eligibility, deliverables, acceptance, and payment
+4. Requested proposal contents, implementation schedule, and TCO pricing
+5. Evaluation formula, submission process, authoritative schedule, and terms
+6. Bidder submission checklist
+
+## Checklist
+
+- [ ] Can every functional and non-functional requirement be answered in a
+      structured, comparable format?
+- [ ] Are Must failures and bidder disqualification rules explicit?
+- [ ] Are deliverables linked to acceptance and payment conditions?
+- [ ] Are bidder eligibility and conflict/subcontractor disclosures covered?
+- [ ] Can all price rows be normalized into the stated TCO period?
+- [ ] Is the scoring formula reproducible by independent evaluators?
+- [ ] Is sensitive environment detail isolated in an NDA-controlled annex?
+- [ ] Is the schedule the single source of truth for all procurement dates?

package/skills/tech-writer/references/doctypes/security-design.md

@@ -0,0 +1,71 @@
+# Security design and threat model type
+
+A security design and threat model identifies protected assets, trust
+boundaries, threats, controls, verification, and residual risk. It turns
+security and compliance requirements into reviewable implementation and
+operational decisions.
+
+## Target reader
+
+Architects, developers, platform and security engineers, privacy and
+compliance reviewers, operators, and accountable risk acceptors.
+
+## Settle before writing
+
+- System scope, architecture, data flows, trust boundaries, and environments
+- Assets, owners, sensitivity, retention, and regulatory obligations
+- Identities, roles, administrative paths, and external dependencies
+- Threat-model method and risk-rating approach
+- Security testing, exception, and residual-risk acceptance authority
+- The approved requirements and system-design baselines
+
+## Responsibility boundary
+
+Document security decisions and trace threats to controls and tests. Do not
+include credentials, private keys, exploitable production details, or
+instructions that bypass controls. Vulnerability findings needing restricted
+handling belong in the repository's approved security-reporting channel.
+
+The security section in `system-design` is sufficient for an integrated
+architecture summary. Use a standalone `security-design` when threat
+modeling, control ownership, compliance evidence, exceptions, or risk
+acceptance needs independent review. When both exist, the security design is
+authoritative for threats, controls, and residual risk.
+
+This document owns security-test intent by tracing requirements and threats
+to controls and planned tests, including the expected environment class and
+required evidence type. The `test-plan` owns actual execution environments,
+schedule, release gates, results, and evidence storage; copy the security
+test IDs, threat IDs, and control IDs into its traceability table.
+
+## Template
+
+Start from `assets/templates/security-design.md`.
+The template is the Japanese-language skeleton; translate its headings when
+the target document is English.
+
+## Recommended skeleton
+
+1. Scope, requirements, assets, data classification, and architecture
+2. Trust boundaries, identity, authentication, authorization, and threats
+3. Preventive, detective, and responsive controls with ownership
+4. Data, secret, API, audit, vulnerability, and supply-chain protection
+5. Security testing, incident response, residual risk, traceability, and approval
+
+## Checklist
+
+- [ ] Are system scope, assets, owners, data flows, and trust boundaries clear?
+- [ ] Are identities, authentication, authorization, privilege, session, and
+      recovery paths covered?
+- [ ] Does each credible threat identify affected assets, impact, likelihood,
+      controls, owner, and test?
+- [ ] Are encryption, key and secret lifecycle, retention, deletion, masking,
+      logging, and audit addressed?
+- [ ] Are input, output, API abuse, availability, dependency, build, artifact,
+      and supply-chain risks covered?
+- [ ] Are security tests, incident response, evidence preservation, and
+      notification responsibilities defined?
+- [ ] Is every exception time-bound, owned, compensated, and accepted by an
+      accountable risk owner?
+- [ ] Can requirements, assets, threats, controls, tests, and implementation
+      locations be traced end to end?

package/skills/tech-writer/references/doctypes/system-design.md

@@ -0,0 +1,74 @@
+# System design type
+
+A system design explains how approved requirements will be realized through
+architecture, components, data, interfaces, deployment, security, quality
+controls, and operations. It must be detailed enough for implementation,
+testing, operation, and review without duplicating source code.
+
+## Target reader
+
+Architects, developers, testers, operators, security reviewers, and technical
+approvers who must verify that the design satisfies the requirements and can
+be built and operated safely.
+
+## Settle before writing
+
+- The approved requirements baseline and stable requirement IDs
+- The system boundary, design scope, environments, and external dependencies
+- The most important quality attributes and their measurable targets
+- Constraints on technology, deployment, security, compliance, cost, and time
+- The level of design detail needed for implementation and review
+- The owner of unresolved design decisions
+
+## Responsibility boundary
+
+Describe implementation choices and trace them to requirements. Do not
+silently redefine scope or acceptance criteria from the requirements
+definition. If the design exposes a missing, conflicting, or infeasible
+requirement, record it as an open issue and update the approved requirements
+through change control.
+
+Use `design-doc` or an ADR for one isolated decision and its alternatives.
+Use `system-design` when the reader needs the integrated design across
+components, data, interfaces, deployment, quality attributes, and operations.
+Its test, operation, migration, and security sections summarize the design
+decisions needed to understand the whole system. Split out a `test-plan`,
+`operations-runbook`, `migration-plan`, or `security-design` when that topic
+needs executable procedures, independent evidence, a different approval
+authority, or a separate lifecycle. When a standalone document exists, it is
+the source of truth for that topic; the system design links to and summarizes
+it instead of duplicating details.
+
+## Template
+
+Start from `assets/templates/system-design.md`.
+The template is the Japanese-language skeleton; translate its headings when
+the target document is English.
+
+## Recommended skeleton
+
+1. Agreement target, scope, assumptions, constraints, and design drivers
+2. Context, container, component, and processing-flow design
+3. Data, transaction, interface, and error-contract design
+4. Security, performance, capacity, availability, and reliability design
+5. Deployment, network, observability, operation, backup, and recovery
+6. Migration, release, rollback, test traceability, trade-offs, and approval
+
+## Checklist
+
+- [ ] Is the design boundary clear, and is the approved requirements
+      baseline identified?
+- [ ] Are major components assigned cohesive responsibilities with explicit
+      dependencies and interfaces?
+- [ ] Are data ownership, schemas, integrity, transactions, retention, and
+      deletion addressed?
+- [ ] Are authentication, authorization, encryption, audit, secrets, and
+      threat controls concrete and testable?
+- [ ] Are performance, capacity, availability, timeout, retry, idempotency,
+      backup, RTO, and RPO decisions quantified?
+- [ ] Are deployment, network boundaries, configuration, observability,
+      release, operation, and incident handling implementable?
+- [ ] Are migration, compatibility, rollback, and failure recovery covered?
+- [ ] Is every major design element traced to requirements and tests?
+- [ ] Are rejected alternatives, accepted trade-offs, risks, open decisions,
+      reviewers, and change history recorded?

package/skills/tech-writer/references/doctypes/technical-proposal.md

@@ -0,0 +1,49 @@
+# Technical proposal type
+
+A technical proposal asks decision-makers to approve a technical approach,
+budget, and delivery plan. It is broader than an ADR: it must connect the
+architecture to measurable outcomes, implementation cost, risks, and a
+recorded decision.
+
+This doctype is for an internal approval proposal. For a supplier's
+technical bid in response to an RFP, structure the response against the
+RFP's requirement IDs, requested proposal contents, pricing, and contract
+deviations instead of using this template.
+
+## Target reader
+
+The person or group accountable for approving the investment, accepting the
+trade-offs, and assigning implementation ownership.
+
+## Settle before writing
+
+- The exact decision or approval being requested
+- The current problem and measurable target outcome
+- Budget, deadline, security, compliance, and staffing constraints
+- At least one alternative, including the current-state baseline
+- The evaluation period used for total cost of ownership
+
+## Template
+
+Start from `assets/templates/technical-proposal.md`.
+The template is the Japanese-language skeleton; translate its headings when
+the target document is English.
+
+## Recommended skeleton
+
+1. Decision requested and executive summary
+2. Background, measurable goals, and non-goals
+3. Proposed architecture, data, and security
+4. Delivery, rollout, rollback, cost, and staffing
+5. Alternatives using shared cost, time, effort, and risk axes
+6. Risks, success metrics, unresolved questions, and decision record
+
+## Checklist
+
+- [ ] Is the requested decision stated before the implementation detail?
+- [ ] Are goals measurable, with an action if a target is missed?
+- [ ] Are non-goals, assumptions, and constraints explicit?
+- [ ] Does the comparison include a current-state baseline and shared axes?
+- [ ] Are initial cost, annual recurring cost, and TCO period comparable?
+- [ ] Are rollout, rollback, security, risks, and ownership covered?
+- [ ] Can the final approver, date, and decision be recorded in the document?

package/skills/tech-writer/references/doctypes/test-plan.md

@@ -0,0 +1,67 @@
+# Test plan type
+
+A test plan defines how requirements and quality risks will be verified,
+which environments and data are needed, and what evidence permits a release
+or acceptance decision. It covers planning and traceability rather than
+replacing executable test code.
+
+## Target reader
+
+Test leads, developers, product owners, business acceptance testers,
+operators, security reviewers, and release approvers.
+
+## Settle before writing
+
+- The approved requirements and design baselines
+- The approved security-design baseline and security test IDs, when present
+- In-scope systems, environments, platforms, and quality attributes
+- The highest-impact quality risks and required test levels
+- Measurable entry, exit, and release criteria
+- Environment, data, tooling, staffing, and schedule constraints
+- Defect severity definitions and residual-risk approval authority
+
+## Responsibility boundary
+
+Define the verification strategy, cases, criteria, ownership, and evidence.
+Keep detailed automation implementation in test code. A test plan must not
+weaken an approved acceptance criterion; record conflicts as open issues and
+resolve them through requirement change control.
+
+The test section in `system-design` is sufficient while verification remains
+an integrated design summary. Use a standalone `test-plan` when execution
+needs its own environments, schedule, evidence, release gates, or approvers.
+When both exist, the test plan is authoritative for test execution and
+release evidence, while the system design retains the architectural rationale.
+When a `security-design` exists, import its security test, threat, and control
+IDs. Preserve `SEC-TC-*` as the planned security-test identity and map it to
+the executable `TC-*` case that produces release evidence.
+
+## Template
+
+Start from `assets/templates/test-plan.md`.
+The template is the Japanese-language skeleton; translate its headings when
+the target document is English.
+
+## Recommended skeleton
+
+1. Agreement target, baselines, scope, quality goals, and risks
+2. Test levels, non-functional testing, environment, and data
+3. Entry, exit, release, and residual-risk criteria
+4. Requirement-to-test traceability and defect management
+5. Schedule, ownership, evidence, risks, and approval
+
+## Checklist
+
+- [ ] Are the requirement and design baselines uniquely identified?
+- [ ] Are scope, exclusions, environments, platforms, data, and production
+      differences explicit?
+- [ ] Does the strategy prioritize tests using concrete quality risks?
+- [ ] Are functional and non-functional criteria measurable?
+- [ ] Can every Must requirement and acceptance condition be traced to tests?
+- [ ] Can every applicable security test, threat, and control be traced from
+      the security design to an executable case and its evidence?
+- [ ] Are entry, exit, defect, release, and residual-risk criteria objective?
+- [ ] Are suspension and resumption conditions defined for blocked or invalid
+      test cycles?
+- [ ] Are evidence storage, ownership, schedule, and approval defined?
+- [ ] Are test-data privacy, cleanup, and environment reset covered?

package/skills/tech-writer/references/style-constitution.md

@@ -8,12 +8,13 @@ Sentence-level naturalness, vocabulary, and rhythm are out of scope here
 
 These 8 rules assume a **living, multi-section reference document** —
 README, design doc/ADR, API reference, release notes/CHANGELOG file as a
-whole, user manual, Zenn/Qiita article. Apply all 8 rules to those
-doctypes. For Zenn/Qiita specifically, rule 1's "title" lives in YAML
-frontmatter rather than an in-body '#' heading — see their doctype
-reference files for the platform-specific frontmatter fields — but every
-other rule (heading hierarchy starting at '##', code examples, disclosed
-limitations, etc.) still applies verbatim.
+whole, user manual, technical proposal, RFI/RFP (including a supplier's RFP
+response), or Zenn/Qiita article. Apply all 8 rules to those doctypes. For
+Zenn/Qiita specifically, rule 1's "title" lives in YAML frontmatter rather
+than an in-body '#' heading — see their doctype reference files for the
+platform-specific frontmatter fields — but every other rule (heading
+hierarchy starting at '##', code examples, disclosed limitations, etc.)
+still applies verbatim.
 
 **Atomic, single-purpose artifacts** — commit messages, PR descriptions,
 issue reports, code comments/docstrings, and a single new entry appended